Recently in COMSEC Category

When I first heard about government's requesting copies of Google's over-captured WiFi traffic, my first thought was what could possibly go wrong?. Shockingly, it now turns out that the French government has your password. Well, maybe not your password, but someones's password:

Wi-Fi traffic intercepted by Google's Street View cars included passwords and email, according to the French National Commission on Computing and Liberty (CNIL).

...

At the time, Google said it only collected "fragments" of personal Web traffic as it passed by, because its Wi-Fi equipment automatically changes channels five times a second. However, with Wi-Fi networks operating at up to 54Mbps, it always seemed likely that those one-fifth of a second recordings would contain more than just "fragments" of personal data.

That has now been confirmed by CNIL, which since June 4 has been examining Wi-Fi traffic and other data provided by Google on two hard disks and over a secure data connection to its servers.

"It's still too early to say what will happen as a result of this investigation," CNIL said Thursday.

"However, we can already state that [...] Google did indeed record email access passwords [and] extracts of the content of email messages," CNIL said.

Well, duh.

Look, these are packet switched networks, and to a great degree the packets are independently interpretable. Even on a much slower network, a password submission (say 300 bytes when you add all the HTTP overhead) takes far less than 200 ms. (Do the math here: even on a 56 kbps modem which is much slower than your average WiFi network this takes something under 50 ms.) Statistically, as long as you capture enough traffic to get a full packet, there's not a huge amount of difference in the number of packets you would expect to capture listening to a single network for hours versus switching which network you listen to every 200 ms. [Handwavy explanation available on request if really necessary.]

In any case, Google no doubt captured a bunch of passwords and now the French CNIL has some of them. I wonder which data set Google provided them, or, more precisely, whether they provided them with a data set captured in France or one from outside of France. From a personal perspective (though I try to use encryption whenever possible), I hope it's the second. Any readers with more legal experience know what the legal implications would be of one choice versus the other?

Regardless of where the traffic came from, it seems like it might have been nice for Google to sanitize the data to remove obvious passwords. This isn't possible in every case, but it seems likely that the vast majority of passwords come from a small number of sites, so Google could have figured out the password submission format and built some kind of masking software. It's pretty hard to tell from the press coverage whether or not they attempted this (or were allowed to), but of course if they had we would of course know that there were passwords since the masking software would have identified them.

OK, so I get how Google could have accidentally captured packet payloads when recording data for Google Street View. Mistakes happen, etc.¹ I also understand why if you were some national government you might want to investigate this sort of potential privacy compromise. That said, it's not clear that this is that great an idea:

A Google spokesman said Thursday that the data should be handed over within a matter of days. Last week, the company found itself in conflict with a privacy regulator at the German city of Hamburg, who wanted access to the data. Google said that it wasn't sure that handing over the data would be legal.

"The data protection authority in Hamburg has made a number of requests -- including to be given access to an original hard-drive containing the payload data, and to a Street View car. We want to cooperate with these requests -- indeed we have already given him access to a car -- but as granting access to payload data creates legal challenges in Germany which we need to review, we are continuing to discuss the appropriate legal and logistical process for making the data available," Google said in a statement last week.

Those challenges have apparently now been addressed.

The company plans to hand over data to German, French and Spanish authorities, according to the Financial Times, (FT) which first reported this latest development on Thursday.

This seems to miss the point a bit: the presumptive objection to Google capturing packet payloads is that it potentially contains people's sensitive information and someone might use it to learn that information. Turning it over the government presumably means that some larger set of people will have access to it. Of course, it's the government, so what could possibly go wrong?

^1.Ironically, the opposite error is the common one for packet sniffing applications: by default tcpdump only records the initial bytes of a packet. So, when you record a protocol trace, if you forget the -s 0 flag, you only end up with the beginning of the packet, which can cause problems in applications that do full packet reassembly.

Yesterday I criticized the proposed requirement of a biometric identifier for work authorization. But just because it's a bad idea doesn't mean it's not interesting to design one. Let's start with the observation I made in the previous post: smart cards are unnecessary here; what you want is a cryptographically protected object that contains the relevant data. E.g.,:

• Name
• Identification number
• Biometric (photo, fingerprint, etc.)
• Meta-data, e.g., whether they're allowed to work or not, expiration date, etc.n

Note that the actual information we're carrying here is mostly irrelevant from the perspective of security design. The cryptograhy protects whatever opaque data we happen to want to cram onto the card.

