This fixes the bug where 5 digit callsigns corrupted the Directory and
merges the changes Corey made to authentication into main.
The updated ground station contains the default authentication key and
sends authenticated commands. Replay attack prevention is not yet
implemented.
Ground stations is here: https://www.g0kla.com/pacsat/index.php
73
Chris
--
Chris E. Thompson
chrisethompson(a)gmail.com
g0kla(a)arrl.net
FYI, I may be late since I have another meeting at 7 (EDT) tonight!
73,
Burns Fisher, WB1FJ
*AMSAT(R) Engineering -- Flight Software*
On Thu, Sep 21, 2023 at 9:03 AM Bob Stricklin via pacsat-dev <
pacsat-dev(a)amsat.org> wrote:
> Hello Guy's,
>
> I said I would send out the meeting invitation for tonights meeting but I
> realize I do not have the credentials to log into the GoTo Meeting portal.
> So let's recycle this meeting ID from last week. I just tested it and it
> seems to work.
>
> If there is an issue I will quickly send out a zoom meeting invitation we
> can use instead.
>
>
> https://meet.goto.com/529052701
>
>
>
> Bob N5BRG
>
>
>
> Begin forwarded message:
>
> *From: *Bill via pacsat-dev <pacsat-dev(a)amsat.org>
> *Subject: **[pacsat-dev] Pacsat dev mtg 9/14/2023*
> *Date: *September 14, 2023 at 2:35:12 PM CDT
> *To: *pacsat-dev(a)amsat.org
> *Reply-To: *Bill <bill(a)brconnect.com>
>
> Pacsat dev mtg 9/14/2023
> Thu, Sep 14, 2023 7:00 PM - 9:00 PM (CDT)
>
> Please join my meeting from your computer, tablet or smartphone.
>
> https://meet.goto.com/529052701
>
> You can also dial in using your phone.
> (For supported devices, tap a one-touch number below to join instantly.)
>
> United States: +1 (872) 240-3311
> - One-touch: tel:+18722403311,,529052701#
>
> Access Code: 529-052-701
>
> Join from a video-conferencing room or system.
> Dial in or type: 67.217.95.2 or inroomlink.goto.com
> Meeting ID: 529 052 701
> Or dial directly: 529052701(a)67.217.95.2 or 67.217.95.2##529052701
>
>
> Get the app now and be ready when your first meeting starts:
> https://meet.goto.com/install
>
>
>
> -----------------------------------------------------------
>
> pacsat-dev mailing list -- pacsat-dev(a)amsat.org
> View archives of this mailing list at
> https://mailman.amsat.org/hyperkitty/list/[email protected]
> 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/[email protected]
> 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
>
Hello Guy's,
I said I would send out the meeting invitation for tonights meeting but I realize I do not have the credentials to log into the GoTo Meeting portal. So let's recycle this meeting ID from last week. I just tested it and it seems to work.
If there is an issue I will quickly send out a zoom meeting invitation we can use instead.
https://meet.goto.com/529052701
Bob N5BRG
Begin forwarded message:
From: Bill via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>>
Subject: [pacsat-dev] Pacsat dev mtg 9/14/2023
Date: September 14, 2023 at 2:35:12 PM CDT
To: pacsat-dev(a)amsat.org<mailto:[email protected]>
Reply-To: Bill <bill(a)brconnect.com<mailto:[email protected]>>
Pacsat dev mtg 9/14/2023
Thu, Sep 14, 2023 7:00 PM - 9:00 PM (CDT)
Please join my meeting from your computer, tablet or smartphone.
https://meet.goto.com/529052701
You can also dial in using your phone.
(For supported devices, tap a one-touch number below to join instantly.)
United States: +1 (872) 240-3311
- One-touch: tel:+18722403311,,529052701#
Access Code: 529-052-701
Join from a video-conferencing room or system.
Dial in or type: 67.217.95.2 or inroomlink.goto.com
Meeting ID: 529 052 701
Or dial directly: 529052701(a)67.217.95.2 or 67.217.95.2##529052701
Get the app now and be ready when your first meeting starts: https://meet.goto.com/install
-----------------------------------------------------------
pacsat-dev mailing list -- pacsat-dev(a)amsat.org
View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected]
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
On Tue, Sep 19, 2023 at 10:52:30PM +0000, Burns Fisher (AMSAT) via pacsat-dev wrote:
> You are not understanding. The reset value always goes up. When it
> increments, the seconds restart at 0, but together they always go up. I
> actually refuse to accept the command if the reset (I call it the epoch)
> has changed.
>
> I don't know how an attacker could force me to send a packet.
If you design a protocol that says "In this situation you send this
packet", as you suggested, then it's possible for an attacker to force
you to send a packet by creating that situation.
> But as I
> say, I would not plan to use this feature. Feel free to read my paper
> about this in the AMSAT Symposium Procedings (maybe 2016 or 17). I'm not
> saying it is perfect, but I think the issues are smaller than you suggest.
Ok, I got the paper and read it (2015, BTW). So the time from the
spacecraft is a reset count, always incremented on each reset, and a
counter of the number of seconds since the last reset. That is good for
a sequence number.
I would still argue that the time from the s/c should be authenticated.
Without that, it would be relatively simple to jam the s/c and pretend
you are the the s/c and spoof the sequence to a ground station.
Authenticating the time would make the protocol much more robust.
We already have algorithms to do authentication, and it's relatively
simple. And it's probably a good idea to authenticate the telementry,
anyway. Since it's not encrypted, users that didn't care wouldn't have
to worry about it.
The only other issue I can think of is if the "last command time" in the
s/c somehow gets set to a really large value and nobody could command
the satellite until it reached that timestamp. I would think that you
would want to make sure the time wasn't too far into the future before
accepting a command.
I've never seen a protocol like this. I'll look through my cryptography
books and resources and see if I can find something like it, but this
seems like a fairly unique situation. Designing secure protocols is
unbelievably hard. Hackers are unbelievably ingenious.
I should apologise, I guess, I'm a hacker by nature. I see something
like this and it's automatic to pick it apart. Nothing personal is
meant by this. You guys have done a lot of amazing work.
-corey
>
> 73,
>
> Burns Fisher, WB1FJ
> *AMSAT(R) Engineering -- Flight Software*
>
>
> On Tue, Sep 19, 2023 at 6:13 PM Corey Minyard <minyard(a)acm.org> wrote:
>
> > Comments inline...
> >
> > On Tue, Sep 19, 2023 at 09:11:22PM +0000, Burns Fisher (AMSAT) via
> > pacsat-dev wrote:
> > > See below.
> > >
> > > 73,
> > >
> > > Burns Fisher, WB1FJ
> > > *AMSAT(R) Engineering -- Flight Software*
> > >
> > >
> > > On Tue, Sep 19, 2023 at 4:59 PM Corey Minyard <minyard(a)acm.org> wrote:
> > >
> > > > On Tue, Sep 19, 2023 at 07:19:27PM +0000, Burns Fisher (AMSAT) via
> > > > pacsat-dev wrote:
> > > >
> > > > >
> > > > > 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.
> >
> > It sounds like you cannot use the s/c time for a sequence number,
> > because it can be reset. You cannot rely on it always going up. So you
> > would need to send two values, one sequence number and the spacecraft
> > time as separate values. In that case, I believe this works.
> >
> > But that's only the case if the telemetry is signed somehow so it
> > cannot be spoofed by an attacker. If an attacker can spoof the
> > telemetry, it can send a future time to the ground station and cause it
> > to send the command with that time, which could then be used later.
> >
> > >
> > >
> > >
> > > > >
> > > > > 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.
> >
> > From what I can tell, it would be easy for an attacker to force you to
> > send this packet.
> >
> > I'm not sure how much we really need to worry about this. But if we
> > need to worry about it, we need a robust protocol.
> >
> > I'm not a professional cryptographer, so I'm not sure how robust either
> > the time or two command protocol is against attack. I also haven't
> > spent a long time thinking about it. But I know that if you rely on
> > anything unauthenticated from the spacecraft, you are in trouble.
> >
> > -corey
> >
> > >
> > >
> > >
> > > >
> > > > 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(a)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(a)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(a)acm.org>
> > wrote:
> > > > > >>
> > > > > >>> 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/[email protected]
> > > > > >>> >> > 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/[email protected]
> > > > > >>> >> 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/[email protected]
> > > > > >>> > 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/[email protected]
> > > > > >> 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
> > > > > >>
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 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/[email protected]
> > > > > > 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/[email protected]
> > > > > 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/[email protected]
> > > 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/[email protected]
> 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
Comments inline...
On Tue, Sep 19, 2023 at 09:11:22PM +0000, Burns Fisher (AMSAT) via pacsat-dev wrote:
> See below.
>
> 73,
>
> Burns Fisher, WB1FJ
> *AMSAT(R) Engineering -- Flight Software*
>
>
> On Tue, Sep 19, 2023 at 4:59 PM Corey Minyard <minyard(a)acm.org> wrote:
>
> > On Tue, Sep 19, 2023 at 07:19:27PM +0000, Burns Fisher (AMSAT) via
> > pacsat-dev wrote:
> >
> > >
> > > 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.
It sounds like you cannot use the s/c time for a sequence number,
because it can be reset. You cannot rely on it always going up. So you
would need to send two values, one sequence number and the spacecraft
time as separate values. In that case, I believe this works.
But that's only the case if the telemetry is signed somehow so it
cannot be spoofed by an attacker. If an attacker can spoof the
telemetry, it can send a future time to the ground station and cause it
to send the command with that time, which could then be used later.
>
>
>
> > >
> > > 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.
From what I can tell, it would be easy for an attacker to force you to
send this packet.
I'm not sure how much we really need to worry about this. But if we
need to worry about it, we need a robust protocol.
I'm not a professional cryptographer, so I'm not sure how robust either
the time or two command protocol is against attack. I also haven't
spent a long time thinking about it. But I know that if you rely on
anything unauthenticated from the spacecraft, you are in trouble.
-corey
>
>
>
> >
> > 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(a)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(a)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(a)acm.org> wrote:
> > > >>
> > > >>> 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/[email protected]
> > > >>> >> > 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/[email protected]
> > > >>> >> 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/[email protected]
> > > >>> > 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/[email protected]
> > > >> 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
> > > >>
> > > >
> > > >
> > > > --
> > > > 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/[email protected]
> > > > 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/[email protected]
> > > 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/[email protected]
> 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
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(a)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(a)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(a)acm.org> wrote:
> >>
> >>> 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/[email protected]
> >>> >> > 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/[email protected]
> >>> >> 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/[email protected]
> >>> > 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/[email protected]
> >> 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
> >>
> >
> >
> > --
> > 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/[email protected]
> > 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/[email protected]
> 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
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.
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.
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!)
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(a)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(a)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(a)acm.org> wrote:
>>
>>> 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/[email protected]
>>> >> > 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/[email protected]
>>> >> 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/[email protected]
>>> > 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/[email protected]
>> 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
>>
>
>
> --
> 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/[email protected]
> 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
>
On Tue, Sep 19, 2023 at 05:58:23PM +0000, Chris Thompson via pacsat-dev 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.
Oops, that was an off-by-one bug in my brain. It will still work, it
will just be padded with zeros at the end. It's better to add the four
extra bytes.
>
> 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.
Using current epoch as the serial number would be an excellent idea.
All it has to be is non-reusable and increasing.
It will cause a problem on January 2038 when the epoch rolls over.
However, if you used an unsigned 32-bit integer and calculated it from
a 64-bit epoch, you get another 70 years beyond that. Or you could do
you own epoch from spacecraft launch time.
-corey
>
> 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(a)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(a)acm.org> wrote:
> >
> >> 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/[email protected]
> >> >> > 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/[email protected]
> >> >> 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/[email protected]
> >> > 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/[email protected]
> > 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
> >
>
>
> --
> 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/[email protected]
> 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
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(a)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(a)acm.org> wrote:
>
>> 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/[email protected]
>> >> > 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/[email protected]
>> >> 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/[email protected]
>> > 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/[email protected]
> 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
>
--
Chris E. Thompson
chrisethompson(a)gmail.com
g0kla(a)arrl.net
If the callsign adds /R it now works. Or if it is VE2/G0KLA for example.
I just add the length of the string to the offset.
But there is a related issue. The "source" field specified in the header
has "variable" length per the PACSAT protocol with the maximum limited to
255. I limit it to 33 chars in the spacecraft because that is what older
PACSAT code did. That works to print out a debug message with the source
(sender) and truncates it if it is longer. But you can send a message with
255 bytes in the source field. So I need to store that length to calculate
the offset even if I truncate the value when I load the header.
I really don't like the PACSAT Headers with their variable content. I
think we should design a better, cleaner, more efficient way to do this.
73
Chris
On Mon, Sep 18, 2023 at 10:21 AM Bob Stricklin via pacsat-dev <
pacsat-dev(a)amsat.org> wrote:
> 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> 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/[email protected]
>> 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/[email protected]
> 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/[email protected]
> 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
>
--
Chris E. Thompson
chrisethompson(a)gmail.com
g0kla(a)arrl.net
