Verification of Security Protocols Lecture 1 Introduction 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, Cas Cremers. Scyther — Semantics and Verification of Security Protocols. PhD thesis, TU Eindhoven, Dieter Gollmann. Computer Security. Wiley, 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 . 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 . These provide collections of cryptographic algorithms and simple authentication protocols for . 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 B -> A: {Finished}Keygen(B, Na, Nb, M) core message exchange of regular TLS This model has been analyzed with AVISPA Source:

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 digest I(A) -> B : {|#(M,B)|}sA I forwards the digest I(A) -> B : (M,A) I impersonates A and replays M B -> I(A) : “I got...” I intercepts B’s request I(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 : N A -> 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