1. 08 Mai 2014!
Security Protocols: Modelling and Verification!
Prof. Indrumator - Cătălin Bîrjoveanu "
Duduman Bogdan Vlad!
1
TLS/SSL (Analysis)
Text
2. Overview
1. Introduction to the SSL / TLS protocol!
• Widely deployed, “real-world” security protocol!
• Well-understood, with detailed specifications!
• Good benchmark for analysis techniques!
2. Protocol analysis!
• //Starting with the RFC describing the protocol!
3. Tools
3. What is TLS/SSL?
❖ 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
7. TLS (Transport Layer Security)
❖ Provides a layer between TCP and
Application !
❖ Itself a layered protocol:
Handshake over Record !
❖ Record (sub)protocol!
❖ provides a private and reliable
connection!
❖ Handshake (sub)protocol!
❖ authenticates one or both parties,
negotiates security parameters!
❖ establishes secret connection keys
for the Record protocol
9. History of the Protocol
❖ SSL 1.0!
❖ Netscape completed the design in early 1994 (Internally used)!
❖ Data integrity protection!
❖ RC4 allowed adversary to make predictable changes to the plaint text!
❖ Vulnerable to replay attacks!
❖ SSL 2.0!
❖ End of 1994, also has several problems!
❖ Handshake protection - MITM undetected!!
❖ Vulnerable to length extension attacks
10. History of the Protocol
❖ SSL 3.0!
❖ fixed previous attacks!
❖ Netscape and Paul Kocher, 1996!
❖ Taher Elgamal - inventor of SSL!
❖ TLS 1.0!
❖ Internet standard based on SSL 3.0, 1999 !
❖ RFC2246 (≈SSL3)
11. History of the Protocol
❖ TLS 1.1!
❖ 2006!
❖ RFC4346!
❖ TLS 1.2!
❖ 2008!
❖ RFC5246
12. Public-Key Encryption, CA & MITM
❖ “Symmetric” encryption!
❖ Share secret key!
❖ Hundred of peoples to
communicate?!
❖ Distance
Key
Key
Them
You
13. Public-Key Encryption, CA & MITM
❖ Solution: public-key
encryption!
❖ Share public key with whole
world!
❖ No known practical way to
gain the private key from pkey
14. Public-Key Encryption, CA & MITM
❖ Visiting first time “https”!
❖ Browser create a random
private key A !
❖ Generates corresponding
public key A(blue)
15. Public-Key Encryption, CA & MITM
❖ Server generate a random
private key A !
❖ Session key established!
❖ Intruder (MITM) ?!
16. Public-Key Encryption, CA & MITM
❖ MITM stops the
communication!
❖ MITM create his own private
key (red B)!
❖ Server doesn’t know if is the
browser
17. Public-Key Encryption, CA & MITM
❖ MITM has the same session
key (red key)!
❖ How to solve? !
❖ Server and Browser can send
there public key and
compare!
❖ what if MITM knows about
that - he has the session key
18. Public-Key Encryption, CA & MITM
❖ Certificate Authority solves the
problems!
❖ There is a single CA - Symantec
(VeriSign)!
❖ FedEx - Federal Express -
encryption key H!
❖ MITM has the public key CA!
❖ What browser and server can
do?
19. Public-Key Encryption, CA & MITM
❖ Server encrypts
public key A with
certificate key H!
❖ Browser do the same
using the built-in CA
20. Public-Key Encryption, CA & MITM
❖ CA compares the 2
public keys!
❖ CA sends reply to
them!
❖ What if MITM
appear?!
❖ the browser will
not be able to
decrypt (key
random R)
21. Obtaining an SSL Certificate
❖ XYZ Inc., intends to secure their customer checkout process, account
management, and internal employee correspondence on their website,
xyz.com.
❖ Steps:
1. XYZ creates a Certificate Signing Request (CSR) and during this process,
a private key is generated.
2. XYZ goes to a trusted, third party Certificate Authority, such as
Trustwave . Trustwave takes the certificate signing request and validates
XYZ in a two step process. Trustwave validates that XYZ has control of
the domain xyz.com and that XYZ Inc. is an official organization listed in
public government records.
3. When the validation process is complete, Trustwave gives XYZ a new
public key (certificate) encrypted with Trustwave's private key.
4. XYZ installs the certificate on their webserver(s).
22. How Customers Communicate with the Server using SSL
Steps:
1. A customer makes a connection to xyz.com on an SSL port, typically 443. This
connection is denoted with https instead of http.
2. xyz.com sends back its public key to the customer. Once customer receives it, his/
her browser decides if it is alright to proceed.
3. The xyz.com public key must NOT be expired
4. The xyz.com public key must be for xyz.com only
5. The client must have the public key for Trustwave installed in their browser
certificate store. 99.9% of all modern browsers (1998+) include the Trustwave root
certificate. If the customer has Trustwave trusted public key, then they can trust
that they are really communicating with XYZ, Inc.
23. How Customers Communicate with the Server using SSL
!
7.If the customer decides to trust the certificate, then the customer will be sent to
xyz.com his/her public key.
8.xyz.com will next create a unique hash and encrypt it using both the customer's
public key and xyz.com's private key, and send this back to the client.
9.Customer's browser will decrypt the hash. This process shows that the xyz.com
sent the hash and only the customer is able to read it.
10.Customer and website can now securely exchange information!
25. The Scyther Tool
❖ Tool for the formal analysis of security protocols !
❖ it is assumed that all cryptographic functions are
perfect: the adversary learns nothing from an
encrypted message unless he knows the decryption
key.!
❖ Description of a protocol in the spdl language !
❖ based on the operational semantics!
❖ spdl (Security Protocol Description Language)
26. The Scyther Tool
❖ Analysis of infinite sets of traces in terms of patterns!
❖ Support for multi-protocol analysis!
❖ Assist in the analysis of classes of attacks and possible
protocol behaviours, or to prove correctness for an
unbounded number of protocol sessions.!
❖ Can optionally output the proof tree (by using the backend).!
❖ The tool provides useful results even in the case that no
attack is found
27. The Scyther Tool
❖ ProVerif or the Avispa tools have shown to be effective
at finding attacks on protocols (Avispa) or establishing
correctness of protocols (ProVerif).!
❖ Scyther offer verification, falsification, and the analysis
of security protocols.!
❖ Performance
28. Installation Scyther Tool
❖ Scyther can be downloaded from the following
website:!
❖ http://users.ox.ac.uk/~coml0529/scyther/!
❖ Installation instruction are included in the
downloadable Scyther archives. Scyther is
available for the Windows, Linux and Mac OS
platforms.
29. Scyther Input File
❖ A minimal input file:!
!
protocol ExampleProtocol(I,R) {!
role I { };!
role R { };!
};
30. Input Language
❖ Main purpose of the language is to describe protocols, which are defined by a set
of roles.!
❖ Protocol definition takes as a parameter a sequence of roles, which are then
defined within its body.!
❖ Roles - are sequences of events, i. e., declarations, send, receive, or claim events.!
❖ Security protocols rely on generating random values. Can be specified by
declaring them inside a role definition using the fresh declaration.!
❖ role X(...) {!
❖ fresh Na: Nonce;!
❖ send_1(X,Y,Na);!
❖ }
31. Input Language
❖ To receive a nonce into a variable with name Na, we specify:!
❖ role Y(...) {!
❖ var Na: Nonce;!
❖ recv_1(X,Y,Na);!
❖ }!
❖ Local declaration!
❖ Two terms can combined into a term pair: we write (x,y)!
❖ Symmetric keys: { ni }kir!
❖ Asymmetric keys: { ni } pk(I)
32. Input Language
❖ Hash functions are essentially encryptions with a function, of
which the inverse is not known by anybody:!
❖ global declaration: hashfunction H1!
❖ how are used: H1(ni);!
❖ Types: Agent, Function, Nonce, Ticket!
❖ You can define a new type: user type!
❖ Recv and Send events mark receiving and sending a message!
33. Input Language
❖ Claim events are used in role specifications to model intended security
properties. For example, the following claim event models that Ni is meant
to be secret!
❖ claim(I, Secret, Ni);!
❖ Claim types:!
❖ Secret!
❖ SKR, echivalent to Secret but additionally mark the parameter term as a
session-key!
❖ Alive - Aliveness (of all roles) !
❖ Weakagree - Weak agreement (of all roles)
34. Input Language
❖ Claim types:!
❖ Nisynch (Authentification Property, Non-injective Synchronisation)!
❖ Niagree (Authentification Property, Non-injective Agreement)!
❖ Reachable!
❖ when this claim is verified, Scyther will check whether this claim can be
reached at all. It is true iff there exists a trace in which this claim occurs. This
can be useful to check if there is no obvious error in the protocol
specification, and is in fact inserted when the--check mode of Scyther is used.!
❖ Empty!
❖ this claim will not be verified, but simply ignored. It is only useful when
Scyther is used!
36. Simplified TLS key transport protocol
❖ Protocol 4.24 is a simplified version of one possible protocol which
transports the 'pre- master secret', PMK, from the client A to the server B"
❖ Session key Kab is calculated as Kab = MACpmk(Na,Nb)"
❖ TLS protocol specifies that four different session keys must be derived
from the pre-master secret: one for encryption and one for data
integrity (MAC calculation) in each direction. !
37. Simplified TLS key transport protocol
❖ Message sequences Mess_Seq1, Mess_Seq2 and Mess_Seq3 consist of
hashes of the sequence of all previous exchanged messages up to that
point using a hash function H.!
❖ Mess_Seq1 = H(Na, Nb, Eb(PMK)).!
38. Bibliografie
1. Protocols for Authentication and Key Establishment - C.Boyd, A.Mathuria!
2. Operational Semantics of Security Protocols - Cas Cremers and Sjouke Mauw, Eindhoven
University of Technology, Department of Mathematics and Computer Science!
3. How SSL works!
4. Security Tools!
5. Scyther Manual!
6. http://blogs.msdn.com/b/kaushal/archive/2013/08/03/ssl-handshake-and-https-
bindings-on-iis.aspx!
7. http://www.windowsecurity.com/articles-tutorials/authentication_and_encryption/
Secure_Socket_Layer.html
