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

[Andrew P.]

Let me see if I can summarize to ensure we all agree on the problem.

"Because there is no strong validation of the license status of any connector to the APRS-IS, it is possible for a non-ham to make illegal RF transmissions through the APRS-IS."

As Steve pointed out, licensed hams can cause DoS attacks (although that technically could be considered a violation due to jamming on RF, that probably wouldn't hold up in court against the originator, but might be put against the TX-IGater). So authentication won't help there.

The US FCC regs specifically state that the first forwarding station is liable for illegal transmissions and ensuring the originator is legally allowed to send the data; subsequent stations are not liable, but are expected to stop forwarding the illegal transmissions once they become aware of them. Can't speak for other nations' regulations, but assuming something similar or more stringent would be safe.

So, we need a way for anybody Tx-IGating to confirm that the packet originator is licensed to transmit to RF, and/or the Igater is allowed to transmit third-party traffic on behalf of the originator. So they have to be able to confirm the originator's license status and/or country of origin (per international agreements regarding third-party traffic handling).

Due to the possibility of forging callsigns, every single packet routed through the APRS-IS would need to be identified with its origination point (client injecting into the APRS-IS) in a form that rogue APRS-IS servers couldn't forge. That doesn't fully help with Rx-Igated traffic (the original station using RF, but if they are transmitting illegally to get to the IGate, that's a separate issue anyway).

Due to the distributed nature of the APRS-IS, we would need a way to ensure all servers were compliant with enforcing origination ID's. So servers that didn't provide origination ID's in their sideways or upwards links to other APRS-IS servers would eventually have to be removed from the network.

So, we would need:

1. Strong and non-repudiable identification of the license status and country of origin of every APRS-IS client instance (not the authors, but the users).

2. Attaching that identification to each packet from that client passed through the APRS-IS.

3. Allowing the selective rejection of traffic from users found to be in violation (perhaps through blacklists and/or Certificate Revocation Lists).

Does that about sum it up?

Andrew Pavlin, KA2DDO

> From: steve at dimse.com
> Date: Sat, 29 Mar 2014 09:05:10 -0400
> To: aprssig at tapr.org
> Subject: Re: [aprssig] APRS-IS Passcode alternative: SSL + Certificates,	with no data encryption
> 
> 
> On Mar 29, 2014, at 4:10 AM, Heikki Hannikainen <hessu at hes.iki.fi> wrote:
> > 
> > * The server at this point doesn't do anything else than that, but it could be improved to pass that knowledge onwards to other servers together with the packets, and then onwards to other clients. For that to be useful, the servers also need to authenticate with each other in a strong way (not just passcode). aprsc can do SSL between servers.
> 
> This is where the problem I hit with the original APRS IS will bite. If you just have a small number of trusted servers a system like this where access is controlled at the entry points can work. But when you have a large number of server operators, and especially where the source code is available and can be modified by any one of those sysops, it becomes impossible to assure there are no weak links, accidental or intentional. Even in a system where all the servers are connected by SSL and all internet users are connected to the servers by SSL it is still possible for someone with a certificate to put any data on the APRS IS in an untraceable manner, and therefore impossible to block it.
> 
> The way to solve this is to individually sign each packet in a way that allows tracing of the packet to an authenticator. Note that this does nothing to insure the data on the APRS IS is actually authentic, or to prevent a Denial of Service (DoS) attack; it is only a means to assign blame if bad data is found and then close the door to that particular certificate in the future. 
> 
> What I haven't heard is exactly what problem all this is aiming to solve. Is this a regulatory issue?
> 
> In the US things are fine from the regulatory standpoint; there have been no problems yet the possibility exists there could be. To become a problem the FCC would have to capture a particular problem packet IGated by a specific station that violated its rules about profanity or commercial use, prove it came from a specific IGate operator (and since anyone in the LAN could have changed their call to the IGate operator call they need technical proof like T-hunting, not just the presence of the callsign in the packet), and issue a citation. This is a highly unlikely sequence of events.
> 
> Are there countries that do not allow IGating from the present APRS IS but would if verification that every packet on the APRS IS was vouched for by someone with a LOTW certificate were assured? I'm no expert on international ham rules but I've never heard of anything like this, in all the examples I know countries either allow internet interconnection or don't.
> 
> If not a regulatory issue, then is it is a general security issue? You don't want to wait until the horse is stolen to lock the door. Good sentiment, but we aren't locking something up with intrinsic value. Yes, I'd hate to see someone start a DoS attack on the APRS IS. If the SSL-based system prevented that, maybe it would be worth the effort. But it only prevents people that can't get ahold of a LOTW certificate from doing so. Few outside the ham community know about the APRS IS, and fewer care. Obviously none so far care enough to mount a DoS attack, since none have occurred with no barriers in place. Does eliminating the negligible threat of DoS from a non-ham make the effort worth it?
> 
> Or is there some other reason I'm missing?
> 
> It seems to me before we start discussing solutions there should be a clear consensus on the problem!
> 
> 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/20140329/94e3c3da/attachment.html>