Re: Using SHA256 for authentication
On Tue, Sep 19, 2023 at 07:19:27PM +0000, Burns Fisher (AMSAT) via pacsat-dev wrote:
Hi Chris,
Just a thought or two:
First, the replay attack code is initially turned off. If you turn it on with a command, and it does not hear another command for n minutes/hours (I don't remember) it turns it back off. Once it hears a command for the first time after replay prevention is turned on, then it stays on until/unless it gets that special command to turn it off.
This is, well, a little weird to me.
One thing that a serial number does not prevent is a replay attack that happens after the ground station sends a command that was not received by the s/c. Suppose we wanted to turn on some device like a camera over a certain area. Send the command as the s/c approaches the area, but for whatever reason the s/c does not receive it (but the bad guy does). The bad guy then sends the command later...maybe he even sends the info to a conspirator around the world and that person sends it. I think with just a serial number the s/c would still respond to it if there had been no command in between. Depending on the exact command it may cause no problem, but that is what the "no later than 300 seconds after the s/c time" is for.
This is true. I've never had to deal with a situation like this, so maybe that's where the weirdness comes from.
It also seems to me that relying on s/c time is not a robust solution. I don't know how robust ground information about that time is valid, but a protocol that didn't rely on that would be better, I think.
I'm not saying reset/seconds is the only way...just mentioning a few things that we do to make it easier: AmCom keeps track of the spacecraft time (if the s/c does not reset, and then has to wait till we determine time 0 (the UTC that corresponds to the start of the new reset epoch). If the s/c is unresponsive, I think I'd send "turn off replay protection" in the blind and go from there. (Note: Fox-1E and HuskySat has/had this capability, but we never turned it on!)
Would not the "turn off replay protection" be subject to the same issue?
Thinking this through a little, the way I would design this would be to allow single commands for things where this isn't important.
For things where an attacker could cause issues with a intercept and delay tactic, have a two-command operation. The first command says "turn on the camera". The spacecraft then returns some sort of indicator that the command is pending. After receiving the indicator, the second command is sent to commit the operation. If the commit is not received after a short period of time, the command is discarded.
The problem is that the operation is now more likely to fail from a missed command. Oh, and the attacker could spoof the indicator from the s/c, so you would have to have something in that indicator (like using sha256) to prevent that.
I'm pretty sure (but I don't have a formal proof, just gut feel from stuff I worked on) that you cannot design a reasonable protocol without some sort of shared state (time on the s/c) or some sort of indication from the s/c.
-corey - AE5KM
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Tue, Sep 19, 2023 at 1:58 PM Chris Thompson via pacsat-dev < pacsat-dev@amsat.org> wrote:
Corey, I was delayed by another bug but managed to look at this today. It looks very good.
I can calculate the same hash value with the default key using the Java Mac class and the HmacSHA256 algorithm. So that is great. It uses the public algorithm.
I did notice that the default key in the code you implemented is 28 bytes and not 32 bytes as you stated in an earlier email. Is that correct? It works with the 28 byte key.
One other thing. The existing code prevents a replay attack by sending the reset/uptime on the spacecraft in the command. We have to send the same reset and an uptime that is the same or no more than 300 seconds after the actual uptime on the spacecraft. I think this could cause issues with an unresponsive spacecraft where we don't know the time onboard. I'm sure that is why there is a special command that goes around the requirement and turns it off.
I would instead propose we send a serial number in the command, with no other meaning. Any command can only be used once and we store the highest serial number used so far. The serial number would be in the hash of the command of course. To make it easy to sync the serial numbers across different command stations I propose that the serial number be unix time in UTC, or the time based on a later epoch if we want something with less than 32 bits. It will just be treated as a serial number that is checked for duplicates when received at the spacecraft. Specifically all commands must have a serial number greater than the largest one received so far.
Maybe that is not secure enough. Let me know.
73 Chris
On Sat, Sep 16, 2023 at 6:56 PM Chris Thompson via pacsat-dev < pacsat-dev@amsat.org> wrote:
Sounds very good. I will try to have a look at it tomorrow or Monday.
73 Chris
On Sat, Sept 16, 2023, 15:53 Corey Minyard minyard@acm.org wrote:
On Sat, Sep 16, 2023 at 1:58 PM Chris Thompson via pacsat-dev pacsat-dev@amsat.org wrote:
Just for reference, the sha.c algorithm did match what I get from Java
with the standard sha-256 digest. So it does work for the 18 bytes of our commands. But it sounds like it will not work if we append the secret key twice.
Yes, my impetus for replacing it, plus the new algorithm allows partial adds of data to make the process easier.
I have pushed up an update-sha-hmac branch that reworks all the keying. It uses the hmac-sha256 algorithm for authentication, it adds the code to load the key from NVRAM, and reworks the keysize to be 32 bytes. Reworking the key size will rearrange NVRAM, unfortunately. With this, you should be able to add a key from the command line and have it write it to NVRAM, and use it for the hmac-sha256 authentication. It does remove the AES code.
-corey - AE5KM
73 Chris
On Sat, Sept 16, 2023, 12:49 Corey Minyard via pacsat-dev <
pacsat-dev@amsat.org> wrote:
I just pulled Authenticate/src/sha.c out of the code and moved it into a separate file and played with it a bit. It wasn't matching the results from sha256sum, and looking at the code, I realized that the implementation only accepts up to 64 bytes of data. It works for buffers less than 64 bytes. It also won't do partial pieces, which would make the implementation of HMAC easier.
I'm going to recommend we adapt https://github.com/h5p9sl/hmac_sha256 to our needs. I'll work on that a bit.
Also, I couldn't find any evidence of any cryptanalysis of encrypting the sha256 output with AES. Sometimes those things work, sometimes you get surprising results. Since the HMAC approach is well known and heavily analyzed, that would seem a better approach.
-corey - AE5KM
On Fri, Sep 15, 2023 at 1:21 PM Chris Thompson via pacsat-dev pacsat-dev@amsat.org wrote: > > I did not implement it yet. It would go in Command task.c and
replace or perhaps duplicate the authenticate function.
> > Feel free to code it. > > I don't know if we will ultimately go this way. I would still like
to make the AES authentication work but I agree this could be simpler and faster. So it would be good to test it.
> > Chris > > On Fri, Sept 15, 2023, 11:20 Corey Minyard minyard@acm.org wrote: >> >> On Fri, Sep 15, 2023 at 10:06 AM Chris Thompson via pacsat-dev >> pacsat-dev@amsat.org wrote: >> > >> > Ok, thanks for that Corey. Very interesting. We may not be
susceptible to the length extension attack vulnerability though. If I understand correctly, then a message sent as: Hash( key + "Watch the enemy") could be manipulated to Hash(key + "Watch the enemy and attack them after 5 mins"), without knowing the key. But our commands are fixed at 18 bytes length (for now at least). So any extra appended message would be ignored. With that said, it may not be much harder to implement the scheme as described.
>> >> Yes, I was more worried about the "various security papers have >> suggested vulnerabilities with this approach" comment in the
article
>> on the key || message || key approach. It probably means there are >> other issues with the approach, possibly key extraction attacks.
The
>> HMAC approach seems generally more cryptographically sound. >> >> I was going to say that I could implement it, though it's pretty >> trivial. You've probably already done it :). >> >> -corey - AE5KM > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev@amsat.org > View archives of this mailing list at
https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
> To unsubscribe send an email to pacsat-dev-leave@amsat.org > Manage all of your AMSAT-NA mailing list preferences at
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at
https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at
https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
See below.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Tue, Sep 19, 2023 at 4:59 PM Corey Minyard minyard@acm.org wrote:
On Tue, Sep 19, 2023 at 07:19:27PM +0000, Burns Fisher (AMSAT) via pacsat-dev wrote:
Hi Chris,
Just a thought or two:
First, the replay attack code is initially turned off. If you turn it on with a command, and it does not hear another command for n minutes/hours
(I
don't remember) it turns it back off. Once it hears a command for the first time after replay prevention is turned on, then it stays on until/unless it gets that special command to turn it off.
This is, well, a little weird to me.
???
One thing that a serial number does not prevent is a replay attack that happens after the ground station sends a command that was not received by the s/c. Suppose we wanted to turn on some device like a camera over a certain area. Send the command as the s/c approaches the area, but for whatever reason the s/c does not receive it (but the bad guy does). The bad guy then sends the command later...maybe he even sends the info to a conspirator around the world and that person sends it. I think with
just a
serial number the s/c would still respond to it if there had been no command in between. Depending on the exact command it may cause no problem, but that is what the "no later than 300 seconds after the s/c time" is for.
This is true. I've never had to deal with a situation like this, so maybe that's where the weirdness comes from.
It also seems to me that relying on s/c time is not a robust solution. I don't know how robust ground information about that time is valid, but a protocol that didn't rely on that would be better, I think.
Every telemetry frame downlink includes the spacecraft time. 300 seconds gives plenty of slack. And as I said AmCom can do this more-or-less automatically.
I'm not saying reset/seconds is the only way...just mentioning a few
things
that we do to make it easier: AmCom keeps track of the spacecraft time
(if
the s/c does not reset, and then has to wait till we determine time 0
(the
UTC that corresponds to the start of the new reset epoch). If the s/c is unresponsive, I think I'd send "turn off replay protection" in the blind and go from there. (Note: Fox-1E and HuskySat has/had this capability,
but
we never turned it on!)
Would not the "turn off replay protection" be subject to the same issue?
I believe that Chris said earlier that this particular command does not require the time. But it is also (hopefully) never used so one could not easily record it. I don't really like this, but after/If we get confidence in this replay protection, it could be removed. As I said, it has been on a few s/c, but never actually used.
Thinking this through a little, the way I would design this would be to allow single commands for things where this isn't important.
For things where an attacker could cause issues with a intercept and delay tactic, have a two-command operation. The first command says "turn on the camera". The spacecraft then returns some sort of indicator that the command is pending. After receiving the indicator, the second command is sent to commit the operation. If the commit is not received after a short period of time, the command is discarded.
The problem is that the operation is now more likely to fail from a missed command. Oh, and the attacker could spoof the indicator from the s/c, so you would have to have something in that indicator (like using sha256) to prevent that.
I'm pretty sure (but I don't have a formal proof, just gut feel from stuff I worked on) that you cannot design a reasonable protocol without some sort of shared state (time on the s/c) or some sort of indication from the s/c.
-corey - AE5KM
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Tue, Sep 19, 2023 at 1:58 PM Chris Thompson via pacsat-dev < pacsat-dev@amsat.org> wrote:
Corey, I was delayed by another bug but managed to look at this
today. It
looks very good.
I can calculate the same hash value with the default key using the Java Mac class and the HmacSHA256 algorithm. So that is great. It uses the public algorithm.
I did notice that the default key in the code you implemented is 28
bytes
and not 32 bytes as you stated in an earlier email. Is that correct?
It
works with the 28 byte key.
One other thing. The existing code prevents a replay attack by sending the reset/uptime on the spacecraft in the command. We have to send the same reset and an uptime that is the same or no more than 300 seconds
after
the actual uptime on the spacecraft. I think this could cause issues
with
an unresponsive spacecraft where we don't know the time onboard. I'm
sure
that is why there is a special command that goes around the
requirement and
turns it off.
I would instead propose we send a serial number in the command, with no other meaning. Any command can only be used once and we store the
highest
serial number used so far. The serial number would be in the hash of
the
command of course. To make it easy to sync the serial numbers across different command stations I propose that the serial number be unix
time in
UTC, or the time based on a later epoch if we want something with less
than
32 bits. It will just be treated as a serial number that is checked
for
duplicates when received at the spacecraft. Specifically all commands
must
have a serial number greater than the largest one received so far.
Maybe that is not secure enough. Let me know.
73 Chris
On Sat, Sep 16, 2023 at 6:56 PM Chris Thompson via pacsat-dev < pacsat-dev@amsat.org> wrote:
Sounds very good. I will try to have a look at it tomorrow or Monday.
73 Chris
On Sat, Sept 16, 2023, 15:53 Corey Minyard minyard@acm.org wrote:
On Sat, Sep 16, 2023 at 1:58 PM Chris Thompson via pacsat-dev pacsat-dev@amsat.org wrote:
Just for reference, the sha.c algorithm did match what I get from
Java
with the standard sha-256 digest. So it does work for the 18 bytes
of our
commands. But it sounds like it will not work if we append the
secret key
twice.
Yes, my impetus for replacing it, plus the new algorithm allows partial adds of data to make the process easier.
I have pushed up an update-sha-hmac branch that reworks all the keying. It uses the hmac-sha256 algorithm for authentication, it
adds
the code to load the key from NVRAM, and reworks the keysize to be 32 bytes. Reworking the key size will rearrange NVRAM, unfortunately. With this, you should be able to add a key from the command line and have it write it to NVRAM, and use it for the hmac-sha256 authentication. It does remove the AES code.
-corey - AE5KM
73 Chris
On Sat, Sept 16, 2023, 12:49 Corey Minyard via pacsat-dev <
pacsat-dev@amsat.org> wrote:
> > I just pulled Authenticate/src/sha.c out of the code and moved it
into
> a separate file and played with it a bit. It wasn't matching the > results from sha256sum, and looking at the code, I realized that
the
> implementation only accepts up to 64 bytes of data. It works for > buffers less than 64 bytes. It also won't do partial pieces,
which
> would make the implementation of HMAC easier. > > I'm going to recommend we adapt
https://github.com/h5p9sl/hmac_sha256
> to our needs. I'll work on that a bit. > > Also, I couldn't find any evidence of any cryptanalysis of
encrypting
> the sha256 output with AES. Sometimes those things work,
sometimes
> you get surprising results. Since the HMAC approach is well known
and
> heavily analyzed, that would seem a better approach. > > -corey - AE5KM > > On Fri, Sep 15, 2023 at 1:21 PM Chris Thompson via pacsat-dev > pacsat-dev@amsat.org wrote: > > > > I did not implement it yet. It would go in Command task.c and
replace or perhaps duplicate the authenticate function.
> > > > Feel free to code it. > > > > I don't know if we will ultimately go this way. I would still
like
to make the AES authentication work but I agree this could be
simpler and
faster. So it would be good to test it.
> > > > Chris > > > > On Fri, Sept 15, 2023, 11:20 Corey Minyard minyard@acm.org
wrote:
> >> > >> On Fri, Sep 15, 2023 at 10:06 AM Chris Thompson via pacsat-dev > >> pacsat-dev@amsat.org wrote: > >> > > >> > Ok, thanks for that Corey. Very interesting. We may not be
susceptible to the length extension attack vulnerability though. If
I
understand correctly, then a message sent as: Hash( key + "Watch the enemy") could be manipulated to Hash(key + "Watch the enemy and
attack them
after 5 mins"), without knowing the key. But our commands are fixed
at 18
bytes length (for now at least). So any extra appended message would
be
ignored. With that said, it may not be much harder to implement the
scheme
as described.
> >> > >> Yes, I was more worried about the "various security papers have > >> suggested vulnerabilities with this approach" comment in the
article
> >> on the key || message || key approach. It probably means
there are
> >> other issues with the approach, possibly key extraction
attacks.
The
> >> HMAC approach seems generally more cryptographically sound. > >> > >> I was going to say that I could implement it, though it's
pretty
> >> trivial. You've probably already done it :). > >> > >> -corey - AE5KM > > > > > > ----------------------------------------------------------- > > > > pacsat-dev mailing list -- pacsat-dev@amsat.org > > View archives of this mailing list at
https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
> > To unsubscribe send an email to pacsat-dev-leave@amsat.org > > Manage all of your AMSAT-NA mailing list preferences at
> > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev@amsat.org > View archives of this mailing list at
https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
> To unsubscribe send an email to pacsat-dev-leave@amsat.org > Manage all of your AMSAT-NA mailing list preferences at
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at
https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
-- Chris E. Thompson chrisethompson@gmail.com g0kla@arrl.net
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at
https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
participants (2)
-
Burns Fisher (AMSAT) -
Corey Minyard