1. Public Key Cryptography
radically different approach [Diffie-Hellman76, RSA78]
sender, receiver do not share secret key
public encryption key known to all
private decryption key known only to receiver
symmetric key crypto
requires sender, receiver know shared secret key
Q: how to agree on key in first place (particularly if never “met”)?
Security
8-1

2. Public key cryptography+ K
Bob’s public
key B -
Bob’s private
key K B
plaintext
message, m
encryption
algorithm
ciphertext
decryption
algorithm
plaintext
message
K (m) B +
m = K (K (m)) B + -
Security
8-2

3. Public key encryption algorithms
requirements: . . + - 1
need K ( ) and K ( ) such that B B
K (K (m)) = m B - + + 2
given public key K , it should be impossible to compute private key K B - B
RSA: Rivest, Shamir, Adelson algorithm
Security
8-3

4. RSA: Creating public/private key pair
1. choose two large prime numbers p, q.
(e.g., 1024 bits each)
2. compute n = pq, z = (p-1)(q-1)
3. choose e (with e<n) that has no common factors
with z (e, z are “relatively prime”).
4. choose d such that ed-1 is exactly divisible by z.
(in other words: ed mod z = 1 ).
5. public key is (n,e). private key is (n,d). K B + K B -
Security
8-4

5. RSA: encryption, decryption
0. given (n,e) and (n,d) as computed above
1. to encrypt message m (<n), compute
c = m mod n e
2. to decrypt received bit pattern, c, compute
m = c mod n d
magic
happens!
m = (m mod n) e
mod n d c
Security
8-5

6. Bob chooses p=5, q=7. Then n=35, z=24.
RSA example:
Bob chooses p=5, q=7. Then n=35, z=24.
e=5 (so e, z relatively prime).
d=29 (so ed-1 exactly divisible by z).
encrypting 8-bit messages. e
c = m mod n e
bit pattern m m
encrypt:
0000l000 12
24832 17 c
m = c mod n d 17 12
decrypt:
Security
8-6

7. Why does RSA work? must show that cd mod n = m where c = me mod n
fact: for any x and y: xy mod n = x(y mod z) mod n
where n= pq and z = (p-1)(q-1)
thus, cd mod n = (me mod n)d mod n
= med mod n
= m(ed mod z) mod n
= m1 mod n
= m
Security
8-7

8. RSA: another important property
The following property will be very useful later:
K (K (m)) = m B - +
K (K (m)) =
use public key first, followed by private key
use private key first, followed by public key
result is the same!
Security
8-8

9. K (K (m)) = m B - +
K (K (m)) =
Why ?
follows directly from modular arithmetic:
(me mod n)d mod n = med mod n
= mde mod n
= (md mod n)e mod n
Security
8-9

10. Why is RSA secure?
suppose you know Bob’s public key (n,e). How hard is it to determine d?
essentially need to find factors of n without knowing the two factors p and q
fact: factoring a big number is hard
Security
8-10

11. Digital signatures
cryptographic technique analogous to hand-written signatures:
sender (Bob) digitally signs document, establishing he is document owner/creator.
verifiable, nonforgeable: recipient (Alice) can prove to someone that Bob, and no one else (including Alice), must have signed document
Security
8-11

12. Bob’s message, m, signed (encrypted) with his private key
Digital signatures
simple digital signature for message m:
Bob signs m by encrypting with his private key KB, creating “signed” message, KB(m) - - K B - -
Bob’s message, m
Bob’s private
key
m,K
(m) B
Dear Alice
Oh, how I have missed you. I think of you all the time! …(blah blah blah)
Bob
Bob’s message, m, signed (encrypted) with his private key
Public key
encryption
algorithm
Security
8-12

13. Digital signatures -
suppose Alice receives msg m, with signature: m, KB(m)
Alice verifies m signed by Bob by applying Bob’s public key KB to KB(m) then checks KB(KB(m) ) = m.
If KB(KB(m) ) = m, whoever signed m must have used Bob’s private key. + - + - + -
Alice thus verifies that:
Bob signed m
no one else signed m
Bob signed m and not m‘
non-repudiation:
Alice can take m, and signature KB(m) to court and prove that Bob signed m -
Security
8-13

