 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
 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
 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
 Informal
Formal Intruder
Protocol
Protocol Model
Description

RFC
(request for
comments) Analysis
Find error Tool
 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
80
70
60
50
40
Page count
30
20
10
0
SSL 2.0 SSL 3.0 TLS 1.0
 Informal
Formal Intruder
Protocol
Protocol Model
Description

Mur code
RFC

Analysis
Find error Tool
 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
 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
 ClientHello

ServerHello,
[Certificate],
[ServerKeyExchange],
[CertificateRequest],
ServerHelloDone

C [Certificate],
ClientKeyExchange,
S
[CertificateVerify]

switch to negotiated cipher

Finished

switch to negotiated cipher

Finished
 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
 Version, Crypto choice, nonce

Version, Choice, nonce,

signed certificate
containing server’s
public key Ks

C Secret key K
encrypted with
S
server’s key Ks

switch to negotiated cipher

hash of sequence of messages

hash of sequence of messages

 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)
Known public signature verification key Ka
Certificate
Certificate
Sign(Ka-1, Ks)
Ka Authority Ka, Ka-1
Ks

Client Sign(Ka-1, Ks) Server

Server certificate can be verified by any client that has CA verification key Ka
Certificate authority is “off line”
 Client, server communicate

 Compare hash of all messages

 Compute hash(hi,hello,howareyou?) locally
 Exchange hash values under encryption
 Abort if intervention detected

Hi
Hello
Client Server
How are you?
ClientHello CS C, VerC, SuiteC, NC

ServerHello SC VerS, SuiteS, NS, signCA{ S, KS }

ClientVerify CS signCA{ C, VC }

{ VerC, SecretC } KS
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))
Master(NC, NS, SecretC)
}

ClientFinished C  S { Hash( Master(NC, NS, SecretC) + Pad2 +

Hash( Msgs
Master(N + C + Master(NC, NS, SecretC) + Pad1))
C, NS, SecretC)
 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.
 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
 ClientHello

Client announces (in plaintext):

• Protocol version she is running
• Cryptographic algorithms she
supports

C S
 Highest version of the
struct { protocol supported by the
client

ProtocolVersion client_version;
Session id (if the client
Random random; wants tosession)
resume an old

SessionID session_id; Cryptographic algorithms

supported by the client
(e.g., RSA or Diffie-Hellman)
CipherSuite cipher_suites;
CompressionMethod
compression_methods;
} ClientHello
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;
 C, Versionc, suitec, Nc

ServerHello

Server responds (in plaintext) with:

C
• Highest protocol version both
client &
server support
S
• Strongest cryptographic suite
selected
from those offered by the client
ruleset i: ServerId do
choose l: serNet do
rule “Server receives ServerHello (new session)"
ser[i].clients[0].state = M_CLIENT_HELLO &
serNet[l].dest = i &
serNet[l].session = 0
==>
var
inM: Message; -- incoming message
outM: Message; -- outgoing message
begin
inM := serNet[l]; -- receive message
if inM.mType = M_CLIENT_HELLO then
outM.source := i;
outM.dest := inM.source;
outM.session := freshSessionId();
outM.mType := M_SERVER_HELLO;
outM.version := ser[i].version;
outM.suite := ser[i].suite;
outM.random := freshNonce();
multisetadd (outM, serNet);
ser[i].state := M_SERVER_SEND_KEY;
end; end; end;
 C, Versionc, suitec, Nc

Versions, suites, Ns,

ServerKeyExchange

C Server responds with his public-key

certificate containing either his RSA,
S
or
his Diffie-Hellman public key
(depending on chosen crypto suite)
 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
 C, Versionc, suitec, Nc

Versions, suites, Ns,

sigca(S,Ks),
“ServerHelloDone”

C ClientKeyExchange
S
Client generates some secret key
material
and sends it to the server encrypted
with
the server’s public key
struct { Let’s model this as
{Secret } c Ks

select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman:
ClientDiffieHellmanPublic;
} exchange_keys
} ClientKeyExchange

struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret
 C, Versionc, suitec, Nc

Versions, suites, Ns,

