Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Security. Asymmetric Cryptosystems Need a hard problem (like symmetric cryptosystems) With a trap door: if you know a secret, the hard problem becomes."— Presentation transcript:

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 ? n ~200 digits – would take quintillions of years Number Field Sieve (fastest known factoring algorithm) is: O(e 1.9223((ln (n)) 1/3 (ln (ln (n))) 2/3 ) The movie Sneakers is about what happens if someone discovers a O(n k ) 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 E KRA (E KUA (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 Alice encrypts message to Bob using Bob’s Private Key Only Bob knows Bob’s Private Key  only Bob can decrypt message Encrypt Decrypt Plaintext Ciphertext Plaintext Alice Bob Bob’s Public Key Bob’s Private Key

14 Signatures 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) Encrypt Decrypt Plaintext Signed Message Plaintext Alice Bob Alice’s Private Key Alice’s Public Key

15 Encrypt Decrypt Plaintext Ciphertext Plaintext User Server KU S KR S The Internet 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 Approach 4: Certificates VeriSign UserServer KU S C S = E KR VeriSign [“Server”, KU S ] CSCS Request $$$$ E KUVeriSign (C S ) = [“Server”, KU S ] Knows KR S

21 Two Kinds of SSL –Low Encryption (40-bit; 1.1x10 12 possible keys) –High Encryption (128-bit; 3.8x10 38 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. SSL Background Plaintext Cipher Text Data Link Header Internet Header Transport Header Application Header Data being sent

22 SSL (Secure Sockets Layer) Browser Server Hello KR CA [Server Identity, KU S ] Check Certificate using KU CA Pick random K KU S [K] Find K using KR S Secure channel using K 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 Protocol Stack With SSL TCP/IP Layer Protocol Application LayerHTTP, IMAP, NNTP, Telnet, FTP, etc. Secure Sockets Layer SSL Transport LayerTCP Internet LayerIP

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 1.Handshake –a negotiation process that creates or rejoins a session 2.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 Achieves Integrity 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 1.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. 2.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. 3.Certificate - If server authentication is required then the server sends the client a certificate or a certificate chain. 4.Certificate request - If the server needs to authenticate the client, it sends the client a certificate request. 5.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. 6.Server hello done - The server tells the client it is finished with its initial negotiation messages.

44 How SSL Works: the Handshake in Detail 7.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. 8.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. 9.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. 10.Change cipher spec - The client tells the server to change to encrypted mode. 11.Finished - The client sends the server a hash of the handshake messages. 12.Change cipher spec - The server tells the client to change to encrypted mode. 13.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

51 Security provider architecture Java security consists of engines and algorithms An engine is an operation that a programmer can perform eg create a message digest An algorithm is a particular implementation of that operation eg MD5 or SHA for message digests The security provider interface provides an easy mechanism for substituting algorithms while leaving the basic operations unchanged Format: –engine.algorithm eg MessageDigest.SHA

52 Security provider architecture

53

54 Java support for cryptography Keys Certificates Key management Message digests Secure message digests Digital signatures Encryption & decryption

55 Keys & certificates: recap Two kinds of keys: –secret (symmetric) –public/private (asymmetric) Certificates can be used to authenticate public keys: –Public keys usually transmitted as part of a certificate

56 Issues Key management and storage Self-certification? Hierarchy of trust

57 The Key class hierarchies: a partial view java.security.Key PublicKeyPrivateKey java.security.interfaces.DSAKey DSAPrivateKeyDSAPublicKey RSAPrivateKey RSAPrivateKeyCrt RSAPublicKey java.security.KeyPair java.crypto.SecretKey

58 Why so many? Certain algorithms require methods to access key generation parameters for export –DSAKey: methods getP(), getQ(), getG() Certain algorithms have specific roles –DHKey: Diffie-Hellman key exchange

59 Example: generate/export key pair Source: Oaks (2001)

60 Example: import key pair Source: Oaks (2001)

61 Distributing public keys: certificates Recall that a key doesn’t provide any authentication of the owner A digitally-signed document + public key doesn’t guarantee that the document came from X Certificates solve the problem. A Certificate Authority verifies the public key However, anyone can obtain a basic level certificate Bootstrapping problem? Who verifies the certificate containing the public key of the CA? Workable solution: provide public keys of main CAs (eg in browser or in Java implementation)

62 Certificates in Java java.security.cert.Certificate byte[] getEncoded() void verify(PublicKey pk) publicKey getPublicKey() java.security.cert.CertificateFactory Certificate generateCertificate(InputStream is) NB Imports a certificate (doesn’t generate from scratch)

63 Certificates in Java Derived from: Oaks (2001)

64 Revoked certificates Expiration date is sometimes not sufficient For immediate invalidation, need a Certificate Revocation List (CRL) Not clear yet how CA issues CRL yet Support in Certificate class

65 Key & certificate management keystore: file (or may be database) holding keys and certificates Alias: keystore-specific name for entity eg mpc Distinguished name (DN): longer name for entity (but not guaranteed unique) –Usually includes common name (eg Martin Cooke); organisation; location; state; country Manipulated using keytool or programmatically

66 keytool

67 Secret key management Recall that in public key systems, the private key must be kept private, but that in secret key systems, the secret key must be shared Management problem! –Use non-electronic means to distribute –Use public key encryption to send encrypted key (eg SSL) –Use key agreement algorithm keytool doesn’t understand secret keys

68 http://java.sun.com/developer/technicalArticles/Security/Signed/

69 Message digests update() add data to digest digest() compute digest Derived from: Oaks (2001)

70 Recall that to verify a message digest, must read in message and its digest, compute the digest, and compare the two –isEqual() Source: Oaks (2001)

71 MAC Derived from: Oaks (2001)

72 Digital signature example: sending Derived from: Oaks (2001)

73 Digital signature example: receiving Derived from: Oaks (2001)

74 Application: signed classes Recall entries in policy file of form: grant signedBy “ mpc ” codebase “ http://mpc.com ” { java.io.FilePermission “ - ”, “ read,write ” ; } Achieved via jarsigner tool –jarsigner app.jar mpc

75 Example: encryption Derived from: Oaks (2001)


Download ppt "Security. Asymmetric Cryptosystems Need a hard problem (like symmetric cryptosystems) With a trap door: if you know a secret, the hard problem becomes."

Similar presentations


Ads by Google