Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
Lecture 13
Transport Layer Security/Secure Socket Layer (TLS/SSL)
(Chapter 9 in KPS)
SSL:SecureSocketsLayervwidely deployed security
protocol§ supported by almost all
browsers, web servers§ the “s” in https§ billions $/year over SSL
vmechanisms: [Woo 1994], implementation: Netscape
vvariation -TLS: transport layer security, RFC 2246
vprovides§ confidentiality§ integrity§ authentication
voriginal goals:§ Web e-commerce
transactions § encryption (especially
credit-card numbers)§ Web-server authentication§ optional client
authentication§ minimum hassle in doing
business with new merchant
vavailable to all TCP applications§ secure socket interface
SSL and TCP/IP
Application
TCP
IP
normal application
Application
SSL
TCP
IP
application with SSL
v SSL provides application programming interface (API) to applications
v C and Java SSL libraries/classes readily available
Could do something like PGP:
v but want to send byte streams & interactive datav want set of secret keys for entire connectionv want certificate exchange as part of protocol: handshake phase
H( ). KA( ).+
KA(H(m))m
KA
m
KS( ).
KB( ).+
KB(KS )
KS
KB
Internet
KS
- Pretty Good Privacy (PGP) used to secure email- KA is Alice’s private key used to sign- KB is Bob’s public key used to encrypt to Bob a session key KS
Toy SSL: a Simple Secure Channel
v handshake: Alice and Bob use their certificates, private keys to authenticate each other and exchange a shared secret
v key derivation: Alice and Bob use shared secret to derive set of keys
v data transfer: data to be transferred is broken up into series of records
v connection closure: special messages to securely close connection
Toy: a Simple Handshake
MS: master secretEMS: encrypted master secret
Toy: Key Derivation
v considered bad to use same key for more than one cryptographic operation§ use different keys for message authentication code (MAC) and
encryption
v 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
v keys derived from key derivation function (KDF)§ takes master secret and (possibly) some additional random data
and creates the keys
Toy: Data Recordsv 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?v instead, break stream in series of records
§ each record carries a MAC§ receiver can act on each record as it arrives
v issue: in record, receiver needs to distinguish MAC from data§ want to use variable-length records
length data MAC
Toy: Sequence Numbers
v problem: attacker can capture and replay record or re-order records
v solution: put sequence number into MAC:§ MAC = MAC(Mx, sequence||data)§ note: no sequence number field, Mx = MAC key
v problem: attacker could replay all recordsv solution: use nonce
Toy: Control Information
v problem: truncation attack: § attacker forges TCP connection close segment§ one or both sides thinks there is less data than there
actually is
v solution: record types, with one type for closure§ type 0 for data; type 1 for closure
v MAC = MAC(Mx, sequence||type||data)
length type data MAC
Toy SSL: Summaryen
cryp
ted
bob.com
Toy SSL isn’t complete
v how long are fields?v which encryption algorithms to use?v want negotiation?
§ allow client and server to support different encryption algorithms
§ allow client and server to choose together specific algorithm before data transfer
SSL Cipher Suitev cipher suite
§ public-key algorithm§ symmetric encryption algorithm§ MAC algorithm
v SSL supports several cipher suites
v negotiation: client, server agree on cipher suite§ client offers choice§ server picks one
common SSL symmetric ciphers§ DES – Data Encryption
Standard: block§ 3DES – Triple strength: block§ RC2 – Rivest Cipher 2: block§ RC4 – Rivest Cipher 4:
streamSSL Public key encryption§ RSA
Real SSL: Handshake (1)
Purpose1. server authentication2. negotiation: agree on crypto algorithms3. establish keys4. client authentication (optional)
Real SSL: Handshake (2)1. client sends list of algorithms it supports, along with
client nonce2. server chooses algorithms from list; sends back:
choice + certificate + server nonce3. client verifies certificate, extracts server’s public
key, generates pre_master_secret, encrypts with server’s public key, sends to server
4. client and server independently compute encryption and MAC keys from pre_master_secret and nonces
5. client sends a MAC of all the handshake messages6. server sends a MAC of all the handshake messages
Real SSL: Handshake (3)
last 2 steps protect handshake from tamperingv client typically offers range of algorithms, some
strong, some weakv man-in-the middle could delete stronger algorithms
from listv last 2 steps prevent this
§ last two messages are encrypted
Real SSL: Handshake (4)
v why two random nonces? v suppose Trudy sniffs all messages between Alice
& Bobv 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
SSL Record Protocol
data
data fragment
data fragmentMAC MAC
encrypteddata and MAC
encrypteddata and MAC
recordheader
recordheader
record header: content type; version; length
MAC: includes sequence number, MAC key Mx
fragment: each SSL fragment 214 bytes (~16 Kbytes)
SSL Record Format
contenttype SSL version length
MAC
data
1 byte 2 bytes 3 bytes
data and MAC encrypted (symmetric algorithm)
Real SSLConnection
TCP FIN message follows
everythinghenceforth
is encrypted
Key Derivationv client nonce, server nonce, and pre-master secret input
into pseudo random-number generator (PRG).§ produces master secret
v master secret and new nonces input into another random-number generator: “key block”
v 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)