Physically, we have a huge amount of latitude in how we design the card; because all the data is cryptography, we don't need any physical tamperproofing features, just a format that will carry enough data (say 1-2k or so, depending on the size of the biometric)¹. The data could be encoded on a mag stripe, smartcard (memory type, not necessarily active), or even a 2-d bar code such as a QR code (though we're probably not too far from the limit here).

Digital Signatures
The natural approach is simply to use digital signatures. The federal government would generate a single central signing key and use it to sign everyone's cards. The public key would just be published somewhere (e.g., in the Federal Register) and so anyone could verify people's identification. (You could also use a multitier model where the central signing key identifies subsidiary keys, etc.). In any case, if we're going to use digitally signed data, we have to contend with the problem of compromise of the central signing key(s?). Someone who stole such a key would be able to generate as many fake IDs as possible. Naturally, you'd want to store the signing key in a hardware security module, which substantially reduces the window of vulnerability, since you would have to steal the module, not just the key. Still, that could happen.

Obviously, from the moment when the key is stolen, you can't trust any signatures which are generated with that key. On the other hand, the signatures generated before the key is stolen are just fine. The problem is distinguishing the two. It's natural to just publish the compromise and state that "any signatures after this data are bogus", but as Jacob Davies observes, once you control the signing key, you can make it generate any signature you want, including one over dates in the past. [Technical note: if the keys are embedded in an HSM, then you could program the module to always put the correct time in its signatures. However, attackers could potentially extract the key, so you can't really trust this level of guarantee.]

Dealing With Key Compromise
Key compromise is a standard problem with digital signatures and has a standard solution: you have some timestamping service which records when signatures were produced, thus differentiating valid from invalid signatures. The time stamping service can just be a separate signing system or (more securely) a hash chaining system such as that used by Haber-Stornetta timestamping [*].

In a system like this, each signature (i.e., identification card) is linked together in a chain of hashes. When document i is signed, producing S_i, we compute H_i = Hash(H_{i-1} || S_i). Because the hashes are one-way, once we know any value H_j, we can verify that any prior value H_i is correct, provided that we know the elements i..j. The way such a system is used in practice is that the timestamping service (in this case the federal government) periodically commits to given hash values, for instance by publishing them in the federal register. From that point onward, it's not possible to create signatures with timestamps prior to the published value, even if the key is compromised, since they don't appear in the chain of hashes implied by the published hash value.

Eliminating Signatures
It should be obvious at this point that it's possible to dispense with signatures entirely: simply use the published hash chain values to verify each document directly. In order for this to work well, however, the verifier needs to have access to the hash chain value for every signed document, which is excessively expensive in terms of data storage on the card. Conveniently, there are techniques for providing a more compact representation.

The most natural approach is to use a Merkle Hash Tree. Hash trees work kind of like a hash chain but they allow us to compress the verification information for a large number of entries into log(N) values. Say, for instance, we want to verify 1000 documents, we would need to store approximately 10 entries (the sibling nodes on the path from each entry to the root of the tree) on each card. The idea here would be that we would form a hash tree from all the identity cards produced in a given day and then use the hash tree root as the input into the hash chaining process. This would give us a mechanism for verifying any given card without any digital signatures at all, provided that we can obtain each hash chain value. Note that you just need a trusted path for the most recent hash chain value: intermediate values are verifiable from the trusted value.

Hybrid Systems
While this system is very secure against history rewriting due to key compromise, it's not very timely. You can't verify any identifier till you've seen a published hash value that post-dates it. This means that there is a direct tradeoff between the amount of data you need to ship around and how long it takes before an identifier becomes verifiable.

We can get past this problem with a hybrid system: digitally sign the root of each hash tree and then use hash chaining to link them together. Any identifier which claims to be older than the latest known hash chain value is directly verifiable without the signature. Any identifier which claims to be newer is verifiable by checking the signature. This means that once you discover a compromised key, it's only usable during the time period (weeks? months?) before the next hash chain value is published. Note that this isn't the time period during which an attacker can sign with the key but rather the time period during which one can verify signatures made with it. As soon as a relying party has a copy of the next hash chain value, they will see that the signature in question isn't incorporated into it (this also provides a tripwire for surreptitiously compromised keys).

Obviously this isn't the only design, but it's one that's reasonably well suited to the environment with a single issuer who issues a really large number of credentials and relying parties who only need to verify fairly infrequently.

^1.Note that if we want the cards to be usable without a scanner, then we need ordinary physical authentication and tamperproofing features of the kind used for drivers licenses, passports, etc, but this is orthogonal to the digital security features. Really, you have two separate identification devices in the same form factor, with the digital one being much stronger—if you can read the digital identifier all the security features on the piece of plastic are redundant.

I just finished complaining in the KARP WG meeting about their rationale for automatic key management:

But why do we need a KMP?

• To address brute force attacks [RFC3562] recommends:
  • frequent key rotation,
  • limited key sharing,
  • key length restrictions, etc.
• Advances in computational power make that management burden untenable for MD5 implementations in today's routing
• Keys must be of a size and composition that makes configuration and maintenance difficult or keys must be rotated with an unreasonable frequency.
• KMPs help A LOT, IF you can make them operationally usable

I'm definitely in favor of automatic key management (indeed, I think there's some possibility that I was the person who prompted Steve Bellovin pushing this point in 4107), but I think this is set of rationales is pretty much totally wrong (you can find my review here). Greg Lebovitz prompted me to explain what was good about AKM and I grudgingly agreed, and since I'm always on the lookout for blog content...

