[aprssig] Now this is an interesting use for APRS

scott at opentrac.org scott at opentrac.org
Wed Apr 12 22:23:58 EDT 2006


The RTEXT authentication scheme is a joke, but I suppose it's not as big a
problem in connected-mode packet where you don't have an easily-accessible
database logging every access attempt for later analysis.  Look at the
example in the manual, page 77.  With RTEXT 'Code', the TNC presents three
challenge strings:
 
111343
314313
211213
 
The user responds with 'oCCoCd'.  Looking at the challenge strings, there's
only possibility that fits the 'oCCo' pattern, and that's line 3.  An
eavesdropper now has three characters of your RTEXT.  Even without
collecting more, an attacker has NINE chances to get a challenge string
without the unknown character (or to guess it) before being locked out for
15 minutes.  Granted, you can have a much longer RTEXT string, but the same
principle applies - cracking it really isn't any harder than figuring out
the letter substitution ciphers they run on the crossword page in the
newspaper.  The scheme has the advantage of being easy to do on paper (and
maybe in your head), but it can't hold up to frequent use.  You're giving
away up to 6 characters of your RTEXT string with each use, and figuring out
which ones they are is easy if someone is keeping track of the
possibilities.
 
The Acentient access code algorithm starts at an initial code, which is
incremented or decremented by n every m minutes, resetting at a specified
time of day, and optionally incrementing or decrementing with each message.
I'm sure there's a more efficient attack against this, but I'd just plot
each overheard code against a time-of-day axis, with each day's points in a
different color.  It should be pretty easy to look at the slope and figure
out the code parameters.  Using the 'adjust with each message' feature would
complicate it a little, but it'd make the system a lot more difficult to use
for a legitimate user.
 
For the T2, I'm planning to offer three different options.  The first, and
the only one currently implemented, is callsign-based.  This offers no
direct protection, but makes an attacker show INTENT to make an unauthorized
access - and could require them to violate FCC rules.  Second, I'm still
working on a scheme that'll offer better protection but will still be usable
from your D7 keypad, with at most a pencil and paper.  Probably something
with aspects of both of the above schemes.  It needs to be something easily
shared, so that multiple authorized users can command a device.  The third
scheme will be a strong one, with protection from man-in-the-middle attacks,
replay attacks, and so forth.  It'll probably use a TEA-based CBC-MAC
variant, likely OMAC-1.  How the MAC is encoded with the message is going to
be a tradeoff between strength and bandwidth usage.  Schemes 2 and 3 will
probably have the option of being combined with callsign authentication -
that way an attacker still has to show intent, even if they do figure out
the key.
 
All of this gets a lot more complicated if you consider the possibility of
an asymmetric link.  If your remote site can't talk to you because of a
misconfiguration, or maybe because it's a specialized device that only has a
receiver, you still want to be able to command it.  A one-time password
might make more sense in that case, but you still can't know if your message
was heard - the system has to tolerate skipped passwords.
 
Lots of fun.  Makes me want to go back to the Black Hat Briefings in Las
Vegas... haven't done that in a few years.
 
Scott
N1VG


  _____  

From: aprssig-bounces at lists.tapr.org [mailto:aprssig-bounces at lists.tapr.org]
On Behalf Of John Habbinga
Sent: Wednesday, April 12, 2006 6:14 PM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] Now this is an interesting use for APRS


On this product the code changes according to a preset schedule.  I guess if
you constantly monitored the system, and the user accessed it frequently and
didn't change the parameters for the code, then you could figure it out. 

We use codes to access our Kantronics KPC3+ TNCs that we use for digipeaters
so that we can make changes


On 4/12/06, A.J. Farmer (AJ3U) < farmer.aj at gmail.com
<mailto:farmer.aj at gmail.com> > wrote: 

On 4/12/06, John Habbinga < kc5zrq at gmail.com <mailto:kc5zrq at gmail.com> >
wrote:
> I downloaded the program and looked it over.  There are plenty of uses for
> the software that would be perfectly legal for use on the U.S. amateur
radio
> bands.  The security code is not encrypted. 

So how do you keep other people on APRS from controlling your stuff, I
wonder?

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org  <mailto:aprssig at lists.tapr.org> 
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig





-- 
John Habbinga, KC5ZRQ
Lubbock, Texas 
http://find-you.com/cgi-bin/find.cgi?call=KC5ZRQ* 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20060412/af02c168/attachment.html>


More information about the aprssig mailing list