Intercepting Predator Video | Hacker News Reader

Intercepting Predator Video

schneier.com

89 pointswglb46 comments

UAVs are flown by airmen sitting at comfortable desks on U.S. military bases, where key management is simpler. But the video feed is different. It needs to be available to all sorts of people

Poppycock! At least encrypt the stream going up to and coming down from the satellite! If lots of people have to see it, redistribute it afterwards. The uplink/downlink encryption is the exact same key management problem as the command signal! Hell, why not use the same key. The video signal going up to and back from the satellite is hanging out there, accessible from the majority of earth's surface. But encrypt it and beam the encrypted signal to those "comfortable military bases." Then you can re-encrypt it for distribution, and completely change the key management problem to suit your needs. (Essentially make it into two key management problems. Divide and conquer.)

I usually like what Bruce has to say, but this blog post wasn't well thought out.

EDIT: Upon re-reading, Bruce's point is that it's the NSA's bureaucratic requirements that make it too cumbersome for an encrypted feed to be easily made available. So it's just easier for them to leave it unencrypted. I still say poppycock. If they were really being clever, they could "leave out encryption," but still obfuscate matters. (Both from the signal standpoint and from the bureaucratic standpoint.)

Even something like a "new compression algorithm" would probably be enough to flummox the Russian software program. If it were unique to the drones, then the sat-download program authors would have no economic incentive to implement it. (And some "representatives" of our interests could have talks with them about it if they happen to implement it anyway.) This isn't strong crypto, but it would at least raise the bar.

EDIT: To those with poor reading comprehension: the tactic is a bit of "divide and conquer." (Colloquially, not algorithmically.) Divide the "key management" problem into two: "Sat up/down link" and "distribute to allies." The "Sat up/down link" is the exact same key management problem as for the control link. Also, if you solve that key management problem by just using obscure compression, then you can distribute the video using ordinary website access controls on establishing streams. Not strong crypto, not uber-secure, but still better than what's there now.

How is the control link key distribution problem the 'exact same' problem? The control link key is secured in the aircraft and at military bases. There's no additional need for ad-hoc distribution, you never have to send a key to someone in a trench somewhere who's too busy shooting to put pants on. The entire point of the article is that the design decision not to encrypt the video was likely influenced by the problems of ad-hoc key distribution. To this reasoned analysis your response is 'hey just do key distribution!'. Doesn't seem very well thought out at all.

'What's the password of the day' is one of the oldest and most basic security measures in military history. Is it a tough technical challenge in a global theater? For sure. But I'll warrant that the bulk of military communications do not take place in clear anyway, so it's a manageable problem.

The point from the article is that the NSA doesn't permit 'password of the day' style encryption - it's all or nothing.

For the operational requirements of the predator, nothing was better than all. They'd prefer an intermediate option, but it isn't available until procedures change.

I get that. It just seems kind of perverse to transmit in clear because scheduled encryption has risks of its own. Last time this was posted I mentioned that while interception of drone video by the Taliban or whoever is probably not that big of an operational threat, bigger strategic competitors like Russia and China have probably accrued a good lot of intelligence by amassing such data in quantity. Perhaps the NSA's thinking is that this is less critical than exposure of dynamic encryption models to the wild.

Lose a point for poor reading comprehension. (EDIT: Probably not comprehending muy actual proposal and knocking down your misread straw man.)

Encrypt the uplink/downlink to protect it against satellite eavesdropping, worry about the distribution to users separately. Uplink/downlink video keys need to be distributed to the same folks who need the control link keys.

Sorry, unless you mean something else, you are just wrong. Encrypting a video link drone->sat->base and leaving out the allies is the exact same key management problem that they are solving with the control link encryption. Basically, leave out drone->sat->allies and solve that another way.

The video data is redistributed to a wide list of folks, people on the battlefield, people in command posts both locally and remote. The control link is not redistributed, it is a closed link between the pilot and the UAV, the data is not needed elsewhere nor is it sent elsewhere.

Do you see the difference?

Read the proposal. Establish a secure link parallel to the control link. Use a different mechanism to redistribute. In that case, there is no difference in the key management of the first stage.

Geez, how many times do I have to go over that?

Good idea but there is too much delay in such a model. Even more so the extra complexity is too much of a trade off (see my other post)

