Secure Communica-on Protocols
Today • SSL/TLS – Protec-on for web browsing / transac-ons • SSH – Secure shell (remote login) • IPSec – IP Security suite, originally for use with IPv6
SSL/TLS • Secure Sockets Layer / Transport Layer Security • History – Developed by Netscape – 1.0 internal – 2.0 Feb 1995 – 3.0, 1996, fixed many bugs – TLS1.0 – Internet standard, 1999 – TLS1.1 in 2004, TLS1.2 in 2008
SSL usage • Protect web transac-ons – HTTPS (lock icon) • Main mo-va-on: send credit card #’s over the web – Aside: bank designed SET protocol was not accepted – Neither was digital cash
SSL modes • Mutual authen-ca-on – Both client and server know each other’s public key • Anonymous client – Server’s public key is known • Anonymous server – No public keys are known – Why use this mode?
SSL Key Distribu-on • Public keys are enclosed in a cer-ficate: – Sign(K_verisign, “the public key for Amazon.com is 0x12345”) • One of ~40 authori-es can cer-fy – Authori-es’ keys are hard‐ coded in browser • What about user cer-ficates?
Protocol ClientHello includes version, cipher suites ServerHello chooses cipher suite Cer*ficate Cer*ficateRequest Cer*ficate ServerHelloDone ClientKeyExchange include PMK encrypted under server’s key ChangeCipherSpec Finished ChangeCipherSpec Finished
Algorithms • Authen-ca-on – RSA, DSA, Ellip-c curve DSA • Encryp-on – RC4, 3DES, AES, IDEA, DES, Camellia • HMAC – HMAC‐MD5 or HMAC‐SHA1 • Key exchanges – RSA, DH, Ellip-c curve DH, SRP, pre‐shared key
Version Nego-a-on • Cipher subs-tu-on agack – Client ‐> “I support AES, 3DES, DES” – Middleman ‐> Server “I support DES” – Server ‐> Client “Let’s use DES” • Problem in SSLv2. SSLv3 uses a MAC on all of exchange messages to protect against this • Cute trick to deal with SSLv2 fallback – Non‐random data in RSA‐PSS
Timing Agacks • Mod‐exp algorithm for RSA cur = M for i in 1..log d if bitisset(d,i) cur = cur * M cur = cur * cur • Timing depends on which bits set in d • More on this & other side channel agacks later
SSH • Secure Shell • Secure replacement for insecure rlogin • Op-mis-c key exchange: – Each host sends its public key (w/o cer-ficate) in message – First -me talking to host a, record its key – Warn if key changed in between instances
SSH Protocols • V1: basic protocol (“my first crypto protocol”) – Many problems • V2: fixes problems, adds func-onality – Uses encrypt‐and‐MAC approach – Supports port forwarding, file transfers, …
SSH plaintext recovery [diagram]
SSH Debian Vulnerability • A maintainer “helpfully” removed these lines MD_Update(&m,buf,j); [ .. ] MD_Update(&m,buf,j); /* purify complains */ • As a result, only 32,767 keys would ever be generated • 18 months to discover bug!
IPSec • IP security suite • Intended for IPv6 – Backported to IPv4 – Now used in most VPN installa-ons • Two extra headers: – AH – authen-ca-on header – ESP – encapsulated payload (encryp-on) • IPSec PKI?
IPSec analysis • AH and ESP considered separate func-onality • Many agacks possible if AH is not used – E.g., CBC cut‐and‐paste
Today • Three widely used protocols – SSL/TLS, SSH, IPSec • Different design choices – Many historical vulnerabili-es • Take away points: – Encryp-on without authen-ca-on “all but useless” [Bellovin 96] – Protocol design is hard, try to avoid it – PKI can be a significant barrier to deployment
Further Reading • Analysis of the SSL 3.0 protocol David Wagner and Bruce Schneier. 2nd USENIX Workshop on Electronic Commerce , November 1996 – Systema*c analysis of the SSL protocol; finds it mostly good • Problem Areas for the IP Security Protocols , Steven M. Bellovin, NDSS 1996 – Most problems due to using encryp*on without authen*ca*on • Plaintext Recovery ANacks against SSH , Mar-n R. Albrecht, Kenneth G. Paterson, Gaven J. Watson, IEEE S&P 2009
Recommend
More recommend
