Cryptography and Network Security

1. Cryptography and Network Security Third Edition by William Stallings Lecture slides by Lawrie Brown Modified by David Martin 91.514 IWS II Guest Lecture

2. Web Security • Web now widely used by business, government, individuals • but Internet & Web are vulnerable • have a variety of threats • integrity • confidentiality • denial of service • authentication • need added security mechanisms

3. SSL history • Transport layer security service • Actually a protocol, not an API, though an API is usually nearby • Popularity really came from Netscape’s attempt to jumpstart ecommerce • 1994: Netscape designed and built SSLv2 • and told consumers that they needed SSL; credit card numbers were too sensitive to let go unencrypted • Only Netscape Commerce Server supported SSL • It relied on X.509 certificates issued by RSADSI • Microsoft had PCT (Private Communications Technology), backwards-compatible with SSLv2 • Fixed various problems, added some new features • 1995: SSLv3 (what we will see)

4. SSL history continued • Microsoft Secure Transport Layer Protocol (STLP) • Derived from SSLv3 • Supported unreliable transport (UDP), client auth via shared secrets • 1996 IETF Transport Layer Security working group • to reconcile SSL and PCT/STLP (and others?) into an IETF protocol • SSLv3 "won" and is the basis for TLS • IESG (steering group) instructed working group to add DSS, DH, 3DES • Big deal because of Netscape's preference for RSA • But more so because 3DES was not exportable • 1995 "Danvers doctrine" said to make decisions based on good engineering rather than national policies • See RFC 3365, "Strong Security Requirements for Internet Engineering Task Force Standard Protocols "

5. SSL history continued • RSADSI provided X.509 certificates for server authentication • RSADSI spun off Verisign • Others seemed poised to compete but didn’t really • Strongest competitor Thawte was eventually bought by Verisign • Not much competition remains • Visit https://www.verisign.com/ • Public Key Infrastructure (PKIX) working group for IETF standardization of X.509 certs • TLS depended on this group's work • TLS published in January 1999 as RFC 2246

6. U.S. Crypto Export control • NSA made the decisions • Authentication was generally approved • Before Sept '98: encryption required export license • up to 40-bit DES, 512-bit key exchange • RC2 and RC4 particularly favored • larger sizes available to banks • After Sept '98: • review still required • up to 56-bit DES and 1024-bit key exchange • Traces of all this are visible throughout SSL

7. U.S. Crypto Export control • After Jan 2000: • open source can just be posted on Internet • commercial/retail software still formally required to undergo review, but generally approval follows

8. SSL Architecture

9. SSL Architecture • SSL session • an association between client & server • created by the Handshake Protocol • define a set of cryptographic parameters • essentially, the master secret • may be shared by multiple SSL connections • SSL connection • a transient, peer-to-peer, communications link, typically a TCP connection • associated with a SSL session

10. SSL Architecture • A session may outlive any particular connection • SSL considers TCP sessions partially unreliable: connections may be broken • So it's possible to resume sessions without having to renegotiate everything • Big potential performance benefit

11. SSL Record Protocol • confidentiality • using symmetric encryption with a shared secret key defined by Handshake Protocol • IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128 • message is compressed before encryption • message integrity • using a MAC with shared secret key • similar to HMAC but with different padding • https • “use security” bit • server authenticated, client not (typically)

12. SSL Change Cipher Spec Protocol • one of 3 SSL specific protocols which use the SSL Record protocol • a single message • causes pending state to become current • hence updating the cipher suite in use

13. SSL Alert Protocol • conveys SSL-related alerts to peer entity • severity • warning or fatal • specific alert • unexpected message, bad record mac, decompression failure, handshake failure, illegal parameter • close notify, no certificate, bad certificate, unsupported certificate, certificate revoked, certificate expired, certificate unknown • compressed & encrypted like all SSL data

14. SSL Handshake Protocol • allows server & client to: • authenticate each other • to negotiate encryption & MAC algorithms • to negotiate cryptographic keys to be used • comprises a series of messages in phases • Establish Security Capabilities • Server Authentication and Key Exchange • Client Authentication and Key Exchange • Finish

16. TLS (Transport Layer Security) • IETF standard RFC 2246 similar to SSLv3 • with minor differences • in record format version number • uses HMAC for MAC • a pseudo-random function expands secrets • has additional alert codes • some changes in supported ciphers • changes in certificate negotiations • changes in use of padding

