COMSEC: January 2009 Archives


January 28, 2009

I'm trying to puzzle out what this NYT article is about. I get the problem: you've got digital records and you want some way to establish their provenance and contents for posterity. What I don't get is what the claimed solution is:
Designing digital systems that can preserve information for many generations is one of the most vexing engineering challenges. The researchers' solution is to create a publicly available digital fingerprint, known as a cryptographic hash mark, that will make it possible for anyone to determine that the documents are authentic and have not been tampered with. The concept of a digital hash was pioneered at I.B.M. by Hans Peter Luhn in the early 1950s. The University of Washington researchers are the first to try to simplify the application for nontechnical users and to try to offer a complete system that would preserve information across generations.


After capturing five gigabytes of video in 49 interviews, the group began to work on a system that would make it possible for viewers to prove for themselves that the videos had not been tampered with or altered even if they did not have access to powerful computing equipment or a high-speed Internet connection.

Despite the fact that there are commercial applications that make it possible to prove the time at which a document was created and verify that it has not been altered, the researchers wanted to develop a system that was freely available and would stand a chance of surviving repeated technology shifts.

At the heart of the system is an algorithm that is used to compute a 128-character number known as a cryptographic hash from the digital information in a particular document. Even the smallest change in the original document will result in a new hash value.

It doesn't help here that the Times's doesn't actually link to the relevant site. They have links all right, but they go to the Times's explanation of the relevant terms, not to the site you want to. So the above is based purely on the Times article. If someone has a pointer to the project site, I'd be interested.

Anyway, using cryptographic hashes for document integrity like this is a pretty standard technique, and there's plenty of free software for it; it's a builtin on most machines. The difficult problem isn't actually establishing integrity though, it's establishing authentication and (more importantly in this case), time of creation. To see why, consider the threat model. Someone gives you a recording that they claim represents a historical event that was observed by someone long-since dead. Classic public key cryptography isn't a complete solution here: how do you validate the original creator's public key and even if you had it, how would you know that they didn't tamper with the data themselves some time years afterwards? What's more useful is to know that that recording existed at (or before) the time it was allegedly made. Hashes can help here, but what you need is to have some independent channel that carries the hash along with some sort of evidence of when it was made. So, for instance you might print a hash of your recording in the newspaper classified section and then anybody who could lay hands on the paper could independently verify the recording. [Technical note: there are some cooler techniques using chains of hash functions but this is the basic principle.]

Note that it doesn't help to have the hash just attached to the document without some other form of cryptographic protection (e.g., a digital signature.) This doesn't buy you any protection against attackers, because they can change the document and the hash to match. The way to think about this is that hashing is a technique for bootstrapping your confidence in a small data value (the hash) into confidence in the entire data object that was hashed. But you still need a secure channel for the object.

With that in mind, I don't really understand how the live CD thing works either. Just like you need the hash to be carried independently, you also need an independent code base to do your own hash computation.


January 22, 2009

I recently did an email interview (well, he sent me questions, I sent answers) with a reporter from the Buffalo News the other day and it's up on the Web here. Lemme tell you, it looks a lot cooler in print, since the lede at least was on the front page. Since it was in email, I seem to have managed not to say anything too stupid, at least not that made it into the article.
"The effect of the Internet is to make it much cheaper for scammers to send out solicitations. This means that scams that formerly were unprofitable because the response rate was so low are now profitable," Eric Rescorla, chief scientist at Network Resonance and an adviser for Voltage Security, said in an e-mail interview Thursday.


Users have to be more cautious and treat someone they talk to online the same way they would treat someone in real life. "Many of these scams work because users are insufficiently skeptical of e-mail they receive via the Internet. If users are a little more worried and it causes them to be more careful about trusting e-mail, that's a good thing," Rescorla said.

Obviously, I spouted a bunch more stuff that didn't make it in, probably deservedly so, but here's one point I am a bit fond of:

With regard to emails that purport to be from your bank, I suspect the problem is simple: people don't understand that it's easy to forge mail and that just because a site looks like your banking site, that doesn't mean it is. This is a case where your real-world intuitions fail you: there aren't a lot of fake brick and mortar bank branches floating around, but it's trivial to set up a fake site that looks like your bank's site.

Of course, this isn't unique to the Internet: you can't trust people who call you on the phone either, even if their Caller-ID information looks OK, but the visual cues on the Web really are good for suckering people in. It's just natural to say to yourself "no criminal would have a site that looks this good, it must be my bank", but of course that's totally wrong.

Thanks to Wasim Ahmad and Stephanie Mode for making the contact and Hovav Shacham and Terence Spies for looking over my answers before I shipped them. The point about it would be good to be more skeptical is Hovav's.


January 18, 2009

Sorry it took me so long to get back to this topic. In previous posts I started talking about the possibility of replacing DNSSEC with certificates. Obviously, this can be done technically, but is it a good idea? The basic argument here (advanced by Paul Vixie but also others) is that putting keys in the DNSSEC would better than the existing X.509 infrastructure.

