Cryptography (Overview)

Transcription

1 Cryptography (Overview) Some history Caesar cipher, rot13 substitution ciphers, etc. Enigma (Turing) Modern secret key cryptography DES, AES Public key cryptography RSA, digital signatures Cryptography in practice Cryptography Basics Alice & Bob want to exchange messages keeping the content secret though not the fact that they are communicating They need some kind of secret that scrambles messages makes them unintelligible to bad guys but intelligible to good guys The secret is a "key" (like a password) known only to the communicating parties that is used to do the scrambling and unscrambling For Caesar cipher, the "key" is the amount of the shift (A => D, etc.) For substitution ciphers, the key is the permutation of the alphabet For Enigma, key is wiring and position of wheels plus settings of patches for modern ciphers, the key is a large integer used as part of an intricate algorithmic operation on the bits of the message Modern Secret Key Cryptography Messages encrypted and decrypted with a shared secret key usually the same key for both operations ("symmetric") Encryption/Decryption algorithm is known to adversaries "security by obscurity" does not work Attacks decrypt specific message(s) by analysis various combinations of known or chosen plaintext and ciphertext determine key by "brute force" (try all possible keys) If key is compromised, all past and future messages are compromised Big problem: key distribution need a secure way to get the key to both/all parties Diplomatic pouches, secret agents,... doesn't work when the parties don't know each other or have no possible channel for exchanging a secret key or when want to exchange secret messages with many different parties e.g., credit card numbers on Internet