Anyway, a little background might be in order. In a simple (non-automatic) system, we just agree on a shared key (e.g., we have a guy with a briefcase chained to his wrist) who transports the key and we use that key directly to protect (encrypt, authenticate, etc.) the data. This is generally referred to as "manual keying". Examples of protocols which use manual keying are the TCP MD5 option as well as some modes of IPsec AH and ESP.

Manual keying seems so easy that it's natural to ask why you would ever do anything else. Unfortunately there are two major problems with using pure manual keying: security and flexibility. The security problem is that while it's OK to use the same key for a long time, actually using it to directly encrypt data intended for multiple contexts can lead to a lot of problems. Probably the easiest to understand is what's called "two-time pads". In a number of encryption algorithms (technical note: stream ciphers) it's unsafe to encrypt two pieces of data with the same key. If you want to encrypt multiple chunks of data you can get around this by treating the chunks as if they were concatenated together and saving the encryption state in between chunks. Unfortunately, if you (for instance) reboot the computer, this state can get lost and now you're just encrypting twice with the same key, which, as I said, is bad. (I'm oversimplifying here, but it's close enough for our purposes). The standard fix is to create a new encryption key for each session, using the long-term encryption key to bootstrap it. This generally requires having some mechanism where the two sides agree to start a new session and establish a fresh key, in other words, automatic key management. There are a number of other benefits as well, including having explicit session boundaries, which often, though not always, implies positive identification of the party on the other end by forcing him to confirm that he has the right keys.

The flexibility problem is mostly about coordination. Let's say we build a system where everyone supports algorithm A and then we want to introduce algorithm B. When Alice wants to connect to Bob, they now need to configure not only the keys the want to use but also the algorithms. And if they get it wrong, nothing will work. As soon as you have more than a few options, the number of ways to get a configuration mismatch starts to get out of control. If we have a mechanism where we explicitly establish a session, then we can also use that to figure out what each side supports and pick a common mechanism. Similarly, if we have systems which operate with multiple security settings, an automatic handshake between them can help to determine the most appropriate mode.

In summary, then, my answer is something like this:

The use of automatic key management mechanisms offers a number of benefits over manual keying. First, it provides fresh traffic keying material for each session, thus helping to prevent a number of attacks such as inter-connection replay and two-time pads. Second, it allows for the negotiation of algorithms, modes, and parameters, thus providing interoperability between endpoints with disparate capabilities and configurations. This second point is especially important because it enables incremental deployment of endpoints with new capabilities while retaining backward compatibility.

I wanted to make one more point: because most of the automatic key mechanisms we have are oriented towards public key cryptography (though they also typically have some sort of pre-shared key mode), there is a tendency to assume that automatic key management implies buying into the whole public key thing, including a public key infrastructure, which is scary for a lot of people. This isn't correct, however. It's quite possible to design an automatic key management system which only requires the same shared keys you would otherwise use (and as I said, popular protocols like TLS and IPsec/IKE do this already if you configure them right). In fact, if you do things right, you can make the whole thing mostly painless. For example, the recently-designed TCP-AO replaces the manual key management in TCP-MD5 with a (incredibly primitive) automatic key management system that only does new key establishment and key rollover, but in a way that's (hopefully) invisible to the end-user.

