# Cryptography Lecture 10 Stefan Dziembowski

## Presentation on theme: "Cryptography Lecture 10 Stefan Dziembowski"— Presentation transcript:

Cryptography Lecture 10 Stefan Dziembowski www.dziembowski.net stefan@dziembowski.net

Plan 1.Qualified signatures 2.PKI and trust management 3.Introduction to the key establishment protocols

Remember the slide from the previous lectures? P5P5 P1P1 P3P3 P2P2 P4P4 pk 1 pk 2 pk 3 pk 4 pk 5 public register: sk 3 sk 5 sk 4 sk 1 sk 2

Question: How to maintain the public register? 1.We start with the case when the public keys are used for signing that is legally binding. 2.Then we consider other cases.

But pk is not my public key! A problem Alice Bob (m, σ =Sign sk (m)) sk A pk A m є {0,1}* Judge I got (m,σ) from Alice It’s not true! I never signed m! Vrfy(pk,m,σ) = yes so you cannot repudiate signing m...

Solution: certification authorities A simplified view: comes with her ID and pk Alice (pk Cert,sk Cert ) checks the ID of Alice and issues a certificate: Sign sk Cert (“pk Alice is a public key of Alice”) Alice Now, everyone can verify that pk Alice is a public key of Alice. So Alice can attach it to every signature Certification Authority really everyone?

What is needed to verify the certificate To verify the certificate coming from Cert one needs: 1.to know the public key of the Cert 2.to trust Cert. It is better if Cert also keeps a document: “I, Alice certify that pk Alice is my public key” with a written signature of Alice.

How does it look from the legal point of view? What matters at the end is if you can convince the judge. Many countries have now a special law regulating these things. In Italy it is: Decreto Legislativo 7 marzo 2005, n. 82 "Codice dell'amministrazione digitale" pubblicato nella Gazzetta Ufficiale n. 112 del 16 maggio 2005 - Supplemento Ordinario n. 93

This law defines the conditions to become an official certification authority (in Italian: certificatore). A certificate issued by such an authority is called a qualified certificate (in Italian: certificato qualificato) A signature obtained this way is called a qualified digital signature (in Italian: firma elettronica qualificata). The qualified signature is equivalent to the written one!

Some of the Italian Certificate Authorities: Banca Monte dei Paschi di Siena S.p.A. (dal 03/08/2004) Lombardia Integrata S.p.A. (dal 17/08/2004) Banca Intesa S.p.A. (dal 09/09/2004 - Società soggetta a cambio di denominazione sociale; ora Intesa Sanpaolo S.p.A.) Banca di Roma S.p.A. (dal 09/09/2004) (cessata attività dal 13/02/2008 - certificatore sostitutivo: nessuno) CNIPA (dal 15/03/2001) I.T. Telecom S.r.l. (dal 13/01/2005) Comando Trasmissioni e Informazioni Esercito (dal 10/04/2003 - già Comando C4 - IEW - cessata attività dal 21/09/2007 - certificatore sostitutivo: nessuno) Consorzio Certicomm (dal 23/06/2005).

So, what to do if you want to issue the qualified signatures? You have to go to one of this companies and get a qualified certificate (it costs!). The certificate is valid just for some given period.

What if the secret key is lost? 1.In this case you have to revoke the certificate. Every authority maintains a list of revoked certificates. 2.The certificates come with some insurance.

In many case one doesn’t want to use the qualified signatures 1.The certificates cost. 2.It’s risky to use them: How do you know what your computer is really signing? Computers have viruses, Trojan horses, etc. You can use external (trusted) hardware but it should have a display (so you can see what is signed). Remember: qualified signatures are equivalent to the written ones!

Practical solution In many cases the qualified signatures are an overkill. Instead, people use non-qualified signatures. Here, the certificates are distributed using a public-key infrastructure (PKI).

Users can certify keys of the other users P1P1 P3P3 P2P2 pk 3 pk 1 pk 2 knows pk 2 knows pk 3 “trusts” P 2 P 2 certifies that pk 3 is a public key of P 3 signature of P 2 P1 believes that pk 3 is a public key of P3 this should be done only if P 2 really met P 3 in person and verified his identity

