4003-420-01/4005-740-01 Data Communications and Networks I Module 7. Network Security -- Lecture Notes Prof. Alan Kaminsky -- Winter Quarter 2008 Rochester Institute of Technology -- Department of Computer Science Overview Selected topics in network security (we cannot hope to cover it all) Defense Against the Dark Arts: Secure communication Defense Against the Dark Arts: Key establishment The Dark Arts: Network attacks If you're going to implement security, you need this book: BUY IT! Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno. Cryptography Engineering: Design Principles and Practical Applications. Wiley Publishing, 2010. Secure communication will focus on the Secure Channel A communication mechanism that addresses these issues: Confidentiality How can we be sure an adversary did not discover the contents of the message? Authentication How can we be sure the right party sent the message? Integrity How can we be sure an adversary did not change the message during transit? Replays How can we be sure an adversary is not sending an old message again (even if the adversary can't change or understand the message)? Building blocks for the secure channel Encryption with block ciphers One-way hash functions Message authentication codes (MACs) Building blocks for key establishment Cryptographic pseudorandom number generators (PRNGs) Key exchange Encryption with public key ciphers Digital signatures Public key infrastructure Encryption With Block Ciphers Ciphertext = Encrypt (Plaintext, Key) C = E(P,K) C = EK(P) Plaintext = Decrypt (Ciphertext, Key) P = D(C,K) P = DK(C) To achieve confidentiality, send C, not P The sender and receiver both know K The sender can compute C from P and K The receiver can compute P from C and K The adversary does not know K -- secret key The adversary sees C, not P Lacking K, the adversary cannot compute P from C alone Kerckhoffs' Principle The security of the cipher must depend only on the secrecy of the key K, not on the secrecy of the encryption and decryption algorithms Security level; key size A cryptographic primitive provides "n bits of security" if an adversary must do 2n operations to attack the primitive successfully A block cipher provides n bits of security if an adversary can find the key with 2n operations To secure data for the next 50 years, Ferguson & Schneier recommend a security level of 128 bits There are block cipher attacks that succeed in 2n/2 operations, where n is the key size Therefore, use a block cipher with a 256-bit key Block size P and C each consist of a certain number of bits, the block size B A block cipher maps a B-bit block P onto a B-bit block C A block cipher can be considered to be a permutation of B-bit values, where the key determines which permutation is used Real-world block ciphers Data Encryption Standard (DES) (1975): B = 64 bits, K = 56 bits Triple-DES: B = 64 bits, K = 112 bits DES and Triple-DES are no longer secure; their block sizes and key sizes are too small Advanced Encryption Standard (AES) (2000): B = 128 bits, K = 128, 192, or 256 bits Defined in FIPS 197, http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf The U.S. National Institute of Standards and Technology sponsored an international public competition to develop AES The five finalist candidate ciphers: Rijndael (the winner), Serpent, Twofish, MARS, RC6 AES or one of the other finalists should be used for new systems The structure of one round of AES The full AES cipher is a series of 10 to 14 such rounds (depending on the key size) Neils Ferguson and Bruce Schneier, Practical Cryptography (Wiley Publishing, 2003), page 55. Block cipher modes Allows you to encrypt a message longer than B bits Electronic codebook mode (ECB) Cipher block chaining mode (CBC) Output feedback mode (OFB) Counter mode (CTR) -- the best according to Ferguson & Schneier Encryption with counter mode Divide the plaintext into B-bit blocks Pi, i = 1, 2, . . . Generate a sequence of B-bit key blocks Ki, i = 1, 2, . . ., also called the key stream Each key block is the encryption of a counter i concatenated with a nonce N Ki = EK (i || N), i = 1, 2, . . . The nonce must be unique If the same combination of encryption key K and nonce N is ever used more than once, an adversary can break the block cipher mode Then the ciphertext block is the plaintext block exclusive-ored with the key block Ci = Pi XOR Ki, i = 1, 2, . . . Decryption with counter mode Exactly the same process as encryption, except feed in the ciphertext, and out comes the plaintext (because exclusive-or is commutative) Note that with counter mode, you don't need the decryption function DK -- you use the encryption function EK on both ends For counter mode decryption to work, you have to transmit the nonce along with the ciphertext Transmitting the nonce is safe because the adversary still doesn't know the key K, so the adversary can't generate the key stream One-Way Hash Functions A one-way hash function converts an arbitrary-sized input M to a fixed-size output H consisting of B bits Properties of a cryptographic hash function One-way: Given the output H, it is hard to find the input M Second preimage resistant: Given M, it is hard to find M' such that H(M') = H(M) Collision resistant: It is hard to find M1 and M2 such that H(M1) = H(M2) Security level of a one-way hash function In general, a collision can be found for a B-bit hash function in 2B/2 operations Therefore, a B-bit hash function provides B/2 bits of security Use 256-bit hash functions Real-world hash functions MD5: B = 128 bits (too small) SHA-1: B = 160 bits (too small) SHA-512: B = 512 bits (too big) SHA-384: B = 384 bits (too big) SHA-256: B = 256 bits (just right) Defined in FIPS 180-3, http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf Due to a weakness in all of the above hash functions, you should always hash twice Don't compute H(M) Instead, compute H(H(M)) -- double hashing One-way hash functions are used as part of . . . Message authentication codes (MACs) Digital signatures Key exchange Further information: Cryptographic One-Way Hash Functions Message Digests for the Twenty-First Century: An Overview of the NIST SHA-3 Cryptographic Hash Algorithm Competition Message Authentication Codes (MACs) Hash Message Authentication Code (HMAC) Defined in RFC 2104 Built from a B-bit one-way hash function H and a B-bit secret authentication key K HMAC (M) = H ((K XOR opad) || H ((K XOR ipad) || M)) ipad is the byte 0x36 repeated to make a B-bit string opad is the byte 0x5C repeated to make a B-bit string Note that HMAC uses double hashing To authenticate a message, compute HMAC(M), and send that along with the message Only someone possessing the secret key K can generate the authentication for a message To verify that a message is authentic, compute HMAC(M), and compare that to the value that was sent along with the message If the two values don't match: Either the message is not authentic (authentication), Or the message was altered during transit (integrity) Only someone possessing the secret key K can verify the authentication for a message Secure Channel Assumptions We are sending discrete messages, not a continuous stream of bytes There is a secret session key known only to the parties at either end of the channel, Alice and Bob Each time we set up a new secure channel, we must use a different session key Later we will study key establishment and see where the session key comes from Building blocks For replay defense: Each message has a unique message number: 1, 2, 3, . . . If one side receives a message with an old message number, it is a replay, we are under attack, ignore the message, shut down the channel! For confidentiality: Encryption using AES (256-bit key) in counter mode Use the message number for the nonce For integrity and authentication: HMAC using the SHA-256 hash function We must guarantee that no two messages ever use the same encryption key-plus-nonce, otherwise an adversary can defeat the security Two different messages either will be sent over different secure channels, so will have different encryption keys . . . Or will be sent over the same secure channel, so will have different nonces (message numbers) We must guarantee that different secure channels use different session keys We must guarantee that message numbers are never reused within the same secure channel The message numbers cannot be allowed to wrap around Getting the encryption and authentication keys from the session key Alice --> Bob encryption key K1 = Double-SHA-256 (session key || MagicNumber1) Alice --> Bob authentication key K2 = Double-SHA-256 (session key || MagicNumber1) Bob --> Alice encryption key K3 = Double-SHA-256 (session key || MagicNumber3) Bob --> Alice authentication key K4 = Double-SHA-256 (session key || MagicNumber4) Alice's initialization algorithm Input: Session key, K // Derive encryption and authentication keys K1 = SHA-256 (SHA-256 (K || MagicNumber1)) K2 = SHA-256 (SHA-256 (K || MagicNumber2)) K3 = SHA-256 (SHA-256 (K || MagicNumber3)) K4 = SHA-256 (SHA-256 (K || MagicNumber4)) // Initialize message counters SendMessageCount = 0 ReceiveMessageCount = 0 Alice's message transmission algorithm Input: Message to be sent, M Additional data to be authenticated, X // Update message number, make sure it doesn't wrap around assert SendMessageCount < 2^32 - 1 SendMessageCount = SendMessageCount + 1 N = SendMessageCount // nonce // Compute the authentication of the message and the additional data A = HMAC-SHA-256 (K2, N || Length(X) || X || M) // Send the nonce (4 bytes) and the encryption of the message (? bytes) // and the authentication (32 bytes) Send N || Encrypt-AES-256 (K1, N, M || A) Bob's message reception algorithm Input: Bytes received from Alice, B Additional data to be authenticated, X Output: Received message M // Make sure at least 36 bytes were received (nonce and authenticator) assert Length(B) >= 36 // Split received bytes into nonce and ciphertext N = First 4 bytes of B C = All but the first 4 bytes of B // Recover the plaintext P = Decrypt-AES-256 (K1, N, C) // Split plaintext into message and authenticator M = All but the last 32 bytes of P A = Last 32 bytes of P // Recompute the authenticator A' = HMAC-SHA-256 (K2, N || Length(X) || X || M) // Verify the authenticator If A != A': Erase and shut down channel Report error (authentication failure) // Verify the message number (nonce) If N <= ReceiveMessageCount: Erase and shut down channel Report error (message replayed) // Update the received message count ReceiveMessageCount = N // Return the message Return M Bob's message transmission algorithm The same as Alice's message transmission algorithm, except . . . Use encryption key K3 instead of K1, and . . . Use authentication key K4 instead of K2 Alice's message transmission algorithm The same as Bob's message reception algorithm, except . . . Use encryption key K3 instead of K1, and . . . Use authentication key K4 instead of K2 Cryptographic Pseudorandom Number Generators (PRNGs) The key negotiation protocol we are about to study needs a source of random numbers -- a pseudorandom number generator (PRNG) PRNG operations Seed: Set the internal state of the PRNG based on a "seed" value Generate: Generate random data based on the internal state, and update the internal state Attacks on a PRNG By observing some output values, deduce past output values Compromises data that relied on those past output values for security By observing some output values, deduce future output values Compromises data that will rely on those future output values for security Obtain the internal state of the PRNG Allows prediction of all future output values until the PRNG is reseeded A cryptographically strong PRNG is a PRNG that can defend against these attacks The PRNGs used in, say, scientific programming, like java.util.Random, are not cryptographically strong The Fortuna PRNG by Ferguson and Schneier Based on the AES block cipher (128-bit block, 256-bit key) Internal state: 256-bit key K, 128-bit counter C To initialize the Fortuna PRNG: K = 0 C = 0 To seed the Fortuna PRNG with a seed value S (a byte array): K = Double-SHA-256 (K || S) C = C + 1 To generate n bytes of random data R: Make sure PRNG has been seeded (C != 0) R = empty For i = 1 to ceiling(n/16) do:     R = R || AES-encrypt (K, C)     C = C + 1 Randomize the key:     T1 = AES-encrypt (K, C)     C = C + 1     T2 = AES-encrypt (K, C)     C = C + 1     K = T1 || T2 Return the first n bytes of R To defend against compromise of the Fortuna PRNG's internal state, the PRNG must periodically be reseeded with "real" random data It's hard to find "real" random data in a computer -- that is, data that can't be predicted by an adversary Things like the precise timing of mouse and keystroke events, or the screen coordinates of mouse movements, might be usable If such random data sources are available, the Fortuna PRNG specifies how to accumulate the random data and, when enough has been accumulated, reseed the PRNG with the random data The Fortuna PRNG must be seeded with real random data the very first time the PRNG is created We don't want to have to wait until enough random data has been collected Solution: Read some random data from a seed file and use that to seed the PRNG After reading the seed file, generate some new random data and write it back into the seed file A Few Concepts From Number Theory Prime number: p Multiplication modulo p: c = a*b (mod p) c = remainder when a*b is divided by p The multiplicative group modulo p: Zp* Zp* = {1, 2, . . . , p−1} This is a group because: There is a set of group elements; {1, 2, . . . , p−1} There is a group operation; multiplication (mod p) The group is closed under the group operation; the product (mod p) of any two elements in the set is also in the set There is an identity element, 1, such that for any element x, x*1 (mod p) = 1*x (mod p) = x For every element x there is an inverse y, such that x*y (mod p) = 1 If x*y (mod p) = 1, we will say y is the multiplicative inverse of x (mod p), and write it y = x−1 (mod p) Exponentiation modulo p: z = xy (mod p) Defined in terms of multiplication modulo p xy (mod p) = x * x * . . . * x (mod p) -- x multiplied by itself y times A generator of the multiplicative group modulo p: A number g such that the set {g0 (mod p), g1 (mod p), g2 (mod p), . . . , gp-2 (mod p)} is the same set as Zp* After that, it starts repeating: gp−1 (mod p) = g0 (mod p) = 1, gp (mod p) = g1 (mod p) = g, etc. Because gp−1 (mod p) = 1, we say that the order of g is p−1 Example: p = 23 is prime Z23* = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22} g = 5 is a generator for Z23* The powers of 5 (mod 23), in order, are {1, 5, 2, 10, 4, 20, 8, 17, 16, 11, 9, 22, 18, 21, 13, 19, 3, 15, 6, 7, 12, 14} 522 (mod 23) = 1 An order-q subgroup of the multiplicative group modulo p: A q-element subset of {1, 2, . . . , p-1} such that the subset is itself a group with the group operation being multiplication modulo p A generator of an order-q subgroup of the multiplicative group modulo p: A number g such that the set {g0 (mod p), g1 (mod p), g2 (mod p), . . . , gq−1 (mod p)} is an order-q subgroup of Zp* After that, it starts repeating: gq (mod p) = g0 (mod p) = 1, gq+1 (mod p) = g1 (mod p) = g, etc. Because gq (mod p) = 1, we say that the order of g is q Example: g = 2 is a generator for an order-11 subgroup of Z23* The powers of 2 (mod 23), in order, are {1, 2, 4, 8, 16, 9, 18, 13, 3, 6, 12} 211 (mod 23) = 1 Key Exchange The Problem Alice and Bob need a unique, secret session key for a secure channel Each new secure channel needs a new session key, so Alice and Bob can't use a fixed value chosen ahead of time Alice and Bob are the only ones in the whole world allowed to know the session key -- Eve the Eavesdropper can't know the session key But without a session key, Alice and Bob can't communicate securely, and Eve can eavesdrop Alice and Bob need a secure channel so they can establish a secret session key so they can establish a secure channel . . . Diffie-Hellman Key Exchange The very first public key algorithm published, in 1976 Pick a random large prime number, p Bare minimum: 2048 bits If at all possible: 4096 bits (say Ferguson & Schneier) Pick a random element, g, of the multiplicative group modulo p, Zp* g must be an element of order q, where q is a 256-bit prime g is a generator for an order-q subgroup of Zp* This guarantees the subgroup generated by g is too large for exhaustive search (O(2256) elements) Alice, Bob, and Eve all know p, q, and g Alice picks a secret random number a in the range 1 < a < q−1 Alice computes x = ga (mod p) and sends x to Bob Bob picks a secret random number b in the range 1 < b < q−1 Bob computes y = gb (mod p) and sends y to Alice Alice computes k = ya (mod p) = gba (mod p) Bob computes k = xb (mod p) = gab (mod p) Eve cannot compute gab (mod p) knowing only ga (mod p) and gb (mod p) The "Diffie-Hellman Problem" A variant of the "Discrete Logarithm Problem" No efficient discrete logarithm algorithm is known So Alice and Bob can exchange x and y over a public (non-confidential) channel Alice and Bob derive the secure channel session key from k k is about the same size as p, i.e. 2048 bits For, say, the AES block cipher, we need a 256-bit key Solution: Hash k using, say, double SHA-256 Session key = H(H(k)) Problems with Diffie-Hellman Key Exchange Small subgroup attack If Eve can pick p and g, Eve can pick g to be a generator for only a small subgroup of Zp* Then Eve can observe Alice's and Bob's messages and find k using exhaustive search Solution: Impose restrictions on p and g so that g is a generator for a large (order-q) subgroup of Zp* Man-in-the-middle attack If Eve sits in the middle between Alice and Bob, then Alice will actually set up a session key with Eve, and Bob will actually set up another session key with Eve Eve can then decrypt all incoming messages, read them, re-encrypt them, and send them on Solution: Add authentication (MAC or digital signature) to the Diffie-Hellman key exchange Key Negotiation Protocol Alice picks s = minimum size (bits) of the prime p Alice picks a random 256-bit nonce N Alice sends s, N to Bob Bob does some checks: s is not too small (e.g. s >= 2048) Bob picks a random s-bit prime p Bob picks a random generator g for an order-q subgroup of Zp*, q a 256-bit prime Making Bob pick p, q, and g each time prevents Eve from choosing them Bob picks a random exponent b in the range 1 < b < q-1 Bob sends p, q, g, y = gb (mod p), AuthenticationBob (s, N, p, q, g, y) to Alice The authentication could use a MAC with a secret authentication key known only to Alice and Bob The authentication could use Bob's digital signature Man-in-the-middle attack is prevented because Eve cannot compute a correct authentication for Bob Replay attack is prevented because the nonce N is different each time Alice does some checks: p is at least s bits long, q is 256 bits long p and q are prime g is an element of order q in Zp* y is a member of the subgroup generated by g Bob's authentication is correct Alice picks a random exponent a in the range 1 < a < q-1 Alice sends x = ga (mod p), AuthenticationAlice (s, N, p, q, g, y, x) to Bob The authentication could use a MAC with a secret authentication key known only to Alice and Bob The authentication could use Alice's digital signature Man-in-the-middle attack is prevented because Eve cannot compute a correct authentication for Alice Replay attack is prevented because the nonce N is different each time Bob does some checks: x is a member of the subgroup generated by g Alice's authentication is correct Alice computes session key = Double-SHA-256 (ya (mod p)) Bob computes session key = Double-SHA-256 (xb (mod p)) The basic Diffie-Hellman key exchange prevents Eve from computing k The one-way hash destroys all knowledge of the mathematical structure used to derive x and y The one-way hash also reduces the key to the correct size (256 bits) Finally, Alice and Bob set up a secure channel using the negotiated secret session key Diffie-Hellman Key Exchange Example Encryption With Public Key Ciphers Ciphertext = Encrypt (Plaintext, Encryption-Key) C = E(P,KE) C = EKE(P) Plaintext = Decrypt (Ciphertext, Decryption-Key) P = D(C,KD) P = DKD(C) Given KE, it is not possible to deduce KD Therefore, make KE public: KE is the public encryption key or just the public key However, keep KD hidden: KD is the private decryption key or just the private key To send a confidential message from Alice to Bob: Alice, Eve, and everybody else know Bob's public key KE Only Bob knows Bob's private key KD Alice sends EKE (plaintext) to Bob Bob computes DKD (ciphertext) to recover the plaintext Lacking KD, Eve cannot recover the plaintext from the ciphertext The RSA public key cipher Bob chooses two large primes p, q of equal size Bob computes n = p q As in Diffie-Hellman key exchange, n should be a minimum of 2048 bits, 4096 bits if at all possible So p and q should each be 1024 bits, 2048 bits if at all possible Bob chooses an encryption exponent e Ferguson and Schneier recommend e = 5 Bob computes the decryption exponent d = e−1 (mod φ(n)), where φ(n) = (p−1)(q−1) In other words, ed = 1 (mod φ(n)) Bob's public key is (e,n) Bob's private key is d From a plaintext P, 1 < P < N, Alice computes the ciphertext C = Pe (mod n) From a ciphertext C, Bob computes the plaintext P = Cd (mod n) Cd (mod n) = Ped (mod n) = Ped (mod φ(n)) (mod n) = P1 (mod n) = P (mod n) = P If Eve could factor n into p and q, Eve could compute d from e and n just like Bob did, and break RSA -- but no one knows an efficient way to factor a 2048-bit number! Digital Signatures Public key cipher: Anyone can encrypt, only one can decrypt Digital signature: Only one can sign, anyone can verify the signature A digital signature is like a backwards public key cipher Signature = Sign (Message, Signing-Key KS) Message = Verify (Signature, Verification-Key KV) Given KV, it is not possible to deduce KS Therefore, make KV public: KV is the public verification key or just the verification key However, keep KS hidden: KS is the private signing key or just the signing key RSA digital signature Same as the RSA public key cipher, except: Bob's verification key is (e,n) Ferguson and Schneier recommend e = 3 Bob's signing key is d To sign a message, sign the one-way hash of the message -- takes less time, and just as secure To sign a message M, Bob computes the signature S = (Double-SHA-256 (M))d (mod n) To verify Bob's signature S on a message M, Alice checks whether Se (mod n) == Double-SHA-256 (M) Digital Signature Standard (DSS) (2009) Defined in FIPS PUB 186-3, http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf Security rests in the difficulty of finding discrete logarithms, rather than factoring We can use digital signatures for authentication in the key negotiation protocol How does Alice know that (e,n) is really Bob's verification key, and not the verification key of some imposter pretending to be Bob? . . . Answer: PKI RSA Example Choosing the parameters For RSA digital signatures, Ferguson & Schneier recommend choosing the public verification exponent e = 3 Then to be able to compute d, 3 must not divide (p−1) and 3 must not divide (q−1) For example, choose e = 3, p = 17, q = 23; then n = pq = 391, φ(n) = (p−1)(q−1) = 352 Compute d such that ed = 1 (mod φ(n)), that is, 3d = 1 (mod 352) You can use the Extended Euclidean Algorithm to compute d For a small modulus, you can find d by trial and error If 3d = 1 (mod 352), then 3d = 352k + 1 for some integer k Try successive values of k until you find one that yields an integer solution for d k = 1: 3d = 352*1 + 1 = 353, no solution k = 2: 3d = 352*2 + 1 = 705, solution is d = 235 Private signing key (d, n) = (235, 391) Public verifying key (e, n) = (3, 391) Example: Sign the number h = 42. We must compute s = 42235 (mod 391) Here's an easy way to do a modular exponentiation Express d in base 2: 235 base 10 = 11101011 base 2 That is, 235 = 128 + 64 + 32 + 8 + 2 + 1 Therefore: s = 42(128 + 64 + 32 + 8 + 2 + 1) (mod 391) s = 42128 * 4264 * 4232 * 428 * 422 * 421 (mod 391) Compute those powers of 42 by repeatedly squaring, reducing (mod 391) after each multiplication: 421 = 42 422 = 42 * 42 (mod 391) = 200 424 = 200 * 200 (mod 391) = 118 428 = 118 * 118 (mod 391) = 239 4216 = 239 * 239 (mod 391) = 35 4232 = 35 * 35 (mod 391) = 52 4264 = 52 * 52 (mod 391) = 358 42128 = 358 * 358 (mod 391) = 307 Therefore: s = 307 * 358 * 52 * 239 * 200 * 42 (mod 391) Multiply those numbers together, reducing (mod 391) after each multiplication: s = 35 * 52 * 239 * 200 * 42 (mod 391) s = 256 * 239 * 200 * 42 (mod 391) s = 188 * 200 * 42 (mod 391) s = 64 * 42 (mod 391) s = 342 Example: Verify the signature s = 342. It should yield h' = 42. We must compute: h' = 3423 (mod 391) h' = 342 * 342 * 342 (mod 391) h' = 55 * 342 (mod 391) h' = 42 The signature verifies! The reason Ferguson & Schneier recommend using e = 3 is because that way, verifying the signature requires only two modular multiplications, which is fast Public Key Infrastructure Certificate Authority (CA) Trusted by everyone Everyone knows the CA's public digital signature verification key without having to look it up Alice's certificate Alice travels physically to the CA's office and proves her identity The CA puts together a certificate containing Alice's public information Alice's identity Validity dates for the certificate Alice's public digital signature verification key The CA digitally signs Alice's certificate Alice can now publish her CA-signed certificate Alice sends a signed message to Bob E.g., one of the Diffie-Hellman key exchange messages Bob gets Alice's certificate, by looking it up, or by Alice including it in the message Bob verifies the CA's signature on Alice's certificate; now Bob knows Alice's certificate is genuine Bob uses Alice's digital signature verification key from Alice's certificate to verify Alice's signature on the message; now Bob knows the message really came from Alice Key Establishment Using Public Key Techniques Alice and Bob want to set up a secret session key K for use with a block cipher, say AES Pretty Good Privacy (PGP): Key establishment using RSA encryption Used to send one authenticated, encrypted email message from Alice to Bob Alice signs the hash of her message using her RSA private signing key Alice chooses a random block cipher key K Alice gets Bob's public key certificate, verifies the certificate, and extracts Bob's RSA public encryption key Alice encrypts K using Bob's RSA public encryption key, and sends that ciphertext to Bob Alice encrypts (her message | her signature) using AES with key K, and sends that ciphertext to Bob Bob gets Alice's public key certificate, verifies the certificate, and extracts Alice's RSA public verifying key Bob decrypts the first ciphertext using his own RSA private decryption key to obtain K Bob decrypts the second ciphertext using AES with key K to obtain Alice's message and signature Bob verifies Alice's signature using Alice's RSA public verifying key The computationally intensive, slow public key techniques (encryption, signature) are used only on short inputs (block cipher key K, hash of message) The fast block cipher is used to encrypt large inputs (message itself) Transport Layer Security (TLS) key establishment (many details omitted) TLS is the Internet standard version of Netscape's proprietary Secure Socket Layer (SSL) RFC 2246 Used for secure web browsing with the HTTPS protocol Client and server first negotiate which algorithms they will use for public key encryption, digital signatures, and block cipher encryption Client sends (unencrypted) a 32-byte number R1 to server 4-byte timestamp (seconds since midnight 01-Jan-1970), to detect replays 28-byte random number Server sends (unencrypted) a 32-byte number R2 to client 4-byte timestamp (seconds since midnight 01-Jan-1970), to detect replays 28-byte random number Server sends its certificate to client; client verifies certificate To authenticate the server to the client (Optional) Client sends its certificate to server; server verifies certificate For HTTPS, the client almost never has a certificate The client authenticates to the server outside of TLS, e.g. by logging into their account on the web site Client generates a 48-byte random pre-master secret PMS Client encrypts PMS using server's public encryption key and sends the ciphertext to server Server decrypts PMS using server's private decryption key Both client and server compute 48-byte master secret MS MS = PRF (PMS, "master secret", R1 | R2) PRF is a pseudorandom function that uses hash functions to mix its arguments and generate a sequence of random bytes Client computes 12-byte value = PRF (MS, "client finished", hash(all previous messages)) and sends that to server; server checks whether it is correct To detect intruders and replays This proves to the server that the thing on the other end: Knows the master secret, Sent R1, and Received the server's R2 Server computes 12-byte value = PRF (MS, "server finished", hash(all previous messages)) and sends that to client; client checks whether it is correct To detect intruders and replays This proves to the client that the thing on the other end: Knows the master secret, Sent R2, and Received the client's R1 Both client and server use the PRF to compute authentication keys, encryption keys, and keystream generator initialization vectors in both directions from the master secret Thereafter, each message is authenticated using HMAC and encrypted using a keystream generated from a block cipher Network Attacks I: Email Attacks Phishing attacks What they are How to detect them Automatic detection of phishing attacks is an authentication problem A system to send secure email messages, with authentication only Alice includes a digital signature on her message and sends it to Bob Is this secure? A system to send secure email messages, with confidentiality and authentication Alice includes a digital signature on her message Alice picks a random encryption key K and encrypts her message-plus-signature using a block cipher with K Alice encrypts K using Bob's public encryption key Alice sends the public-key-encrypted K and the K-encrypted message-plus-signature to Bob Pretty Good Privacy (PGP) works this way Is this secure? A system to send truly secure email messages Can it be done? Even if it can be done cryptographically . . . Bruce Schneier: "Why digital signatures are not signatures" (http://www.schneier.com/crypto-gram-0011.html#1) Network Attacks II: Denial of Service Attacks General pattern: Overload a system with so much junk that legitimate users can't get through SYN flooding Mail bombing DOS attacks on web servers Distributed DOS attacks Network Attacks III: Wireless Network Attacks Imagine what you can do if you go into Starbucks, or downtown Canandaigua NY, or any wireless "hot spot" with your wireless Ethernet equipped laptop . . . Packet sniffing You can see your neighbors' incoming and outgoing emails You can see the web pages your neighbors are viewing If those web pages are not designed properly, you can see your neighbors' logins and passwords Access hijacking Some places, you have to pay for the privilege of using the wireless hot spot I don't know how they enforce this, but it could be done based on the source MAC address in your Ethernet packets If your wireless Ethernet card is the kind with a software programmable MAC address, you can reprogram it to match your neighbor's, and the hot spot will think your packets are coming from your neighbor You can now use as much online time as you want, and your neighbor will pay You can now frame your neighbor -- make it look like your neighbor sent emails or visited web sites that they never did Wireless access point spoofing You can make your laptop act as a wireless access point that looks just like Starbucks' wireless access point Your neighbor will see two wireless access points and will not know which is the legitimate one If your neighbor hooks up to you instead of the legitimate one, you are now the proverbial man-in-the-middle Covert surveillance Imagine if private investigators were doing all this, say for your spouse to use against you in a divorce case Imagine if the government -- police, FBI, CIA -- were doing all this Data Communications and Networks I • 4003-420-01/4005-740-01 • Fall Quarter 2012 Course Page Alan Kaminsky • Department of Computer Science • Rochester Institute of Technology • 4486 + 2220 = 6706 Home Page Copyright © 2012 Alan Kaminsky. All rights reserved. Last updated 22-Oct-2012. Please send comments to ark­@­cs.rit.edu.