Yes, but the point I'm making is that there is no difference in key management. Your assertion is that there is a latency problem. That may be true. But the key management for the 1st half would be the same.

So you're going to continue insisting that there is no difference in key management between the scenarios -

- communication between two parties, one of which is physically secure with plenty of time in advance to agree on keys.

- delivering keys to arbitrary receivers on arbitrary points of the world, potentially under combat or other severely adverse conditions with very limited advance warning.

Are you sure you have the right definition of what 'key management' is? Isn't it easier to just admit Bruce Schneier actually _had_ thought out his post and you, not so much?

http://en.wikipedia.org/wiki/Key_management

My point is that there is no difference in key management for the 1st part (drone->sat->base). The rest is a different key management problem, one which the military already faces with communications to forces in the field and with allied forces. But by taking the 1st part out of the picture with the same key management used for the control link, you don't have plaintext perched on a satellite visible to the whole globe.

You still have to solve the rest, but that is at least an improvement.

Your passive-agressive link to Wikipedia -- what is your point in this? What exactly in the article did I miss?

> The rest is a different key management problem

Which is the entire problem.

You seem to be of the mis-conception that the video goes back to base and then is redistributed. AFAIK this is not the case :) Also, importantly, these signals are being intercepted as they are transmitted to the troops on the ground :)

You seem to be of the mis-conception that the video goes back to base and then is redistributed. AFAIK this is not the case :)

Thanks for starkly admitting your reading comprehension problem. My proposal is for the video to be encrypted all the way back to the base then redistributed.

Now please go back and edit your responses to me to correct this incomprehension of my position.

Arrrgh, don't they cover reading comprehension in schools anymore? Thank you.

EDIT: Anyone would find this frustrating:

Me: "They are already doing X. That would be the same as Y. I propose they do Y."

cl: "No it doesn't"

Me: "X = Y (paraphrase)"

cl: "No it doesn't"

Me: "X = Y (2nd paraphrase)"

cl1: "Okay it does, but that doesn't solve the problem."

cl2: "Oh, I thought you said they were already doing Y."

sigh

I'm not going to take the time to try to work out who is right and who is wrong in this case, but I believe from my limited time here on HN that the attitude you're displaying in this comment is not entirely appropriate. You can certainly make your point without the personal attacks, even if others don't.

Please, stick to the facts, and if people mis-understand you then restate your point more clearly and addressing the misunderstanding. If you're right, most times they'll apologise and everything is great. If you're wrong then you don't look like a complete asshole.

As I say, I'm not addressing the technical points - I probably don't have the background, and it's Christmas, so I certainly don't have the time. I'm not down-voting you because I can't judge the technical merits, but I'd ask you to be more considerate in your tone. It's one of the things that makes HN so much more pleasant than most other fora.

Please.

Ive replied to all your points clearly. What you propose is best case scenario. But as I said the delay and the key maanagement on the battleield is far too complicated against the benefits.

You finally admitted the misconception that I thought the video went back to base to be redistributed. Then you changed your position to say, okay, it's the same key management problem, but that doesn't solve anything. Now you're glossing over my 2nd proposal that builds on top of my first one, which avoids key management on the battlefield.

Congrats. Brilliant troll, and you made me look like the bad guy.

Your proposal is not a response to Schneier's points, you've merely moved the important problem off of the balance sheet with some hand waving.

Congratulations, you've solved the easy problem. When you've solved the hard problem, then you'll have a valid counter-point to the article.

Congratulations, you just admitted my point: taking the first leg and just encrypting it is equivalent to the control-link key management problem -- a point you dismissed again and again earlier in the thread.

Now, do you make valid points about the difficulty of key management for the 2nd problem? Yes. But mainly I have been expounding on the equivalence of the 1st part. I am correct about that. Have been this whole thread. You just admitted it. Thanks.

Now on to the rest. The military already faces a key management for other communications. They just need to do it with enough bandwidth to support video feeds to take care of the 2nd part. Certainly, they already do such key management for other communications. Will it be trivial to implement? No. But is just putting things up on a satellite in view of the whole globe? I think not.

Do you still not get it? It doesn't matter if you are "right" on your points. Your points don't address the subject sufficiently. You've created for yourself a tiny bubble of logic disengaged from the main discussion where you are, in the abstract, "right". It doesn't matter if you're "right" because you're not having the same discussion as everyone else.

