COMSEC: December 2009 Archives

 

December 20, 2009

This is seriously not good. It turns out that both military aircraft and drones transmit unencrypted video feeds of their activities:
How'd the militants manage to get access to such secret data? Basically by pointing satellite dishes up, and waiting for the drone feeds to pour in. According to the Journal, militants have exploited a weakness: The data links between the drone and the ground control station were never encrypted. Which meant that pretty much anyone could tap into the overhead surveillance that many commanders feel is America's most important advantage in its two wars. Pretty much anyone could intercept the feeds of the drones that are the focal point for the secret U.S. war in Pakistan.

Using cheap, downloadable programs like SkyGrabber, militants were apparently able to watch and record the video feed - and potentially be tipped off when U.S. and coalition forces are stalking them. The $26 software was originally designed to let users download movies and songs off of the internet. Turns out, the program lets you nab Predator drone feeds just as easily as pirated copies of The Hangover.

And here's the real scandal: Military officials have known about this potential vulnerability since the Bosnia campaign. That was over 10 years ago. And, as Declan McCullagh observes, there have been a series of government reports warning of the problem since then. But the Pentagon assumed that their adversaries in the Middle East and Central Asia wouldn't have the smarts to tap into the communications link. That's despite presentations like this 1996 doozy from Air Combat Command, which noted that that "the Predator UAV is designed to operate with unencrypted data links."

...

Meanwhile, military officials assure are scrambling to plug the hole. "The difficulty, officials said, is that adding encryption to a network that is more than a decade old involves more than placing a new piece of equipment on individual drones," the Journal notes. "Instead, many components of the network linking the drones to their operators in the U.S., Afghanistan or Pakistan have to be upgraded to handle the changes."

So, obviously this isn't the best design anyone has ever heard of. It would be interesting to ask whether the control channels used to send commands to the drones are are similarly unprotected.

In any case, there are two major technical obstacles to adding encryption to a system like this. The first is key management, as mentioned in the first linked article; you need to somehow get keys to the relevant people. The second is the problem of sending encrypted data around, as mentioned in the last graf.

I'm not overly worried about the need to upgrade individual network elements in between the drones and the operators: unless those elements actually process the data instead of passing it along, they should be relatively indifferent to whether the video is encrypted or not. I can imagine a couple of types of processing that would cause problems. For instance, if the intermediate elements compress the data with some lossy compression algorithm, this will interact badly with encrypted data, which is not only incompressible but also extremely sensitive to any damage. But if they're just relaying the data (which seems likely given that this seems to be all built with commodity protocols), that seems unlikely to cause any problems. It's not like all the routers on the Internet need to be upgraded whenever you get a new version of your Web browser.

As usual, the key management problem is more serious, as suggested by this paragraph:

"Can these feeds be encrypted with 99.5 percent chance of no compromise? Absolutely! Can you guarantee that all the encryption keys make it down to the lowest levels in the Army or USMC [United States Marine Corps]? No way," adds a second Air Force officer, familiar with the ROVER issue. "Do they trust their soldiers/Marines with these encryption keys? Don't know that."

As there are no encryption keys at all in the current environment, it's hard to see how the situation could get any worse by giving them to every marine in the field, but it's understandable that one would want to do a little better. In this case, we actually have two kinds of capabilities to deal with: those required to view the video feed and (in the case of drones) those required to remotely control them. These aren't necessarily going to be issued to the same people: you may want soldiers in the field to be able to view the video feed from the drones, but fun as it might be there's no real reason to let them pilot the thing. Since only authorized pilots are likely to be allowed to operate the drone, key management here seems pretty simple: just have a key manually shared between the operator and the drone.

One-way video feeds to soldiers in the field require a slightly more sophisticated system, but it's not inherently complicated, as we can use the same schemes used for broadcast encryption: We have a key of the day (or the hour or whatever) and we use that to encrypt the video. Each device has its own key and we periodically broadcast the key of the day encrypted under the device key. If a device gets lost or stolen, we just stop encrypting under that key. This doesn't work that well for video encryption because it's easy to get a decryption box and so attackers can just get a box and extract the key. Presumably soldiers in the field do a better job of keeping their viewing units in their possession and don't deliberately give them to the Taliban and we can periodically verify that they still have them. And as noted above, it's not like any encryption system we deploy is going to make the system less secure, so it's not like it has to be perfect.

Acknowledgement: Perry Metzger pointed this story out to me.

 

December 7, 2009

Cryptome has posted the lawful intercept compliance policies of a bunch of ISP and telephone providers. I haven't done more than skim these, but so far what's shocking seems to be how un-shocking they are. It's certainly no secret that network providers need to comply with law enforcement requests for lawful intercept, and the purpose of these guides seems to be to streamline the process by documenting what the LEA neads to provide in order to get an intercept. There seems to be some complaining on /. about the fact that these policies contain the the amount providers expect to be reimbursed for various kinds of activities, but given that (1) the providers do in fact have to comply with subpoenas and (2) CALEA provides for reimbursement, it's not like it's unreasonable for them to get reimbursed. At less than $100 per request, it's not like it's going to be a big revenue source for Yahoo.

A little more distressing is that none of the policies I looked at (remember I didn't study them that carefully) seem to explicitly say that they won't provide intercept services except when legally required to (this is not the same as when legally permitted to.) That's something I think I would like my service provider to adopt as a policy, but I can't say I'm surprised that they haven't done so.