It's IETF time again and recently I've reviewed a bunch of drafts concerned with cryptographic rekeying. In my opinion, rekeying is massively overrated, but apparently I've never bothered to comprehensively address the usual arguments. Now seems like as good a time as any...

As background, there are two major kinds of cryptographic keys:

• Long-term keys (e.g., your password or an SSL server's RSA key pair).
• Traffic keys used to encrypt and/or authenticate data in transit.

For instance, in channel security protocols like SSL/TLS, SSH, or IPsec, you use your long-term keys to authenticate a cryptographic handshake which sets up the traffic keys which are then used to encrypt/MAC the data between the communicating peers. In other protocols, such as DNSSEC or X.509, long-term keys are used to directly protect data—this is particularly common in applications where data is signed and then published. Sometimes these situations shade into each other: even though TCP-MD5 is a channel security protocol, you use the shared key directly to authenticate the traffic. Even with TCP-AO, where you generate a separate key for each connection, connections are very long-lived so the traffic keys are very long-lived as well.

All of the following rationales were recently seen in IETF submissions:

Key "strengthening". If you change keys frequently, analytic or brute-force attackers need to do more work in order to maintain their access to valid keys. See, for instance: draft-birkos-p2psip-security-key-refresh-00:

A secondary goal is to limit the amount of time available to attackers that may be using cryptanalysis in order to reveal private keys.

I've already beat up on this idea: unless you change keys incredibly frequently, you just don't get a significant level of security enhancement. For instance, changing keys daily is only about 9 bits more secure than changing them yearly.

This rationale gets applied especially often in situations where for some reason you can't use a key as long as you would like, e.g., for packet size reasons or because you're using a key that the user has to remember.

Key exhaustion: minimizing the amount of traffic available to the attacker protected with the same key. For instance: draft-ietf-karp-design-guide-00:

Cryptographic keys must have a limited lifetime so that they are vulnerable against cryptanalysis attacks. Each time a key is employed, it generates a cipher text. In case of routing protocols the cipher text is the authentication data that is carried by the protocol packets. Using the same key repetitively allows an attacker to build up a store of cipher texts which can prove sufficient for a successful cryptanalysis of the key value.

This was true once upon a time, but now it's just cryptographic inertia (do you still type "sync; sync; sync"?). While it's not true that cryptographic algorithms can be used for an unlimited number of operations, the limits are extremely far out and mostly depend on the properties of the cryptographic modes rather than the algorithms themselves. For instance, in cipher block chaining mode, with a b-bit block, you can safely encrypt up to around 2^{b/2} blocks. With a modern algorithm like AES, this means 2^{68} bytes of data, which is a truly ridiculous number. Even in situations where there are limits (e.g., counter mode with a limited counter space), the threat is generally to the data rather than the key. When we're talking about asymmetric algorithms (public key encryption, digital signature, etc.) there's no realistic threat from processing an unlimited amount of data.

Damage limitation If a key is disclosed, but you change it in the meantime, then you're only vulnerable during the time period before it is changed. (This is especially relevant sounding if the key is disclosed but you don't know about it). For instance draft-ietf-karp-design-guide-00.

Another reason for limiting the lifetime of a key is to minimize the damage from a compromised key. It is unlikely a user will discover an attacker has compromised his or her key if the attacker remains "passive." Relatively frequent key changes will limit any potential damage from compromised keys.

This isn't totally crazy: obviously if you know that your key has been compromised, you should change it, so it's at least superficially plausible that if you think your key might have been compromised you should change it. But we need to ask how that could actually happen. You've got a 128-bit (or whatever) encryption key stuffed into some file on your hard drive. There are a few ways that key could become available to an attacker:

