overview foundations of cryptography
TRANSCRIPT
CS342 Computer Security Department of Computer Science Wellesley College
Foundations of Cryptography
Tuesday April 19 and Thursday April 21, 2016
Reading: S&M Secs. 7.1 – 7.4, 7.6; Chs. 8-10 Schneier Applied Cryptography, Chs. 1, 2-4, 7-12, 18.14
Ferguson, Schneier, & Kohno, Cryptography Engineering, Chs. 2,5,6 Kaufman, Perlman, & Speciner, Ch. 9 (esp. 9.7.2-9.7.); 11; 13-14, 15
Anderson, Security Engineering, Ch. 3
Cryptographic ideas are central to security technology. Most practical security systems involve many of the following technologies:
o Symmetric-key cryptography, in which parties use a shared secret key to encrypt/decrypt messages to communicate confidentially
o Hashing for message authentication and digital signatures.
o Public-key cryptography, in which asymmetric public/private key pairs address the key exchange problem and support encryption and digital signatures
o Public key infrastructure (PKI), including certificate authorities, that help public key crypto work in practice.
These technologies are embedded in protocols of messages between two parties that implement secure communication.
22-2
Overview
22-3
Cast of Characters
Alice wants to send a message M to Bob.
Eve may be eavesdropping on the communication (passive attacker)
Mallory may be able to change the message (active attacker)
M = �one if by land two if by sea�
Alice Bob
Eve
Mallory
22-4
Eve�s Lament
http://xkcd.com/177/
22-5
Goals of Cryptography Confidentiality: No one can read M except Alice and Bob (e.g., whispering, locked box); Authentication: Bob knows M comes from Alice, not someone masquerading as Alice (e.g., wax seal, watermark paper, signature); Integrity: Bob can verify that M has not be altered after it was sent by Alice (e.g., tamperproof packaging); Nonrepudiation: Alice should not be able to falsely deny sending M.
message authentication, digital signatures
encryption/ decryption
22-6
Terminology Cryptography = scrambling messages: converting messages into
"gibberish" that can be converted back to message.
Cryptanalysis = breaking secret codes.
Cryptology = cryptography + cryptanalysis (in practice cryptography is often used for cryptology).
Steganography = hiding messages, ``security through obscurity''. E.g., under wax, under hair, invisible ink, in lower order bits of images, in whitespace (http://compsoc.dur.ac.uk/whitespace/tutorial.html)
Note: Can combine steganography and cryptography.
22-7
The Basic Scenario
Encrypt Decrypt M
plaintext (text,image, voice, …)
ciphertext (Eve can see
Mallory can see/alter)
plaintext
Alice�s key
KA
Bob�s key
KB
M = D(KB, C) C = E(KA,M)
E(key, msg) is the encryption (enciphering) function D(key, msg) is the decryption (deciphering) function Need D(KB, E(KA , M)) = M for all M.
22-8
Kerkhoffs�s Principle o Separate cryptography into public algorithms
and private keys (Dutch linguist Auguste Kerckhoffs, 1883)
o Private algorithm is an example of security through obscurity, which is usually not secure, at least once algorithm is known (e.g., Navajo code talkers in WW2).
o Proprietary algorithms often contain holes; public algorithms are analyzed by lots of smart people to find potential problems.
o People (rightly) suspicious of private algorithms, so hard to adopt on widespread basis.
22-9
Symmetric vs. Public-Key Cryptography Symmetric (a.k.a. shared-key, secret-key, private-key):
o Alice and Bob share the same key (or they have different keys that can be easily calculated from one another).
o Communicating keys is a big problem. (How to do e-commerce?)
o We begin with this Asymmetric (public-key):
o Bob can publish a public key that anyone (including Alice) can use to encrypt a message, but only Bob has a private key that can decrypt the message. The private key cannot easily be determined from the public key.
o Alice can contact Bob without exchanging keys with him! But public-key management is still a problem.
o Later in this lecture 22-10
Symmetric Cryptography Algorithms For simplicity, often assume messages & keys use 26-letter alphabet. (in reality, typically use 8-bit = 256-character bytes or raw bits).
In each of the following examples: What is the key? How many keys are there? (Modern crypto relies on computational intractability.)
o Shift cipher
o Vigenere cipher
o One-Time pad
o Substitution cipher
o Transposition cipher
o Rotor Machines
o Block Cipher
o Stream Cipher
22-11
Shift Cipher shift message
0 ibm
1 jcn
2 kdo
… …
25 hal
o Idea: �shift� the letter in each plaintext position by the same amount
o Caesar cipher: shift by 3
o Rot13: shift by 13 (doing twice is id)
o How easy is it to break an encrypted message?
Cryptographic Tools 22-12
Shift Cipher: JavaScript Malware, 2010 In a spam .html message sent to Takis:
Shift cipher of 1 for
<meta http-equiv="refresh" content="0;url=http://blacklefilm.com/x.html" />
which redirects to what appears to be a drive-by download site.
22-13
Vigenere Cipher Idea: �shift� the letter in each plaintext position as determined by repeating key
Plaintext: oneifbylandtwoifbysea Key: cabcabcabcabcabcabcab Ciphertext: qnfkfcalbpduyojhbzueb
o The same plaintext at different positions may be encrypted to different ciphertext (e.g. �ifby�).
o How secure is Vigenere? Check out http://cs.wellesley.edu/~fturbak/codman-archive/codman-nov-02-2007/
Most common digrams (in order): th, he, in, en, nt, re, er, an, ti, es, on, at, se, nd, or, ar, al, te, co, de, to, ra, et, ed, it, sa, em, ro. The most common trigrams (in order): the, and, tha, ent, ing, ion, tio, for, nde, has, nce, edt, tis, oft, sth, men See http://pages.central.edu/emp/LintonT/classes/spring01/cryptography/letterfreq.html 22-14
Frequency Analysis
English letter frequencies:
Cryptographic Tools
22-15
XOR Operation (⊕) On Bits
⊕ 0 1 0 0 1 1 1 0
plaintext o n e i f ascii 111 110 101 105 102 bits 0110 1111 0110 1110 0110 0101 0110 1001 0110 0110
key 1011 0101 0101 1010 1110 1111 0100 0000 0110 1101
ciphertext 1101 1010 0011 0100 1000 1010 0010 1001 0000 1011
key 1011 0101 0101 1010 1110 1111 0100 0000 0110 1101
bits 0110 1111 0110 1110 0110 0101 0110 1001 0110 0110
ascii 111 110 101 105 102 plaintext o n e i f
Properties • Associativity: ( x ⊕ y) ⊕ z = x ⊕ (y ⊕ z) • Commutativity: x ⊕ y = y ⊕ x • Identity: x ⊕ 0 = x = 0 ⊕ x • Invertability: x ⊕ x = 0
Consequence: (p ⊕ k) ⊕ k = p
22-16
One-Time Pad
k1
p1
c1
p1
… plaintext message as bits
⊕
⊕ k1
k2
p2
c2
p2
⊕
⊕ k2
k3
p3
c3
p3
⊕
⊕ k3
k4
p4
c4
p4
⊕
⊕ k4
key
key
…
…
View message as n bits and have n-bit random �pad� as key. Effectively Vigenere with key as long as message.
22-17
Evaluating One-Time Pad o If used properly, one-time pad is perfectly secure.
Ciphertext C for message M can decrypt to any message M� with some key.
o New key must be chosen for every message:
• Reusing keys breaks security by opening messages to analysis (e.g., Russian Venona ciphers).
• How to communicate such long keys securely? (Why not send messages the same way?)
o If pad isn�t really random but psuedo-random generated by seed, this is a stream cipher .
22-18
One-Time Pads in the News
http://www.nytimes.com/2012/11/02/world/europe/world-war-ii-pigeons-message-a-mystery.html
22-19
Stream Cipher
ks1
p1
c1
p1
… plaintext message as bits
⊕
⊕ ks1
ks2
p2
c2
p2
⊕
⊕ ks2
ks3
p3
c3
p3
⊕
⊕ ks3
ks4
p4
c4
p4
⊕
⊕ ks4
keystream generator key
keystream generator key
Basic architecture is like one-time pad, except XORing is done with key stream generated by key. E.g., key is seed to psuedo-random number generator (PRNG). Example: RC4.
22-20
Evaluating Stream Ciphers
A simple way to encrypt long/infinite streams of data (e.g., a network link). Security of stream cipher depends entirely on details of keystream generator.
22-21
Substitution Cipher Idea: replace plaintext letters according to alphabet permutation. A �key� is one such permutation. E.g.:
a b c d e f g h i j k l m n o p q r s t u v w x y zj d u s c l n f r h a g z w k y i p t m x b v q o e
plaintext: ciphertext:
o n e i f b y l a n d t w o i f b y s e ak w c r l d o g j w s m v k r l d o t c j
plaintext: ciphertext:
Encrypt a message via this permutation. E.g.:
o Same plaintext at different positions encrypts to same ciphertext.
o Can implement by rotors (e.g. WW2 Enigma)
o How many keys are there? 22-22
Breaking Substitution Ciphers There are 26! = 4x1026 keys.
So substitution ciphers must be very secure, right? !
" Oops! How are substitution ciphers broken?
22-23
Transposition Cipher Idea: shuffle chunks of the plaintext message A �key� is one such shuffling. E.g.:
o n e i f b y l a n d t w o i f b y s e a x y z
n b i o f l e y n o t a w f d i y x e b a z s y
o Same plaintext at different positions can be shuffled differently.
o May need to �pad� end of message. Pads must be chosen carefully!
o How many keys are there for shuffle blocks of length n?
o How can transposition ciphers be broken?
22-24
Block Cipher
key
… Fixed-length plaintext block (e.g. 64 bits)
Fixed-length ciphertext block …
key
… Fixed-length plaintext block
E
D
How many different blocks with n bits? In theory, how many different encryption functions? In practice far fewer, depending on key size. How many encryption functions for key size k? Examples: DES, AES. Skipjack, IDEA, Blowfish, RC5
22-25
Block Cipher: Electronic Codebook Mode (ECB)
k E
k D
P1
C1
P1
k E
k D
P2
C2
P2
k E
k D
P3
C3
P3
k E
k D
P4
C4
P4
…
…
…
plaintext message as blocks (may need padding at end)
Advantages: • Easy to parallelize
• Can modify part of encrypted file without re-encrypting whole file.
• Ciphertext bit errors in one block don�t propagate to other blocks. Disadvantages: • Can make �codebook� of any decrypted blocks.
• Can perform statistical attacks on blocks. Stereotyped beginnings and endings of messages especially problematic. • Adding or losing a ciphertext bit (synchronization error) throws everything off if no frames.
• Block replay: Mallory can replace, remove, repeat, interchange blocks (e.g. modify bank transfers to other accounts to move money to his account).
22-26
Evaluating ECB
22-27
Block Cipher: Cipher-Block Chaining Mode (CBC)
k E
k D
P2
C2
P2
…
…
… ⊕
⊕
k E
k D
P1
C1
P1
⊕
⊕
k E
k D
P3
C3
P3
⊕
⊕
k E
k D
P4
C4
P4
⊕
⊕
Initialization Vector (IV)
Why Initialization Vectors?
Same message (or message prefix) won�t yield same ciphertext for different IVs (like password hashing salt). IVs chosen randomly. Advantages of CBC:
Resistant to �codebooks�, statistical attacks, and block replay. Disadvantages of CBC:
• Inherently sequential.
• Error problems: o Changed bit in ciphertext block garbles current plaintext block and changes one bit of subsequent block .
o Adding/removing single bit in ciphertext block garbles rest of plaintext message.
22
22-28
Evaluating CBC
22-29
Data Encryption Standard (DES) o In 1972, National Bureau of Standards issued request for standard
crypto algorithm.
o Data Encryption Standard (DES) was adopted as federal standard in 1977 and ANSI standard in 1981.
o Grew out of IBM Lucifer system and evaluated by the National Security Agency (NSA). People worried that NSA reduced key size from 128 to 56 bits and may have introduced a trapdoor.
o DES is a block cipher --- maps 64-bit plaintext block to 64 bit ciphertext block controlled by 56-bit key. Uses 16 rounds of the same substitution/permutation operation.
22-30
Encryption/Decryption with openssl Command [cs342@puma] cat secret.txt One if by land, two if by sea. [cs342@puma] openssl enc -des -nosalt -pass pass:foobar -in secret.txt -out secret.enc [cs342@puma] cat secret.enc S\3725\337*|^T\341\345^^\366\316\207\370\261\351d\371^D^A#\245^V1>\240Gy\230\256 [cs342@puma] openssl enc -d -des -nosalt -pass pass:foobar -in secret.enc One if by land, two if by sea.
22-31
Brute Force Attacks on DES Although denied by US govt. (esp. NSA) people suspected DES was breakable by brute force (i.e., try all possible keys) with enough computing power. Shown in series of RSA-Labs-sponsored challenges to break DES keys:
o Jun. 1997: 140 days by DESCHALL project (distributed.net), as described in Matt Curtin�s Brute Force: Cracking the Data Encryption Standard
o Feb. 1998: 39 days by distributed.net
o Jul. 1998: 56 hours by Electronic Frontier Foundation's (EFF) "Deep Crack" machine
o Jan. 1999, key broken in 22 hours and 15 minutes by Deep Crack + distributed.net
Moral: Key size matters!
National Institute of Standards and Technology (NIST) requested proposals for new encryption standard in 1997; winner in 2000 was dubbed Advanced Encryption Standard (AES) . Minimum of 128-bit keys; up to 256-bit keys. Other block ciphers: o Skipjack (Clipper chip/Fortezza program, 80-bit keys)
o Triple-DES (TDES) = three rounds of DES with 3 different keys; 2*56 = 112 effective bits of security with 3*56 = 168-bit keys.
o IDEA (128-bit keys)
o Blowfish (Schneier, up to 448-bit keys).
o RC5 (Rivest, parameterized over key & block size)
22-32
Other Block Ciphers
Brute force attack: Try all possible keys. Feasability depends on key size, available computrons. Information theoretic attacks: Letter frequency information can break shift & substitutions cipher quickly. (To reduce redundancy of messages, some crypto implementations first compress message.) Algorithm/implementation attacks: take advantage of details in algorithm or its implementation – e.g. choice of randomness, padding functions . Examples: • Netscape SSL �random� session key easily guessable with time/process info. • Kerberos v.4 DES 56-bit session key only had 20 bits of info. Side channel attacks: determine key from timing, memory usage, power, electromagnetic field, etc. Keyjacking: Hijack calls to cryptographic API. Other approaches we�ve seen: information leakage (find keys on stack, in memory pages, etc.) and social engineering (shoulder surfing, dumpster diving, etc.)
22-33
Breaking Cryptography (S&M Ch. 8)
22-34
Cryptanalytic Attack Classification
Add ciphertext-only: given only encrypted messages, deduce messages/key.
known-plaintext: given plaintext messages & encryptions, deduce key/algorithm
chosen-plaintext: deduce key from black-box encrypter.
chosen-ciphertext: deduce key from black-box decrypter.
purchase-key/rubber-hose: bribe/threaten key holder until s/he gives up key
22-35
Change of Focus: Message Authentication Confidentiality: No one can read M except Alice and Bob (e.g., whispering, locked box); Authentication: Bob knows M comes from Alice, not someone masquerading as Alice (e.g., wax seal, watermark paper, signature); Integrity: Bob can verify that M has not be altered after it was sent by Alice (e.g., tamperproof packaging); Nonrepudiation: Alice should not be able to falsely deny sending M.
message authentication, digital signatures
encryption/ decryption
22-36
Message Authentication via Digital Signatures With encryption scenario, nothing prevents Eve from recording and replaying messages and Mallory from modifying messages (e.g. splicing parts of different messages together). Want a way to determine that an plaintext message is authentic -- it�s really from who it says it's from, and has not been changed. If Alice sends Bob (unencrypted) M, want it accompanied with a digital signature SA,M that has the following properties:
• authenticity: Bob confident M is from Alice (only she signs SA,M ).
• integrity of signed document. Changing M invalidates SA,M
• unforgeability: no one but Alice knows how to sign SA,M.
• unreusabilty: SA,M depends on M, so can�t be used with another msg.
• nonrepudiation of signature: Alice can�t claim she didn�t send M.
o For untampered message, M = M� and S = S� = S��. Otherwise, Bob thinks message has been changed and/or is not from Alice.
o Replay a problem, but can be solved with sequence #s/timestamps.
o MAC provides no confidentiality by itself. M could be plaintext.
o MAC can be combined with encryption, but authentication key should be unrelated to encryption key. 22-37
Message Authentication Code (MAC)
MAC
MAC
M
Shared authentication key K
S = MAC(K,M)
M� S�� = MAC(K,M�)
S� S�
M�
22-38
CBC-MAC Idea: Break message into n fixed-sized blocks (padding if necessary) and encrypt with block cipher in CBC mode. MAC is final cipher block.
Ferguson, Schneier, and Kohno (FSK) warn:
o Never use same key for encryption and authentication.
o Collision attacks limit security to half the length of block size.
o Not recommended, because difficult to use correctly.
K E
M2
… ⊕ K E
M1
⊕ K E
Mn
MAC
⊕
Initialization Vector (IV)
discard discard
padded
22-39
CMAC Idea: Like CBC-MAC, but XOR key-dependent value in input to final block to disrupt some CBC-MAC attacks
K E
M2
… ⊕ K E
M1
⊕
Mn
MAC
⊕
Initialization Vector (IV)
discard discard
padded
K E
⊕ f
Digression: Cryptographic Hash Functions A cryptographic hash function H(M) returns a fixed-length hash value h for any size message M. This value h is known as a cryptographic checksum, fingerprint, message digest. They’re used in passwords, digital signatures, integrity checking, etc.
Hash Function Bits in Fingerprint
MD5 (Message Digest, Rivest, 1992) 128 SHA-1 (Secure Hash Algorithm, NSA, 1995) 160
SHA-2 (NSA, 2001) 224, 256, 384, 512 SHA-3 (NIST, 2012) 224, 256, 384, 512
01011010001 01011101101 100110110…
M (arbitrarily large)
H(M) = h (fixed size) H 11010011010110…110
22-40
Desirable Crypto Hash Function Properties One-way (a.k.a. Pre-image Resistance): • Easy to compute H(M) = h. • Given h�, hard to find an M� such that H(M') = h� (even though
there are ∞ such values, by the pigeon-hole principle). • Implies that, given M, hard to find M� such that H(M) = H(M�). Collision Resistance: • Practically difficult to find (M1, M2) that collide: H(M1) = H(M2).
Seemingly Random Behavior: • H behaves like a random mapping: changing a single bit in M should
change about half the bits in H(M), in an unpredictable way
Note: do note confuse cryptographic hash functions with much simpler hash functions used in hash tables!
22-41
Hashing Examples Using openssl
[cs342@tempest ~] echo "One if by land, two if by sea." | openssl dgst -md5 (stdin)= fe66cbf9d929934b09cc7e8be890522e [cs342@tempest ~] echo "One if by land, two if by sea." | openssl dgst -md5 -c (stdin)= fe:66:cb:f9:d9:29:93:4b:09:cc:7e:8b:e8:90:52:2e [cs342@tempest ~] echo "One if by land, two if by sea" | openssl dgst -md5 -c (stdin)= 78:4b:61:4a:66:98:17:82:18:d9:25:ca:c9:64:c5:56 [cs342@tempest ~] echo "One if by land, Two if by sea." | openssl dgst -md5 -c (stdin)= 96:07:e8:69:cd:97:59:98:ad:21:8e:46:a8:c0:4f:0e [cs342@tempest ~] echo "One if by land, two if by sea." | openssl dgst -sha1 -c (stdin)= 28:47:d1:e5:9a:96:83:bf:2f:2a:91:b8:f3:ec:21:63:d3:be:5a:6b [cs342@tempest ~] echo "One if by land, two if by sea" | openssl dgst -sha1 -c (stdin)= 24:e2:d1:19:44:c2:17:49:1f:d8:9c:23:d0:9d:d2:d9:87:87:11:f1
22-42
More Hashing Examples
[cs342@tempest ~] echo "One if by land, two if by sea." | openssl dgst -sha256 -c (stdin)= 67:82:97:b4:e2:4f:95:28:b7:f1:cf:37:dc:8b:49:83:3f:94:d6:45:50:eb:1c:4f:79:86: 56:0a:59:8e:e1:ed [cs342@tempest ~] echo "One if by land, two if by sea" | openssl dgst -sha256 -c (stdin)= 94:09:b6:88:06:44:df:e8:47:28:e2:9c:5e:99:0c:16:76:5c:ad:1d:32:36:25:ef:2b:c3: 0e:d8:7a:ed:38:95 [cs342@tempest ~] echo "One if by land, two if by sea." | openssl dgst -sha512 -c (stdin)= 93:fc:e3:a3:07:6a:90:ec:51:29:be:71:da:bf:47:dd:d0:67:ed:89:c6:b4:f9:27:ba:f6: c8:8c:a1:78:d2:53:ac:92:bc:3d:a5:52:06:98:d5:40:14:9f:2e:ad:fe:ab:55:ae:6f:d7:67:cf:1e: b4:85:0a:01:9c:78:8f:97:22 [cs342@tempest ~] echo "One if by land, two if by sea" | openssl dgst -sha512 -c (stdin)= 8c:89:d6:ad:9e:30:09:53:00:70:bd:a0:4c:1a:62:34:7c:5e:f2:a3:c0:25:02:99:e2:7a:89:b0:ac:2f:a5:fc:7c:44:72:a7:a6:69:75:45:c9:3f:18:f9:12:e0:a7:50:bf:73:c4:f8:61:42:fd:90:78:3d:06:28:7b:f0:48:8c
22-43
Hashes in Practice: Safe Downloads & Intrusion Detection
Safe downloads from untrusted sites (as long as have file hash from trusted site). Can use hashes to guarantee file integrity.
E.g., http://www.safer-networking.org/en/download/index.html [lynux@localhost ~]$ openssl dgst -md5 Desktop/spybotsd160.exe MD5(Desktop/spybotsd160.exe)= 0e7fbf50f87b3b7c384a2471154a7558
Intrusion detection: use hash (possibly combined with key) to fingerprint all important system files.
22-44
22-45
Hashes Aren�t Digital Signatures!
One-way hashes can be used for integrity in some cases (e.g., code fingerprint from ``reputable'' website), but by themselves they're not suitable for signing messages from Alice to Bob. Why?
22-46
Hash-Based MACs
A MAC combine hashes with keys to so that only key-holders can authenticate. Useful for authenticating files between users and determining if user files have changed Basic idea: send pair <M, S> of message M and signature S, where the S is calculated from M and key K. Some possible signatures: • encrypt hash value of M with key: S = E(K, H(M)).
• hash encrypted value of M: S = H(E(K, M)).
• hash result of concatenating key and message: (1) S = H(K @ M) or (2) S = H(M @ K). Schneier & FSK mention some vulnerabilties of these approaches.
Generic Hash Attacks Recall: want hash function H to have both the following properties: Pre-Image Resistance: given h, hard to find M s.t. H(M) = h Collision Resistance: hard to find M1 and M2 s.t. H(M1) = H(M2) For k-bit hashes: • given h, about how many messages M do we expect to examine in a brute force attack on h? • about how many messages M do we expect to examine to find a collision?
To figure these out, let�s think about birthdays … 22-47 22-48
Birthday Problems
The following two problems are very different: 1. Alice is in a room of n people. What�s the smallest n for which there�s a 50% probability that someone else shares Alice�s birthday? 2. (Birthday Paradox) There are n people in a room. What�s the smallest n for which there�s a 50% probability that at least one pair share the same birthday?
Solution to Birthday Problem #1:
Let B(n) = at least one of n people shares Alice�s birthday and NB(n) = not one of the n people shares Alice�s birthday
Then p(B(n)) + p(NB(n)) = 1, so p(B(n)) = 1 – p(NB(n)).
p(NB(n)) = (364/365)n
Note: expected number of people to have first match is 365.
Consequence: for k-bit hash, expect to find a message with a given hash value h after 2k hashes.
22-49
Birthday Problem #1: Details
n p(NB(n)) p(B(n)) 50 .872 .128 100 .760 .240 150 .663 .337 200 .578 .422 250 .504 .496 253 .500 .500 300 .439 .561 400 .334 .666 500 .254 .746 750 .128 .872 1000 .064 .936
22-50
Birthday Paradox: Details Solution to Birthday Problem #2 (Birthday Paradox)
Let B(n) = at least two of n people share same birthday and NB(n) = no two people share the same birthday.
Then p(B(n)) + p(NB(n)) = 1, so p(B(n)) = 1 – p(NB(n)).
p(NB(n)) = (365/365)*(364/365)*(363/365)* … * ((366 – n )/365)
= 365! / ((365 – n)! * 365n)
n p(NB(n)) p(B(n)) 10 .883 .117 15 .747 .253 20 .589 .411 23 .493 .507 30 .294 .706 40 .109 .891 50 .03 .97 60 .006 .994 70 .001 .999
22-51
Birthday Paradox: Results Suppose a system generates a random sequence of n values in [1 .. L].
There are (n * (n-1))/2 pairs of sequence elements (ignoring order).
There is a 1/L chance that any pair has equal values.
So the probability of a collision is (n * (n-1))/2L ~ n2/2L.
When is the collision probability about 50%?
What does this imply about the number of messages that need to be examined to find collisions for a hashing function with a k-digit fingerprint?
22-52
Birthday Paradox: Practical Consequences MD5 hash (128 bits)
o Expect to find collisions after 264 ~ 18x1018 messages. Once unthinkably large, but now very thinkable.
o Cryptanalytic advances starting in 2005 allow finding collisions in much fewer than 264 computations.
o �While the existence of such efficent collision finding attacks may not immediately break all uses of MD5, it is safe to say that MD5 is very weak and should no longer be used.� (FSK, Ch. 5)
SHA-1 hash (160 bits)
o Expect to find collisions after 280 ~ 1.2x1024 messages. Within the realm of thinkability.
o Algorithm details make it possible to finding collisions in much fewer than 280 computations.
o �It is no longer safe to trust SHA-1�. (FSK, Ch. 5)
22-53
Iterative Hash Functions In practice, a hash function H on fixed size blocks (typically 512 bits) is applied iteratively to message blocks starting with a fixed value.
H
M2
h2
… ⊕ H
M1
h1
⊕ H
Mn
hn
⊕
h0
h0 (fixed)
= H(M)
Properties: • Easy to implement. • Can compute as soon as part of message received, so works well on stream of data. • But, subject to some attacks.
padded
22-54
Attacks on Iterative Hash Functions
Length Extension Attack:
o Knowing H(M1 @ M2 … @ Mn), we know a lot about H(M1 @ M2 … @ Mn @ Mn+1 ).
o E.g., Consider MAC(K,M) = H(K @ M) = h. Mallory can add an extra block to the end of M without changing h.
Partial-Message Collisions:
o Consider MAC(K,M) = H(M @ K) = h, where K is a multiple of a block size. Then if Mallory finds M� such that H(M�) = H(M), she can replace M by M� without changing h.
FSK suggest the hash function H�(M) = H(H(M) @ M) to fix these problems.
Password Interception
Alic
e
Bob <�I�m Alice�, H(password) >
Mal
lory
password
22-55
Man-in-the-Middle /Chess Grandmaster Attacks
Alic
e
Bob
Mal
lory
message to Bob
Many password interception techniques are examples of man-in-the-middle (MITM) attacks: Mallory impersonates Alice to Bob and Bob to Alice.
message� to Bob
message to Alice message� to Alice
This is also known as the chess grandmaster attack: Mallory can play remote chess against grandmasters Alice (white) and Bob (black) at the same time and will win one game or draw both.
22-56
Replay Attack
Alic
e
Bob
<�I�m Alice�, H(password) >
Eve
Eve can record encrypted password and later replay it. How to foil replay attack?
<�I�m Alice�, H(password) >
22-57
Foiling Replay Attack
o Timestamps/Sequence Numbers/Nonces but, as we�ll see in more detail later, these have problems: • timestamps require synchronization and might be guessable • consecutive sequence numbers are obviously related • nonces must be remembered by Bob.
o Password Aging • bad social properties; people try to circumvent. • how frequent to be effective deterrent?
o One-time Passwords (OTP): Alice has a sequence of passwords and uses each only once (they�re nonreusable!). • how to generate password sequence? • how to synchronize Alice and Bob?
o Challenge-Response: Alice responds to new challenge from Bob on each login.
22-58
One-Way Authentication: Challenge-Response
Alic
e
Bob
�I�m Alice�
R
E(KAB, R) or H( <KAB, R> )
Alice responds to nonce challenge R from Bob by encrypting or hashing R with shared key KAB.
22-59
MITM Attack on Challenge-Response
Alic
e
Mal
lory
�I�m Alice�
R
E(KAB, R) or H( <KAB, R> )
MIG-in-the-Middle attack. described by Ross Anderson:
Bob
�I�m Alice�
R
E(KAB, R) or H( <KAB, R> )
SAA
F ra
dar
in N
amib
ia
Cuba
n M
IG
over
Nam
ibia
R
E(KSAAF, R) SAA
F je
t ov
er A
ngol
a
Cuba
n ra
dar
in A
ngol
a
R
E(KSAAF, R)
R
E(KSAAF, R)
22-60
Other Challenge-Response Attacks Violated assumptions can lead to many attacks:
Impersonation: Nothing authenticates Bob, so Mallory can impersonate Bob.
Known Plaintext: Plaintext R can help Eve figure out key KAB.
Chosen Plaintext: As Bob, Mallory can get Alice to encrypt any M.
Session Hijacking: Mallory hijacks conversation after initial handshake.
Server Database Attack: Mallory may be able to find KAB (and thereby impersonate Alice) by attacking Bob�s database.
Predictable Nonce: If nonce is a sequence number or coarse-grained timestamp, Mallory can replace R by a �later� R′, obtain E(KAB, R′) from Alice, and use this to impersonate Alice for later nonce R′. (This is impractical for fine-grained timestamp.)
Moral: Cryptography not enough by itself – must consider system in which it�s used. (Radia Perlman�s talk on How to Build an Insecure System out of Perfectly Good Cryptography.)
22-61
Review: Symmetric-Key Crypto
Encrypt Decrypt M
plaintext ciphertext plaintext
K
M = D(K, C) C = E(K,M)
o Alice and Bob share same key K.
o Need D(K, E(K, M)) = M for all keys K and messages M.
o Fundamental problem is key exchange:
• How do Alice and Bob choose & share K, especially if they never meet in person?
• How many keys are needed for n parties, each of whom want to communicate in pairs?
It�s essential to solve this problem for electronic commerce.
K Alice Bob
22-62
Diffie-Hellman Key Exchange (1976)
Public knowledge: • a large prime n • a generator g for n (i.e., any number k between 1 and n-1 can be expressed as gi (mod n) for some i)
Depends on hardness of discrete log problem: Hard to calculate i from gi (mod n)
Alic
e
Bob
gx (mod n) picks random x
• Allows Alice and Bob to create a new session key without meeting • Does not authenticate Alice or Bob.
picks random y gy (mod n) now knows key
k = gxy (mod n) now knows key k = gxy (mod n)
E.g. 2 is a generator for 11: 210 = 1 (mod 11) 29 = 6 (mod 11) 21 = 2 (mod 11) 27 = 7 (mod 11) 28 = 3 (mod 11) 23 = 8 (mod 11) 22 = 4 (mod 11) 26 = 9 (mod 11) 24 = 5 (mod 11) 25 = 10 (mod 11)
22-63
Public-Key Crypto
Encrypt Decrypt M
plaintext ciphertext plaintext
Bob�s public key, KBpub
Bob�s private key, KBpriv
M = D(KBpriv, C) C = E(KBpub,M)
o Each person has a key pair: 1. a public key Kpub that is published to the world; 2. a private key Kpriv that only the person knows.
o Need D(Kpriv, E(Kpub, M)) = M for all key pairs (Kpub, Kpriv) and all M.
o Must be practically impossible to determine Kpriv from Kpub
o Solves key exchange problem. Anyone can look up P�s public key in a public directory to encrypt a message for P, but only P can decrypt it. (But we�ll see there are problems with public directories…)
Alice Bob
22-64
Sounds Magical … Do Algorithms Exist? Yes!
Idea of public-key crypto due to Diffie/Hellman and Merkle (1976). Implementations based on computationally intractable problems:
o Merkle/Hellman encryption (1978) based on knapsack problem (NP complete).
o RSA (Rivest,Shamir, Adelman, 1978) based on difficulty of factoring large numbers. The most popular approach to public-key crypto, it supports both encryption and digital signatures. We�ll study this algorithm.
o El Gamal (1985) based on difficulty of calculating discrete logarithms in finite field. Supports both encryption and digital signatures.
In contrast, symmetric-key crypto implementations are a �black art�.
22-65
RSA Foundations: Modular Arithmetic
x =(mod n) y means x mod n = y mod n
equivalently: x + kn = y for some k
x = y (mod n) is an alternative notation.
For all x, y, n:
x + y =(mod n) (x mod n) + (y mod n)
x * y =(mod n) (x mod n) * (y mod n)
xm =(mod n) (x mod n)m
Examples:
7002 * 7775 =(mod 7) ??
15315417 =(mod 153) ??
22-66
RSA Foundations: Multiplicative Modular Inverses
Multiplicative modular inverses of relative primes:
If x, y are relatively prime (i.e., gcd(x,y) = 1) then there�s a k s.t.
x⋅k =(mod y) 1 (alternatively, k =(mod y) x-1 )
This is a consequence of Euclid�s gcd algorithm. E.g. 21, 25:
21 ⋅ 6 =(mod 25) 126 =(mod 25) 5 ⋅ 25 + 1 =(mod 25) 1
25 ⋅ 16 =(mod 21) 400 =(mod 21) 19 ⋅ 21 + 1 =(mod 21) 1
22-67
RSA Foundations: Fermat�s Little Theorem
Fermat�s Little Theorem:
If p is prime and p doesn�t divide x, then x(p-1) =(mod p) 1 E.g.
5 96 =(mod 97) 1
64 96 =(mod 97) 1
96 96 =(mod 97) 1
300 96 =(mod 97) 1 But
97 96 =(mod 97) 0
194 96 =(mod 97) 0
22-68
RSA Foundations: Chinese Remainder Theorem Chinese Remainder Theorem†
Suppose a and b are relatively prime. Then:
(x =(mod a) y) and (x =(mod b) y) iff (x =(mod ab) y)
Examples:
10 =(mod 3) 22 and 10 =(mod 4) 22 implies 10 =(mod 12) 22
23 =(mod 30) 53 implies 23 =(mod 2) 53 and 23 =(mod 15) 53
23 =(mod 3) 53 and 23 =(mod 10) 53
23 =(mod 5) 53 and 23 =(mod 6) 53 † This is a specialized version of the Chinese Remainder Theorem.
The general version involves n equations and n numbers that are pairwise relatively prime.
22-69
RSA Foundations: Practice Lemma Suppose p, q are prime. Using Fermat�s Little Theorem and Chinese Remainder Theorem, show the following:
if w =(mod (p-1)(q-1)) 1 then mw =(mod pq) m for all k and all m < p ⋅q Consider:
m1+k(p-1)(q-1) =(mod p) ? m1+k(p-1)(q-1) =(mod q) ?
Does it matter if one of p or q divides m?
22-70
1. Choose two large (100s of digits) random prime numbers, p and q.
2. Define n = p ⋅ q
3. Choose e relatively prime to (p-1)(q-1).
4. Define d =(mod (p-1)(q-1)) e-1 (by Thm 1)
5. Define public key Kpub = pair (e,n)
6. Define private key Kpriv = pair (d,n)
7. To encrypt m with public key (e,n), split m (as bitstring) into m1 @ m2 @ … s.t. each mi (as number) is < n and calculate:
E((e,n), mi) = (mie mod n) = ci
8. To decrypt ci: D((d,n), ci) = (cid mod n)
Note: E(kpub, m) stands for E(kpub, m1) @ E(kpub, m2) @ …
D(kpriv, c) stands for D(kpriv, c1) @ D(kpriv, c2) @ …
RSA (Rivest, Shamir, Adelman 1978)
22-71
RSA Implements Public-Key Crypto! D(kpriv, E(kpub, mi))
= D((d,n), E((e,n), mi)) (by defns of kpriv and kpub )
= ((mie mod n)d mod n) (by defns of E & D)
=(mod n) mied (by modular arithmetic)
=(mod n) mi1+k(p-1)(q-1) (because d =(mod (p-1)(q-1)) e-1 )
=(mod n) mi (by Practice Lemma; recall n = p ⋅ q)
22-72
Problem: Larger Numbers are Being Factored Security of RSA depends on hardness of factoring large numbers.
In 1977, Rivest said factoring a 125-digit number would take 40 quadrillion years (reported by Schneier). But computers are getting faster, so he was wrong!
Decimal digits Bits When factored
90 299 1988 100 333 1989 129 429 1994 140 466 1999 155 515 1999 576 1914 2003 640 2127 2005
Moral: use large numbers in RSA.
Consider: If someone found a way to break RSA, would they tell you? 22-74
Chosen Plaintext Attack on Public Key Crypto Suppose Eve has ciphertext C = E(KBpub,M). If M comes from a small range of possible messages, Eve can try them all (because KBpub is public)!
22-75
Chosen Ciphertext Attack on RSA, #1 Eve has ciphertext C = Me mod n of message M encrypted by Alice. Suppose Eve can trick Alice into signing a message. Eve chooses random R < n and calculates:
X =(mod n) Re Y =(mod n) XC T =(mod n) R-1
Eve tricks Alice into signing Y to yield U = Yd mod n. Now Eve computes TU mod n. What is this? 22-76
Chosen Ciphertext Attack on RSA, #2 & #3 Mallory wants to trick notary public Trent into signing �bad� msg B (might have wrong timestamp, claim to be from Alice, etc.) Attack 1: Mallory finds an X such that G =(mod n) B (Xe) is a �good� message that Trent will sign. Trent returns Gd mod n. What is this? Attack 2: Mallory finds �good� G1 and G2 such that B =(mod n) G1 G2. Trent returns G1
d mod n and G2d mod n.
How can Mallory get Bd mod n? Moral: Never sign a random document from a stranger!
22-77
Other RSA Attacks (Schneier, S&M) Common Modulus Attack: If two parties use same n but different e1 and e2, it�s possible to decrypt a message encrypted with both. Moral: Never share n! Low Encryption Exponent Attack: Small e makes encryption faster, but have problems if same small e is used for different n. (1) Can decrypt e copies of same M via Chinese Remainder Thm. (2) can decrypt e(e+1)/2 linearly dependent messages. Moral: Be careful with small e; use random padding for larger messages. Low Decryption Exponent Attack: Small d makes decryption faster, but it is vulnerable to attack if it�s small (< n/4). Moral: Use large d! Timing Attack: Can determine bits of keys with decryption timing attack . Moral: implementation details matter! 22-78
RSA Provides Digital Signatures, Too! Since exponentiation is commutative, we also have:
E(Kpub, D(Kpriv, mi) )
= ((mid mod n)e mod n)
=(mod n) mied =(mod n) mi
(by same reasoning as above)
D(Kpriv, m) is a public-key signature of m.
D M s = D(KApriv, M) M��= E(KApub,s�) s�
M� E
Alice�s private key, KApriv
Alice�s public key, KApub
22-79
Properties of Public-Key Signatures Bob receives message signed D(kApriv, m)
(i.e. he receives pair <m, D(kApriv, m)> )
Assume only Alice knows kApriv (it hasn�t been stolen):
Authenticity: Bob confident message from Alice (only she knows kApriv ).
Unforgeability: because no one but Alice knows kpriv.
Unreusabilty: signature depends on documents & can�t be used for another document.
What about documents (e.g. digital checks of a certain amount) that might be sent more than once?
Integrity of signed document. Changing m requires changing signature in way that can�t be done without knowing kApriv.
Nonrepudiation of signature: Alice can�t claim she didn�t send m.
22-80
Combining Encryption & Signatures
Alice wants to send a secret, signed message m to Bob. She can send this to Bob:
E(K_Bpub, <�From Alice�, D(K_Apriv, M)>) Bob can process her message as follows:
1. Bob uses K_Bpriv to get <�From Alice�, signed_M>. 2. Bob sees it�s from Alice, and computes E(K_Apub, signed_M).
If it�s not gobbdelygook, trust message. If not, ignore message.
Alternatives that Alice could send to Bob: • <�From Alice�, E(K_Bpub, D(K_Apriv, M))> • <�From Alice�, D(K_Apriv, E(K_Bpub, M))>
22-81
Public-Key in Practice
In practice, public-key crypto is orders of magnitude slower than symmetric-key crypto.
Assume Alice and Bob have never met.
o Suppose Alice wants to encrypt a large message M to Bob. It�s too expensive to use public key crypto to encrypt M. What to do?
• Alice uses a key generator (PRNG) to generate a session key K_s for symmetric key crypto (e.g. AES).
• Alice sends to Bob <�From Alice�, E(K_Bpub, K_s), E(K_s, M)>
• Bob uses K_Bpriv to extract K_s, and uses that to decrypt M.
o Suppose Alice wants to send a signed large message M to Bob. It�s too expensive to use public key crypto to sign M. What to do?
• Alice sends to Bob <�From Alice�, M, D(K_Apriv, H(M))>
• Bob uses K_Apub and H to verify M.
22-82
Public Key Infrastructure (PKI) But how does Alice know KBpub and Bob know KApub?
o This is the realm of Public Key Infrastructure (PKI) = everything needed to make public key cryptography work in practice.
o PKI is all the �stuff� (S&M) needed to make public-key cryptography work in the real world. It�s essentially an issue of trust management.
o In particular, why should we trust that what is claimed to be Alice�s public key is Alice�s public key?
• Certainly we�d trust Alice to give us her own public key directly. But this is no better than secret-key distribution!
• The key issue in PKI is finding ways to trust Alice�s public key when it comes from other sources.
o In practice, the X.509 standard dominates PKI. See readings for details.
22-98
Diffie and Hellman�s Vision
Idea: Public keys are stored in a public directory
Person h Key Alice KA
Bob KB
Carol KC … …
Problems: • How do we know information is correct? Who guarantees that the key published for Alice is her public key KA and not Mallory�s key KM. Public-key crypto breaks if this can happen!
• One global directory has many practical problems, so likely to be many local directories. Some will be more trustable than others. How do we decide trust? • For a web-based directory how do we know it hasn�t been compromised? Are we sure we�re even talking to the right directory?
22-99
Certification Authority (CA): Idea
We (and many others) trust Carlo (the Certification Authority = CA) to manage and distribute public keys.
Alice registers her public key KA with Carlo, who has high standards for verifying that Alice is really Alice (and not Mallory) – that�s why we trust him!
Everyone knows Carlo�s public key KCApub.
Carlo creates a signed certificate (signed with KCApriv) that KA is Alice�s public key.
This certificate specifies Alice�s public key and can be distributed by anyone!
22-100
certA
Certification Authority (CA): Picture
certA
Alic
e
Bob
<“Alice�s public key�, KApub>
Carl
o (C
A)
“What�s your public key?�
E(KApub, “Msg from Bob: … �)
Ellli
e
“Alice�s key?�
Dav
e
“Alice�s key?�
certA
E(KApub, “Msg from Dave: … �)
E(KApub, “Msg from Ellie: … �)
certA = <“cert from Carlo”, D(KCApriv, “Alice�s public key is KApub�)>
Note: certA can be published anywhere! 22-101
Chrome Certificates
22-102
Certificate Chain
22-103
Chrome Certificate Authorities
22-104
Menu> Settings> Advanced Settings> HTTPS/SSL Manage Certificates
Assume Bob knows CA’s public key.
Strawman 0: CA signs public key from someone claiming to be Alice.
Strawman 1: CA generates key pair for Alice, issues it to her, then signs her public key.
Strawman 2: Alice generates her key pair and brings it to CA for signing.
Strawman 3: Alice generates her key pair and brings it to CA for signing along with signed request proving she knows the private key.
Practical matters:
o it�s important for Alice to provide proof she�s who she says she is.
o Where is cert stored?
o CA�s private key must remain private!
Ways to Make Certificates (S&M, Ch. 10)
22-105
SSL Protocol (used in HTTPS)
22-107 Source:(h*ps://upload.wikimedia.org/wikipedia/commons/e/e5/(
Ssl_handshake_with_two_way_authen<ca<on_with_cer<ficates.png(
End of SSL
22-108
Thanks(to(Carissa(Sun(for(this(link:(
h*p://www.tenable.com/blog/pciBsscBannouncesBtheBendBofBsslBusageBforBtheBpaymentBcardBindustry(
The(Payment(Card(Industry(Security(Standards(Council((PCI(SSC)(
released(a(special(bulle<n(on(February(13,(2015(announcing(impending(
revisions(to(the(Payment(Card(Industry(Data(Security(Standard((PCI(DSS)(
…(The(stated(purpose(of(this(bulle<n(is(to(inform(the(payment(card(
industry(that(the$PCI$SSC$has$determined$that$the$Secure$Sockets$Layer$(SSL)$protocol$is$no$longer$an$acceptable$solu<on$for$the$protec<on$of$data$based$on$the$PCI$SSC’s$defini<on$of$“strong$cryptography.”$
SSL -> TLS
22-109
Thanks(to(Carissa(Sun(for(this(link:(
h*ps://www.sans.org/readingBroom/whitepapers/protocols/sslBtlsBbeginnersBguideB1029(
Secure(Socket(Layer((SSL)(is(being(phased(out(and(replaced(by((
Transport(Layer(Security((TLS).(
Trust Chains
Notation: Write [M]U for D(KUpriv, M)
o Suppose Bob trusts Cindy to verify Alice. Then Bob trusts the cert
[Alice�s public key is KAlicePub]Cindy
o Suppose Doug doesn�t know Cindy, but trusts Edna to verify Cindy. Then Doug can use the cert chain
[Cindy�s public key is KCindyPub]Edna → [Alice�s public key is KAicePub]Cindy
o Can extend chains to any length, as long as they�re rooted at at trust anchor.
trust anchor for Doug
22-111
Problems with Trust
Entity A trusts entity B when A assumes that B will behave exactly as A expects.
Adams and Lloyd, Understanding Public Key Infrastructure
Involves assumptions, behavior, expectations.
o What is trust?
o Problem: trust isn�t transitive! Just because Doug trusts Edna to verify Cindy�s public key doesn�t mean he trusts Cindy to verify Alice�s public key. E.g., Cindy might be very lax about whose keys she signs.
[Cindy�s public key is KCindyPub]Edna → [Alice�s public key is KAicePub]Cindy
22-112
Models of Trust
Monopoly: world chooses one trusted CA.
Oligarchy: there are many trusted CAs. E.g., the CAs baked into browsers.
Anarchy: each user responsible for choosing trust anchors and evaluating trust chains. E.g. PGP �web of trust�, signing parties.
22-113
Revocation
Need revocation when (1) private key is compromised or (2) person can no longer be trusted (e.g. disgruntled employee).
Revocation mechanisms:
o Certifications have built-in expiration date that limits damage time.
o Certification Revocation List (CRL) = list of unexpired serial numbers that should no longer be honored. Recent CRL must be checked before using public key in cert.
o Delta CRLs: provide small change lists on top of larger �complete� CRLs.
22-114
Bad Certificates
Expired/revoked/self-signed certificates raise warning flags.
E.g. https://cs.wellesley.edu
22-115
Pop-up Box Problems
Kaufman, Perlman, & Speciner consider the following scenarios:
o Warning: This was signed by an unknown CA. Would you like to accept the certificate anyway? (OK)
o Would you like to always accept this certificate without being asked in the future? (OK)
o Would you like to always accept certificates from the CA that issued that certificate? (OK)
o Would you like to always accept certificates from any CA? (OK)
o Since you�re willing to trust anyone for anything, would you like me to make random edits to the files on your hard drive without bothering you with a pop-up box? (OK)
�… it would be an interesting psychology exercise to see how outrageous you can be before a user stops cliciking OK.�
22-116