Verification of Security Protocols

Lecture 1Introduction and Overview

Sandro Etalle

Note

• Basically identical to (and based on) last year’s lecture given by Christian Haack.

Literature

• M. Abadi.• Security protocols and their properties. 20th Int. Summer

School on Foundations of Secure Computation, pages 39–60, 1999.

• Cas Cremers.• Scyther — Semantics and Verification of Security

Protocols. PhD thesis, TU Eindhoven, 2006.

• Dieter Gollmann.• Computer Security. Wiley, 1999.

• P. Ryan and S. Schneider.• Modelling and Analysis of Security Protocols. Addison-

Wesley, 2001.

Protocols

• What are communication protocols?• A set of rules that governs the interaction between

agents.

• Examples.• TCP governs computer interactions over an IP network.• HTTP governs the exchange of data in HTML format.• SMTP governs the exchange of e-mail.

• What are security protocols?• communication protocols that operate in an untrusted

environment or among untrusted agents• often their goal is to provide security services, like for

instance authentication

Trusted Channels and Honest Participants

• Communications protocols usually assume:– trusted channels– honest participants

• Trusted channels.– No hostile agents have access to the

communication medium to interfere with the protocol.

• Honest participants.– All agents that participate in the protocol

cooperate to achieve the protocol goal.

Untrusted Channels

• Security protocols usually assume untrusted channels– Hostile agents that do not participate in the

regular protocol have access to the communication medium and have an interest in subverting the protocol (e.g., through eavesdropping, redirecting messages, modifying messages).

• Example: The Internet.

Dishonest Participants

• Security protocols sometimes assume: dishonest participants

• agents that claim to be regular participants of the protocol, but really try to subvert it or act to their own advantage against the protocol rules.

• Examples.• I compromised machines where attackers got hold of

cryptographic keys • compromised users that somehow got their

cryptographic keys certified • electronic merchants that falsely deny receiving a

payment clients of electronic merchants that falsely deny making an order

Attackers

• Hostile agents (both dishonest participants and outsiders attacking via untrusted channels) are called attackers.

Protocol Goals

• Secrecy (aka Confidentiality).• Prevention of unauthorized disclosure of information.

• A strong notion: • Attackers should not be able to deduce any information

at all about communicated messages.• For instance, they should not be able to observe:

– the length of messages– that the same message has been sent twice

• A weaker notion: • Attackers should not be able to deduce the content of

messages.

Protocol goals (2)

• Authentication.– (“Verifying who’s talking.”)– User authentication: Verifying the claimed

identity of a user. Often password-based.– Message authentication: Verifying that a message

comes from the agent it claims to come from.

• Integrity.– Prevention of unauthorized modification of

information.– Can be seen as an instance of message

authentication.

Protocol Goals (3)

• Anonymity.• Preventing to identify specific properties of individual

eventswithin a set of events.

• Examples.• Voter anonymity: A voting protocol should prevent that

observers can link voters to the candidates they voted for• allow that observers can count the total number of votes for a

each candidate• allow that (some) observers can check who has cast a vote (to

prevent double voting)• Anonymous networking: An anonymizing network protocol

might try to prevent network observers from linking sender identities to receiver identities

Protocol Goals (4)

• Non-repudiation. Preventing a sender (receiver) of a message from falsely denying that he has sent (received) the message.– For instance, in e-commerce a merchant may deny that

he has received a payment, or a client may deny that he has made an order.

• Fairness. No participant can gain advantage over another by aborting the protocol.– First you send me the merchandise, then I pay! No,

first you send me the payment, then I send the merchandise!

– Electronic contract signing: Who signs first?

Protocol Goals (5)

• Availability. Prevention of unauthorized withholding of services or resources.– Denial of service attacks are attacks on availability

A note on the goals

• The list of protocol goals is not exhaustive.• Some goals are common to many application

domains.• E.g., secrecy, authentication.

• Other goals are more specific• Fair exchange to e-commerce and contract signing.

• Some goals overlap.– message authentication and integrity.– anonymity and strong secrecy.

• Some goals are incompatible.– anonymity and authentication

Common security protocols

