- pacsat-dev - mailman.amsat.org

Re: Bug in the code
by Bob Stricklin 18 Sep '23

18 Sep '23

Wow! That bug was insidious. What if a six character call sign adds /R? Longer and a special character. Bob On Sep 18, 2023, at 9:12 AM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: Good catch! 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, Sep 18, 2023 at 10:09 AM Chris Thompson via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I found a serious flaw in the upload code. I documented it in github but will paste the description below: https://github.com/AMSAT-NA/PacSatSW/issues/24 If the user of the ground station has a 6 digit (or longer) callsign and they upload a file then the PACSAT header is corrupted. Specifically the length byte of the upload_time field (number 0x12) is corrupted and likely all the bytes of the header from that point are wrong. The header is added successfully to the directory and can be downloaded. When the header is re-downloaded the ground station throws the header away as corrupted but then keeps requesting the "hole" in the directory. If the IHU is reset then the header is found to be corrupt and is not re-loaded into the directory, but the directory at the ground station still has a hole and it does not resolve itself by requesting the hole from the spacecraft. There are no files in that date range to close the hole. The bug appears to be in the spacecraft because the uploaded file saved at the ground station appears to have the correct header. The bug is likely because the upload_time field is updated at a fixed offset but we have a different length callsign. In fact the sender is in field (0x10) and can be up to 30 chars. Oops! All the other fields that are updated in place are in the fixed length initial header bytes. But not this one. It was later made mandatory and never moved into the mandatory header by the protocol designers. There is also a second bug here. When the sat is rebooted and the corrupt file is rejected, then the ground station should be able to close its hole. It should request the directory and get an updated header for the header before the corrupted file, with the new and old dates that close out the hole. That requires the upload_time on the adjacent header to be changed otherwise it won't be broadcast. We already update at boot the new and old dates. We would have to see that there is a corrupt file and then update the upload_time on the adjacent header. There is also a third bug here. When the header was updated with the upload_time we did not see that it was corrupted. We do run a check on uploaded file headers but apparently that runs before we update the upload_time. If it had run after the upload_time was updated then it would have rejected the header and the directory would not have been corrupted. -- Chris E. Thompson chrisethompson(a)gmail.com<mailto:chrisethompson@gmail.com> g0kla(a)arrl.net<mailto:g0kla@arrl.net> ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto: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(a)amsat.org<mailto: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(a)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(a)amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: Bug in the code
by Burns Fisher (AMSAT) 18 Sep '23

18 Sep '23

Good catch! 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, Sep 18, 2023 at 10:09 AM Chris Thompson via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I found a serious flaw in the upload code. I documented it in github but > will paste the description below: > https://github.com/AMSAT-NA/PacSatSW/issues/24 > > If the user of the ground station has a 6 digit (or longer) callsign and >> they upload a file then the PACSAT header is corrupted. Specifically the >> length byte of the upload_time field (number 0x12) is corrupted and likely >> all the bytes of the header from that point are wrong. The header is added >> successfully to the directory and can be downloaded. When the header is >> re-downloaded the ground station throws the header away as corrupted but >> then keeps requesting the "hole" in the directory. >> > > >> If the IHU is reset then the header is found to be corrupt and is not >> re-loaded into the directory, but the directory at the ground station still >> has a hole and it does not resolve itself by requesting the hole from the >> spacecraft. There are no files in that date range to close the hole. >> > > >> The bug appears to be in the spacecraft because the uploaded file saved >> at the ground station appears to have the correct header. The bug is likely >> because the upload_time field is updated at a fixed offset but we have a >> different length callsign. In fact the sender is in field (0x10) and can be >> up to 30 chars. Oops! All the other fields that are updated in place are >> in the fixed length initial header bytes. But not this one. It was later >> made mandatory and never moved into the mandatory header by the protocol >> designers. >> > > >> There is also a second bug here. When the sat is rebooted and the corrupt >> file is rejected, then the ground station should be able to close its hole. >> It should request the directory and get an updated header for the header >> before the corrupted file, with the new and old dates that close out the >> hole. That requires the upload_time on the adjacent header to be changed >> otherwise it won't be broadcast. We already update at boot the new and old >> dates. We would have to see that there is a corrupt file and then update >> the upload_time on the adjacent header. >> > > >> There is also a third bug here. When the header was updated with the >> upload_time we did not see that it was corrupted. We do run a check on >> uploaded file headers but apparently that runs before we update the >> upload_time. If it had run after the upload_time was updated then it would >> have rejected the header and the directory would not have been corrupted. > > > -- > Chris E. Thompson > chrisethompson(a)gmail.com > g0kla(a)arrl.net > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)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(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Bug in the code
by Chris Thompson 18 Sep '23