sigca(S,Ks),
“ServerHelloDone”

C {Secretc}Ks
S
If the protocol is correct, C and S share
some secret key material secretc at this point

switch to key derived switch to key derived

from secretc from secretc
Mur rules define a finite-state machine for each protocol participant

Client state Server state

ClientHell
M_SLEEP o M_CLIENT_HELLO

ServerHell
o
M_SERVER_HELLO M_SEND_KEY

ServerKeyExchang
e
M_SERVER_KEY M_CLIENT_KEY

M_SEND_KEY M_DONE
ClientKeyExchange
 Informal
Formal Intruder
Protocol
Protocol Model
Description

Mur code Mur code,

RFC similar for
all
protocols
Analysis
Find error Tool
 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;
 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;
 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;
 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
 Informal
Formal Intruder
Protocol
Protocol Model
Description

Mur code Mur code,

RFC similar for
all
protocols
Analysis
Find error Tool

Specify security
conditions and run
Mur
 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;
 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;
 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;
  Mur rules for protocol
participants and the
intruder define a
nondeterministic state
transition graph
...
...
 Mur will exhaustively
enumerate all graph nodes
 Mur will verify whether
specified security conditions
Correctness
hold in every reachable
condition violated node
 If not, the path to the
 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
 C, Versionc=3.0, suitec

Versions=3.0, suites
sigca(S,Ks),
“ServerHelloDone”

C {Secretc}Ks
S
If the protocol is correct, C and S share
some secret key material secretc at this point

switch to key derived switch to key derived

from secretc from secretc
 C, Versionc=2.0, suitec

Server is fooled into thinking Versions=2.0, suites

he is communicating with a
client who supports only SSL sigca(S,Ks),
2.0 “ServerHelloDone”

C {Secretc}Ks
S

C and S end up communicating using SSL 2.0

(weaker earlier version of the protocol)
struct { Model this as {Version , c
Secret } c Ks
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman:
ClientDiffieHellmanPublic;
} exchange_keys
} ClientKeyExchange
This piece matters! Need to add it to the model.
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret
 C, Versionc=3.0, suitec

Versions=3.0, suites
sigca(S,Ks),
Prevents “ServerHelloDone”
version

C
rollback attack

{Versionc,Secretc}Ks
Add rule to check that received
version is equal to version in
ClientHello
S
If the protocol is correct, C and S share
some secret key material secretc at this point

switch to key derived switch to key derived

from secretc from secretc
 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
 VerC, SteC VerC, SteC

C VerS, SteS, KI I VerS, SteS, KS S

K
{ SecretC } I { SecretC } S
K

 Intruder in the middle

 Replaces server key by intruder’s key
 Intercepts secret from client
 Simulates client to server, server to client
 VersionC, SuiteC

C VersionS, SuiteS, signCA{ S, KS } S

K
{ SecretC } S

 Defeats previous attack

 But client is not authenticated to the server ...
 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
 Nonces to avoid replay
C, Versionc, suitec , Nc

Versions, suites, Ns
Server public key in
certificate signed by sigca(S,Ks),
CA “ServerHelloDone”

C {Versionc,Secretc}Ks S
switch to negotiated cipher

Hash of sequence of messages

Hash of sequence of messages

Hash messages to
confirm consistent
views
 … SuiteC …

… SuiteS …
…

C Switch to negotiated cipher S

Finished Finished

data data
 o d ifCy…
… Suite
M
d i
S y
… Suite f…
M…o

C Switch to negotiated cipher S

X X
Finished Finished

data data
 SessionId, VerC= 3.0, NC, ...

VerS= 3.0, NS, ...

C Finished Finished S

data data
 SessionId, VerC= 2.0, NC, ...

VerS= 2.0, NS, ...

C
X
Finished
{ NS } SecretKey
X
Finished
{ NC } SecretKey
S

data data

SSL 2.0 Finished messages do not include version numbers or cryptosuites

 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
 Mur by default, but we’ll describe many other
tools
 Play with Mur 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
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.
 Mur analysis of SSL 3.0 (similar to this lecture)
 Actual Mur 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