Lecture 020 - Crypto

Internet Security

Concern:

• Route Hijacks

• IP Spoofing

• Spam

• End-host impersonation

Security Means

• Authentication (Who am I talking to?)

  • Phishing
  • Password Cracking

• Confidentiality (Is my data hidden?)

  • Traffic Eavesdropping: look at packet (DNS lookup, payload size)
  • Spyware

• Integrity (Has my data been modified?)

  • Tampering: Traffic modification
  • DNS Poisoning

• Availability (Can you reach me?)

  • Denial-of-Service: DoS
  • Trojan Horse
  • Destroy hardware, modify software
  • Corrupt packets

Cryptographic Tools

Tools:

• XOR: just XOR forward and backward

  • only one time pad (OTP)
  • key cannot be reused
  • key need to be the size of the longest possible message
  • Shannon's theorem: only way to achieve perfect security

• Stream Ciphers: RC4

• Block Ciphers: AES

• Collision-resistant hashing: SHA-256

  • Consistent: same into always yield same output
  • Preimage Resistant: can't hash backward from output to input
  • Collision Resistent: hard to collide with different input

• Message Authentication Code (MAC): ensure integrity using a (hashed) checksum

• Challenge-response Authentication in Symmetric Key: to verify authenticity of client, server could send one time nonce to client and require client to hash.

• Secret-key cryptography (symmetric key): AES

• Public-key cryptography (asymmetric key): RSA, ElGamal

• Key Distribution Center: server shares different secret key with each registered user, providing a channel for sharing symmetric key. (only used within organization since centralized KDC can be malicious)

MAC: same word, different meaning - Media Access Control: MAC Address - Message Authentication Code: for integrity

Also note that Message Authentication Code cannot guarantee authenticity. Since one adversarial could replay the message again. MAC only guarantees integrity.

Different Order of MAC: in summary, MAC-then-Encrypt is attackable, but Encrypt-then-MAC is not.

• MAC-then-Encrypt: Compute the MAC on the cleartext, append it to the data, and then encrypt the whole? (That's what TLS does)

• Encrypt-and-MAC: Compute the MAC on the cleartext, encrypt the cleartext, and then append the MAC at the end of the ciphertext? (That's what SSH does)

• Encrypt-then-MAC: Encrypt the cleartext, then compute the MAC on the ciphertext, and append it to the ciphertext? (In that case, we do not forget to include the initialization vector (IV) and the encryption method identifier into the MACed data.)

TLS uses MAC-then-encrypt, even though encrypt-then-MAC is generally considered better, for legacy reasons

Certification Authority (CA)

So, public key exchange is secure. But another issue is that: if you ask kokecacao.me for a public key, someone could intersect the message and send you a fake public key and read your secret message. Here is where Certification Authority (CA) comes in.

Diffie-Hellman Key Exchange is vulnerable to man-in-the-middle attack and CA will prevent it.

Certification authority (CA): binds public key to particular entity. We trust CA blindly (CA can be malicious but is often governed by country law)

1. CA make sure server's identity by posting response challenges to a domain name, to link IP to domain name
2. CA establish CA signed certificate to domain name
3. User request certificate from domain name, then verify CA's certificate using CA's public key
4. User can trust the IP address who responded the certificate by trusting CA

CA servers have often been compromied by hackers.

I will not explain what CA does in detail. You should look at one of my posts on how to set up SSL certificate for more hands-on experience.

Certificate Transparency: to make all certificate and their CA's public key discoverable, an idea is to use a distributed certificate storage (store both real certificate and malicious ones since we can't distinguish, but we still can check inconsistency)

It is essentially a blockchain storing CA certificates and changes instead of leger.

Merkle Tree

Merkle Tree is a tool to check whether a message is included in a checksum in $O(\log n)$ time instead of $O(n)$ time for $n$ messages in $1$ checksum.

Merkle Tree Construction: given $n$ messages, we want to obtain one summary hash for all $n$ messages.

• naive: hash them in sequential order, producing $O(n)$ intermediate hashes in a sequence structure

• efficient: hash them in pair-wise reduction, producing $O(n)$ intermediate hashes in a tree structure

Merkle Tree Verification:

• Problem: given a message $M$ and a root hash $H$, you want to know whether $H$ hashed $M$ using least intermediate hashes while creating $H$.

• Naive Solution: we get all other original $n-1$ messages and hash them again to see if we obtain $H$

• Efficient Solution: only need $O(\log n)$ intermediate hashes (see image)

Merkle proof consistency: it is rare such that two different sequences of messages will hash to the same root in Merkle Tree.

Merkle Tree is used to concatenate multiple ($2^n$) transactions into one block in blockchains.

Transport Layer Security (TLS)

TLS implements HTTPS by adding a layer on top of TCP.

• ensures: confidentiality, integrity, authentication

• use: symmetric and asymmetric key

Algorithm:

1. Client: ClientHello: ClientRandom256, SupportedProtocols
2. Server: ServerHello: ServerRandom256, ProtocolDecided
3. Server: CACert
4. Client: decrypt CACert with CAPublic to obtain ServerPublic that is verified by CA
5. Server: generate $g^a \mod p$, add signature, sign both with ServerPrivate to produce ServerDHE
6. Client: decrypt ServerDHE with true ServerPublic: if signature match, then Server's identity verified
7. Client: generate, send $g^b \mod p$
8. PremasterSecret (PS) is $g^{ab} \mod p$
9. Both server generate 4 symmetric keys using PremasterSecret, ClientRandom256, ServerRandom256
10. Exchange MAC to ensure all previous messages are not tampered
11. From now on, all messages are encrypted and MACed

4 Symmetric Keys:

CB: For encrypting client-to-server messages
CS: For encrypting server-to-client messages
IB: For MACing client-to-server messages
IS: For MACing server-to-client messages

Note that ClientRandom256, ServerRandom256 are chosen for every handshake to prevent replay attack. Shared secret is deleted after TLS session so adversary cannot regenerate shared secret even with server's private key.

Access Control

Access Control: who (subject) can do what (rights) to what/whom (objecat/subject)

Access Control Matrix: a $\text{number of files} \times \text{number of users}$ matrix storing permission rwx.

Access Control Matrix is a dense matrix storying sparse data, wasting storage space. Access Control Lists (ACL), like adjacency lists version of the matrix, is not any better.

Why don't we use layered permission system?

Anonymity

Anonymity is not confidentiality: Confidentiality hides the content of the communication. Anonymity hides identities of the parties who are communicating

Idea: multiple proxies, relays to enable anonymous communication.

Onion Router: servers who provide replay service

Each router learns only the identity of the next router. This is because you will never know whether the previous router is the original message sender or not.

Note that two connections are not encrypted:

• asking directory server for a list of Tor nodes

• last relay to destiny server

Problems:

• Performance: long latency, performance decreases, linearly with the number of proxies added

• Security: timing attack possible if first and last proxy servers are compromised by the same adversary