In the Iraqi case, I'm guessing the bandwidth of the signal would be prohibitive to send out on anything other than satellite.

Also, if you send it out again you will still have a key management problem if the data is encrypted.

I do agree with the premise that if there is crypto it doesn't have to be strong as the enemy do not have a proper analytic capacity. While I also know that the current US defence chief wants gear to fight the war on his hands right now and down the track, but you'd think that they might have considered that crypto would be a good idea at some point and at least had some plans on how to incorporate it. At the moment it just looks like the US military were caught with their pants down.

In the Iraqi case, I'm guessing the bandwidth of the signal would be prohibitive to send out on anything other than satellite.

So, by obfuscating with a "new compression algorithm" you can also actually do compression and save yourself a little bandwidth. This also gets you over bureaucratic hurdles. "By introducing this algorithm, we are save X gigabytes per whatever."

Exactly. These drones (or similar drones) are able to fire laser or radio guided missiles. I can't believe fire command and control of the drones isn't handled with 'hardcore' security of some kind. But it was too hard to encrypt a video feed? I don't buy it.

Key management is a tricky issue, especially when your neighborhood working with AT&T No Such Agency spies are the ones who get to dictate how keys are managed (i.e. same as if your adversary are soviet crypto-hackers).

Schneiers argument is that encryption is not a viable option because key management would be a nightmare. The insurgents get the raw videostream by intercepting it using some sort of antenna to pick up the signal directly from the predators. Since, presumably, the military actors that need the videostream don't actually pull it out of the air themselves but get it through some kind of military channel (Internet, VPN or whatever they use) wouldn't the obvious thing to do be to encrypt the raw stream from the predators to the command post where the signal is picked up by the mlitary and distributed and send it on to whoever needs it in unencrypted form? That way the insurgents wouldn't be able to pick the signal out of the air, and everyone associated with the military who needs it would have access to it. No key management nightmare needed.

I even don't buy that key management is too hard. The logistics of sending encryption keys around secure military networks has got to be stupid easy compared to supply chain for, say, jeeps. Giving out encryption keys is the same problem as moving jeeps around, just different logistics. Things need to go from supplier to recipient. Keys can be revoked and set to expire automatically, that's got to make things even easier. Inside the armed forces, anyway.

Between "key management is hard, lets go unencrypted", and underestimation of locals, I'd much more buy into the echo chamber that said "towelheads are dumbasses who couldn't find sand in their own damn desert" much more than anything else.

Read the bit by Jeff Schroeder at the end of the comments, that pretty much deflates that whole key management argument.

Yes, but it only applies for US troops with security clearance. As he points out guys on the ground and allies that they don't necessarily want to share crypto with can't join the game.

So, you don't want to share crypto with your allies but you do want to share your data with the enemy ?

Precisly!

Just as I may want to share how much money I have in the bank to a business asociate to prove I have the assest to make a deal.

I'd do this by showing him/her the bank account information on screen, but I don't want to give him/her the transit, bank acount number and password to access said bank account.

Why the feeds are unencrypted is irrelevant, as are all the statements about how easy or hard it should have been to "do it right."

The only relevant issue is "what effect does the compromise have on the usefulness of the intelligence gathered by the UAV?" For a variety of reasons I would say this causes only a very small amount of degradation in the usefulness or lifespan of the intelligence. Do I think it should be fixed? Yeah. Do I think it's the most life-saving use of engineering resources? No. Do I think all the arm-waving is going to cost more than the solution? Definitely.

FTA: "The problem is, the world has changed. Today's insurgent adversaries don't have KGB-level intelligence gathering or cryptanalytic capabilities. At the same time, computer and network data gathering has become much cheaper and easier, so they have technical capabilities the Soviets could only dream of. Defending against these sorts of adversaries doesn't require military-grade encryption only where it counts; it requires commercial-grade encryption everywhere possible."

Bruce's points against broadcast encryption seem rather weak to me. If it was possible to distribute secret keys during WW2, surely it's also possible in 2009 - probably a great deal faster and more efficiently.

If a UAV was flying over areas of the world that I know well it's highly likely that I'd be able to identify the locations that it was looking at, and send out warnings/orders accordingly. Also I could perform reconnaissance on the typical flight paths of the UAVs, and plan accordingly.

