Cryptography and Networks Advanced Network Security Peter Reiher August, 2014

Outline Using cryptography in networks IPSec SSL and TLS

Encryption and Network Security Relies on the kinds of encryption algorithms and protocols discussed previously Can be applied at different places in the network stack With different effects and costs

Cryptographic Effects for Networks What useful purposes does crypto serve in networks? What is necessary for it to achieve those purposes? When is that easy and when is it hard? And why?

Secrecy Encrypt the traffic before sending it across the network If crypto strong and correct, attackers can’t deduce the message contents Strong – a crypto algorithm that is not easy to break Correct – proper implementation and use of crypto (keying, etc.)

Authentication Proper crypto can give assurances of who created messages Easiest using public key crypto But sometimes of value with symmetric crypto, as well

Integrity Encrypted data cannot be easily tampered with Without totally corrupting the decrypted version Strong, correct encryption thus allows detection of message alteration Sort of bundled together with the secrecy property

What If I Only Care About Integrity? Encryption is computationally expensive Generally based on how much data is encrypted Can I get integrity via crypto without paying full cost of encrypting packets? Yes, via digital signatures

Digital Signatures Essentially, encrypt a hash of the data Rather than the full data Attach encrypted hash to the unencrypted packet Receiver undoes the crypto on the hash and checks its value If message altered, hash doesn’t match

Deliver the actual message plus the hash A Simple Example An IP message Deliver the actual message plus the hash The IP header The payload Compute a hash of the message

Checking the Digital Signature Compare the hash in the message to the newly computed hash Calculate the hash on the incoming message

Cryptographic Hashes Hashes used for digital signatures require some special properties Hard to find another text that hashes to the same value Hard to invert Changing one bit changes hash value Not all hash functions are suitable Suitable ones are called cryptographic hashes

Some Common Cryptographic Hashes MD5 “Broken” in 2009, not good to use it SHA-1 Not fully broken, but some weaknesses found Soon, SHA-3 Designed to replace SHA-1

Some Details What do we hash? Just the payload? Entire packet? Payload plus some header fields? Where? Where do we create and where do we check? Can’t attackers replace the original hash? With a proper hash of the altered data

What Do We Hash? Integrity protection is applied only to the parts of the packet we hash So if we only hash the payload, no protection for the headers However, some header fields change E.g., the packet TTL If we hash those, the hash won’t match

What Do We Want to Protect? Depends on our integrity goals Are we using this mechanism to ensure correct headers? Or do we only care about the payload? Often, apps won’t examine headers anyway Digital signature typically provide some authentication, too

Where Do We Hash? At the packet’s creation point? And checked at its destination? Or at some intermediate points? Note: IP checksumming will be done at each hop, regardless of digital signatures

Avoiding Hash Replacement If attacker can intercept message, he can replace the hash Even if it’s a crypto hash, he can still calculate hash for another value And replace the right one Everyone knows the crypto hashing functions Solved with keyed hashes

Keyed Hash Functions Crypto hash functions aren’t keyed Anyone knowing the function and the text can produce the hash Keyed hash functions also use a secret key Perhaps merely concatenated to the text before hashing Usually a bit more complicated

Message Authentication Codes MACs Basically, keyed hash functions HMAC is most famous approach HMAC(K, m) = H((K  opad) | H((K  ipad) | m)) opad and ipad are constants Safer against certain attacks than just hashing concatenation of m and K

MACs and Keys Safe digital signatures require MACs Which requires signer and signature checker use proper keys Which requires safe key distribution Generally a hard problem Typically no easier in the signature case

Where Do We Apply Encryption? At some point we encrypt the data It then travels across all or part of the network To another point where we decrypt Protection given by crypto only applies to the instants when data is encrypted

Link Level Encryption Source Destination ciphertext plaintext ciphertext plaintext ciphertext ciphertext plaintext ciphertext ciphertext plaintext ciphertext plaintext ciphertext Let’s say we want to send a message using encryption Different keys (maybe even different ciphers) used at each hop

When Do We Use Link Encryption? When only one link is untrusted Or is much less trusted than the rest When endpoints can’t/won’t do the crypto Most common case is Wifi 802.11 standards include options for link encryption

End-to-End Encryption Source Destination plaintext ciphertext ciphertext ciphertext ciphertext plaintext ciphertext When would link encryption be better? Cryptography only at the end points Only the end points see the plaintext Normal way network cryptography done

When Do We Use End-to-End Encryption? When we don’t trust any element of the intermediate network When we want crypto decisions to be under control of sender/receiver Might be unsure what intermediates will do Used to protect most sensitive traffic in the Internet

Where Are the Endpoints, Anyway? If you do end-to-end encryption, where are the endpoints? The network layer end points? The transport layer end points? The application layer end points? Maybe not even end machine to end machine (e.g., VPNs)? Has serious implications for where you do cryptography And keying and trust issues