14. Digital signature = signed message digest
Bob sends digitally signed message:
Alice verifies signature, integrity of digitally signed message:
large
message m
H: Hash
function
KB(H(m)) -
encrypted
msg digest
H(m)
digital
signature
(encrypt)
Bob’s
private
key
large
message m K B -
Bob’s
public
key
digital
signature
(decrypt) K B +
KB(H(m)) -
encrypted
msg digest
H: Hash
function +
H(m)
H(m)
equal ?
Security
8-14

15. Certification authorities
certification authority (CA): binds public key to particular entity, E.
E (person, router) registers its public key with CA.
E provides “proof of identity” to CA.
CA creates certificate binding E to its public key.
certificate containing E’s public key digitally signed by CA – CA says “this is E’s public key”
digital
signature
(encrypt) K B +
Bob’s
public
key K B + CA
private
key
certificate for Bob’s public key, signed by CA -
Bob’s
identifying information K CA
Security
8-15

16. Certification authorities
when Alice wants Bob’s public key:
gets Bob’s certificate (Bob or elsewhere).
apply CA’s public key to Bob’s certificate, get Bob’s public key K B +
digital
signature
(decrypt)
Bob’s
public
key K B + CA
public
key + K CA
Security
8-16

17. Secure e-mail . - Alice wants to send confidential e-mail, m, to Bob.
KS( ) .
KB( ) + -
KS(m )
KB(KS ) m KS KB
Internet
Alice:
generates random symmetric private key, KS
encrypts message with KS (for efficiency)
also encrypts KS with Bob’s public key
sends both KS(m) and KB(KS) to Bob
Security
8-17

18. Secure e-mail . - Alice wants to send confidential e-mail, m, to Bob.
KS( ) .
KB( ) + -
KS(m )
KB(KS ) m KS KB
Internet
Bob:
uses his private key to decrypt and recover KS
uses KS to decrypt KS(m) to recover m
Security
8-18

19. Secure e-mail (continued)
Alice wants to provide sender authentication message integrity
H( ) .
KA( ) - +
H(m )
KA(H(m)) m KA
Internet
compare
Alice digitally signs message
sends both message (in the clear) and digital signature
Security
8-19

20. Secure e-mail (continued)
Alice wants to provide secrecy, sender authentication, message integrity.
H( ) .
KA( ) - +
KA(H(m)) m KA
KS( )
KB( )
KB(KS ) KS KB
Internet
Alice uses three keys: her private key, Bob’s public key, newly created symmetric key
Security
8-20

21. SSL: Secure Sockets Layer
widely deployed security protocol
supported by almost all browsers, web servers
https
billions $/year over SSL
mechanisms: [Woo 1994], implementation: Netscape
variation -TLS: transport layer security, RFC 2246
provides
confidentiality
integrity
authentication
original goals:
Web e-commerce transactions
encryption (especially credit-card numbers)
Web-server authentication
optional client authentication
minimum hassle in doing business with new merchant
available to all TCP applications
secure socket interface
Security
8-21

22. SSL and TCP/IP
Application
TCP IP
normal application
Application
SSL
TCP IP
application with SSL
SSL provides application programming interface (API) to applications
C and Java SSL libraries/classes readily available
Security
8-22

23. Could do something like PGP:KA -
H( ) .
KA( ) . -
KA(H(m)) - m KS
KS( ) . + + m
Internet
KB( ) . + KS
KB(KS ) + KB +
but want to send byte streams & interactive data
want set of secret keys for entire connection
want certificate exchange as part of protocol: handshake phase
Security
8-23

24. Toy SSL: a simple secure channel
handshake: Alice and Bob use their certificates, private keys to authenticate each other and exchange shared secret
key derivation: Alice and Bob use shared secret to derive set of keys
data transfer: data to be transferred is broken up into series of records
connection closure: special messages to securely close connection
Security
8-24

25. Toy: a simple handshake
hello
public key certificate
KB+(MS) = EMS
MS: master secret
EMS: encrypted master secret
Security
8-25

26. Toy: key derivation
considered bad to use same key for more than one cryptographic operation
use different keys for message authentication code (MAC) and encryption
four keys:
Kc = encryption key for data sent from client to server
Mc = MAC key for data sent from client to server
Ks = encryption key for data sent from server to client
Ms = MAC key for data sent from server to client
keys derived from key derivation function (KDF)
takes master secret and (possibly) some additional random data and creates the keys
Security
8-26