From a cryptographic perspective, this is probably not true: DNSSEC uses generally the same cryptographic techniques as X.509, including supporting MD5 (though it's marked as non-recommended). It may actually be weaker: one potential defense against collision attacks with X.509 is to randomize the serial number, but it's not clear to me that there's something as simple with DNSSEC RRSIG RRs though presumably you could insert a random-looking record if you really wanted to. Cryptographic security isn't the main argument, though. Rather, the idea is that DNSSEC would be more secure for non-cryptographic reasons.

I can see two basic arguments for why DNSSEC would be more secure, one quasi-technical and one administrative. The quasi-technical argument is that there is a smaller surface area for attack. Because a Web client (this is more or less generally true, but Web is the most important case) will accept a certificate from any CA on the trust anchor list, the attacker just needs to find the CA with the weakest procedures and get a certificate from that CA. This works even if the target site already has a certificate from some other CA, because the client has no way of knowing that. By contrast, at least in theory only one registrar is allowed to authorize changes to your domain, the attacker needs to target that registrar. That said, domain name thefts have occurred in the past, and so it's not clear how good a job the registrars actually do. Moreover, it wouldn't be that hard to import this sort of semantics into X.509; the CAs would need to coordinate with the registrars to verify the user's identity, but that's not impossible. Another possibility would be to have a first-come-first-served type system where CA X wouldn't issue certificates for a domain if CA Y had already done so without some sort of enhanced verification. Obviously, this is imperfect, but it would at least make hijacking of popular domains difficult.

The second argument is purely administrative, namely dissatisfaction with CA operational practices. Here's Vixie: "frankly i'm a little worried about nondeployability of X.509 now that i see what the CA's are doing operationally when they start to feel margin pressure and need to keep volume up + costs down." That said, it's not clear that registrar procedures will be any better (again, there have been DNS name thefts as well), and it's quite possible that they would be worse. Note that in some cases, such as GoDaddy, they're actually the same people. Moreover, there needs to be some coordination between the registrars and the registries, and that's a new opportunity for a point of failure. Anyway, this seems to me to be an open question.

The most difficult problem with this plan seems to be deployment. So far, DNSSEC deployment has been extremely minimal. Until it's more or less ubiquitous, users and clients need to continue trusting X.509 certificates, so adding DNSSEC-based certificates to the mix marginally increases the attack surface area, making the situation worse (though only slightly), not better. And as usual, this is a collective action problem: as long as clients trust X.509 certs there's not a lot of value to server operators to transition to DNSSEC-based certificates, which, of course, means that there's not a lot of incentive for clients (or more likely implementors) to start trusting them either. It's not really clear how to get past this hurdle in the near future.


January 6, 2009

In the wake of the recent attack on MD5 in certificates (see my summary here), the topic of replacing X.509 certificates with DNSSEC has come up.
i wasn't clever but i was in that hallway. it's more complicated than RFC 2538, but there does seem to be a way forward involving SSL/TLS (to get channel encryption) but where a self-signed key could be verified using a CERT RR (to get endpoint identity authentication). the attacks recently have been against MD5 (used by some X.509 CA's) and against an X.509 CA's identity verification methods (used at certificate granting time). no recent attack has shaken my confidence in SSL/TLS negotiation or encryption, but frankly i'm a little worried about nondeployability of X.509 now that i see what the CA's are doing operationally when they start to feel margin pressure and need to keep volume up + costs down.

The basic observation is as follows: the role of certificates in SSL is to bind domain names (e.g., to public keys. But this creates a parallel authentication hierarchy; the CA is attesting to your ownership of some DNS zone, but you also need to be able to control the zone itself, or people won't be able to talk to you. It's natural, then, to think about just stuffing your public key in the DNS. Unfortunately, you can't trust the DNS, at least not without DNSSEC. However, if you had DNSSEC (so the argument goes) you could stuff public keys into the DNS and people could then trust them and skip the whole certificate step. This is a fairly natural idea and has been proposed many times over the years (I remember proposing it back in 1996 or so).

It's not clear that this is really as useful as it sounds, for reasons I'll get into in a subsequent post. However, right now let's assume it's useful and explore the design space a bit.

Mostly when this topic comes up, there is a lot of discussion of encoding. In particular, there are two big issues:

  • Should we store certificates or keys?
  • What resource record type should we use?

Certificates versus keys
The argument for keys rather than certificates is straightforward: certificates are redundant. Most of the stuff in the certificate is various kinds of control information (issuer, serial, the signature, etc.) that isn't relevant here because the DNSSEC record is itself a quasi-certificate. And since this stuff is big and we'd like DNS records to fit within 576 bytes, it's naturally to strip things down as much as we can. There's an RR type for this for IPsec, but not SSL.

The counterargument here is that most of our software is already designed to deal with certificates and it's a pain to make it use raw public keys. For instance, if you're doing SSL, the server is going to send you a certificate and you can just memcmp() it against the certificate you get out of DNSSEC. Note that you don't need to use a real certificate here. Self-signed works fine. This also has the advantage that it's a a useful transition mechanism in settings where you don't have DNSSEC; if you have a mechanism for putting certificates in DNS, potentially you could use it as part of a mechanism to reduce client-server traffic (the client tells the server "I think I have your cert, don't send it to me if it has hash X") which doesn't rely on the DNS to provide authenticated data. Oh, adn btw, there already is an RR for doing this as well.

There's actually a third possibility: have the DNS store a digest of the certificate. This lets the DNS act as an authentication channel for the server certificate but doesn't chew up as much bandwidth as the certificate or the public key. Of course, that still requires some channel for the certificate, but if you're doing SSL that happens by default. It obviously works less well for non-cert protocols like SSH, and doesn't give you any kind of preloading benefit.

RR Type
The second issue is what resource record type should be used. While this seems like a topic that ought to be of interest only to DNS weenies, it turns out to be important for at least one reason: you can have multiple services with different keys running on different ports on the same host. As far as I can tell, none of the proposed mechanisms really provide for this. It's not really an issue for IPsec, where there is more or less one cert for each IP, but it's definitely an issue for SSL or SSH. One could imagine inventing a new record type which segregated by port, or using a TXT record, or... Anyway, my impression is that this isn't totally trivial.

Of course, we've totally ignored the question of whether this is a good plan. But this post is getting awfully long, so I'll deal with it in a subsequent post.