2. Course organization (subject to revision)
ļµJanuary
ā¢ Two written homeworks: first due next Thursday (9 days)
ā¢ Lectures on case studies (protocols and tools)
ā¢ Choose your project: weāll start giving examples Thursday
ļµFebruary
ā¢ Project presentation #1: describe your system (5-10 min)
ā¢ Lectures on additional approaches
ā¢ Project presentation #2: describe security properties
ļµMarch
ā¢ Project presentation #3: results of study
Grading: 20% homework, 30% project presentations, 50% project results and final presentation
3. Overview
ļµIntroduction to the SSL / TLS protocol
ā¢ Widely deployed, āreal-worldā security protocol
ļµProtocol analysis case study
ā¢ Start with the RFC describing the protocol
ā¢ Create an abstract model and code it up in Murj
ā¢ Specify security properties
ā¢ Run Murj to check whether security properties are
satisfied
ļµThis lecture is a compressed version of what you
would do if SSL were your project!
4. What is SSL / TLS?
ļµTransport Layer Security protocol, ver 1.0
ā¢ De facto standard for Internet security
ā¢ āThe primary goal of the TLS protocol is to provide
privacy and data integrity between two communicating
applicationsā
ā¢ In practice, used to protect information transmitted
between browsers and Web servers
ļµBased on Secure Sockets Layers protocol, ver 3.0
ā¢ Same protocol design, different algorithms
ļµDeployed in nearly every web browser
6. History of the Protocol
ļµSSL 1.0
ā¢ Internal Netscape design, early 1994?
ā¢ Lost in the mists of time
ļµSSL 2.0
ā¢ Published by Netscape, November 1994
ā¢ Several problems (next slide)
ļµSSL 3.0
ā¢ Designed by Netscape and Paul Kocher, November 1996
ļµTLS 1.0
ā¢ Internet standard based on SSL 3.0, January 1999
ā¢ Not interoperable with SSL 3.0
7. SSL 2.0 Vulnerabilities
ļµShort key length
ā¢ In export-weakened modes, SSL 2.0 unnecessarily weakens the
authentication keys to 40 bits.
ļµWeak MAC construction
ļµMessage integrity vulnerability
ā¢ SSL 2.0 feeds padding bytes into the MAC in block cipher
modes, but leaves the padding-length unauthenticated, may
allow active attackers to delete bytes from the end of messages
ļµCiphersuite rollback attack
ā¢ An active attacker may edits the list of ciphersuite preferences
in the hello messages to invisibly force both endpoints to use a
weaker form of encryption
ā¢ āLeast common denominator" security under active attack
8. Letās get going with SSL/TLS ā¦
Intruder
Model
Analysis
Tool
Formal
Protocol
Informal
Protocol
Description
Find error
RFC
(request for
comments)
9. Request for Comments
ļµNetwork protocols are defined in an RFC
ļµTLS version 1.0 is described in RFC 2246
ļµIntended to be a self-contained definition of the
protocol
ā¢ Describes the protocol in sufficient detail for readers
who will be implementing it and those who will be
doing protocol analysis (thatās you!)
ā¢ Mixture of informal prose and pseudo-code
ļµRead some RFCs to get a flavor of what protocols
look like when they emerge from the committee
11. From RFC to Murj Model
Intruder
Model
Analysis
Tool
Formal
Protocol
Informal
Protocol
Description
Find error
Murj code
RFC
12. TLS Basics
ļµTLS consists of two protocols
ļµHandshake protocol
ā¢ Use public-key cryptography to establish a shared
secret key between the client and the server
ļµRecord protocol
ā¢ Use the secret key established in the handshake
protocol to protect communication between the client
and the server
ļµWe will focus on the handshake protocol
13. TLS Handshake Protocol
ļµTwo parties: client and server
ļµNegotiate version of the protocol and the set of
cryptographic algorithms to be used
ā¢ Interoperability between different implementations of
the protocol
ļµAuthenticate client and server (optional)
ā¢ Use digital certificates to learn each otherās public keys
and verify each otherās identity
ļµUse public keys to establish a shared secret
15. ļµEncryption scheme
ā¢ functions to encrypt, decrypt data
ā¢ key generation algorithm
ļµSecret key vs. public key
ā¢ Public key: publishing key does not reveal key-1
ā¢ Secret key: more efficient, generally key = key-1
ļµHash function, MAC
ā¢ Map input to short hash; ideally, no collisions
ā¢ MAC (keyed hash) used for message integrity
ļµSignature scheme
ā¢ Functions to sign data, verify signature
Recall: Basic Cryptographic Concepts
16. Use of cryptography
C
Version, Crypto choice, nonce
Version, Choice, nonce,
signed certificate
containing serverās
public key Ks
S
Secret key K
encrypted with
serverās key Ks
hash of sequence of messages
hash of sequence of messages
switch to negotiated cipher
17. SSL/TLS Cryptography Summary
ļµPublic-key encryption
ā¢ Key chosen secretly (handshake protocol)
ā¢ Key material sent encrypted with public key
ļµSymmetric encryption
ā¢ Shared (secret) key encryption of data packets
ļµSignature-based authentication
ā¢ Client can check signed server certificate
ā¢ And vice-versa, in principal
ļµHash for integrity
ā¢ Client, server check hash of sequence of messages
ā¢ MAC used in data packets (record protocol)
18. Public-Key Infrastructure
Certificate
Authority Ka, Ka-1
Client Server
Known public signature verification key Ka
Sign(Ka-1, Ks)
Certificate
Sign(Ka-1, Ks)
Ks
Server certificate can be verified by any client that has CA verification key Ka
Certificate authority is āoff lineā
Ka
19. Another general idea in SSL
ļµClient, server communicate
ļµCompare hash of all messages
ā¢ Compute hash(hi,hello,howareyou?) locally
ā¢ Exchange hash values under encryption
ļµAbort if intervention detected
Client Server
Hi
Hello
How are you?
20. SSL/TLS in more detail ā¦
ClientHello C ļ® S C, VerC, SuiteC, NC
ServerHello S ļ® C VerS, SuiteS, NS, signCA{ S, KS }
ClientVerify C ļ® S signCA{ C, VC }
{ VerC, SecretC }
signC { Hash( Master(NC, NS, SecretC) + Pad2 +
Hash(Msgs + C + Master(NC, NS, SecretC) + Pad1)) }
-------- Change to negotiated cipher --------------------------------------------------------------------
ServerFinished S ļ® C { Hash( Master(NC, NS, SecretC) + Pad2 +
Hash( Msgs + S + Master(NC, NS, SecretC) + Pad1))
}
ClientFinished C ļ® S { Hash( Master(NC, NS, SecretC) + Pad2 +
Hash( Msgs + C + Master(NC, NS, SecretC) + Pad1))
}
KS
Master(NC, NS, SecretC)
Master(NC, NS, SecretC)
21. Abbreviated Handshake
ļµThe handshake protocol may be executed in an
abbreviated form to resume a previously
established session
ā¢ No authentication, key material not exchanged
ā¢ Session resumed from an old state
ļµFor complete analysis, have to model both full
and abbreviated handshake protocol
ā¢ This is a common situation: many protocols have
several branches, subprotocols for error handling, etc.
22. Rational Reconstruction
ļµ Begin with simple, intuitive protocol
ā¢ Ignore client authentication
ā¢ Ignore verification messages at the end of the
handshake protocol
ā¢ Model only essential parts of messages (e.g., ignore
padding)
ļµExecute the model checker and find a bug
ļµAdd a piece of TLS to fix the bug and repeat
ā¢ Better understand the design of the protocol
23. Protocol Step by Step: ClientHello
C
ClientHello
S
Client announces (in plaintext):
ā¢ Protocol version she is running
ā¢ Cryptographic algorithms she supports
24. struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites;
CompressionMethod compression_methods;
} ClientHello
ClientHello (RFC)
Highest version of the protocol
supported by the client
Session id (if the client wants to
resume an old session)
Cryptographic algorithms
supported by the client (e.g.,
RSA or Diffie-Hellman)
25. ClientHello (Murj)
ruleset i: ClientId do
ruleset j: ServerId do
rule "Client sends ClientHello to server (new session)"
cli[i].state = M_SLEEP &
cli[i].resumeSession = false
==>
var
outM: Message; -- outgoing message
begin
outM.source := i;
outM.dest := j;
outM.session := 0;
outM.mType := M_CLIENT_HELLO;
outM.version := cli[i].version;
outM.suite := cli[i].suite;
outM.random := freshNonce();
multisetadd (outM, cliNet);
cli[i].state := M_SERVER_HELLO;
end; end; end;
26. ServerHello
C
C, Versionc, suitec, Nc
ServerHello
S
Server responds (in plaintext) with:
ā¢ Highest protocol version both client &
server support
ā¢ Strongest cryptographic suite selected
from those offered by the client
29. āAbstractā Cryptography
ļµWe will use abstract data types to model
cryptographic operations
ā¢ Assumes that cryptography is perfect
ā¢ No details of the actual cryptographic schemes
ā¢ Ignores bit length of keys, random numbers, etc.
ļµSimple notation for encryption, signatures, hashes
ā¢ {M}k is message M encrypted with key k
ā¢ sigk(M) is message M digitally signed with key k
ā¢ hash(M) for the result of hashing message M with a
cryptographically strong hash function
31. struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys
} ClientKeyExchange
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret
ClientKeyExchange (RFC)
Letās model this as {Secretc}Ks
32. āCoreā SSL
C
Versions, suites, Ns,
sigca(S,Ks),
āServerHelloDoneā
S
C, Versionc, suitec, Nc
{Secretc}Ks
switch to key derived
from secretc
If the protocol is correct, C and S share
some secret key material secretc at this point
switch to key derived
from secretc
33. Participants as Finite-State Machines
M_SLEEP
ClientHello
Murj rules define a finite-state machine for each protocol participant
Client state
M_SERVER_HELLO
M_SERVER_KEY
M_SEND_KEY
M_CLIENT_HELLO
Server state
M_SEND_KEY
M_CLIENT_KEY
M_DONE
ServerHello
ServerKeyExchange
ClientKeyExchange
35. Intruder Can Intercept
ļµStore a message from the network in the data
structure modeling intruderās āknowledgeā
ruleset i: IntruderId do
choose l: cliNet do
rule "Intruder intercepts client's message"
cliNet[l].fromIntruder = false
==>
begin
alias msg: cliNet[l] do -- message from the net
ā¦
alias known: int[i].messages do
if multisetcount(m: known,
msgEqual(known[m], msg)) = 0 then
multisetadd(msg, known);
end;
end;
end;
36. Intruder Can Decrypt if Knows Key
ļµIf the key is stored in the data structure modeling
intruderās āknowledgeā, then read message
ruleset i: IntruderId do
choose l: cliNet do
rule "Intruder intercepts client's message"
cliNet[l].fromIntruder = false
==>
begin
alias msg: cliNet[l] do -- message from the net
ā¦
if msg.mType = M_CLIENT_KEY_EXCHANGE then
if keyEqual(msg.encKey, int[i].publicKey.key) then
alias sKeys: int[i].secretKeys do
if multisetcount(s: sKeys,
keyEqual(sKeys[s], msg.secretKey)) = 0 then
multisetadd(msg.secretKey, sKeys);
end;
end;
end;
37. Intruder Can Create New Messages
ļµAssemble pieces stored in the intruderās
āknowledgeā to form a message of the right format
ruleset i: IntruderId do
ruleset d: ClientId do
ruleset s: ValidSessionId do
choose n: int[i].nonces do
ruleset version: Versions do
rule "Intruder generates fake ServerHello"
cli[d].state = M_SERVER_HELLO
==>
var
outM: Message; -- outgoing message
begin
outM.source := i; outM.dest := d; outM.session := s;
outM.mType := M_SERVER_HELLO;
outM.version := version;
outM.random := int[i].nonces[n];
multisetadd (outM, cliNet);
end; end; end; end;
38. Intruder Model and Cryptography
ļµThere is no actual cryptography in our model
ā¢ Messages are marked as āencryptedā or āsignedā, and
the intruder rules respect these markers
ļµOur assumption that cryptography is perfect is
reflected in the absence of certain intruder rules
ā¢ There is no rule for creating a digital signature with a
key that is not known to the intruder
ā¢ There is no rule for reading the contents of a message
which is marked as āencryptedā with a certain key,
when this key is not known to the intruder
ā¢ There is no rule for reading the contents of a āhashedā
message
40. Secrecy
ļµIntruder should not be able to learn the secret
generated by the client
ruleset i: ClientId do
ruleset j: IntruderId do
rule "Intruder has learned a client's secret"
cli[i].state = M_DONE &
multisetcount(s: int[j].secretKeys,
keyEqual(int[j].secretKeys[s], cli[i].secretKey)) > 0
==>
begin
error "Intruder has learned a client's secret"
end;
end;
end;
41. Shared Secret Consistency
ļµAfter the protocol has finished, client and server
should agree on their shared secret
ruleset i: ServerId do
ruleset s: SessionId do
rule "Server's shared secret is not the same as its client's"
ismember(ser[i].clients[s].client, ClientId) &
ser[i].clients[s].state = M_DONE &
cli[ser[i].clients[s].client].state = M_DONE &
!keyEqual(cli[ser[i].clients[s].client].secretKey,
ser[i].clients[s].secretKey)
==>
begin
error "S's secret is not the same as C's"
end;
end;
end;
42. Version and Crypto Suite Consistency
ļµClient and server should be running the highest
version of the protocol they both support
ruleset i: ServerId do
ruleset s: SessionId do
rule "Server has not learned the client's version or suite correctly"
!ismember(ser[i].clients[s].client, IntruderId) &
ser[i].clients[s].state = M_DONE &
cli[ser[i].clients[s].client].state = M_DONE &
(ser[i].clients[s].clientVersion != MaxVersion |
ser[i].clients[s].clientSuite.text != 0)
==>
begin
error "Server has not learned the client's version or suite correctly"
end;
end;
end;
43. Finite-State Verification
...
...
ļ¬ Murj rules for protocol
participants and the intruder
define a nondeterministic state
transition graph
ļ¬ Murj will exhaustively
enumerate all graph nodes
ļ¬ Murj will verify whether
specified security conditions
hold in every reachable node
ļ¬ If not, the path to the violating
node will describe the attack
Correctness
condition violated
44. When Does Murj Find a Violation?
ļµBad abstraction
ā¢ Removed too much detail from the protocol when
constructing the abstract model
ā¢ Add the piece that fixes the bug and repeat
ā¢ This is part of the rational reconstruction process
ļµGenuine attack
ā¢ Yay! Hooray!
ā¢ Attacks found by formal analysis are usually quite
strong: independent of specific cryptographic
schemes, OS implementation, etc.
ā¢ Test an implementation of the protocol, if available
45. āBasicā SSL 3.0
C
Versions=3.0, suites
sigca(S,Ks),
āServerHelloDoneā
S
C, Versionc=3.0, suitec
{Secretc}Ks
switch to key derived
from secretc
If the protocol is correct, C and S share
some secret key material secretc at this point
switch to key derived
from secretc
46. Version Consistency Fails!
C
Versions=2.0, suites
sigca(S,Ks),
āServerHelloDoneā
S
C, Versionc=2.0, suitec
{Secretc}Ks
C and S end up communicating using SSL 2.0
(weaker earlier version of the protocol)
Server is fooled into thinking he
is communicating with a client
who supports only SSL 2.0
47. struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys
} ClientKeyExchange
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret
A Case of Bad Abstraction
Model this as {Versionc, Secretc}Ks
This piece matters! Need to add it to the model.
48. Better ābasicā SSL
C
Versions=3.0, suites
sigca(S,Ks),
āServerHelloDoneā
S
C, Versionc=3.0, suitec
{Versionc,Secretc}Ks
switch to key derived
from secretc
If the protocol is correct, C and S share
some secret key material secretc at this point
switch to key derived
from secretc
Prevents version
rollback attack
Add rule to check that received version
is equal to version in ClientHello
49. Summary of Incremental Protocols
ļµA = Basic protocol
ļµB = A + version consistency check
ļµD = B + certificates for both public keys
ā Authentication for client + Authentication for server
ļµE = D + verification (Finished) messages
ā Prevention of version and crypto suite attacks
ļµF = E + nonces
ā Prevention of replay attacks
ļµG = āCorrectā subset of SSL
ā Additional crypto considerations (black art) give SSL 3.0
50. VerC, SteC
VerS, SteS, KI
{ SecretC }
C S
KS
Attack on Protocol B
ļµIntruder in the middle
ā¢ Replaces server key by intruderās key
ā¢ Intercepts secret from client
ā¢ Simulates client to server, server to client
I
VerC, SteC
VerS, SteS, KS
{ SecretC }
KI
51. Solution: Certificate Authority
ļµDefeats previous attack
ā¢ But client is not authenticated to the server ...
VersionC, SuiteC
VersionS, SuiteS, signCA{ S, KS }
{ SecretC }
C S
KS
52. Replay Attacks
ļµNetwork eavesdropper can record messages
ļµIf protocol is deterministic, then
ā¢ Eavesdropper can replay client messages to server, OR
ā¢ Eavesdropper can replay server message to client
ļµThis is a problem
ā¢ In each session, each party should be guaranteed that the other
is a live participant in the session
ļµSolution
ā¢ Each run of each protocol should contain at least one new value
generated by each party, included in messages, and checked
before session is considered done
53. āCoreā SSL Handshake with server auth (only)
C
Versions, suites, Ns
sigca(S,Ks),
āServerHelloDoneā
S
C, Versionc, suitec , Nc
{Versionc,Secretc}Ks
Hash of sequence of messages
Hash of sequence of messages
switch to negotiated cipher
Server public key in
certificate signed by CA
Nonces to avoid replay
Hash messages to confirm
consistent views
54. Anomaly (Protocol F)
C S
ā¦ SuiteC ā¦
ā¦ SuiteS ā¦
ā¦
Switch to negotiated cipher
Finished Finished
data data
55. Anomaly (Protocol F)
C S
ā¦ SuiteC ā¦
ā¦ SuiteS ā¦
ā¦
Switch to negotiated cipher
Finished Finished
data data
X X
57. Version Rollback Attack
C S
SessionId, VerC= 2.0, NC, ...
Finished Finished
data data
VerS= 2.0, NS, ...
X
X
{ NS } SecretKey { NC } SecretKey
SSL 2.0 Finished messages do not include version numbers or cryptosuites
58. Basic Pattern for Doing Your Project
ļµRead and understand protocol specification
ā¢ Typically an RFC or a research paper
ā¢ Weāll put a few on the website: take a look!
ļµChoose a tool
ā¢ Murj by default, but weāll describe many other tools
ā¢ Play with Murj now to get some experience
(installing, running simple models, etc.)
ļµStart with a simple (possibly flawed) model
ā¢ Rational reconstruction is a good way to go
ļµGive careful thought to security conditions
59. Background Reading on SSL 3.0
Optional, for deeper understanding of SSL / TLS
ļµ D. Wagner and B. Schneier. āAnalysis of the SSL 3.0 protocol.ā
USENIX Electronic Commerce ā96.
ā¢ Nice study of an early proposal for SSL 3.0
ļµ J.C. Mitchell, V. Shmatikov, U. Stern. āFinite-State Analysis of SSL
3.0ā. USENIX Security ā98.
ā¢ Murj analysis of SSL 3.0 (similar to this lecture)
ā¢ Actual Murj model available
ļµ D. Bleichenbacher. āChosen Ciphertext Attacks against Protocols
Based on RSA Encryption Standard PKCS #1ā. CRYPTO ā98.
ā¢ Cryptography is not perfect: this paper breaks SSL 3.0 by directly
attacking underlying implementation of RSA