[pacsat-dev] Re: Using SHA256 for authentication

20 Sep 2023

      I don't know which scheme is better but I have the reset and uptime at the
ground station so I will just use that.  Given all the spacecraft code is
already written for that approach.  We can easily update this later
following further analysis.
73
Chris
On Tue, Sept 19, 2023, 21:58 Corey Minyard minyard@acm.org wrote:
...
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@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@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@amsat.org> wrote:
> Corey, I was delayed by another bug but managed to look at this
today.  It
...
> looks very good.
>
> I can calculate the same hash value with the default key using
the
...
...
Java
...
...
...
> Mac class and the HmacSHA256 algorithm.  So that is great.  It
uses the
...
...
...
> public algorithm.
>
> I did notice that the default key in the code you implemented
is 28
...
...
...
...
bytes
...
> and not 32 bytes as you stated in an earlier email.  Is that
correct?
...
...
It
...
> works with the 28 byte key.
>
> One other thing.  The existing code prevents a replay attack by
sending
...
...
...
> the reset/uptime on the spacecraft in the command.  We have to
send the
...
...
...
> same reset and an uptime that is the same or no more than 300
seconds
...
...
after
...
> the actual uptime on the spacecraft.  I think this could cause
issues
...
...
with
...
> an unresponsive spacecraft where we don't know the time
onboard.
...
...
I'm
...
...
sure
...
> that is why there is a special command that goes around the
requirement and
...
> turns it off.
>
> I would instead propose we send a serial number in the command,
with no
...
...
...
> other meaning.  Any command can only be used once and we store
the
...
...
...
...
highest
...
> serial number used so far.  The serial number would be in the
hash
...
...
of
...
...
the
...
> command of course.  To make it easy to sync the serial numbers
across
...
...
...
> different command stations I propose that the serial number be
unix
...
...
...
...
time in
...
> UTC, or the time based on a later epoch if we want something
with
...
...
less
...
...
than
...
> 32 bits.  It will just be treated as a serial number that is
checked
...
...
for
...
> duplicates when received at the spacecraft.  Specifically all
commands
...
...
must
...
> have a serial number greater than the largest one received so
far.
...
...
...
...
...
>
> Maybe that is not secure enough.  Let me know.
>
> 73
> Chris
>
>
> On Sat, Sep 16, 2023 at 6:56 PM Chris Thompson via pacsat-dev <
> pacsat-dev@amsat.org> wrote:
>
>> Sounds very good.  I will try to have a look at it tomorrow or
Monday.
...
...
...
>>
>> 73
>> Chris
>>
>> On Sat, Sept 16, 2023, 15:53 Corey Minyard minyard@acm.org
wrote:
...
...
...
>>
>>> On Sat, Sep 16, 2023 at 1:58 PM Chris Thompson via pacsat-dev
>>> pacsat-dev@amsat.org wrote:
>>> >
>>> > Just for reference, the sha.c algorithm did match what I
get
...
...
from
...
...
Java
...
>>> with the standard sha-256 digest.  So it does work for the 18
bytes
...
...
of our
...
>>> commands.  But it sounds like it will not work if we append
the
...
...
...
...
secret key
...
>>> twice.
>>>
>>> Yes, my impetus for replacing it, plus the new algorithm
allows
...
...
...
...
...
>>> partial adds of data to make the process easier.
>>>
>>> I have pushed up an update-sha-hmac branch that reworks all
the
...
...
...
...
...
>>> keying.  It uses the hmac-sha256 algorithm for
authentication, it
...
...
...
...
adds
...
>>> the code to load the key from NVRAM, and reworks the keysize
to
...
...
be 32
...
...
...
>>> bytes.  Reworking the key size will rearrange NVRAM,
unfortunately.
...
...
...
>>> With this, you should be able to add a key from the command
line
...
...
and
...
...
...
>>> have it write it to NVRAM, and use it for the hmac-sha256
>>> authentication.  It does remove the AES code.
>>>
>>> -corey - AE5KM
>>>
>>> >
>>> > 73
>>> > Chris
>>> >
>>> > On Sat, Sept 16, 2023, 12:49 Corey Minyard via pacsat-dev <
>>> pacsat-dev@amsat.org> wrote:
>>> >>
>>> >> I just pulled Authenticate/src/sha.c out of the code and
moved it
...
...
into
...
>>> >> a separate file and played with it a bit.  It wasn't
matching
...
...
the
...
...
...
>>> >> results from sha256sum, and looking at the code, I
realized
...
...
that
...
...
the
...
>>> >> implementation only accepts up to 64 bytes of data.  It
works
...
...
for
...
...
...
>>> >> buffers less than 64 bytes.  It also won't do partial
pieces,
...
...
...
...
which
...
>>> >> would make the implementation of HMAC easier.
>>> >>
>>> >> I'm going to recommend we adapt
https://github.com/h5p9sl/hmac_sha256
...
>>> >> to our needs.  I'll work on that a bit.
>>> >>
>>> >> Also, I couldn't find any evidence of any cryptanalysis of
encrypting
...
>>> >> the sha256 output with AES.  Sometimes those things work,
sometimes
...
>>> >> you get surprising results. Since the HMAC approach is
well
...
...
known
...
...
and
...
>>> >> heavily analyzed, that would seem a better approach.
>>> >>
>>> >> -corey - AE5KM
>>> >>
>>> >> On Fri, Sep 15, 2023 at 1:21 PM Chris Thompson via
pacsat-dev
...
...
...
...
...
>>> >> pacsat-dev@amsat.org wrote:
>>> >> >
>>> >> > I did not implement it yet.  It would go in Command
task.c
...
...
and
...
...
...
>>> replace or perhaps duplicate the authenticate function.
>>> >> >
>>> >> > Feel free to code it.
>>> >> >
>>> >> > I don't know if we will ultimately go this way.  I would
still
...
...
like
...
>>> to make the AES authentication work but I agree this could be
simpler and
...
>>> faster.  So it would be good to test it.
>>> >> >
>>> >> > Chris
>>> >> >
>>> >> > On Fri, Sept 15, 2023, 11:20 Corey Minyard <
minyard@acm.org
...
...
...
...
wrote:
...
>>> >> >>
>>> >> >> On Fri, Sep 15, 2023 at 10:06 AM Chris Thompson via
pacsat-dev
...
...
...
>>> >> >> pacsat-dev@amsat.org wrote:
>>> >> >> >
>>> >> >> > Ok, thanks for that Corey.  Very interesting.  We may
not be
...
...
...
>>> susceptible to the length extension attack vulnerability
though.  If
...
...
I
...
>>> understand correctly, then a message sent as: Hash( key +
"Watch
...
...
the
...
...
...
>>> enemy") could be manipulated to Hash(key + "Watch the enemy
and
...
...
...
...
attack them
...
>>> after 5 mins"), without knowing the key.  But our commands
are
...
...
fixed
...
...
at 18
...
>>> bytes length (for now at least). So any extra appended
message
...
...
would
...
...
be
...
>>> ignored.  With that said, it may not be much harder to
implement
...
...
the
...
...
scheme
...
>>> as described.
>>> >> >>
>>> >> >> Yes, I was more worried about the "various security
papers
...
...
have
...
...
...
>>> >> >> suggested vulnerabilities with this approach" comment
in
...
...
the
...
...
...
>>> article
>>> >> >> on the key || message || key approach.  It probably
means
...
...
...
...
there are
...
>>> >> >> other issues with the approach, possibly key extraction
attacks.
...
>>> The
>>> >> >> HMAC approach seems generally more cryptographically
sound.
...
...
...
...
...
>>> >> >>
>>> >> >> I was going to say that I could implement it, though
it's
...
...
...
...
pretty
...
>>> >> >> trivial.  You've probably already done it :).
>>> >> >>
>>> >> >> -corey - AE5KM
>>> >> >
>>> >> >
>>> >> >

...
...
...
...
...
>>> >> >
>>> >> > pacsat-dev mailing list -- pacsat-dev@amsat.org
>>> >> > View archives of this mailing list at
>>>
https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
...
...
...
...
...
>>> >> > To unsubscribe send an email to
pacsat-dev-leave@amsat.org
...
...
...
...
...
>>> >> > Manage all of your AMSAT-NA mailing list preferences at
>>> https://mailman.amsat.org
>>> >>
>>> >>

...
...
...
...
...
>>> >>
>>> >> pacsat-dev mailing list -- pacsat-dev@amsat.org
>>> >> View archives of this mailing list at
>>>
https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
...
...
...
...
...
>>> >> To unsubscribe send an email to
pacsat-dev-leave@amsat.org
...
...
...
...
...
>>> >> Manage all of your AMSAT-NA mailing list preferences at
>>> https://mailman.amsat.org
>>> >
>>> >
>>> > -----------------------------------------------------------
>>> >
>>> > pacsat-dev mailing list -- pacsat-dev@amsat.org
>>> > View archives of this mailing list at
>>>
https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
...
...
...
...
...
>>> > To unsubscribe send an email to pacsat-dev-leave@amsat.org
>>> > Manage all of your AMSAT-NA mailing list preferences at
>>> https://mailman.amsat.org
>>>
>>
>> -----------------------------------------------------------
>>
>> pacsat-dev mailing list -- pacsat-dev@amsat.org
>> View archives of this mailing list at
>>
https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
...
...
...
...
...
>> To unsubscribe send an email to pacsat-dev-leave@amsat.org
>> Manage all of your AMSAT-NA mailing list preferences at
>> https://mailman.amsat.org
>>
>
>
> --
> Chris E. Thompson
> chrisethompson@gmail.com
> g0kla@arrl.net
>
> -----------------------------------------------------------
>
> pacsat-dev mailing list -- pacsat-dev@amsat.org
> View archives of this mailing list at
> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
> To unsubscribe send an email to pacsat-dev-leave@amsat.org
> Manage all of your AMSAT-NA mailing list preferences at
> https://mailman.amsat.org
>
...

pacsat-dev mailing list -- pacsat-dev@amsat.org
View archives of this mailing list at
https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
...
To unsubscribe send an email to pacsat-dev-leave@amsat.org
Manage all of your AMSAT-NA mailing list preferences at
https://mailman.amsat.org
...

pacsat-dev mailing list -- pacsat-dev@amsat.org
View archives of this mailing list at
https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
...
To unsubscribe send an email to pacsat-dev-leave@amsat.org
Manage all of your AMSAT-NA mailing list preferences at
https://mailman.amsat.org