a scalable* architecture for public key distribution acting in concert with secure dns daniel berger...

A Scalable* Architecture for Public Key Distribution Acting In

Concert with Secure DNS

Daniel Berger [email protected]

* buzz-word compliant

24-August-2004Dan Berger [[email protected]] 2

Introduction

In 1992 Phil Zimmerman released PGP – the first strong cryptography tool aimed squarely at “normal” people.

12 years later widespread peer-to-peer use of cryptography is still in its infancy.

General, scalable, authenticated key distribution is necessary to encourage this adoption, and it’s missing.


Why Key Distribution?

Key distribution is typically left as a footnote: “How Alice obtains Bob’s public key is beyond

the scope of this discussion…” Collaborative tools are integrating

cryptography for privacy or data verification. Each of these tools are being forced to re-invent

the key-distribution wheel. Prior experience with cryptography shows this to

be highly-error prone.


Contributions

Simple, scalable, deployable infrastructure for key registration and distribution. Use of DNSSEC for trustworthy delegation.

Uses the namespace familiar to Internet users without adding significant load to the DNS

infrastructure. Trust decisions are associated with communication

endpoints, not disinterested third parties. Service Location and Key Management Protocols. Prototype implementation.


Roadmap

Architectural Overview “Key” Cryptographic Concepts Related Work DNS Review DNSSEC Backgrounder Key Query/Registration Protocols Client & Server Implementation Future Work, Conclusions


Architectural Overview

Goal: Answer “If I were Bob’s key, where would I be?”

Use a trustworthy name service to allow domains to: securely delegate key distribution services, and publish key-signing key commitments for key

authentication Distribute key management load across the

network and name space. A picture is worth a thousand words…


1000 Words


Cryptographic Concepts

Ciphers: Symmetric & Asymmetric Digital Signatures Secure Hash Functions Key Authentication


Symmetric vs. Asymmetric Ciphers

Given plain-text P, encryption key Ke, and encryption function E: E(P, Ke) -> C

Given cipher-text C, decryption key Kd, and decryption function D: D(C, Kd) -> P

If Ke == Kd, the cipher is symmetric [AES]. Securely exchanging keys is hard.

If Ke != Kd, the cipher is asymmetric [RSA]. Knowing Ke reveals nothing about Kd, so give Ke to

everyone!


Keys vs. Certificates

Typically, endpoints deal with certificates, rather than keys.

Certificates = key + meta-data. What sort of key is this? To whom does the key belong? For how long is it valid? Who vouches for it?

We will use the terms interchangeably.


Digital Signatures

Given message M, signing key Ks, and signature function SIGN: SIGN(M, Ks) -> S(M, Ks)

Given message M, signature S(M, Ks), verification key Kv, and verification function VERIFY: VERIFY(M, S(M, Ks), Kv) -> 1|0

Ks == Kv (HMAC) Ks != Kv (DSA)


Secure Hash Functions

Hash functions map an input M into fixed length output h.

For a secure (or one-way) hash function H: Given M computing h is easy Given h, computing M | H(M) == h is hard Given M, computing M’| H(M) == H(M’) is hard Finding M, M’ | H(M) == H(M’) is hard

Examples: MD5 (128bit), SHA-1 (160bit)


Key Authentication

Recall: “Knowing Ke reveals nothing about Kd, so give Ke to everyone!”

Problem: How does Alice, given Ke claiming to belong to Bob, determine if it actually does? When people talk about “key distribution,” they often

mean authenticated key distribution” Two common approaches:

Certifying Authority (CA): “Big Brother says so” (SSL) Web-of-Trust: “Tom, Dick, and Harry all say so” (PGP)


You Have to Know Something

Web-of-trust or certifying authority key-authentication scheme; Alice (trying to authenticate a key claiming to be Bob’s) needs some prior knowledge: Keys from some number of partially trusted

introducers (web-of-trust) A key from a (or a few) ultimately trusted

introducer (certifying authority)


Related Work

In-Band Key Transmission (e.g. SSL, SSH)

Application-Specific Key-Servers (e.g. pgp.mit.edu)

Keys as Attributes in a Directory Service (e.g. X.500, DNS)


In-Band Key Transmission

SSL/TLS and SSH transmit key information during protocol negotiation. SSL uses the CA key authentication model – the

key is signed by a certifying authority. SSH asks the end user to authenticate the

binding between key and host the first time, and raises alarms if the binding changes.

Acceptable when: There is an established CA infrastructure (barrier

to entry), or Relationships are (mostly) static.


App-Specific Key-Servers

PGP key-server, originally used PGP’s inbuilt keyring management with a web-front end.

PGP and GPG support fetching keys from, and registering keys to, a PGP keyserver.

Works reasonably well, but it’s application specific. PGP API’s are very immature, making it difficult

to leverage in communication tools.


Keys as Directory Attributes

X.500 DNS


X.500

“Everything & the kitchen sink” – a set of recommendations from ITU for scalable, replicable, extensible directory service. Standards exist for associating public keys with

directory objects.

Technical, administrative, and conceptual complexity have been barriers to adoption.


DNS

“It just works” – the directory Internet users use everyday.

Many proposals for distributing keys of various sorts in DNS. Problem: DNS isn’t trustworthy, so external key

authentication needed. Problem: Will DNS scale to managing keys for

end-users (>950 Million vs. 230M hosts)? Problem: DNS Administration model mismatch

(“frequent” end-user driven update).


