Security

1. Security

2. Asymmetric Cryptosystems • Need a hard problem (like symmetric cryptosystems) • With a trap door: if you know a secret, the hard problem becomes easy

3. One-Way Functions • Easy to compute, hard to invert • Trap-door one way function: • D (E (M)) = M • E and D are easy to compute. • Revealing E doesn’t reveal an easy way to compute D. • Hence, anyone who knows E can encrypt, but only someone who knows D can decrypt

4. Cryptography • Cryptography makes it difficult for an unauthorized third party to access and understand private communication between two parties. Private data can be made unintelligible to unauthorized parties through the process of encryption. Encryption uses complex algorithms to convert the original message, or cleartext, to an encoded message, called ciphertext. Decryption does the reverse. • A key is a bit string that is used by the algorithms for encryption or decryption.

5. Encryption Algorithms • Parties • Alice and Bob want to communicate. • Charlie, the unauthorized third party, is known as the attacker. • Secret key • Alice and Bob agree on an algorithm, and have the same secret key, which they use to encrypt plaintext and decrypt cyphertext. • Well-known secret key cryptographic algorithms include the Data Encryption Standard (DES), triple-strength DES (3DES), Rivest Cipher 2 (RC2), Rivest Cipher 4 (RC4) and the Advanced Encryption Standard (AES).

6. Encryption Algorithms (cont.) • Public key • Alice and Bob agree on an algorithm, and Alice creates a pair of keys—public and private—and sends the public key to Bob and other people. Bob (or anyone else) encrypts with the public key, but only Alice can decrypt with the secret private key. • Well-known public key algorithms include Rivest Shamir Adleman (RSA) and Diffie-Hellman (DH). • Because they require extensive computations, these algorithms run slowly. Therefore they’re only used for encrypting small pieces of data, such as secret keys or signatures.

7. RSA [Rivest, Shamir, Adelman 78] One-way function: multiplication is easy, factoring is hard Trap-door: number theory (Euler and Fermat)