2 DES and AES Data Encryption Standard (DES) developed ~1977 by IBM, with NSA involvement widely used, though lingering concerns about trap doors 56-bit key is now too short: can exhaustively test all keys in a few hours with comparatively cheap special-purpose hardware "triple DES" uses 3 DES encryptions to increase effective key length Advanced Encryption Standard (AES) result of an international competition run by NIST ( completely open: algorithms and analyses in public domain Rijndael: winning algorithm selected October 2000 approved as official US government standard 128, 192, 256-bit keys fast in both hardware and software implementations The Big Problem: Key Distribution Public Key Cryptography Fundamentally new idea Diffie & Hellman (USA, 1976); earlier in England but kept secret Each person has a public key and a private key the keys are mathematically related a message encrypted with one can only be decrypted with the other Public keys are published, visible to everyone Private keys are secret, known only to owner Alice sends a secret message to Bob by encrypting it with Bob's public key only Bob can decrypt it, using his private key Bob sends a secret reply to Alice by encrypting it with Alice's public key only Alice can decrypt it, using her private key Eve knows Alice and Bob are talking but can t decrypt what they are saying Digital Signatures Can use public key cryptography for digital signatures if Alice encrypts a message with her private key and it decodes properly with her public key it had to be Alice who encoded it Signature can be attached to a message Alice encrypts a message with her private key Alice encrypts the result with Bob's public key only Bob can decrypt this (with his private key) but it won't make any sense yet

3 Bob then decrypts it with Alice's public key if it decodes properly, it had to be Alice who encrypted it originally Necessary properties of digital signatures can only be done by the right person: can't be forged can't re-use a signature to sign something else signature attached to a document: signs specific contents signature can't be repudiated Usually done by signing a "cryptographic hash" of a document, not the document itself Secure hash is computed by an algorithm Reduces any data to a comparatively short number such that can't deduce the original document from the number any change to the original document produces a completely different hash can't find another document that has the same hash Current secure hash algorithms MD5 (Rivest, MIT): 128 bits SHA-1 (US government standard): 160 bits New international competition to create a new version of SHA-1 analogous to AES competition (again run by NIST) first round submissions in 10/08, final round 12/10, winner in winning algorithm, Keccak, for standardization under SHA-3 RSA Public Key Cryptographic Algorithm Most widely used public key system Invented by Ron Rivest, Adi Shamir, Len Adleman, 1977? patent expired Sept 2000, now in public domain Based on (apparent) difficulty of factoring very large integers "large" >= 1024 bits ~ 300 digits public key based on product of two large (secret) primes encrypting and decrypting require knowledge of the factors Slow, so usually use RSA to exchange a secret "session key" session key used for secret key encryption with AES used by SSH for secure login used by browsers for secure exchange of credit card numbers https: http with encryption SSL (Secure Sockets Layer) or TLS (Transport Layer Security) used to encrypt TCP/IP Properties of Public/Private Keys Can't deduce the public key from the private, or vice versa Can't find another encryption key that works with the decryption key Keys are long enough that brute force search is infeasible Nasty problems: if a key is lost, all messages and signatures are lost if a key is compromised, all messages and signatures are compromised it's hard to revoke a key

4 it's hard to repudiate a key (and hard to distinguish that from revoking) Authentication how do you know who you are talking to? is that really Alice's public key? public key infrastructure, web of trust, digital certificates How Online Shopping Works Browser says "Prove that you're really Amazon" Amazon says "Here's my certificate from a CA" encrypted with the CA's private key Browser decrypts certificate with CA's public key Browser generates a random key, encrypts it with Amazon's public key, sends it to Amazon Browser and Amazon now use AES to talk securely Security and secure user authorization were not considered by Tim Berners-Lee when he constructed the WWW, they came from the commercialization of it. The two areas of focus are: 1) Server Authentication the identity of the server is vouched for in some way, so you can trust it. 2) Safe Passage data passed via the Internet cannot be read or altered in between client and server. SSL developed into Transport Layer Security (TLS) (RFC 4346) and is considered a part of the Presentation Layer of the OSI model. Privacy encrypted message using Public Key encryption's two keys, one private and one public with each able to encrypt a message but only the other capable of decryption. Integrity the encrypted message must make a safe journey without interceptions or changes. Digital signature. Authentication - certifiable How do you know that the public key belongs to the sender? A Certificate Authority provides assurance a trusted third party. Browsers are pre-loaded with CA information and if missing you will receive a warning. How TLS security works? The TLS protocol exchanges records, which encapsulate the data to be exchanged. Each record can be compressed, padded, appended with a message authentication code (MAC), or encrypted, all depending on the state of the connection. Each record has a content type field that specifies the record, a length field and a TLS version field. When the connection starts, the record encapsulates another protocol the handshake messaging protocol which has content type 22.

5 Simple TLS handshake A simple connection example follows, illustrating a handshake where the server (but not the client) is authenticated by its certificate: 1. Negotiation phase: A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested CipherSuites and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a session ID. The server responds with a ServerHello message, containing the chosen protocol version, a random number, CipherSuite and compression method from the choices offered by the client. To confirm or allow resumed handshakes the server may send a session ID. The chosen protocol version should be the highest that both the client and server support. For example, if the client supports TLS1.1 and the server supports TLS1.2, TLS1.1 should be selected; SSL 3.0 should not be selected. The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).[20] The server sends a ServerHelloDone message, indicating it is done with handshake negotiation. The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate. The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed "pseudorandom function". 2. The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption parameters were present in the server certificate)." The ChangeCipherSpec is itself a record-level protocol with content type of 20. Finally, the client sends an authenticated and encrypted Finished message, containing a hash and MAC over the previous handshake messages. The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down. 3. Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted, if encryption was negotiated)." The server sends its authenticated and encrypted Finished message. The client performs the same decryption and verification. 4. Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be authenticated and optionally encrypted exactly like in their Finished message. Otherwise, the content type will return 25 and the client will not authenticate.

6 How SSL Security Works? $ openssl s_client -connect cs.sfasu.edu:443 Following steps happens on the process: 1. The client sends the server the client s SSL version number, session data, and other information required that the server needs to communicate with the client using SSL. 2. The server sends the client the server s SSL version number other required information that the client needs to communicate with the server over SSL. 3. The server sends its own certificate, and if the client is requesting a server resource that requires client authentication, the server requests the client s certificate and go to nest step. 4. Then the client uses the information sent by the server to authenticate the server. If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client proceeds to next step. 5. Using all data generated in the handshake thus far, the client will create the pre-master secret for the session, encrypts it with the server s public key, and then sends the encrypted pre-master secret to the server. 6. If the server has requested client authentication, the client also signs another piece of data that is unique to this handshake and known by both the client and server. 7. If the server has requested client authentication, the server attempts to authenticate the client. If the client cannot be authenticated, the session ends. If the client can be successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then performs a series of steps to generate the master secret. 8. Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity. 9. The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished. 10. The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished. 11. The SSL handshake is now complete and the session begins. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity. This is the normal operation condition of the secure channel. At any time, due to internal or external stimulus (either automation or user intervention), either side may renegotiate the connection, in which case, the process repeats itself.