Your SlideShare is downloading. ×
TLS.doc
TLS.doc
TLS.doc
TLS.doc
TLS.doc
TLS.doc
TLS.doc
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

TLS.doc

445

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
445
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Secure password-based cipher suite for TLS: The importance of end-to-end security Marie L.S. Dumont CS 265
  • 2. Introduction: The Secure Socket Layer (SSL) is the standard protocol for securing end-to-end transport over the Internet. SSL was further refined in the Transport Layer Security (TLS) protocol and now seems to provide a reasonable level of security. Currently, all standard methods for authentication in TLS rely on a Public-Key Infrastructure (PKI). While this is suitable for many cases it might not suit environments where the infrastructure is “light-weight” (e.g., diskless workstations), situations where a system has to be bootstrapped from scratch, or contexts where user mobility is required. Furthermore, current cipher suites also pose their own risks, prominently illustrated in the home-banking applications for the web. For security reasons, these applications rely mainly on the integration of SSL into the web browsers. As issuing client certificates securely and reliably is quite involved, most of them use SSL for server authentication. A secure channel is set up from the browser of the bank customer to the server and the customer authenticates herself by typing her password into a simple web form. However, in such a setup the authentication of the customer is not directly tied to the secure channel and, in fact, the security cannot be guaranteed if the customer does not explicitly verify the connection before entering her password. Verification of the certificate by the customer to ensure that it identifies the right bank and is issued by a Certification Authority (CA) is a non-trivial task. To prevent further attacks, the customer has to verify the fingerprint of the CA and if the customer fails to do this properly, a man-in-the-middle attack is possible leading to a potential theft of her money. This seems to put too high a burden on the average customer. Using client side certificates helps but complicates the setup and requires proper protection of the client’s keys, a difficult task given the (in)security of the common operating systems available today. The integration of the Encrypted Key Exchange (EKE) protocol into TLS helps to reduce the risks explained above by providing mutual authentication and key establishment with perfect forward secrecy over an insecure channel. Diffie-Hellman Encrypted Key Exchange (DH-EKE): Client Server (password pwd) (password pwd) x ← Zp-1 Êpwd(hx) y ← Zp-1, Kmstr ← (hx)y, C1 ← domain (E) Êpwd(hy), EKmstr(C1) Kmstr ← (hy)x, C2 ← domain (E) EKmstr(C1, C2) verify response EKmstr(C2) verify response
  • 3. In this protocol, a weak secret P is used to encrypt two randomly chosen half-keys of a Diffie-Hellman key exchange (DH), that is, hx (mod p) and hy (mod p). All the exponentiations are performed in the underlying finite cyclic group Zp*(that is, computed modulo p, a prime number). The session key computed by the client and the server is hxy (mod p). This key is cryptographically strong regardless of the strength of the password as long as x and y are secret and cryptographically strong random numbers. Refined DH-EKE: The refined DH-EKE protocol forms the basis of the integration into TLS. Client Server (password pwd) (password pwd) x ← Zp-1 Kauth = H1(pwd, IDC, IDS) ÊKauth(hx) y ← Zq, Kauth= H1(pwd, IDC, IDS) Kmstr ← (hx)(y((p-1)/q)) Kconf ← G1(Kmstr), Ksess ← G2(Kmstr) gy, MACKconf(“1”, ÊKauth(hx), gy) Kmstr ← (gy)(x (mod q)) Kconf ← G1(Kmstr), Ksess ← G2(Kmstr) MACKconf(“2”, ÊKauth(hx), gy) abort if MAC not OK The encryptions in the confirmation flows are replaced by Message Authentication Codes (MAC), which is cleaner in terms of functionality and is more efficient. Two separate and independent keys are derived using the key-derivation function Gi: a confirmation key Kconf to provide key confirmation and a session key Ksess for a higher-level protocol. This allows modular protocol composition and prevents protocol interference attacks, i.e., no interference is possible between the messages of the key-exchange protocol and any higher-level protocol, regardless of its use of the session key Ksess. The encryption key is the password authentication key Kauth derived from the password and the identifiers of both parties using the pseudo-random function H1. This guarantees, with high probability, pair-wise unique encryption keys and eliminates the risk of interference between a client’s (potentially parallel) sessions with multiple servers, even if this client reuses the same password with several of these servers.
  • 4. Overview of TLS: TLS is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. The Record Protocol encapsulates higher-level protocols (such as HTTP) and handles the reliability, confidentiality and compression of the messages exchanged over the connection. The TLS Handshake Protocol is responsible for setting up the secure channel between the server and the client, and provides the keys and algorithm information to the Record Protocol. The integration of the password-based protocols are not relevant to the Record Protocol, therefore it will not be discussed further. Client Server ClientHello ServerHello, Certificate*, ServerKeyExchange, CertificateRequest*, ServerHelloDone Certificate*, ClientKeyExchange, CertificateVerify*, [ChangeCipherSpec], Finished [ChangeCipherSpec], Finished Application Data ← --------------------------------------------------------- (Situation-dependent messages are flagged with an asterisk.) ClientHello: Contains a random challenge to guarantee freshness and to tell the server the cryptographic algorithms supported by the client. ServerHello: Contains a set of algorithms called the cipher suite chosen by the server based on the ClientHello message and another random challenge to help assure the server of the freshness of the protocol. Certificate: Contains the server’s certificate, if server authentication is required. ServerKeyExchane: Contains the server’s DH half-key gx signed with the server’s signing key. CertificateRequest: Contains a list of accepted certificate types and CAs, if client authentication is required. ServerHelloDone: Marks the end of server hello side. ClientKeyExchange: Contains the client’s DH half-key gy, the DH key gxy (premaster secret obtained using the server’s half-key and its own half-key), the master secret (or the
  • 5. session key) which is the hash of the premaster secret together with the two previously exchanged challenges. CertificateVerify and Certificate: Required if client authentication to server is required. ChangeCipherSpec: Notifies the Record Protocol of the newly negotiated keys and algorithms. Finished: A Message Authentication Code (MAC) over all the previously sent handshake messages using a newly derived key. The server derives the premaster secret and the master secret from ClientKeyExchange message and its own inputs. Verification of the Finished message will assure the server of the integrity and freshness of the request. The server then sends a similar Finished message to the client. This authenticates the server to the client and assures the freshness of the keys used. At this point, the client can start sending application data to the server. Integration of DH-EKE in TLS: Client Server (password pwd) (v = g*Kvrfy, Kauth) ClientHello choose y, y’εR Zq ServerHello, ServerKeyExchange (gy, g*y’), ServerHelloDone derive Kauth and Kvrfy from pwd and choose x εR Zp-1 ClientKeyExchange (ÊKauth(hx)) calculate premaster secret pms = H3((hx)(y(p-1/q)),vy’)) [ChangeCipherSpec], Finished (MACG3(pms) (ÊKauth(hx), gy, …)) calculate premaster secret pms = H3((gy)(x (mod q)), (g*y’)Kvrfy) accept session if Finished OK [ChangeCipherSpec], Finished (MACG4(pms) (ÊKauth(hx), gy, …)) accept session if Finished OK Application Data
  • 6. ← ---------------------------------------------------------- The client first chooses a password pwd. Then, the client derives a password authentication key Kauth = H1(pwd, IDC, IDS) and computes the password verifier v = gKvrfy with Kvrfy = H2(pwd, IDC, IDS), where IDC and IDS are the identifiers of the client and server respectively. Finally v and Kauth are sent securely to the server and stored together with the client’s name in the server’s user database. Protocol Flow Processing: 1. Client  Server The client proposes some of the DH-EKE cipher suites in the ClientHello message. 2. Server  Client The server chooses y, y’εR Zq and computes gy (mod p) and g*y’ (mod p). ServerKeyExchange: Computes the ServerDHEKEParams field with gy and g*y’. If the server’s group parameters are not a priori fixed, the server also prepares ServerDHParamsProof to allow optimized parameter verification for the client. 3. Client  Server The client verifies that the gy and g*y’ contained in ServerKeyExchange are of the right size and order, i.e., (gy)q (mod p) = 1 ^ gy (mod p) ≠ 1. The client aborts if the above conditions are not fulfilled. The client asks the user for password and derives the authentication key (Kauth) and the verifier key (Kvrfy). ClientKeyExchange: The client chooses x εR Zp-1, computes hx (mod p), encrypts hx, ÊKauth(hx) and enters it along with the user’s identity in the ClientDHEKEParams field. 4. Server  Client The server extracts the identity of the client from the ClientKeyExchange and retrieves the client’s record from the user database. The server computes the premaster secret pms as H3((hx)(y(p-1/q)),vy’) and generates the server’s Finished message by means of a MAC over all previously sent handshake messages. The server performs a ChangeCipherSpec and sends the Finished message to the client. 5. Client  Server The client computes pms = H3((gy)(x (mod q)), (g*y’)Kvrfy) to obtain the premaster secret and verifies the server’s Finished message. If the verification fails, the client aborts. The client generates the Finished message (a MAC over all previously exchanged handshake messages), proceeds with the ChangeCipherSpec and sends the Finished message to the server. The client can start sending data immediately after the Finished message. 6. Server  Client The server verifies the client’s Finished message. If the verification fails, the server aborts, increments the ‘potential online attack’ counter in the client’s database record and locks the account if the ‘potential online attack’ counter reaches a threshold. If the verification is correct, the
  • 7. ‘potential online attack’ counter is updated; the exact procedure depends on local policy: setting it to 0, decrementing it by 1, etc… Conclusion: The key-exchange protocols are resistant to (offline) dictionary attacks even when used with memorizable and potentially weak secrets (or passwords). By proper handling of online dictionary attacks, which are usually detectable, these systems are at least as secure as other systems based on strong public or shared keys. Also they do not have to be backed up by any infrastructure such as a PKI. The integration of these protocols into TLS is as non-intrusive as possible and DH-EKE outperforms comparable cipher suites, thus providing mutual authentication and perfect forward secrecy over an insecure channel. References: 1. Michael Steiner, Secure Password-Based Cipher Suite for TLS, http://www.semper.org/sirene/publ/SBEW_01EKETLS.pdf 2. SSL 2.0 Protocol Specification, http://wp.netscape.com/eng/security/SSL_2.html 3. RFC 2246, TLS Protocol Version 1.0, January 1999, http://www.ietf.org/rfc/rfc2246.txt

×