27. Toy: data records
why not encrypt data in constant stream as we write it to TCP?
where would we put the MAC? If at end, no message integrity until all data processed.
e.g., with instant messaging, how can we do integrity check over all bytes sent before displaying?
instead, break stream in series of records
each record carries a MAC
receiver can act on each record as it arrives
issue: in record, receiver needs to distinguish MAC from data
want to use variable-length records
length
data
MAC
Security
8-27

28. Toy: sequence numbers
problem: attacker can capture and replay record or re-order records
solution: put sequence number into MAC:
MAC = MAC(Mx, sequence||data)
note: no sequence number field
problem: attacker could replay all records
solution: use nonce
Security
8-28

29. Toy: control information
problem: truncation attack:
attacker forges TCP connection close segment
one or both sides thinks there is less data than there actually is.
solution: record types, with one type for closure
type 0 for data; type 1 for closure
MAC = MAC(Mx, sequence||type||data)
length
type
data
MAC
Security
8-29

30. Toy SSL: summary hello certificate, nonce KB+(MS) = EMS
type 0, seq 1, data
type 0, seq 2, data
type 0, seq 3, data
type 1, seq 4, close
type 1, seq 2, close
bob.com
encrypted
Security
8-30

31. Toy SSL isn’t complete how long are fields?
which encryption protocols?
want negotiation?
allow client and server to support different encryption algorithms
allow client and server to choose together specific algorithm before data transfer
Security
8-31

32. SSL cipher suite (super old, DONT USE!)
common SSL symmetric ciphers
DES – Data Encryption Standard: block
3DES – Triple strength: block
RC2 – Rivest Cipher 2: block
RC4 – Rivest Cipher 4: stream
SSL Public key encryption
RSA
cipher suite
public-key algorithm
symmetric encryption algorithm
MAC algorithm
SSL supports several cipher suites
negotiation: client, server agree on cipher suite
client offers choice
server picks one
NOTE: RC2, RC4 broken, DES is not secure anymore!
Security
8-32

33. Real SSL: handshake (1) Purpose server authentication
negotiation: agree on crypto algorithms
establish keys
client authentication (optional)
Security
8-33

34. Real SSL: handshake (2)
client sends list of algorithms it supports, along with client nonce
server chooses algorithms from list; sends back: choice + certificate + server nonce
client verifies certificate, extracts server’s public key, generates pre_master_secret, encrypts with server’s public key, sends to server
client and server independently compute encryption and MAC keys from pre_master_secret and nonces
client sends a MAC of all the handshake messages
server sends a MAC of all the handshake messages
Security
8-34

35. Real SSL: handshaking (3)
last 2 steps protect handshake from tampering
client typically offers range of algorithms, some strong, some weak
man-in-the middle could delete stronger algorithms from list
last 2 steps prevent this
last two messages are encrypted
Security
8-35

36. Real SSL: handshaking (4)
why two random nonces?
suppose Trudy sniffs all messages between Alice & Bob
next day, Trudy sets up TCP connection with Bob, sends exact same sequence of records
Bob (Amazon) thinks Alice made two separate orders for the same thing
solution: Bob sends different random nonce for each connection. This causes encryption keys to be different on the two days
Trudy’s messages will fail Bob’s integrity check
Security
8-36

37. SSL record protocol record header: content type; version; length
data
fragment
MAC
encrypted
data and MAC
record
header
record header: content type; version; length
MAC: includes sequence number, MAC key Mx
fragment: each SSL fragment 214 bytes (~16 Kbytes)
Security
8-37

38. SSL record format data and MAC encrypted (symmetric algorithm) content
type
SSL version
length
MAC
data
1 byte
2 bytes
3 bytes
data and MAC encrypted (symmetric algorithm)
Security
8-38

39. Real SSL connection everything henceforth is encrypted TCP FIN follows
handshake: ClientHello
handshake: ServerHello
handshake: Certificate
handshake: ServerHelloDone
handshake: ClientKeyExchange
ChangeCipherSpec
handshake: Finished
application_data
Alert: warning, close_notify
Real SSL connection
everything
henceforth
is encrypted
TCP FIN follows
Security
8-39

40. Key derivation
client nonce, server nonce, and pre-master secret input into pseudo random-number generator.
produces master secret
master secret and new nonces input into another random-number generator: “key block”
because of resumption: TBD
key block sliced and diced:
client MAC key
server MAC key
client encryption key
server encryption key
client initialization vector (IV)
server initialization vector (IV)
Security
8-40