DNS Review

A hierarchical namespace structured as a rooted tree.

Allows mapping (resolving) names to resources Name -> Authoritative Name Server (SOA) Name <-> Address (A/PTR) Name -> Mail Exchange Hosts (MX) Name -> Service Location (SRV) …

DNS SRV Records Relatively little-known DNS record type. Maps a given domain, service, protocol tuple to a

(weighted set of) host(s) providing that service.


DNSSEC from 30k Feet

Recall: “DNS isn’t trustworthy…” In 1995, Bellovin and Vixie presented

papers @ USENIX about DNS security. The conclusions were fairly grim. The lack of authentication and verification in the

DNS protocol precluded making it trustworthy. IETF formed the DNS SEC(ure) working

group to attack the problem. Several false starts and years later, we’re

“almost there.”


DNSSEC: Zone Signing

Provides data origin authentication and integrity verification.

The server authoritative for a domain (zone) cryptographically signs the published information and includes the signatures in query responses. The keys used to sign the (keys used to sign the)

data are signed by the parent domain.* A security aware client can:

authenticate the zone signing keys, and Re-compute signatures to detect data tampering.


Details Omitted for Clarity

The implementation details aren’t critical (and are still in-flux).

The key capability we exploit in DNSSEC is secure delegation out of the DNS hierarchy.


Side Note: Keys in DNSSEC

Originally, the DNSSEC specification included distributing end-user application keys.

This was explicitly un-done for three reasons: Scalability Concerns (945M users v. 230M hosts) Query Interface Efficiency (“what sort of key?”) Administrative Model Mismatch (user-driven

updates)


Our Proposed Solution

Use DNSSEC to delegate key management to named servers on a per domain basis.

Three operations: Bind a key to a name (key registration) Find a key registered to a name (key query) Revoke a specific key (key revocation)

buzz-words a-plenty: Web services, SOAP, XML, WSDL…


1000 Word (Redux)


Key Registration

Given a DNS name ([email protected]) and a public key, bind the key to the name + the service it protects. Question 1: who handles key registrations for

example.com? Question 2: can the registering user/application

be authenticated as “[email protected]?”


Authenticated Registration

Authentication details are likely to be domain specific.

Our proposal dictates the wire protocol: HTTP authentication or a hand-off to an external

authentication server. Once authenticated, the registered key and

meta-data are signed by the key server.


Registering a Key


Key-Management Keys

Once a user authenticates, they can register a key-management key with the key-registration server.

Future key management requests signed with this key are considered authenticated. “One key to rule them all…”


Key Query

Given a DNS name ([email protected]), and key attributes (algorithm, bit length, container format, service…), find matching published keys. Question 1: who distributes keys for

example.com? Question 2: do any matching keys exist? Question 3: can the keys be authenticated? Question 4: do I (the user) trust example.com to

provide keys for it’s users?


Finding a Key


Authenticating Keys

Once a client retrieves a key, how do they confirm the key was actually published by the authoritative server? The server signs registered keys, and publishes a SHA-

1 hash* of the verification key in DNS. (Detail: Many such key-signing keys can be active at any

time, the server specifies which key was used to generate the signature.)

The client retrieves the named key-signing key from the key-query server and it’s hash from DNS

The hash authenticates the key-signing key, the key-signing key authenticates the retrieved key(s).


Trusting Retrieved Keys

Once the key-signing key has been authenticated (via DNSSEC) and

The retrieved keys have been authenticated (via the key-signing key)

The user must decide: Do I trust the containing domain to publish keys on behalf of it’s users?


Implementation: DNSSEC

The current pre-release of bind (9.3rc1) is tracking the DNSSEC proposals.

The documentation, however, lags. Basically:

Write a zone file Generate zone signing keys Sign the zone Enable DNSSEC via bind configuration Configure a security-aware resolver (lwresd)


DNSSEC Resolution


Implementation: Client

About 2000 lines of C, using the gSOAP SOAP framework and OpenSSL crypto library.

Provides a DNSSEC-aware resolver interface, key-query, and key-registration methods.

Use pattern: construct and populate a query/registration request, submit the request, act on the response.


Client Layers


Implementation: Server

About 1000 lines of Python, using the ZSI SOAP framework, M2Crypto OpenSSL wrapper, and SQLite RDBMS.

Provides handlers for key registration and key query.

Design pattern: dispatch to handler, transform request objects into SQL, transform results into response object(s).


Server Layers


Performance

Python client to Python server: 2.8 registrations/sec, 1.6 queries/sec.

C client to Python server: 7 registrations/sec, 6.3 queries/sec.

Data Transfers: Registration: 5kB/request Query/Response: 6.5kB/request

DNS: 3 additional DNS records (2x SRV, 1x key-signing key

hash) 1 DNS query/key registration 2 DNS queries/key query


Conclusion

A general solution to key distribution can be a powerful enabler for communication and collaboration tools.

Working with the DNS namespace avoids introducing new user concepts.

Our proposed protocol focuses on key registration and query, resulting in a conceptually simple tool for developers.


Future Work

The python server code seems to be a significant bottle-neck – re-implementing the server could significantly improve performance.

The “hooks” for key-revocation are presented, but stubbed out.

Wider peer review; USENIX submission planned, possible IETF submission (draft or RFC).

Re-evaluate use of SHA-1 (CRYPTO ’04)


Questions?

a scalable* architecture for public key distribution acting in concert with secure dns daniel berger...

Documents