• You could accidentally send it to them (e.g., cut-and-paste it into an AIM window [thanks to Chris Morrow for this vivid example]
• They could compromise your endpoint and steal it.
• They could gain temporary access, e.g., by bribing your staff.

So, in the second case, changing your keys doesn't help, since the attacker will just steal them. In the third case, it might help, if the relevant staffer has been fired, or they have to take a risk every time they steal a key, or something. On the other hand, if they have continuous access, then changing the key doesn't help. The first is a real risk, but despite my native paranoia it seems like realistically you would know if this happened, and just be able to change the key then, rather than worrying about whether it happened and you didn't know.

Having a key leak and not know it is primarily (though not exclusively) a concern for keys used for confidentiality. In order to exploit a key used for authentication/integrity you need to inject traffic, so this is more likely to be noticed. By contrast, to exploit a key used for confidentiality you just need to watch passively. This can also be done retroactively, since disclosure of an encryption key at time T still compromises data encrypted before the key was disclosed. Note that we're talking about the direct use of a key here, not about intent: protocols which use a long-term RSA key to authenticate a DH exchange aren't vulnerable to passive attack from disclosure of the RSA key, even if the only purpose of the protocol is confidentiality.

Moreover, if we follow this logic to its obvious conclusion we should be changing keys every few minutes; we don't, of course, because changing keys has costs (I'm also concerned that the very process of changing keys increases the risk for leakage, since you need more direct contact with the key management process). Without a mathematical model for the cost/benefit computation (I don't have anything more than handwaving just yet), I don't think it makes much sense to provide guidance that keys should be changed frequently.

This paper on a new fault-based attack on RSA has been making the rounds (Pellegrini, Bertacco, and Austin, "Fault-Based Attack of RSA Authentication). The general idea here is that you have a system that is doing RSA signatures (e.g., an SSL/TLS Web Server). You induce faults in the signature computation by reducing the power to the processor, which causes the process to produce invalid signatures which can then be analyzed by the attacker to recover the private key. They demonstrate this attack on OpenSSL.

Theoretically, this is interesting, but I'm not sure how much practical impact it has: in order to mount this attack, you need direct physical access to the machine in order to control the input voltage supply. Unless you're working with a computer that is fairly heavily secured, physical access generally translates into being able to take control of the device and extract the private key in any case. Second, the attack as implemented was performed on a FPGA-based SPARC implementation, and the researchers seem to have directly controlled the input power to the processor. In most computers (though DC-based datacenters may be different) the power to the chip is pretty heavily controlled by the power supply, and so it's at least an open question if you would be able to get good control over the chip input voltage by manipulating the AC line voltage. So, it's not like there are a huge number of environments in which this attack would be feasible.

Based on my reading of this paper, because the attack relies on invalid signatures, the simple countermeasure is just to check signatures before you emit them, which OpenSSL doesn't currently do (I'm not sure I agree wih the authors call OpenSSL's failure to do this a "serious vulnerability", but I'm not sure I agree with this characterization, since my understanding is that it's pretty standard practice not to do so). Because RSA signature verification is about 20x faster than RSA signature generation, adding this additional check would not cause significant performance overhead. However, even without this countermeasure, this doesn't seem like a significant risk to most uses of RSA.

OpenDNS (a free DNS service) has decided to adopt DNSCurve to secure its traffic. Some background might be helpful here: DNS, of course, is susceptible to a variety of forgery attacks, which is why the IETF has spent approximately 10 trillion man hours developing DNSSEC. There's a fair amount of dissatisfaction with DNSSEC (I'm not that thrilled with it either) and Dan Bernstein has developed an alternative called DNSCurve.

At a very high level, the approaches stack up like this:

• DNSSEC is an object security system. Each DNS zone has an asymmetric (public/private) key pair which is used to sign the records in the zone.
• DNSCurve is a channel security system. Each DNS server has a Diffie-Hellman (actually ECDH) key pair. When a client connects to the server, it does an ECDH key exchange and the shared key is used to authenticate traffic between the client and server.

The primary argument for DNSCurve seems to be performance: DNSCurve has better performance than DNSSEC in two respects: the packets are smaller and under certain conditions the load on the server is lower. These properties are related but not identical. The packets are smaller partly because DNSSEC replaces the digital signature with a symmetric integrity check. These can be a lot smaller than digital signatures using RSA (and a fair bit smaller than even the smallest digital signatures). Second, because DNSCurve uses elliptic curve cryptography, the keys that need to be carried in packets are smaller. (This is mostly relevant in packets which carry the key for a zone rather than packets which carry other data).

The packet size argument is straightforward. The load argument is more complicated. As I noted above, DNSCurve uses elliptic curve cryptography, which is faster and has smaller keys than RSA (the basic algorithm used by by DNSEC). This means that it's inherently faster to set up a DNSCurve association than it is to sign a DNSSEC record using RSA. In addition, DNSCurve has a mechanism for the client and server to cache the DH shared secret. The upshot of this is that it's substantially cheaper to authenticate a new DNS record with DNSCurve than it is with DNSSEC. In the worst case, it involves an ECDH operation. In the best case, it just involves a symmetric crypto operation. So, in this respect the performance of DNSCurve is superior.

However, this isn't really a heads-up comparison: in the DNSSEC model, you sign the zone once whenever it changes (possibly using a key thats kept offline) and then just send copies of it to any requester, so no cryptographic operations are needed after the initial signature. By contrast, because DNSCurve uses a symmetric, rather than asymmetric, integrity mechanism, the DNS server needs to compute that integrity check for each new request. This means that while DNSCurve is faster if you change your DNS data frequently and don't serve that many requests, it's slower if you don't change it often but serve a lot of requests. In addition, it means that while DNSSEC signing can be done offline with a key that is never on an Internet accessible machine, DNSCurve requires that the private key to the zone be kept on the DNS server, thus potentially exposing it to theft if the server is compromised. By contrast, if DNSSEC is used in an offline signing mode, then compromise of the server does not enable forgery attacks. Where DNSCurve has a major advantage is if your server provides dynamic responses (e.g., for DNS load balancing), in which case offline signing isn't that useful and the performance advantage of DNSCurve is most significant.

It's also worth noting that the use of faster algorithms isn't an inherent advantage of DNSCurve. DNSSEC (like all relatively modern COMSEC protocols) supports multiple algorithms and there have been proposals to add ECC (see, for instance, draft-hoffman-dnssec-ecdsa). An ECDSA-enabled DNSSEC would still be slower than DNSCurve if run in a dynamic environment, but performance would be a lot closer and how much slower would depend on how many repeat requests you got from the same client; if each client only makes one request, then performance would be more or less equivalent. The packet size of ECC DNSSEC would be a little worse, but probably not enough worse to make a big difference.

This isn't to say that there aren't other factors to consider (see the DNSCurve site for the other arguments in favor of DNSCurve). However, the performance argument doesn't seem to me to be dispositive, since which solution is faster depends on your deployment model and assumptions about the client environment.

For some reason, the silly idea of universal personal authentication for Internet users seems to have an undue appeal on tech executives. Here's Barbara Kiviat reporting on Microsoft's Craig Mundie:

What Mundie is proposing is to impose authentication. He draws an analogy to automobile use. If you want to drive a car, you have to have a license (not to mention an inspection, insurance, etc). If you do something bad with that car, like break a law, there is the chance that you will lose your license and be prevented from driving in the future. In other words, there is a legal and social process for imposing discipline. Mundie imagines three tiers of Internet ID: one for people, one for machines and one for programs (which often act as proxies for the other two).

...

Mundie pointed out that in the physical world we are implicitly comfortable with the notion that there are certain places we're not allowed to go without identifying ourselves. Are you allowed to walk down the street with no one knowing who you are? Absolutely. Are you allowed to walk into a bank vault and still not give your name? Hardly.

This is one of those ideas that comes up so often and initially seems like a natural analogy, but on closer inspection just starts to look confused.

First, a drivers license isn't principally a form of general purpose authentication but rather a permit from the state to drive. It has a biometric component in order to permit the police to determine that you're the actual holder of the permit and not someone who just has their license. Of course, because the license is so ubiquitous, it's widely used as a form of general ID, but if you do something to lose your license, the state will still issue you an identification card; indeed you can generally get an id card even if you're ineligible to drive. (Here's what California has to say). So, on the one hand Mundie says you don't have a right to complete anonymity (which I at least sort of agree with) and that his proposed Internet driver's license would serve as a form of ID and on the other hand, he suggests that you could lose your right to use the Internet for some unspecified set of misbehaviors. So, which is it, a permit or a form of ID?

Second, if it's a permit, under what conditions might it be revoked? Having your machine compromised? Failure to keep your software updated? If it's just for bad system hygiene then you're going to see a huge number of revocations. If it's for actual malfeasance then aren't you just going to revoke the licenses of people who would be in serious legal jeopardy in any case? Internet security problems come from two kinds of users: those who are genuinely malicious and those who are just careless. The problem with the first is finding them, not punishing them once you've done so. As for the second, revoking their right to use the Internet seems rather excessive.

On the other hand, if the idea is to just have a form of ID, then I don't really see why we need something government sponsored. Can't sites decide for themselves whether to to try to authenticate you?

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.

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.