[aprssig] Re: Authentication over APRS was: Ab)Use of APRS for telemetry? Anyone doing it?

[Scott Miller]

> This brings up a question I've had for some time. As I recall, the FCC
rules prevent amateurs from using "encryption" or anything that obscurs the
meaning of a message. I don't recall the exact words.

This comes up every time anyone mentions passwords or authentication.  I
think the relevant section of Part 97 is 97.113(a)(4): Prohibited
Transmissions.

"...messages in codes or ciphers intended to obscure the meaning thereof,
except as otherwise provided herein..."

Satellite command links are specifically exempted.  Authentication, as
apposed to encryption, doesn't seem to be prohibited at all, nor does there
seem to be any good reason for it to be.  Encryption prevents the FCC from
ensuring the service is used as intended - authentication makes sure only
authorized users can command a remote station, which should be a good thing.
You can keep your command data in the clear and use a message authentication
code to ensure integrity.

> Including a simple password in the message does nothing to prevent "replay
attacks" (not good if you want to do something like open your garage door,
or unlock something)

Very true.  This gets overlooked a lot.  Man-in-the-middle attacks are also
possible - you could always jam a target station with a directional signal
and prevent it from hearing a valid command while you intercept it and
retransmit it in a modified form.  You need to address both of these
possibilities.

> One could certainly use a OTP (one time pad), but that clearly violates
the FCC rule mentioned above.

Someone responded to this already, but I think there's some confusion
between a one time pad and one time password.  One time passwords are useful
for authentication over an unencrypted link - S/Key is a good example.
Before I went to only using SSH, I'd carry around a card of S/Key passwords
in my wallet in case I needed to log in to a machine over Telnet.  One time
pads are another matter - they're used for encryption.  In fact, they're
probably the simplest form of provably secure encryption, provided you've
got a good random number source.  Definitely not what you want to use if
you're trying to keep the FCC off your back!

> So, I was thinking the best method would be to send the command in plain
text, thereby making the FCC happy. Including a date stamp to avoid replay
attacks. And finally, attaching a hash of the message body encrypted with a
PK (public key) tool. This way nothing is encrypted excecpt the "signature".
>
> I've not given this much thought as to the "size" of the key, and the
complexity of PKE code for microcontrollers...

BIG.  I was looking at ECDSA, which has a smaller key size, but it's still
big.  You shouldn't really need public key cryptography though.  A simple
symmetric algorithm like TEA can be used in a CBC-MAC (cypher block chaining
message authentication code) mode.  Assuming your target device knows the
same secret key, you can 'sign' a message using that key and the target
device can verify that you know the key and that the message hasn't been
altered.  You still need to provide some protection from replay attacks -
probably in the form of a challenge/response or sequence number.

The disadvantage, compared to a public key scheme, is that no one else can
validate the message without the secret key.  This is more a problem if
you're trying to do something like implement protected objects - like maybe
you're the NWS and you don't want people moving your hurricane.  The best
solution I've found is to do the same as above, but in future messages you
disclose the key you used last time.  That way, the receiving stations can
be sure that the updated object was sent by someone who knew the secret key
used in the first one.  It doesn't provide proof of identity, but at least
you know the object wasn't hijacked after creation.

Anyway, my point is that using a symmetric key MAC, you should be able to
implement strong authentication without violating the letter or spirit of
Part 97.

Scott
N1VG