<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2802" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2>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:</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2>111343</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2>314313</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2>211213</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2>Scott</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=375371601-13042006><FONT face=Arial
color=#0000ff size=2>N1VG</FONT></SPAN></DIV><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> aprssig-bounces@lists.tapr.org
[mailto:aprssig-bounces@lists.tapr.org] <B>On Behalf Of </B>John
Habbinga<BR><B>Sent:</B> Wednesday, April 12, 2006 6:14 PM<BR><B>To:</B> TAPR
APRS Mailing List<BR><B>Subject:</B> Re: [aprssig] Now this is an interesting
use for APRS<BR></FONT><BR></DIV>
<DIV></DIV>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. <BR><BR>We use codes to access our Kantronics KPC3+ TNCs
that we use for digipeaters so that we can make changes<BR><BR>
<DIV><SPAN class=gmail_quote>On 4/12/06, <B class=gmail_sendername>A.J. Farmer
(AJ3U)</B> <<A onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:farmer.aj@gmail.com" target=_blank> farmer.aj@gmail.com</A>>
wrote:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">On
4/12/06, John Habbinga <<A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:kc5zrq@gmail.com" target=_blank> kc5zrq@gmail.com</A>>
wrote:<BR>> I downloaded the program and looked it over. There
are plenty of uses for<BR>> the software that would be perfectly legal
for use on the U.S. amateur radio<BR>> bands. The security
code is not encrypted. <BR><BR>So how do you keep other people on APRS from
controlling your stuff, I
wonder?<BR><BR>_______________________________________________<BR>aprssig
mailing list<BR><A onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:aprssig@lists.tapr.org" target=_blank>aprssig@lists.tapr.org
</A><BR><A onclick="return top.js.OpenExtLink(window,event,this)"
href="https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig"
target=_blank>https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig</A><BR></BLOCKQUOTE></DIV><BR><BR
clear=all><BR>-- <BR>John Habbinga, KC5ZRQ<BR>Lubbock, Texas <BR><A
onclick="return top.js.OpenExtLink(window,event,this)"
href="http://find-you.com/cgi-bin/find.cgi?call=KC5ZRQ*"
target=_blank>http://find-you.com/cgi-bin/find.cgi?call=KC5ZRQ*</A>
</BLOCKQUOTE></BODY></HTML>