P1P1 P3P3 P2P2 pk 3 pk 1 pk 2 knows pk 2 knows pk 3 “trusts” P 2 P4P4 pk 4 knows pk 4 “trusts” P 3 P 2 certifies that pk 3 is a public key of P 3 signature of P 2 P 3 certifies that pk 4 is a public key of P 4 signature of P 3 P 1 believes that pk 3 is a public key of P 3

P1P1 P3P3 P2P2 pk 3 pk 1 pk 2 knows pk 2 knows pk 3 “trusts” P 2 P4P4 pk 4 P 2 certifies that pk 3 is a public key of P 3 signature of P 2 P 3 certifies that pk 4 is a public key of P 4 signature of P 3 P 1 believes that pk 3 is a public key of P 3 “trusts” P 3 knows pk 4 P4P4 pk 4 “trusts” P 4 P 4 certifies that pk 5 is a public key of P 5 signature of P 4 This is called a certificate chain knows pk 5

A problem What if P 1 does not know P 3 ? How can he trust him? Answer: P 2 can recommend P 3 to P 1. P1P1 P3P3 P2P2 pk 3 pk 1 pk 2 knows pk 2 knows pk 3 “trusts” P 2 P4P4 pk 4 “trusts” P 3 knows pk 4

A question: is trust transitive? P1P1 P3P3 P2P2 pk 3 pk 1 pk 2 “trusts” P 2 “trusts” P 3 P1P1 P3P3 P2P2 pk 3 pk 1 pk 2 “trusts” P 3 Does: imply: ?

Example P1P1 P3P3 P2P2 pk 3 pk 1 pk 2 trusts that P 2 is a very honest person P1P1 P3P3 P2P2 pk 3 pk 1 pk 2 doesn’t trust that P 3 is honest, because he thinks that P 2 is honest but naive trusts that P 3 is a very honest person I can recommend P 3

Moral Trust is not transitive: “P 1 trusts in the certificates issued by P 2 ” is not the same as saying: “P 1 trusts that if P 2 says you can trust the certificates issued by P 3 then one can trust the certificates issued by P 3 ”

Recommendation levels level 1 recommendation: A: ”you can trusts in all the certificates issued by B” level 2 recommendation: A : “you can trust that all the level 1 recommendations issued by B” level 3 recommendation: B : “you can trust that all the level 2 recommendations issued by B” and so on... Recursively: level i+1 recommendation: A : “you can trust that all the level i recommendations issued by B”

P1P1 P3P3 P2P2 P4P4 P1P1 P3P3 P2P2 P4P4 trusts the certificates issued by P 4 Now, if: then Of course the recommendations also need to be signed. Starts to look complicated... P 2 issues a recommendation of level 2 for P 3 P 3 issues a recommendation of level 1 for P 4 P 2 trust in all the recommendations issued by P 2

How is it solved in practice? In popular standard is X.509 the recommendation is included into a certificate. Here the level of recommendations is bounded using a field called basic constraints. X.509 is used for example in SSL. SSL is implemented is implemented in every popular web- browser. So, let’s look at it.

this field limits the recommendation depth (here it’s unlimited)

Concrete example Let’s go to the Banca Di Roma website

a certificate chain

the second certificate was signed by ”Verisign Primary Authority” for “Verisign Inc”. (it’s not strange, we will discuss it)

Look here

The third certificate was issued by Verisign Inc. for Banca di Roma

The typical picture web browser knows these certificates VerisignDigiCert Entrust... Verisign Europe Verisign USA Verisign Italy Banca di Roma a certificate path Implicit assumptions: the author of the browser is honest, nobody manipulated the browser

CA 1 CA 2 CA 3 CA n client cert 1 cert 2 cert 3 cert n-1 cert n Moreover: each cert i has a number d i denoting a maximal depth of certificate chain from this point (this limits the recommendation depth) That is, we need to have: d i ≥ n - i All these certificates have to have a flag “Is a Certification Authority” switched on. d1d1 d2d2 d3d3 dndn

Is it so important to check it? Yes! For example: the last element in the chain can be anybody (who paid to Verising for a certificate). For sure we do not want to trust the certificates issued by anyone.

