[aprssig] Now this is an interesting use for APRS
scott at opentrac.org scott at opentrac.orgThu Apr 13 02:23:58 UTC 2006
- Previous message: [aprssig] Now this is an interesting use for APRS
- Next message: [aprssig] Now this is an interesting use for APRS
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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://www.tapr.org/pipermail/aprssig/attachments/20060412/327baf46/attachment.htm
- Previous message: [aprssig] Now this is an interesting use for APRS
- Next message: [aprssig] Now this is an interesting use for APRS
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