17. TLS Key Exchange • Our “Key” is called “pre-master secret” in documentation • Static RSA • client chooses key and sends it encrypted under public key associated with server cert • no forward secrecy • Ephemeral RSA • server signs newly chosen weak RSA key under strong long-term RSA key • client chooses pre-master secret and transmits it under the weak key • export considerations • forward secrecy • what if short-term key is revealed? • what if long-term key is revealed?

18. TLS Key Exchange • Anonymous Diffie-Hellman (DH) • unauthenticated, like project 3 "any" mode, rare • Static DH • Server’s contribution is fixed in cert, sort of like project 3 "fixed" mode, rare • Ephemeral DH • server authenticates contribution by signing it, common • Fortezza • PCMCIA smart card • Skipjack (declassified June 1998) • Key escrow • Law Enforcement Access Field (LEAF) • Key encrypted in IV • Extremely rare

19. TLS Key Exchange • Server Gated Crypto (SGC) • Historical • For approved financial transactions • Special server certs allow clients to use strong crypto where they would normally refuse • www.fortify.net

20. Server chooses cipher from suite Client chooses pre-master secret According to selected key exchange method MAC of handshakes (over these choices) prevent simple cipher suite modification MAC shared secret is derived from master secret From Rescorla, SSL and TLS: Designing and Building Secure Systems, Addison-Wesley 2001

21. Moeller Downgrade Attack • Requires attacker to factor 512-bit RSA • But works even if client and server are willing to use 1024 bits • Start by forging messages forcing client and server to agree on 512-bit export RSA • Remove all other choices from offered suites • Problem: MAC over agreement • Attackers factors 512 bits to recover shared secret • Uses it to forge and substitute MACs • Then listen to rest of session • Solutions: • Have ServerKeyExchange signature depend on ClientHello • Just stop using the export suites (either side)

22. Netscape PRNG • Wagner, Goldberg ’96 • Disassembly • Observed that Netscape RNG was seeded from process ID and time of day in SSLv2 • Guess & verify secret • Speed • Logged onto machine, 25 secs • No login, about an hour

23. Client Authentication • SSL/TLS, IE, Netscape all support client certs • Rarely used outside of corporate settings • Peoplesoft ? • HTTP Basic authentication within SSL session • Cleartext password stored on server, but hidden on wire

24. Performance • SSL is slow • Crypto • Latency (in addition to TCP) • Session resumption • Servers have it rough, signing with private key to prove identity

25. From Rescorla, SSL and TLS: Designing and Building Secure Systems, Addison-Wesley 2001

26. From Rescorla, SSL and TLS: Designing and Building Secure Systems, Addison-Wesley 2001

27. Performance • Layering woes • Nagle algorithm, delayed ack • Client stack waits for ack of old record before sending tinygram • Such as first client application-layer transmission, perhaps • Server stack delays its ack of old record up to 200 ms • TCP_NODELAY turns off algorithm • Not default in openssl ? • Accelerators • Crypto cards • Inline HTTP/TLS -> HTTP

28. HTTPS and Web Servers • HTTP over SSL usually port 443 • 443 means "use SSL" • Web pages typically include a lot of embedded content • potentially fetched over different TCP connections • session resumption is critical for performance • HTTP persistent connections are very helpful • Proxies • A proxy is a man-in-the-middle • HTTP "CONNECT" method just relays data; proxy can't examine • Possible to reconfigure clients so that a real man-in-the-middle "attack" on https is possible • You set up your own CA • Apache / OpenSSL / mod_ssl very common combination • Fairly complicated setup • Plenty of commercial server support

29. Original Purpose • Protecting consumer credit-card info • Never worked as well as advertised, because of ubiquity of redirects • While some people are trained to look for the miniscule lock icon, they alsoneed to verify that the URL isreasonable

30. Prominent site Not even any apparent SSL use on this page Though it's really enabled "If you receive an error message", please try without SSL Example: Amazon

31. Secure Electronic Transactions (SET) • open encryption & security specification • to protect Internet credit card transactions • developed in 1996 by Mastercard, Visa etc • not a payment system • rather a set of security protocols & formats • secure communications amongst parties • trust from use of X.509v3 certificates • privacy by restricted info to those who need it