One Kelly Sweeney is publicly advocating that public access to AIS ship information should be prohibited in order to foil pirates and terrorists.
I must respectfully disagree with the premise of this article. I’m the lead of GPSD, a widely-used open-source GPS/AIS monitor daemon, and I am thus both a domain expert on AIS and a systems architect who is required to think about data security issues all the time. Attempting to “secure” AIS data would harm the public and have no security benefits. In fact, the second-order effects would be seriously bad.
The public harm is obvious; people such as your friend on Puget Sound with an interest in knowing what traffic passes near them would be hindered. But it would also fail to have security benefits, because getting actual use out of AIS is in direct contradiction with the threat model.
AIS information has to be widely available to anyone on the water in order for the system to achieve its design purposes (notably, automated collision avoidance). This means that credentials to get access to it have to be widely distributed as well. Pirates and terrorists would have very strong incentives to steal and spoof those credentials.
Any security light enough to leave the system usable would be no more than a minor, easily surmountable nuisance to the bad guys; any security heavy enough to stop them would make the friction cost of enabling AIS high enough to effectively lock out many legitimate users who have actual need for it.
Suppose for example that AIS receivers were password-protected so that a skipper had to enter an MMSI/password pair periodically to maintain access. The consequences you’d be begging for would include (a) most boaters never changing a factory-preset password that the bad guys would swiftly learn, (b) forgetful boaters putting their passwords on post-its near the AIS receiver, (c) boats being raided and stolen for receivers with known passwords, (d) non-forgetful boaters being threatened and tortured for their passwords.
Ineffective security is often worse than none at all. This would be one of those cases.
Also see my Comment to USCG on NAIS policy
(I have attempted to leave this as a comment on Captain Sweeney’s blog,. but the UI and captcha challenge there is so badly designed that I don’t know whether or not I have succeeded.)
Here’s a security model that might work for at least a while: use a DRM chip to restrict AIS data temporally and geographically. Use a cryptographically secure pseudorandom function, seeded by some master key, to generate symmetric encryption keys for every (latitude, longitude, time) triplet, down to a resolution of, say, half a degree and 6 hours. Implement this PRF on a chip that takes a GPS signal as input and outputs the key for your local coordinates, as well as all those adjacent in all three dimensions. Use this key to encrypt your AIS data, and publish the encrypted data.
Beating this system would require an adversary sophisticated enough either to spoof a GPS signal or to extract the master key from the chip. It would still allow collision prevention, and would still allow the fellow on Puget sound to know what maritime traffic is passing him by. At the same time, presuming the DRM holds up, it would prevent pirates from using the system to stalk any ship that isn’t already close enough to spot with a telescope.
>seeded by some master key
Judging by the history of similar systems, said key would remain unknown for all of, oh, about three weeks.
> Judging by the history of similar systems, said key would remain unknown for all of, oh, about three weeks.
I think this is a hasty generalization from a couple of extraordinary examples. Unlike software copy protection, hardware-based DRM is a problem that by-and-large favors the defender. This is why smartcards exist and generally work. Furthermore, the set of people motivated to attack AIS would be smaller and probably less sophisticated than in the case of CSS and AACS, which are the systems that I assume you’re thinking of.
Eric, your AIVDM link doesn’t work. It should be “AIVDM.html”, not “AIVDM.htm”.
ESR says: thanks, fixed.
> hardware-based DRM is a problem that by-and-large favors the defender
In your future trolling endeavors, try not to be so obvious.
If you think I’m trolling, then I invite you to purchase an X509 smartcard from any reputable vendor, have it locally generate a certificate, and then extract the private key. If you have a physics degree and access to an electron microscope, maybe you’ll eventually succeed. If so, then my next challenge to you will be to find me a Somali pirate with the same background.
>have it locally generate a certificate,
And there’s the problem. Supposing we stipulate that smartcards made this way are secure, you couldn’t have an equivalent of a “locally generated certificate” in the AIS case; the economics of the AIS receiver market wouldn’t support it even if it could be reconciled with the goal of making broadcast information decryptable by all nearby listeners. In practice, you’d end up with one master key and the same vulnerabilities as the CSS/AACS case.
I’m afraid you’ve fallen into what that XKCD cartoon Morgan Greywolf cited appropriately described as “crypto-nerd fantasy”. In other words, failing to take a sufficiently inclusive systems view of the problem, including interactions outside the scope of the security system.
@esr: Hmmmmm….this seems appropriate. ;)
@dfranke:
I honestly can’t think of a hardware-based DRM system that hasn’t been cracked. Everything from copy protection dongles to the aforementioned CSS and AACS. The problem is that, ultimately, the end-user will already have the encrypted data, the mechanism necessary to decode it, and the key. All they have to do is put them together. This is Crypto 101 stuff, Daniel.
Morgan: I honestly can’t think of a hardware-based DRM system that hasn’t been cracked
TPM chips. To the public’s knowledge, only one out of many vendors has ever been successfully attacked, and what the guy went through to pull it off was pretty amazing. It was certainly more impressive than spoofing a GPS signal would be, which I’ve already stipulated as a weakness of the system.
The problem is that, ultimately, the end-user will already have the encrypted data, the mechanism necessary to decode it, and the key. All they have to do is put them together. This is Crypto 101 stuff, Daniel.
It’s really a physics problem, not a cryptography problem. It basically comes down to figuring how to build a box that you can’t break into without destroying the contents.
ESR: Supposing we stipulate that smartcards made this way are secure, you couldn’t have an equivalent of a “locally generated certificate†in the AIS case; the economics of the AIS receiver market wouldn’t support it even if it could be reconciled with the goal of making broadcast information decryptable by all nearby listeners. In practice, you’d end up with one master key and the same vulnerabilities as the CSS/AACS case.
Are you telling me that the economics of the AIS market wouldn’t support issuing each AIS receiver a unique master key that’s shared with a central server? I’ll take your word for that, but I’m surprised.
>Are you telling me that the economics of the AIS market wouldn’t support issuing each AIS receiver a unique master key that’s shared with a central server?
Yes. Remember, we’re taking ships at sea here. How are you going to guarantee a connection to the central server? Ain’t no WiFi where you’re going; in fact, the only option is low-bandwidth, long-latency connections via satellite. And the equipment to do that is pricey.
As others have indicated, key management is difficult. Any system that relies on the perpetual secrecy of keys built in hardware will not meet its operational goals. I feel the smart-card example is a bit of a red herring, as it doesn’t really apply here. Also, side channels such as timing attacks don’t require electron microscopes. Hardware the attacker can connect to equipment of his choosing, will be broken. Secrets that must be kept by hundreds of people at dozens of companies in dozens of nations, will not be. And I guess now you’ve trolled us all.
I’d actually like to go the other way with the protocol design: simpler, not more complicated. AIS in its current form seems quite heavy for the task of collision avoidance. I only need to know that I’m on a collision course with a big ship; I don’t need to know who owns it and what it’s carrying. This sort of information is of far more use to taxation and enforcement authorities (and, incidentally, terrorists, pirates, smugglers, and thieves, but those use cases probably weren’t considered while they were designing AIS). That’s no surprise, given who set up the system and mandated its use.
Capt. Sweeney is also fairly transparent here. Any boat he would bother steering around would be able to afford the fancy “locked-down” AIS equipment. Smaller boats operate at their own risk in his vicinity. Anyway, he’s trying to shut the barn door several years after the horses have left. I doubt many ship owners would be happy about intentional obsolescence of recently-installed mandatory equipment, and even that wouldn’t really produce the secrecy he desires.
Yes. Remember, we’re taking ships at sea here. How are you going to guarantee a connection to the central server? Ain’t no WiFi where you’re going; in fact, the only option is low-bandwidth, long-latency connections via satellite.
Okay, then I’ve misunderstood the parameters of the problem, and need to know more about how AIS works before I can answer whether or not there’s any decent technological solution. But what Jess suggests in his middle paragraph sounds sensible on its face.
@Daniel, I think you need to do more study on the history of DRM and closed encryption systems. From subway access cards to cell phone systems to music and movie DRM to video game mods to the NSA’s Skipjack algorithm, any closed system that has been used (or even merely proposed for use) by the public has been broken, usually in a ridiculously short period of time, and often by people with no more interest in the system than the challenging of breaking it. Why? Because security is hard, and most people charged with implementing security for a system do so at the end, not at the beginning.
On a different note, I haven’t heard anyone propose how they were going to handle backward-compatibility for Secure-AIS? Since there’s no way to successfully replace all AIS receivers and transmitters with new ‘secure’ equipment simultaneously (and no budget to do so if it were possible) there isn’t any real way to make the existing AIS go away short of shutting off all of the government sponsored pieces, and it wouldn’t be in the public good to do that.
Trivia question: how many times has the FAA tried to upgrade the US ATC?
Because security is hard, and most people charged with implementing security for a system do so at the end, not at the beginning.
Indeed, this, and not any of the circumstances particular to hardware or closed systems or DRM, is the crux of the problem. The majority of all security systems get broken, regardless of any of these advantages or disadvantages, because implementors are stupid.
@Daniel, not necessarily stupid. As a programmer with more than 30 years experience, let me assure that inexperienced, untrained, and unimaginative are all possibilities as well. Another problem is when otherwise secure components are used beyond their intended (and tested) use. As an example, some encryption algorithms are perfectly secure when used in non-reentrant fashion (ie: in a single-threaded embedded system) but are horribly insecure when used on a multi-process/multi-threaded OS (such as Unix, Windows, etc). If I design a hammer that is intended for hand-use, but you put that hammer into a robot that runs continuously, striking an object every 15 seconds, whose fault is it when the handle breaks?
I think there’s more to it than that. We need a corollary to, or perhaps a general case restatement of, Bruce Schneier’s “Digital files cannot be made uncopyable, any more than water can be made not wet.”
The stupidity of implementers certainly is an issue when attempting to secure private communications, or attempting to authenticate a communication — we seem to have reasonable theoretical underpinnings of both private key and public key cryptography for those functions, even though, for example, there is no solid proof yet that somebody can’t come up with a great new factoring algorithm tomorrow — the risk seems acceptable. But when cryptography is stretched to cover things outside those problem domains, like being able to play a DVD on these 600 million licensed players but nowhere else, or like being able to have a ship broadcast location and bearing information to all those and only those with a legitimate need to know, the stupidity of implementers is only an issue in that anybody who has studied the matter deeply (and thus is not merely ignorant) who still thinks cryptography can realistically be used for those problems, is either stupid by definition, or is an as-yet-unknown genius who should explain it all to the rest of us so he can get his fifteen minutes.
Creator/Notator on the Atari ST has stood for 20 years without a functional crack. But it’s unusual:
1) Its primary author, Gerhard Lengeling — having virtually completed his studies for an MD and then dropped out to teach himself programming — is probably smarter than any of us posting here and that’s really saying something. He’s also German; you know the Germans make good stuff!
2) Notator is considered one of the best engineered MIDI sequencers on the market. Pros keep their old STs humming just to run it.
3) Pro-quality MIDI sequencing was and is a niche enough market that spending a lot of time making the copyright protection airtight and robust is a worthwhile investment; you can easily recoup all the costs back with the premium price you charge. Therefore, half the development time spent on Notator was spent just on the copy protection. (And they still had enough time and money left over to make the product itself world-class…)
While it’s possible to — in theory — retrieve every piece of information necessary to crack a closed cryptosystem, it’s also possible to design such a system that is resistant to virtually any practical human attack, even attacks by determined humans with exotic equipment. Remember, that TPM crack required the cracker to sizzle off the chip packaging with acid and probe it while it was running — and it only worked against one vendor’s model of chip!
1. My first thought at reading this article was that if you are looking for a good security or cryptography solution for civilian used then you just might look at what the better kinds of armies or navies are doing and imitate it.
2. Then I realized that the reason this sort of thing works fairly well in the better kinds of armed services is discipline: they simply do not tolerate password on post-it notes on the screens and have effective ways of prevent users from doing so. Generally such ways are in the civilian realm not possible.
3. Such levels of disciplined behaviour are possible in the civilian realm only if there is a strong enough personal interest to do so: people tend to do a fairly good job of protecting their credit card PIN codes, but they care very little about the computer passwords: the home PC has a low chance of being broken into and contains few important materials, and the corporate network is the problem of the employer and not the problem of the employee. Security doesn’t work because there is little personal interest in making it work.
4. One way out is simply accepting that civilian systems are insecure, period. Another one is making people legally responsible, such as getting your password stolen and used to harm a third person/organization would mean you could be sued for negligence.
oh now you’re getting all “common sense” again
just because it’s called that, doesn’t mean it is. yew crazed fewl yew.
esr, your list of consequences is ordered A-B-B-C instead of (i assume) A-B-C-D.
@esr: Captain Sweeney here seems most concerned that realtime AIS information is available on the Internet for anyone to see. Even if AIS receivers were equipped with some sort of DRM, what’s to stop pirates, terrorists, or other associated bad guys from simply acquiring their own AIS receivers?
I’m also not convinced that having that information on the Internet is such a huge deal. After all, as you point out, there simply isn’t decent Internet access available at sea anyway.
Just to clarify: what I mean is that marinetraffic.com gets this data from AIS itself somewhere down the line, what’s to stop the baddies from receiving this data with their own DRM-equipped equipment?
I am thus […] a domain expert on AIS
A domain expert who quotes the Wikipedia article on AIS sans attribution!
link
Firstly terrorism isn’t really the big issue the media makes it out to be. You’re more likely to be killed by lightning than in a terrorist attack. Not because our anti terrorism policies are effective (they’re not), but just because there are simply not a lot of competent terrorists around. That the bad guys got lucky a few times is no reason to impose all kinds of restrictions on the general public.
Secondly piracy is not such a big problem too, except in a small area of the world, and it wouldn’t be a problem if went about it more rigorously, eg. killing the pirates in stead of paying them off.
This will however not keep those who need to be seen to do something to do something. And where there is a opportunity to set up yet another licencing agency that can collect monopoly rents you can be sure that some industry leaders and politicians will be in favor of it.
Daniel,
AIS functions as a short range digital broadcast of position information. For cost and convenience it is sent over standard marine VHF frequencies. This allows the equipment to use existing antennas with just the need for a splitter (at most). Because of this, AIS is limited to line-of-sight range from the position of the antenna. On a high mast or ship mount, 20-25 miles at best. For small craft or congestion waters with land interference, 5-15 miles is typical.
AIS isn’t actually intended for collision avoidance as a primary role. It’s primary purpose is as a navigation aid to allow a navigator information about possible hazards in their vicinity and be able to act upon them in a timely manner. Collision avoidance might be the outcome but AIS by itself is not required to do that. AIS also doesn’t need to broadcast supporting information like vessel name, type, cargo, etc. Just positional information to allow receivers to plot them. Don’t believe me? Pull down an AIS plotting application for your area and click the ship targets. For my area (Chesapeake Bay), usually only 20-30 percent of the ships additional information besides position, heading, speed and what they are (Cargo, Tow, Tug, Fishing, etc). And most that do are US-flag vessels that work on the Bay.
So the usefulness of AIS in terrorist scenario is by design limited. First, you have to be close enough to the ship to pick up its transponder. And if you’re close enough, odds are good you are or will very shortly be within visual range of the ship anyway so what’s the point of encryption? And if a vessel finds that AIS is drawing terrorists and pirates to them, they can simply turn it off. And even if it isn’t, terrorists are going to target vessels that are easy targets. Most of the time ships are targets as they’re approaching port and it doesn’t take a lot of equipment to float in a small boat with a pair of binoculars outside of New Jersey, New York, Long Island or Baltimore and look for that target that is “just right”.
The purpose of the system is simplicity and ease of use/access. If anything, the cost of AIS hardware is plummeting (see Standard Horizon GX2100W for an example) and will continue to get cheaper. Why introduce crypto onto it and retard access or usage? What purpose will it serve? In the greater marine community, encouraging vessels to have AIS receivers can only increase safety. Especially in crowded waterways or frequently traveled shipping lanes. Stop this against what? The nebulous threat of a terrorist or pirate? Please.
Some technologies need to be left alone because they work. This is an example that does.
>AIS isn’t actually intended for collision avoidance as a primary role.
That depends on who’s talking. Some authoritative sources on the design goals emphasize that, some don’t.
ESR:
>AIS isn’t actually intended for collision avoidance as a primary role.
That depends on who’s talking. Some authoritative sources on the design goals emphasize that, some don’t.
Agreed. I take the COLREGS view of AIS as an aid and not to be used as sole mechanism to make a decision in avoiding collision. Always have more than one source of information even if that second source are your eyes keeping watch. Same applies to GPS.
@lapin:
That’s really not a very good troll.
Eric obviously thought he was quoting a fact — you know, a non-copyrightable small piece of uncreative information. And, he was, I believe, correctly quoting a fact (and was IMO correct to believe that wikipedia is usually OK for that sort of fact).
Why would the “International Maritime Organization” care about non-international voyages? They don’t. But the US does, and our government regulations extend the IMO’s protocols for large domestic ships.
But even if Eric had gotten it wrong, the classification of which ships are required to use AIS has nothing whatsoever to do with the actual operation of the AIS protocols, which is what Eric claims to be a domain expert in.
This is entirely a problem of using the wrong fucking tool for the job.
You want to solve problems with pirates, sink the boat they’re riding in and the mother ship they’re operating from. Then burn the docks they shipped out from and the town that gave them succor.
Given what I’ve seen so far, a semi-auto .50 cal would be adequate for the first two, and a single fly-by with a MOAB would be sufficient for the second two.
Do that twice and I bet piracy goes WAY down.
>You want to solve problems with pirates, sink the boat they’re riding in and the mother ship they’re operating from. Then burn the docks they shipped out from and the town that gave them succor.
Prissy left-liberals should note that this procedure – including the burn-the-town part, when applied to stateless pirate havens like Somalia – would in fact be completely in accordance with international law and the customs of the sea from Grotius onwards, and was the normal practice of navies into the early twentieth century. Hanging the pirates from a convenient yardarm would be legal and customary as well, but might be a bit much for modern sensibilities.
> If so, then my next challenge to you will be to find me a Somali pirate with the same background.
I doubt that there’s a Somali pirate who can make an internal combustion engine, yet Somali pirate boats have said engines.
The obstacle for pirates, like the obstacle for the rest of us, is not whether we can make something, but whether we can afford to pay someone who can make it.
Of course, perhaps we could find other experts of AIS and get their opinions too? Sort of a ‘peer review’ type of thing.
>Of course, perhaps we could find other experts of AIS and get their opinions too? Sort of a ‘peer review’ type of thing.
Exactly two people, as far as I know, have submitted comments on the NAIS policy docket relating to AIS disclosure and security. One of them was me and the other is a marine scientist who’s a GPSD user. This suggests that the pool of peer experts is not large.
i do have to agree with william on this one, burn down the ships, and burn down the docks. problem solved. i also think that public access to the AIS ship information shouldn’t be prohibited. by the way nice site, first time here.