So, what happens when a user contacts the bank? Alice sends (cert 1,..., cert n ) If Alice’s browser knows cert 1 it can verify the chain and read the public key of the bank from cert n Bank

What happens if the certification path is invalid? For example if the first certificate in the path is not known to the user. Experiment: let’s delete the Verisign certificate for the configuration of the browser...

What happens?

Suppose Alice and Bob want to authenticate to each other... Alice Bob internet Observation: authentication itself is not very useful. More useful: key establishment

Protocols for key establishment Suppose Alice and Bob want to establish a fresh session key in an authentic way. When is it possible? Using symmetric cryptography: Alice and Bob can use some trusted server S. Using asymmetric cryptography: e.g. using PKI.

Symmetric cryptography The server can help Alice and Bob to establish a session key. (in reality it’s not so trivial to design a secure protocol) AliceBob server S share a private key K AS share a private key K BS

The public-key cryptography Alice sends (cert 1,..., cert n ) If they accepted the certificate paths they can establish a session key: 1.Alice selects a random key K. 2.Alice encrypts K with Bob’s public key, and sign is it with her private key, and sends it to Bob. 3.Bob verifies the signature and decrypts the K. Again: in reality it’s not that simple... Bob sends (cert’ 1,..., cert’ n )

What if one of the parites doesn’t have a certificate? Typical situation in real life... E.g. a bank can verify authenticity of Alice by asking her for a secret password. This password is provided to her (in a physical way) when she opened an account. How to prevent the dictionary attacks? Not so trivial...

Designing the key establishment protocols It is an active area of research. It’s more complicated than one may think... On the next slides we show some common errors.

An idea (1) AliceBob server S key shared by Alice and the server: K AS key shared by Bob and the server: K BS (A,B) Enc KAS (K AB ), Enc KBS (K AB ) (Enc KBS (K AB ),A) selects a random K AB

An attack AliceBob server S key shared by Alice and the server: K AS key shared by Bob and the server: K BS (A,B) Enc KAS (K AB ), Enc KBS (K AB ) (Enc KBS (K AB ),A) selects a random K AB (Enc KBS (K AB ),D) I’m talking to D

An idea (2) AliceBob server S key shared by Alice and the server: K AS key shared by Bob and the server: K BS (A,B) Enc KAS (K AB,B), Enc KBS (K AB,A) selects a random K AB

A replay attack AliceBob (A,B) Enc KAS (K’ AB,B), Enc KBS (K’ AB,A) the adversary stores the values that the server sent in the previous session and replays them. So, the key is not fresh...

How to protect against the replay attacks? Nonce – “number used once”. Nonce is a random number generated by one party and returned to that party to show that a message is newly generated.

An idea (3): Needham Schreoder 1972. AliceBob server S key shared by Alice and the server: K AS key shared by Bob and the server: K BS (A,B,N A ) Enc KAS (K AB, B, N A, Enc KBS (K AB,A)) Enc KBS (K AB,A) selects a random K AB Enc KAB (N B – 1) Enc KAB (N B )

An attack on Needham Schroeder Bob Enc KBS (K’ AB,A) Enc K’AB (N B – 1) Enc K’AB (N B ) Assume that an old session key K’ AB is known to the adversary. If e.g. K’ AB is used as one-time pad this may happen...

The final solution AliceBob server S key shared by Alice and the server: K AS key shared by Bob and the server: K BS (A,B,N A,N B ) Enc KAS (K AB, B, N A ) Enc KBS (K AB, A, N B ) selects a random K AB Enc KBS (K AB, A, N B ) (B,N B )

Other desirable features 1.Forward-security: if an adversary breaks into the machine at some time t the previous session keys remain secret. 2.Deniability: A user can always deny that he sent some message. 3.Resistance to denial-of-service attacks (don’t put to much work on the server!).

Another (real-life) problem Alice and Bob may use different versions of the protocol. Therefore at the beginning of the protocol they have to agree on the ciphers that they will use. How to do agree in a secure way? Alice Bob Alice: I prefer to use AES, but I can also use DES Alice: I can only use DES, Bob: I can only use DES, Bob: I prefer to use AES, but I can also use DES They’ll end up using DES!

Protocols used in practice Symmetric: Kerberos Asymmetric: SSL, SSH, IPSec...