• Transport layer security: SSL/TLS– secrecy, authentication, message integrity.

• is included in web browsers. For instance, if you enter a website whose URL begins with https, then you are communicating with the web server over SSL/TLS.

• Network layer security: IPsec– secrecy, authentication, message integrity.

• Virtual private networks (VPN) between a company’s local network and their employees’ home computers sometimes tunnel their network traffic through IPsec.

Common security protocols (2)

• Application layer security: S/Mime, PGP– secrecy, authentication and message integrity for

e-mail.• These provide collections of cryptographic algorithms

and simple authentication protocols for e-mail.

• Wireless security: WEP, WPA– (some degree of) secrecy, user authentication and

message integrity over a wireless network.• Connecting your laptop to a wireless access point often

uses one of these protocols..

Common security protocols (3)

• Distributed computing environment: Kerberos– user authentication in a distributed computing

environment where many users from many workstations share common computation servers.• If you are working in a local university network with a file

server, there is a good chance that you are authenticating yourself to the file server using Kerberos.

• Smart card authentication– authentication of a card to a terminal.

• When you pay with your chipcard, then a simple authentication protocol is used to authenticate your card to the payment terminal.

Standards, Models, Implementations

• Documents that define security protocols are called standards.

• Protocol standards are long documents mostly written in plain English mixed with some bits of formal notation.

• The standard that defines TLS is called RFC2246.

• RFC2246 has 80 pages.• You can google for RFC2246 and take a look.

Standards, Models, Implementations

• Formal protocol analysis usually does not directly analyze protocol standards.

• Instead, it analyzes protocol models.• Models are meant to extract those protocol

features that are central to the security properties we care about ,while hiding “irrelevant” details.– Of course, there is the danger that protocol models

neglect protocol features that are crucial for security after all. But we have to start somewhere.

Ex.: protocol model for TLS• 0. A -> B: A, Na, Sid, Pa• 1. B -> A: Nb, Sid, Pb• 2. B -> A: {B, Kb}inv(Ks)• 3. A -> B: {A, Ka}inv(Ks)• 4. A -> B: {PMS}Kb• 5. A -> B: {H(Nb,B,PMS)}inv(Ka)• 6. A -> B: {Finished}Keygen(A, Na, Nb, M)

– where M = PRF(PMS,Na,Nb)– Finished = H(M,messages) for all messages 0 - 5

• 7. B -> A: {Finished}Keygen(B, Na, Nb, M)

• core message exchange of regular TLS• This model has been analyzed with AVISPA • Source: http://www.avispa-project.org

Standards, Models, Implementations

• Protocols are implemented in programming languages like C or Java.

• It would be interesting to – try to verify that a particular protocol

implementation correctly implements the protocol standard that it claims to implement.

– and/or to verify security properties directly on protocol implementations.• Not surprisingly, this is harder than analyzing abstract

protocol models.• For this reason, formal protocol analysis so far has mostly

focused on analyzing protocol models

Security Protocols & Crypto

• Security protocols use crypto primintives• symmetric and asymmetric encryption• digital signatures• cryptographic hash functions• message authentication codes (aka keyed hash

functions)• random number generation

• Cryptographic algorithms implement them• Symmetric encryption: DES, AES (Rijndael), IDEA, ...• Public key encryption: RSA, ...• Digital signing: ElGamal, DSA, ...• Cryptographic hash functions: SHA-1, MD5, ...

Crypto alone is not enough

• crypto algorithms are like locks

• even if you have the perfect lock, things can go wrong

• source: Cas Cremer

• we assume perfect crypto, but … what is it?

Perfect crypto assumptions

• No info without key. – One cannot learn

anything about an encrypted message unless one has the key.

• No modification without key. – One cannot modify an

encrypted message unless one has the key. (will get detected).

• Perfect keys. – Keys cannot be guessed

or “extracted” from ciphertexts.

• Perfect random numbers– cannot be guessed.

• Perfect hashes. – are one-way and

collision-free.

Attacker model (Dolev-Yao)

• The attacker controls the communication medium. He can:– eavesdrop (and learn)– redirect messages– inject messages– apply cryptographic operations to the data he has

