Order Tray | Contact Us | Home | SIG Lists

[aprssig] Password authentication

Scott Miller scott at opentrac.org
Thu Jan 22 21:53:42 UTC 2009


I just added a new password authentication scheme to the Tracker2, and I 
figured I'd throw this out there in case anyone's interested in the 
implementation details - it'd be nice to have support for it built into 
APRS clients, but if that's going to happen then it'd be best to 
standardize the scheme, and now is the time to do that before it makes 
it into an official firmware release.

Someone on the Tracker2 mailing list pointed out that the scheme is 
architecturally identical to the Perfect Paper Passwords system 
(http://www.grc.com/ppp/design.htm), so if you're familiar with that, 
this is pretty much the same thing.  It's also similar to S/KEY, but 
with some important differences.

The scheme works like this:  You pick a reasonably long and 
hard-to-guess pass phrase, and enter that at the T2's command line. 
This gets converted to a 128-bit key and stored, and the sequence 
counter is set to 0.

Another command generates a list of 4-character passwords from this key, 
starting with the next sequence (0 if you haven't used any yet).  You 
can print this out and keep it in your wallet.

When you need to send a command to the T2, you include the next unused 
password right after the CMD prefix in the message - for example, 
"CMDM0VT DIGI OFF", where "M0VT" is the password.  The device updates 
its counter in non-volatile memory, so that password can't be used again.

If you don't want to keep a list of passwords, a local calculator (this 
is where the APRS applications come in) can do it for you - just enter 
the pass phrase and the sequence number, and it gives you the password.

Internally, it uses the XXTEA algorithm to hash your pass phrase 
(encrypting an initialization vector with each 16-byte block of the pass 
phrase in turn, in cipher block chaining mode).  This 128-bit hash 
serves as a key to XXTEA-encrypt a nonce plus the sequence number, and 
20 bits are taken from the resulting ciphertext and encoded into 4 
alphnumeric characters to serve as the password.  The password is 
case-insensitive and avoids most of the confusing letters and numbers - 
there's no O or I, for example.

This is all in the current development build, and will be in the next 
official release.  If anyone has any comments or feedback on the scheme, 
let me know now before I start harassing the APRS client developers 
about adding password calculators to their products.  =]

I'm also happy to share the code behind all of this if anyone else wants 
to implement it.  I haven't done much optimization yet, but the code 
(it's all written in C) doesn't take up more than about 1.2k in the T2.

Scott
N1VG




More information about the aprssig mailing list