A Scalable* Architecture for Public Key Distribution Acting In Concert with Secure DNS

1
A Scalable Architecture for Public Key
Distribution Acting In Concert with Secure DNS

• Daniel Berger dberger_at_cs.ucr.edu
• 24-August-2004

buzz-word compliant
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 its
  missing.

3
Why Key Distribution?

• Key distribution is typically left as a footnote
• How Alice obtains Bobs 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.

4
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.

5
Roadmap

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

6
Architectural Overview

• Goal Answer If I were Bobs 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

7
1000 Words
8
Cryptographic Concepts

• Ciphers Symmetric Asymmetric
• Digital Signatures
• Secure Hash Functions
• Key Authentication

9
Symmetric vs. Asymmetric Ciphers

• Given plain-text P, encryption key Ke, and
  encryption function E
• E(P, Ke) -gt C
• Given cipher-text C, decryption key Kd, and
  decryption function D
• D(C, Kd) -gt 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!

10
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.

11
Digital Signatures

• Given message M, signing key Ks, and signature
  function SIGN
• SIGN(M, Ks) -gt S(M, Ks)
• Given message M, signature S(M, Ks), verification
  key Kv, and verification function VERIFY
• VERIFY(M, S(M, Ks), Kv) -gt 10
• Ks Kv (HMAC)
• Ks ! Kv (DSA)

12
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)

13
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)

14
You Have to Know Something

• Web-of-trust or certifying authority
  key-authentication scheme Alice (trying to
  authenticate a key claiming to be Bobs) 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)

15
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)

16
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.

17
App-Specific Key-Servers

• PGP key-server, originally used PGPs 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 its application
  specific.
• PGP APIs are very immature, making it difficult
  to leverage in communication tools.

18
Keys as Directory Attributes

• X.500
• DNS

19
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.

20
DNS

• It just works the directory Internet users
  use everyday.
• Many proposals for distributing keys of various
  sorts in DNS.
• Problem DNS isnt trustworthy, so external key
  authentication needed.
• Problem Will DNS scale to managing keys for
  end-users (gt950 Million vs. 230M hosts)?
• Problem DNS Administration model mismatch
  (frequent end-user driven update).

21
DNS Review

• A hierarchical namespace structured as a rooted
  tree.
• Allows mapping (resolving) names to resources
• Name -gt Authoritative Name Server (SOA)
• Name lt-gt Address (A/PTR)
• Name -gt Mail Exchange Hosts (MX)
• Name -gt 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.
  

22
DNSSEC from 30k Feet

• Recall DNS isnt trustworthy
• In 1995, Bellovin and Vixie presented papers _at_
  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, were
  almost there.

23
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.

24
Details Omitted for Clarity

• The implementation details arent critical (and
  are still in-flux).
• The key capability we exploit in DNSSEC is secure
  delegation out of the DNS hierarchy.

25
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)

26
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

27
1000 Word (Redux)
28
Key Registration

• Given a DNS name (bob_at_example.com) 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 bob_at_example.com?

29
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.

30
Registering a Key
31
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

32
Key Query

• Given a DNS name (bob_at_example.com), 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 its users?

33
Finding a Key
34
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 its hash from DNS
• The hash authenticates the key-signing key, the
  key-signing key authenticates the retrieved
  key(s).

35
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 its users?

36
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)

37
DNSSEC Resolution
38
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.

39
Client Layers
40
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).

41
Server Layers
42
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

43
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.

44
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)

45
Questions?