learned– generated keys and random numbers

Crypto Primitives

• Symmetric encryption: {M}K– Message M encrypted with symmetric key K.– M can only be recovered by someone who has K

• Asymmetric encryption: {|M|}K– Message M encrypted with asymmetric key K.– M can only be recovered by someone who has the

decryption key that matches K.

• Cryptographic Hashing: #(M)– The hash of message M.

• Tupling: (M1, . . . ,Mn)– The tuple of M1, . . . ,Mn.

Nonces and Keys

• Messages– M

• Nonces– N1, N2– random numbers used to guarantee e.g.

uniqueness of a session– we assume they are unguessable

• Keys– K1, K2– we assume they are unguessable

Assumptions

• We assume "injectivity" for all primitives, i.e.:– If {M}K = {M0}K0 , then M = M0 and K = K0.– If {|M|}K = {|M0|}K0 , then M = M0 and K = K0.– If #(M) = #(M0), then M = M0.– If (M1, . . . ,Mk) = (N1 , . . . ,Nj),– then k = j, M1 = N1 , . . ., and Mk = Nk.

• so hash functions, are perfectly collision-free.• and DY is insensitive to message length: – it is impossible to confuse a tuple with a triple. In

reality, this is not the case

Example: basic authentication

A -> B : (M,A) • A sends message M to B

B -> A : N • B generates a nonce N and sends it to A

A -> B : {|#(M,B,N)|}sA • A sends a signed message digest• sA is A’s private signing key.

• At the end of a complete run, B knows:– M originates from A (because the digest is signed be A)– M is intended for B (because the digest includes B’s name)– M was sent as part of this run (because the digest includes

the nonce N)

What if we omit the nonce?

A -> B : (M,A) B -> A : “I got the message, please send signature”A -> B : {|#(M,B,N)|}sA

• A replay attack launched by intruder I.A -> B : (M,A)B -> A : “I got the message, please send signature”A -> I(B) : {|#(M,B)|}sA I intercepts and saves the digestI(A) -> B : {|#(M,B)|}sA I forwards the digestI(A) -> B : (M,A) I impersonates A and replays MB -> I(A) : “I got ...” I intercepts B’s requestI(A) -> B : {|#(M,B)|}sA I replays the digest. Oooops!

• Imagine A is you, B is your bank, M is an order to transfer your rent to your evil landlord’s account, and I is your evillandlord!

What if we omit B’s name?

A -> B : (M,A) B -> A : NA -> B : {|#(M,N)|}sA

• Is the omission of B’s name harmless? If not, can you think of an attack and a concrete scenario where the attack would cause harm?

Way to find attacks (aka bugs in protocols)

• Fully automatic– Model Checking– Theorem Proving

• Interactive – Interactive Theorem Proving– Type checking

Model Checking

• Build a finite state machine whose states are all possible intermediate states of protocol runs. Explore all possible executions searching for an attack on the protocol.– almost completely automatic

• Limitations: – Black box security protocols really are infinite

state (due to possible parallel sessions) . As a result, the absence of an attack in the finite model does not necessarily imply the absence of an attack on the full protocol.

Automatic Theorem Proving

• Search for a safety proof for the protocol. If a safety proof is found, then the protocol is indeed safe.

• Limitations: – Such tools do not always terminate or sometimes

terminate with the answer: "I can’t find a safety proof, but possibly a safety proof exists.“

– Sometimes a protocol is safe even if no safety proof exists, but I am not sure I want to use such protocols.

Interactive Theorem Proving

• We have to find the safety proof ourselves and the tool checks its correctness. In other words: we have to deliver the ideas and the tool ensures that we do not mess up.

• Limitations: – Basically none, if you can find someone who does

the proof.

Type Checking

• We have to annotate the protocol with types– an automatic typechecker checks if the protocol is

well-typed. Type systems for security protocols are designed so that well-typed protocols are robustly safe for secrecy and authenticity.

• Limitations: – Type systems for cryptographic protocols are

incomplete, i.e., there are safe protocols that cannot be proven safe by these typecheckers