8. Security of RSA • n is public, but not p and q where n = pq • How much work is factoring n? Number Field Sieve (fastest known factoring algorithm) is: O(e1.9223((ln (n))1/3 (ln (ln (n)))2/3) n ~200 digits – would take quintillions of years The movie Sneakers is about what happens if someone discovers a O(nk) factoring algorithm.

9. Math behind RSA • Find P and Q, large prime numbers • Choose E such that E is greater than 1, E is less than PQ, and E and (P-1)(Q-1) are relatively prime, which means they have no prime factors in common. E does not have to be prime, but it must be odd. (P-1)(Q-1) can't be prime because it's an even number.

10. Compute D such that (DE - 1) is evenly divisible by (P-1)(Q-1). Mathematicians write this as DE = 1 (mod(P-1)(Q-1)), and they call D the multiplicative inverse of E. This is easy to do -- simply find an integer X which causes D = (X(P-1)(Q-1) + 1)/E to be an integer, then use that value of D. • The encryption function is C=(T^E)mod PQ, where C is the ciphertext (a positive integer), T is the plaintext (a positive integer), and ^ indicates exponentiation. The message being encrypted, T, must be less than the modulus, PQ. • The decryption function is T=(C^D)modPQ, where C is the ciphertext (a positive integer), T is the plaintext (a positive integer), and ^ indicates exponentiation.

11. Your public key is the pair (PQ,E). Your private key is the number D (reveal it to no one). The product PQ is the modulus (often called N in the literature). E is the public exponent. D is the secret exponent.You can publish your public key freely, because there are no known easy methods of calculating D, P, or Q given only (PQ, E) (your public key). If P and Q are each 1024 bits long, the sun will burn out before the most powerful computers presently in existence can factor your modulus into P and Q.

12. Asymmetric Cryptosystems • Encryption and Decryption are done with different keys • Keep one of the keys secret, reveal the other EKRA (EKUA (M)) = M Alice’s Public Key: KUA Alice’s Private Key: KRA Only KRA can decrypt a message encrypted using KUA.

13. Public-Key Applications: Privacy Bob Alice • Alice encrypts message to Bob using Bob’s Private Key • Only Bob knows Bob’s Private Key only Bob can decrypt message Decrypt Ciphertext Encrypt Plaintext Plaintext Bob’s Public Key Bob’s Private Key

14. Signatures Bob Alice Signed Message Decrypt Encrypt Plaintext Plaintext • Bob knows it was from Alice, since only Alice knows Alice’s Private Key • Non-repudiation: Alice can’t deny signing message (except by claiming her key was stolen!) • Integrity: Bob can’t change message (doesn’t know Alice’s Private Key) Alice’s Public Key Alice’s Private Key

15. The Internet Ciphertext Encrypt Decrypt Plaintext Plaintext KUS KRS User Server Public Key Private Key How does User know the public key to use?

16. Key Management

17. Approach 1: Meet Secretly • User and Server Operator meet secretly and swap public keys • If you can do that, might as well agree on a secret (symmetric key) instead • Doesn’t work for Internet transactions

18. Approach 2: Public Announcement • Publish public keys in a public forum • Append to email messages • Post on web site • New York Time classifieds • Easy for rogue to pretend to be someone else • Forge email, alter web site, lie to New York Times

19. Approach 3: Public Directory • Trusted authority maintains directory mapping names to public keys • Entities register public keys with authority in some secure way • Authority publishes directory • Print using watermarked paper, special fonts, etc. • Allow secure electronic access • Depends on secure distribution of directory’s key

20. KUS CS = EKRVeriSign[“Server”, KUS] Request CS Approach 4: Certificates VeriSign $$$$ User Server EKUVeriSign (CS) = [“Server”, KUS] Knows KRS

21. SSL Background • Two Kinds of SSL • Low Encryption (40-bit; 1.1x1012 possible keys) • High Encryption (128-bit; 3.8x1038 possible keys) • SSL is a transport level technology for authentication and data encryption between a web server and a Web server (example). • Applied at the socket interface from the application to the network software. Internet Header Application Header Data Link Header Transport Header Data being sent Plaintext Cipher Text

22. KRCA[Server Identity, KUS] KUS[K] Secure channel using K SSL (Secure Sockets Layer) Server Browser Hello Check Certificate using KUCA Pick random K Find K using KRS Note: This is slightly simplified from the actual SSL protocol. This version is vulnerable to a person-in-the-middle attack!

23. Security Achieved by the Secure Sockets Layer (SSL) • Confidentiality Encrypt data being sent between client and server, so that passive wiretappers cannot read sensitive data. • Integrity Protection Protect against modification of messages by an active wiretapper. • Authentication Verify that a peer is who they claim to be. Servers are usually authenticated, and clients may be authenticated if requested by servers.

24. TCP/IP Layer Protocol Application Layer HTTP, IMAP, NNTP, Telnet, FTP, etc. Secure Sockets Layer SSL Transport Layer TCP Internet Layer IP TCP/IP Protocol Stack With SSL

25. Secure sockets layer • Developed by Netscape, now taken on by Internet Engineering Task Force, to establish Transport Layer Security (TLS 1.0 is just SSL 3.1) • Works by securing communication channels • Provides server authentication, confidentiality, integrity (SSL 3.0 supports client authentication too) • Lower-level than HTTP, FTP etc • Higher-level than TCP/IP

26. Benefits of SSL • Used by most browsers • Simple to use service such as HTTPS built on top of SSL • Designed to be easy for clients • Server authentication always required • Usually, no client authentication required

27. How it works • Client • connects to site using HTTPS protocol and tells server which cipher suites it supports • Server • tells client which cipher suites it supports • sends certificate to client • Initiates a key exchange algorithm using public key cryptography • Client • Completes key exchange by generating symmetric key which is sent back to server. This key used for subsequent data exchange. • Verifies certificate (ie checks for trusted CA) • Tells server which cipher suite to use

28. How SSL Achieves Authentication • Optional • Protocol • If the client wants to authenticate the server then they follow the protocol in “Authentication with a Public Key Certificate” with the client acting as Bob. • If the server wants to authenticate the client then they follow the protocol in “Authentication with a Public Key Certificate” with the server acting as Bob.

29. How SSL Works • Handshake • a negotiation process that creates or rejoins a session • If (Handshake succeeds) then Encrypted data can be exchanged Else The connection is aborted

30. How SSL Works: the Handshake • Negotiate the cipher suite • Authenticate identities (optional) • Exchange secret key

31. How SSL Works: Negotiate the Cipher Suite • A cipher suite • A set of cryptographic algorithms • An algorithm for exchanging a secret key • A secret key encryption algorithm and key length • A cryptographic hash function • The client tells the server which cipher suites it has available, and the server chooses the best mutually acceptable cipher suite.

32. How SSL Achieves Confidentiality • Create a secret key • Based on information generated by the client with a secure random number generator • Use public keys to exchange the secret key • The server sends its public key to the client • The client encrypts the secret key with the server's public key and sends it to the server • The server decrypts the secret key information with the server’s private key • Encrypt and decrypt data with the secret key • The client and server use the negotiated algorithm

33. Cryptographic Hash Functions Q: How can we prevent Charlie from tampering with data that Alice sends to Bob? A: Make any change in the data detectable. • A cryptographic hash function is like a checksum. • A cryptographic hash function generates, a small string of bits, known as a hash, from a message. Any slight change to the message should make a change in the resulting hash. • Widely used hash functions are Message Digest 5 (MD5) and Secure Hash Algorithm (SHA).

34. Message Authentication Code • A message authentication code (MAC) is like a cryptographic hash, but it uses a secret key. • Including a secret key with the data processed by a cryptographic hash produces a hash called an HMAC. • Here’s how we prevent Charlie from tampering with data that Alice sends to Bob. • Alice calculates an HMAC for her message and append the HMAC to her original message. She encrypts the message plus the HMAC using a secret key she shares with Bob. • Bob decrypts the message and recalculates the HMAC. If his HMAC differs from the one Alice sent then the message was modified in transit.

35. How SSL AchievesIntegrity Protection • Client and server use their secret key, and an agreed-upon cryptographic hash function to attach an HMAC to each message sent. • The receiver checks that each message has not been altered.

36. Digital Signatures Q: How does Alice prove to Bob that a message comes from her? A: Demonstrate that she has her private key. • Protocol • As before, Alice creates her public and private keys, and distributes her public key with her name attached. • Alice encrypts a message using her private key and sends the message to Bob. • If Bob can decrypt the data with Alice's public key, the message must have been encrypted by Alice with her private key, since only Alice has her private key. • This is called a digital signature.

37. Public Keys and Authentication Q: How does Alice prove to Bob that she is Alice? A: Demonstrate that she has her private key. • Protocol • Bob creates a random number, encrypts it with Alice’s public key and sends it to Alice. • Alice decrypts the random number with her private key, and sends the random number to Bob, proving she’s Alice.

38. Public Keys and Authentication (cont.) Q: How do we prevent Charlie from pretending to be Alice by circulating a public key named ‘Alice’? A: By having someone we trust verify that Alice is Alice. • Public Key Certificate • A digital ‘passport’ that is issued by a trusted organization and identifies the bearer. • A trusted organization is called a certificate authority (CA). • The CA digitally signs the certificate, thereby attesting to the validity of the certificate’s information.

39. Public Key Certificate Contains the fields: • Subject’s public key • Subject • Information about the entity that the certificate represents. • Issuer • The CA that issued the certificate. If a user trusts the CA that issues a certificate, and if the certificate is valid, the user can trust the certificate. • Signature • The signature is created using the CA's private key and ensures the validity of the certificate. • Period of validity • The certificate’s expiration date.

40. Authentication with a Public Key Certificate Q: How is a public key certificate used to help Alice prove to Bob that she is Alice? • Protocol • Bob obtains Alice’s public key certificate. • Bob also has a certificate for a trusted CA that supposedly signed Alice’s public key certificate. • Bob checks that the trusted CA signed Alice’s public key certificate by using the CA’s public key to decrypt the signature in Alice’s public key certificate. • Run the protocol for “Q: How does Alice prove to Bob that she is Alice?”

41. Certificate Chains • Multiple certificates may be linked in a certificate chain. • The first certificate is that of the sender. • The next is the certificate of the entity that issued the sender’s certificate. • If there are more certificates in the chain, each is that of the authority that signed the previous certificate. • The final certificate in the chain is the certificate for a root CA, a certificate authority that is widely trusted. • Well-known public CAs include VeriSign, Entrust, and GTE CyberTrust.

42. How SSL Works: the Handshake in Detail

43. How SSL Works: the Handshake in Detail • Client hello - The client sends the server information including the highest version of SSL it supports and a list of the cipher suites it supports. • Server hello - The server chooses the highest version of SSL and the best cipher suite that both the client and server support and sends this information to the client. • Certificate - If server authentication is required then the server sends the client a certificate or a certificate chain. • Certificate request - If the server needs to authenticate the client, it sends the client a certificate request. • Server key exchange - The server sends the client a server key exchange message when the public key information sent in 3) above is not sufficient for key exchange. • Server hello done - The server tells the client it is finished with its initial negotiation messages.

