6.824 2001 Lecture 17: Key management - In the previous lectures we have seen how to authenticate and encrypt messages, with both symmetric and public-key techniques. These techniques presuppose that parties have already created and appropriate distributed the cryptographic keys to be used. Today we talk about how to distributed keys in a secure manner. - We will talk mostly about authentication. In fact, we will focus on server authentication. Server authentication is often harder than user authentication: (1) client's don't know about servers in advance (server often do know about clients) and (2) A user can access any server in the world (ie. we cannot build a table with all OK servers). - The primary attack of concern is server impersonation. If we don't have server authentication, then 1. a user might write sensitive data to a server controled by attacker 2. the attacker might substitute data - The basic approach is to build on authentication with public-key systems: 1. server signs document with private key 2 client verifies document with public key - Tke key management questions then are: - How does the client get server's public key? - How to know the server's key is really server's? - How to give the server key to the system? - How to make it efficient? (signing every document is slow and is in fact the wrong semantics---we want to be able to sign relationships between documents too). - The problem of key management is closely related to the key-to-name binding problem. In the real world principals are named by descriptive names and not keys. So for a key we need to be able to answer can we *trust* the key to speak for the principal. - Example: server authentication in the Web. In web browser, user clicks on www.amazon.com and sets up an SSL connection with an IP address for the DNS name amazon.com. As part of the connection setup the SSL protocol verifies the name amazon.com using amazon's server certificate. amazon.com obtained the server certificate from certificate authority (e.g., verisign). Thus: 1. server -> verisign please give me a certificate for amazon.com's pub key K 2. verisigh -> server certificate {amazon.com,K} signed by verisign private key [verisign runs a certification procedure] 3. browser -> server connection request 4. server -> browser: {amazon.com, K} signed with verisign's private key [browser verifies certificate using verisign's public key] 5. browswer sends request Certificate: struct X509_certificate { unsigned version; unsigned serial; signature_cipher_identifier; issuer_signature; issuer_name; subject_name; subject_public_key_cipher_identifier; subject_public_key; validity_period; }; - Where did the browser get server's public key? How does it know that it speaks for Verisign? - The browser has a number of public keys embedded in its binary (incl. Verisign's public key). So, we trust Netscape or Microsoft to put in the right public key. - There is a user panel where users can add public keys for certificate authorities. - Why should the browser believe the certificate? - Verisign ran an "extensive" certification procedure to verify that amazon the book stores indeed owns amazon.com. So, what does it do? Verisign ask for your articles of incorporation for a company with the appopriate name. Verisign checks whether you own the DNS name that you getting a certificate for. Etc. Tension: between convenience and security. If the certification procedure is precise than certificate means a lot but it is a pain in the neck for the server company. If the certification procedure is lax, then certificate doesn't mean anything. - Verisign charges for certificates. Many people find this expensive so some certificates are self-signed {amazon.com,K} is signed by amazon. Does that make you trust a certificate less or more? [less] - What does a certificate mean when the private key of amazon is compromised? [nothing]. What if verisign's private key is compromised? [all certificates signed by verisign mean nothing---verisign should keep its key secure (e.g, off-line)!] - How does one revoke certificates? [Certificate revocation lists (don't really work) and timeout (6-12 months).] - Did the user intend to visit the book store? what if the user clicks "aamazon.com"? does certificates solves this problem? [no; if the aazon.com's web site looks like amazon.com's there is no way to tell the difference to figure out that you want amazon instead of aamazon.] - What happens if the dns name in the certificate is different from the one you typed at the browser? - the first time a windown pops up - if you say continue, it is validated for future use! [See Fu's CERT advisory.] - Example: Kerberos - Kerberos based on symmetric-key system using secret keys and a centralized auhentication server. The authentication server authenticates the client and helps in setting up an authenticated connection betwen the client and the server. From Kerberos V5 RFC: The authentication process proceeds as follows: A client sends a request to the authentication server (AS) requesting "credentials" for a given server. The AS responds with these credentials, encrypted in the client's key. The credentials consist of 1) a "ticket" for the server and 2) a temporary encryption key (often called a "session key"). The client transmits the ticket (which contains the client's identity and a copy of the session key, all encrypted in the server's key) to the server. The session key (now shared by the client and server) is used to authenticate the client, and may optionally be used to authenticate the server. It may also be used to encrypt further communication between the two parties or to exchange a separate sub-session key to be used to encrypt further communication. Alice logs in and wants to talk to a server named Bob. A is Alice, B is Bob, AS the Authentication Server, TGS is the ticket granting server. Typical scenario: 0. Alice logs in, types her password PwdA 1. A -> AS. "A" 2. A <- AS. {Ka,tgs {Ka,tgs}Kas,tgs}PwdA 3. A -> TGS. B, {Ka,tgs}Kas,tgs, {A,TS}Ka,tgs 4. A <- TGS. {{Ka,b}Kb,tgs, Kab}Ka,tgs 5. A -> B. {Ka,b}Kb,tgs, {A,TS}Ka,b 6. A <- B. {TS+1}Ka,b {Kc,s}Ks,tgs is a "ticket". It establishes a session key between client c and server c, and is signed by the key Ks,tgs shared between the server and the ticket-granting server. How is A sure that she is talking to B? How is A sure she isn't seeing a replayed reply? How is B sure he is talking to A? How is B sure he isn't seeing a replayed reply? How is A sure she is talking to the real AS? The protocol pushes all these questions back to the AS. How does the AS get correct passwords for A and B? Kerberos changes key distribution from O(N^2) to O(N). Is O(N) good enough? - How does an MIT user get authenticated access to a CMU server? That is, how can the MIT user trust the results of /afs/cs.cmu.edu? Needs to get a ticket for cs.cmu.edu file server. It requires that the administrators at MIT and CMU exchange inter-realm keys, which registers the local TGS as a principle in the remote realm and vice versa. This means Kerberos inter-realm authentication is O(N^2), and must be done by administrators, not users. [as noted by the RFC better automatic solutions are needed if cross-realm access is common.]