[aprssig] APRS-IS Passcode alternative: SSL + Certificates, with no data encryption

[pfbram at comcast.net]

I'm pretty much in agreement. At best, a few techniques might slightly improve the situation, but not stop an even casually determined person. About the only end-to-end secure (+identity) system I see would basically be like secure wi-fi, which would entail new kinds of hardware with built-in encryption, ability to drop an SSL cert or public/private ssh key pair into it, or something along those lines. 

The tinkerer might instead consider dabbling in wireless mesh networks which have the lower-level fundamentals already in place. That whole direction looks like a rabbit hole that leads nowhere feasible given the open spirit of amateur radio, rules against crypto over RF and so on. Arguably no reason to reinvent the wheel for amateur radio frequencies. 

In the pre-computer days, operators gave their callsign over phone or CW and that was that. In the relatively rare cases of trouble, eventually someone might be able to trace the source of transmissions. TCP/IP/UDP is also traceable, but a determined person on wi-fi, anonymizer systems, routing through international sites, etc. can commit mischief with some anonymity. Ultimately, though, it would seem that people with those sorts of skills have financial motive in mind, so they would have other pickings. 

73 
Paul / KD0KZE 

----- Original Message -----
From: "Steve Dimse" <steve at dimse.com> 
To: "TAPR APRS Mailing List" <aprssig at tapr.org> 
Sent: Tuesday, April 1, 2014 12:02:18 AM 
Subject: Re: [aprssig] APRS-IS Passcode alternative: SSL + Certificates, with no data encryption 

On Apr 1, 2014, at 12:21 AM, Paul Bramscher <pfbram at comcast.net> wrote: 

> Could be more trouble than it's worth here, though. 

I've been trying to imaging how even with magic wands there could be an APRS IS that was secure. I don't see one; as long as there is any way to get illegitimate data onto the APRS IS it cannot be called secure. Here is a scenario for you optimists to chew on. 

A basic principle of the present APRS IS and the US rules is that a transmission on amateur RF can be retransmitted without any repercussion. Transmission on RF is accepted as authentication (e.g. a repeater trustee has no responsibility for retransmitting bootleggers). Imagine there is suddenly a steady stream of profane messages on the newly-secured APRS IS that appear to be originated by NNN4XYZ on RF. They appear on the APRS IS signed with the certificate of IGate operator WWW4ABC. 

So use your complex hypothetical proposals to differentiate between these two possibilities: Is IGate operator WWW4ABC trying to poison the reputation of NNN4XYZ? Or is a third party trying to poison the rep of WWW4ABC and/or NNN4XYZ by placing this data on RF making it appear to be from one ham and signed by a second? Unless the RF packets are also signed individually (way too bandwidth-intenstive) I don't see any way to tell (other than by sitting in front of the QTH of the IGate to see if it is on RF - the monitor must be very close because it could be a milliwatt xmitter hidden in a nearby tree) to differentiate between these two. 

There is a huge difference in liability between these two scenarios. Someone that transmits profane data on 144.39 is violating Part 97. Someone who injects the same data into the APRS IS violates no FCC rule, instead liability is with any IGate operator that retransmits the data. So long as I can legally inject data into the APRS IS that causes an IGate operator to break the rules, there is no shield for the IGate operator, and the whole exercise of securing the APRS IS is pointless. 

In other words, not only do I think reaching any level of security on the APRS IS is a waste of time, not only do I think it would require every APRS IS packet be individually signed, but I'm beginning to think it also would require packet level signing of the RF network as well. 

Steve K4HG 

_______________________________________________ 
aprssig mailing list 
aprssig at tapr.org 
http://www.tapr.org/mailman/listinfo/aprssig 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20140401/e0f951f6/attachment.html>