44. How SSL Works: the Handshake in Detail • Certificate - If the server requests a certificate from the client in Message 4, the client sends its certificate chain, like the server did in Message 3. • Client key exchange - The client generates information used to create a key to use for symmetric encryption. For RSA, the client then encrypts this key information with the server's public key and sends it to the server. • Certificate verify – If the server is authenticating the client, the client sends a random number that it digitally signs. When the server decrypts number with the client's public key, the server authenticates the client. • Change cipher spec - The client tells the server to change to encrypted mode. • Finished - The client sends the server a hash of the handshake messages. • Change cipher spec - The server tells the client to change to encrypted mode. • Finished - The server sends the client a hash of the handshake messages. • Encrypted data - The client and the server communicate using the symmetric encryption algorithm and the cryptographic hash function negotiated in Messages 1 and 2, using the secret key that the client sent to the server in Message 8.

45. How SSL Works: the Handshake Shortcut If the parameters generated during an SSL handshake are saved, these parameters can be re-used for future SSL connections. • Session Describes an ongoing relationship between a particular client and a particular server One session per SSL connection But a session may be reused repeatedly, on sequential or concurrent connections Reusing a session greatly speeds up handshaking

46. Issues with SSL • Secures communication at the transport level rather than at the message level • Does nothing to protect data sitting in a filestore or database • Doesn’t support end-to-end security over a chain of entities • Slows down processing by > 90%

47. SSL in Java • Simpler to use HTTPS directly, but … • … can use Java Secure Sockets Extension (JSSE) • Often no more than using SSLServerSocketFactory instead of ServerSocketFactory and SSLSocketFactory instead of SocketFactory

48. What can go wrong? • Java API doesn’t call right SecurityManager checks (63 calls in java.*) • Font loading bug, synchronization • ClassLoader is tricked into loading external class as internal • Bug in Bytecode Verifier can be exploited to circumvent SecurityManager • Policy is too weak and allows damaging behavior

49. Hostile Applets • See http://java.sun.com/sfaq/chronology.html (about 1 new vulnerability/month) • Easy to write “annoying” applets (policy is too imprecise; no way to constrain many resource operations) • http://www.cigital.com/hostile-applets/index.html

50. Where • java.security: • message digests • certificates • Java Cryptography Extension (JCE) • Encryption • Key generation and agreement • Message authentication codes • Java Secure Sockets Extensions (JSSE) • Implements SSL programmatically