Transcript Cryptography

Cryptography
Lecture 10
Stefan Dziembowski
www.dziembowski.net
[email protected]
Plan
1. Qualified signatures
2. PKI and trust management
3. Introduction to the key establishment
protocols
Remember the slide from the
previous lectures?
public register:
P3
P2
pk1
sk3
sk2
pk2
P4
pk3
pk4
pk5
P1
sk4
sk1
P5
sk5
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.
A problem
skA
m є {0,1}*
pkA
(m, σ =Signsk(m))
Alice
Bob
It’s not true!
I never signed m!
I got (m,σ) from Alice
Vrfy(pk,m,σ) = yes
so you cannot repudiate signing m...
But pk is not my public
key!
Judge
Solution: certification authorities
A simplified view:
(pkCert,skCert)
comes with her ID and pkAlice
Certification Authority
Alice
checks the ID of Alice and
issues a certificate:
SignskCert(“pkAlice is a public key of Alice”)
Now, everyone can verify that pkAlice is a public key of Alice.
So Alice can attach it to every signature
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 pkAlice 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
knows pk2
knows pk3
P2
P1
pk1
P3
pk3
pk2
“trusts” P2
P2 certifies that pk3 is a public key of P3
signature of P2
P1 believes
that pk3 is a
public key of P3
this should be done only if P2 really met P3 in person and verified his identity
knows pk2
P1
pk1
knows pk3
P2
P3
pk3
pk2
knows pk4
P4
pk4
“trusts” P2
“trusts” P3
P2 certifies that pk3 is a public key of P3
signature of P2
P3 certifies that pk4 is a public key of P4
signature of P3
P1 believes
that pk3 is a
public key of P3
knows pk2
P1
pk1
knows pk3
P2
P3
pk3
pk2
knows pk4
P4
pk4
knows pk5
P4
pk4
“trusts” P2
“trusts” P3
This is called a
certificate chain
“trusts” P4
P2 certifies that pk3 is a public key of P3
signature of P2
P3 certifies that pk4 is a public key of P4
signature of P3
P4 certifies that pk5 is a public key of P5
signature of P4
P1 believes
that pk3 is a
public key of P3
A problem
knows pk2
P1
pk1
knows pk3
P2
P3
pk3
pk2
knows pk4
P4
pk4
“trusts” P2
“trusts” P3
What if P1 does not know P3?
How can he trust him?
Answer: P2 can recommend P3 to P1.
A question: is trust transitive?
Does:
P1
pk1
P2
P3
pk3
pk2
“trusts” P2
“trusts” P3
P2
P3
imply:
P1
pk1
pk3
pk2
“trusts” P3
?
Example
P1
pk1
P2
pk2
trusts that
P2 is a very
honest person
P1
pk1
P2
pk2
I can
recommend P3
P3
pk3
trusts that
P3 is a very
honest person
P3
pk3
doesn’t trust that P3
is honest, because he thinks that
P2 is honest but naive
Moral
Trust is not transitive:
“P1 trusts in the certificates issued by P2”
is not the same as saying:
“P1 trusts that
if
P2 says you can trust the certificates issued by P3
then
one can trust the certificates issued by P3”
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”
Now, if:
P1
P2
P3
P4
P2 trust
P2 issues
P3 issues
in all the
recommendations
issued by P2
a recommendation
of level 2 for P3
a recommendation
of level 1 for P4
then
P1
P2
P3
P4
trusts the certificates issued by P4
Of course the recommendations also need to be signed.
Starts to look complicated...
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 webbrowser.
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
Verisign
DigiCert
Entrust
...
Implicit assumptions:
Verisign
Europe
Verisign
USA
Verisign
Italy
Banca di Roma
• the author of the browser is honest,
• nobody manipulated the browser
a certificate path
d1
CA1
cert1
d2
CA2
cert2
d3
CA3
cert3
certn-1
dn
CAn
certn
client
All these certificates have to
have a flag “Is a Certification Authority”
switched on.
Moreover:
each certi has a number di denoting a
maximal depth of certificate chain from
this point
(this limits the recommendation depth)
That is, we need to have:
di ≥ n - i
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?
sends
(cert1,..., certn)
Alice
If Alice’s browser knows cert1 it can
verify the chain and read the public
key of the bank from certn
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
internet
Observation: authentication itself is not very useful.
More useful: key establishment
Bob
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
share a private key
KAS
share a private key
KBS
server S
Alice
Bob
The server can help Alice and Bob to establish a session
key.
(in reality it’s not so trivial to design a secure protocol)
The public-key cryptography
sends
(cert1,..., certn)
Alice
sends
(cert’1,..., cert’n)
Bob
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...
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)
key shared by Alice and
the server: KAS
key shared by Bob and
the server: KBS
server S
(A,B)
selects a random KAB
EncKAS(KAB),
EncKBS(KAB)
(EncKBS(KAB),A)
Alice
Bob
An attack
key shared by Alice and
the server: KAS
key shared by Bob and
the server: KBS
server S
(A,B)
selects a random KAB
EncKAS(KAB),
EncKBS(KAB)
(EncKBS(KAB),A)
Alice
I’m
talking
to D
(EncKBS(KAB),D)
Bob
An idea (2)
key shared by Alice and
the server: KAS
key shared by Bob and
the server: KBS
server S
(A,B)
selects a random KAB
EncKAS(KAB,B),
EncKBS(KAB,A)
EncKBS(KAB,A)
Alice
Bob
A replay attack
the adversary stores the
values that the server sent
in the previous session and
replays them.
So, the key is not fresh...
(A,B)
EncKAS(K’AB,B),
EncKBS(K’AB,A)
EncKBS(K’AB,A)
Alice
Bob
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.
key shared by Alice and
the server: KAS
key shared by Bob and
the server: KBS
server S
(A,B,NA)
selects a random KAB
EncKAS(KAB, B, NA, EncKBS(KAB,A))
EncKBS(KAB,A)
EncKAB(NB)
Alice
EncKAB(NB – 1)
Bob
An attack on Needham Schroeder
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...
EncKBS(K’AB,A)
EncK’AB(NB)
EncK’AB(NB – 1)
Bob
The final solution
key shared by Alice and
the server: KAS
key shared by Bob and
the server: KBS
server S
(A,B,NA,NB)
selects a random KAB
EncKAS(KAB, B, NA)
EncKBS(KAB, A, NB)
(B,NB)
Alice
EncKBS(KAB, A, NB)
Bob
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:
I prefer to use
AES, but I can
also use DES
Alice
Bob:
I can only
use DES,
They’ll end up using DES!
Alice:
I can only
use DES,
Bob:
I prefer to use
AES, but I can
also use DES
Bob
Protocols used in practice
• Symmetric: Kerberos
• Asymmetric: SSL, SSH, IPSec...