Probably a major risk in the world of 24 hour news and P2P networks is the possibility of recording and later re-broadcasting closeup video of what happens when UAVs misidentify their targets and hit civilian populations. This could result in some public relations catastrophes for the UAV operators. If the military are happy for this information to be broadcast unencrypted they should also prepare themselves for said footage to appear on YouTube or TV news.

Every accessor needs the keys - all relevant field commanders, etc. They also need security clearances. The keys need to be stored and managed securely. They should also be updated regularly, which means that all commanders need new keys at some point. I presume the keys for each UAV would be different.

In WW2 it was only a few top commanders who worked with Ultra (afaik), and it wasn't anywhere as regular as broadcast video. I guess the main difference here is the number of users is that much greater and in Schneier's opinion the value of the information is that much lesser.

> If it was possible to distribute secret keys during WW2, surely it's also possible in 2009 - probably a great deal faster and more efficiently.

Not really. Think how widely these keys would have to be spread to have any use. The drones are often used for immediate intervention: i.e. if needed they are launched to provide forward intelligence to units on the ground.

That kind of key management is a nightmare: especially when you think other nationalities/agencies/services might require the feed instantly too.

It would be a perfect setup to have encryption and key management - and I expect that technically a structure could be set up to do it securely. But one important feature of battlefields is that they get extremely confused and disorganised - it would break down at key moments, and regularly. The key to battlefield tech is always simpicity. So it's a tradeoff; one that doesn't seem to have worked out badly so far.

Ok, maybe they didn't intend it, but what about the psychological warfare side of it? Didn't whistling WWII bombs further scare the folks on the ground?

Today's wars are more psychological than ever. The enemy probably watches and gets scared by video of their locations being watched and blown up. They might even think twice after seeing things from our perspective.

Or maybe they even did. Video really goes out over an encrypted link, and this is a setup. Maybe they have a good way to track the hardware needed? Maybe wait for the insurgents to noticeably use this technique, then midnight UAV runs with the unencrypted satellite feed disabled can go on unnoticed for longer. Hell, use this to feed false data so that instead of insurgents running out of a building just about to be bombed, they run right into a squad waiting to capture them.

There are also a spook-side theories. This could be a subtle poke in the ribs to say the insurgents could be doing this, and General Atomics embarrassed itself into a needed round of funding.

Yeah, that's cool. It's like the movie "Sleep Dealer". They looked for someone watching a feed and dropped a bomb on his house.

previous coverage of this subject here:

http://news.ycombinator.com/item?id=1000464

and here:

http://news.ycombinator.com/item?id=1002227

And the general reaction (on Hacker News and elsewhere) was ridicule and disbelief. Schneier explains why he thinks this is naive.

I think Bruce is focusing too much on the technical side of this, I think it simply never crossed the mind of those that built this thing that the 'enemy' would be technologically savvy enough to pull this off.

I think you're focusing too much on ignoring everything that's been written on this from the original story to Bruce Schneier's commentary.

Every source has reported that the military has been aware of the possibility the video feed might be intercepted by an adversary since operations in Bosnia well over a decade ago. It's basic common sense that the designers must have considered such a possibility as well - after all, they made the control link encrypted.

So far there is no proof that they considered that, if they had they would have probably evaluated the PR fallout from such a breach of security as well.

Judging by how this is playing out in the media so far that does not seem to look too good for those that built this system.

I disagree. Often it's easy for insiders to misjudge public reaction. Insiders have spent a lot of time with a system, they're perception of the system is colored by extensive debates by experts in the system and the consensus results of those debates. But outsiders lack the benefit of that debate and the context of all of the technical details and restrictions the insiders are aware of. To outsiders all of the technical options are equally trivial and outsiders don't have the time, context, or access to people with the expertise to have a serious technical conversation on the subject.

In short, outsiders jump to conclusions based on their, almost certainly wrong, hasty assumptions. Insiders may not appreciate that their extensive technically detailed justifications for their current procedures are utterly useless in the face of ignorant casual public armchair analysis.

Now, whether or not the experts are justified in their position is an entirely different topic, but it's quite easy to see why they may not have anticipated the PR fallout from this problem.

The one thing I find conspicuosly lacking is comments from professionals. A quick scan of Small Wars Journal found no relevant articles or comments.

OK, dug a little deeper, http://smallwarsjournal.com/blog/2009/12/insurgents-hack-us-...

Reply on news.ycombinator.com