This week I’m attending Real World Crypto 2017 in New York City. For each of the three days of the conference I’ll be highlighting a few of my favorite talks from my perspective as an engineer building infrastructure software.
Project Wycheproof - Scaling Crypto Testing
Thai Duong gave an overview of Project Wycheproof, an open source project developed at Google which tests cryptographic libraries for known weaknesses.
According to Thai, Google internally provides abstractions for common cryptographic protocols and operations by wrapping third party libraries such as OpenSSL and OpenJDK. Unfortunately, as we’ve learned over the past few years popular crypto libraries aren’t always as well tested as we’d hope.
Project Wycheproof set out to develop a set of unit tests to check for known weaknesses in common cryptographic algorithms. The tests are written in Java in order to utilize it’s common cryptographic interfaces, allowing the same tests to be re-used for multiple implementations of a given algorithm. A test runner is provided to allow projects to run the tests as part of their own CI workflows.
Thus far the Wycheproof developers have released over 80 unit tests and uncovered over 40 bugs.
NSEC5: Provably Preventing DNSSEC Zone Enumeration
Sharon Goldberg gave a presentation about NSEC5, an approach to providing authenticated “not found” DNS responses while simultaneously:
- Preventing zone enumeration
- Eliminating exposure of the signing key which could be used to forge DNS responses
RSA-based NSEC5 has been around for a few years, but the talk focused on a newer approach which used elliptic curve cryptography (ECC) to achieve much better performance than previous approaches requiring online signing.
For those unfamiliar with DNSSEC, the talk provided an approachable overview.
DNSSEC provides authentication of DNS responses by pre-signing records with an offline key. Because the key is kept offline, an attacker who compromises a nameserver can’t forge responses.
The first challenge this presents is proving that a record doesn’t exist. Without an online key the nameserver can’t sign a response stating that the name doesn’t exist, and the DNS namespace is too large to practically pre-sign records for every possible name. Instead, NSEC records can be created by sorting the set of names in a zone, then pre-signing each consecutive pair. For any name that doesn’t exist the nameserver can return the NSEC record containing the pair of names surrounding the requested one, providing an authenticated proof of non-existence.
The approach used in NSEC allows anyone who can query the nameserver to enumerate the names in a zone by constructing queries to iterate the set of NSEC records. NSEC3 was developed to counter this by hashing each name - in theory preventing an attacker from seeing the underlying names.
NSEC3 in turn is easily succeptible to a dictionary attack, allowing the attacker to reverse the hashed names. A server willing to keep signing keys online can successfully prevent this by dynamically generating NSEC3 (or NSEC) records which prove the non-existence of a name without disclosing actually existent names by generating and signing “fake” names on either side - at the risk of increasing the exposure of the signing key.
NSEC5 addresses this problem without putting the primary signing key (which can be used to forge DNS records) online by introducing a secondary online key. In place of the hashed names used in NSEC3 records, NSEC5 uses a “keyed hash” function - essentially a hash of a signature generated using the secondary key. The keyed hashes are still signed by the offline key, but cannot be reversed - only queried online. Nameservers return NSEC5PROOF records which contain the query signed with the online secondary key, as well as the NSEC5 record signed with the offline key. For a more detailed explanation see the paper.
If a nameserver is compromised the online (secondary) key can be used to enumerate names within the corresponding zone, but the nameserver must necessarily have this list in any case, so nothing is really lost.
I enjoyed this talk for the approachable presentation and novel solution to a practical infrastructure problem - but it didn’t influence my reservations about the real world benefits of DNSSEC. Plenty has been written on those limitations so I won’t go in-depth here.
The afternoon was dominated by two sessions on post-quantum cryptography. Cryptographers expect that in the coming decades it will become practical for well funded attackers to compromise existing public-key algorithims using quantum computers. These sessions kicked off with an introduction to NIST’s Post-Quantum Cryptography Project, which is attempting to identify cryptographic algorithms that NIST should recommend in a post-quantum world, followed by presentations of several such algorithms.
These sessions reinforced to me the need for the infrastructure software community to be prepared for this shift. Today re-keying broad swaths of infrastructure due to a vulnerability like Heartbleed is costly and slow. In the future we need to be prepared to rapidly and repeatedly upgrade algorithms and protocols - and to re-encrypt or destroy data at rest whose encryption has been compromised. Doing this in a cost-effective way likely implies huge leaps forward in centralization and automation.
That’s it for day one! Check back for another update, or check the conference website for a link to the live stream or recordings once they’re available.