18 Sep '23

> > I found a serious flaw in the upload code. I documented it in github but will paste the description below: https://github.com/AMSAT-NA/PacSatSW/issues/24 If the user of the ground station has a 6 digit (or longer) callsign and > they upload a file then the PACSAT header is corrupted. Specifically the > length byte of the upload_time field (number 0x12) is corrupted and likely > all the bytes of the header from that point are wrong. The header is added > successfully to the directory and can be downloaded. When the header is > re-downloaded the ground station throws the header away as corrupted but > then keeps requesting the "hole" in the directory. > > If the IHU is reset then the header is found to be corrupt and is not > re-loaded into the directory, but the directory at the ground station still > has a hole and it does not resolve itself by requesting the hole from the > spacecraft. There are no files in that date range to close the hole. > > The bug appears to be in the spacecraft because the uploaded file saved at > the ground station appears to have the correct header. The bug is likely > because the upload_time field is updated at a fixed offset but we have a > different length callsign. In fact the sender is in field (0x10) and can be > up to 30 chars. Oops! All the other fields that are updated in place are > in the fixed length initial header bytes. But not this one. It was later > made mandatory and never moved into the mandatory header by the protocol > designers. > > There is also a second bug here. When the sat is rebooted and the corrupt > file is rejected, then the ground station should be able to close its hole. > It should request the directory and get an updated header for the header > before the corrupted file, with the new and old dates that close out the > hole. That requires the upload_time on the adjacent header to be changed > otherwise it won't be broadcast. We already update at boot the new and old > dates. We would have to see that there is a corrupt file and then update > the upload_time on the adjacent header. > > There is also a third bug here. When the header was updated with the > upload_time we did not see that it was corrupted. We do run a check on > uploaded file headers but apparently that runs before we update the > upload_time. If it had run after the upload_time was updated then it would > have rejected the header and the directory would not have been corrupted. -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Re: Using SHA256 for authentication
by Corey Minyard 16 Sep '23

16 Sep '23

On Sat, Sep 16, 2023 at 1:58 PM Chris Thompson via pacsat-dev <pacsat-dev(a)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(a)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(a)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(a)acm.org> wrote: >> >> >> >> On Fri, Sep 15, 2023 at 10:06 AM Chris Thompson via pacsat-dev >> >> <pacsat-dev(a)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(a)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(a)amsat.org >> > Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)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(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)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(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

2 1

Re: Using SHA256 for authentication
by Chris Thompson 16 Sep '23

16 Sep '23

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. 73 Chris On Sat, Sept 16, 2023, 12:49 Corey Minyard via pacsat-dev < pacsat-dev(a)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(a)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(a)acm.org> wrote: > >> > >> On Fri, Sep 15, 2023 at 10:06 AM Chris Thompson via pacsat-dev > >> <pacsat-dev(a)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(a)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(a)amsat.org > > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)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(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: Using SHA256 for authentication
by Corey Minyard 16 Sep '23

16 Sep '23

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(a)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(a)acm.org> wrote: >> >> On Fri, Sep 15, 2023 at 10:06 AM Chris Thompson via pacsat-dev >> <pacsat-dev(a)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(a)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(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: Using SHA256 for authentication
by Burns Fisher (AMSAT) 16 Sep '23

16 Sep '23

Why don't you talk to Heimir. I still think we should try to re-use as much code as possible, in particular AMCOM. Heimir can figure out how AMCOM does it. I don't object to changing it for Golf for that matter, except that it is getting later and later and there will soon be a lot more software requirements. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Fri, Sep 15, 2023 at 2:21 PM Chris Thompson via pacsat-dev < pacsat-dev(a)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(a)acm.org> wrote: > >> On Fri, Sep 15, 2023 at 10:06 AM Chris Thompson via pacsat-dev >> <pacsat-dev(a)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(a)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(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

2 1

Re: Using SHA256 for authentication
by Corey Minyard 15 Sep '23

15 Sep '23

On Fri, Sep 15, 2023 at 10:06 AM Chris Thompson via pacsat-dev <pacsat-dev(a)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

2 1

Re: monitor command
by Chris Thompson 15 Sep '23

15 Sep '23

There was no change to the monitor command that I remember. It does print the RSSI when it is over a certain "squelch" threshold. If it is printing it continually then it may be getting RFI on the 2m receiver. 73 Chris On Fri, Sept 15, 2023, 11:34 Bill Reed via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > When is set monitor on on version "i" I get random rssi readings? Is > this expected? > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)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(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

monitor command
by Bill Reed 15 Sep '23

15 Sep '23

When is set monitor on on version "i" I get random rssi readings? Is this expected?

1 0