Outline
X.509 certificates
Network security basics
Secure socket layer
(More in the course T-110.5240 Network security, period II)
2
Key distribution problem Public keys make key distribution easier than it is for
secret keys, but it is still not trivial: How to find out someone’s authentic public key?
Solution: an authority issues certificates that bind public keys to names
Certificate = SignCA (Name, PK, validity dates)
– Message signed by the authority, containing the subject name and public key
Questions:– Who could the authority be?
– How does everyone know the public key of the authority?
– What is the difference between authority and trusted third party?
4
X.509 PKI ITU-T/ISO X.509 standard, IETF RFC3280 Certification authority (CA) issues certificates
– CA can delegate its authority to another CA → CA hierarchy
X.509 certificates are identity certificates i.e. bind a principal name to a public key
Users, computers and services are end entities CAs and end entities are principals
– Each principal has a key pair – Key pair = public and private signature key
(RSA keys can also be used for encryption)
Standard notation for a certificate: CA<<Alice>>
5
6
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
d1:32:5b:f8:d7:09:02:37:50:57:93:55:84:c9:b2:4c
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=FI, O=Sonera, CN=Sonera Class2 CA
Validity
Not Before: Nov 19 12:02:09 2009 GMT
Not After : Nov 19 12:02:09 2010 GMT
Subject: C=FI, O=TKK, OU=Computing Centre, CN=wwwlogin.tkk.fi/[email protected]
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:c7:94:9b:49:29:6f:2d:6d:32:70:97:73:39:1e:
04:20:89:ea:05:89:02:01:1a:d7:2d:ad:86:f6:99:
69:7e:13:19:f2:09:d0:e6:05:ca:93:13:a7:e2:7b:
3b:b6:68:e7:49:c7:3b:53:fd:b5:c1:bc:64:65:6c:
4d:89:37:ab:b5:6b:2a:38:2b:45:82:f6:99:97:21:
57:fc:ac:26:9b:04:3b:ad:13:26:8e:85:ff:44:ba:
4f:1e:27:cc:f2:fd:c1:47:c4:de:b6:d2:6c:2c:48:
6e:a3:cc:cd:0c:ed:75:4b:a2:c7:f0:c2:e1:9b:e9:
d3:0c:1b:90:35:c8:ee:e7:01
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:4A:A0:AA:58:84:D3:5E:3C
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.271.2.3.1.1.2
X509v3 CRL Distribution Points:
URI:ldap://194.252.124.241:389/cn=Sonera%20Class2%20CA,o=Sonera,c=FI?certificaterevocationlist;binary
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Subject Key Identifier:
86:4C:D0:93:1A:A4:C4:7C:94:A0:28:04:F3:DA:17:12:18:FF:23:D7
Signature Algorithm: sha1WithRSAEncryption
50:c3:94:71:b3:d2:1d:7f:be:71:5e:fe:ff:ec:09:50:68:f0:
27:54:cd:e8:f2:17:90:3e:ea:6c:e2:81:12:bf:e2:73:72:9e:
02:d3:b4:03:88:2a:6a:b1:00:ca:70:24:1b:3f:da:d6:30:46:
X.509 certificate exampleSave certificate into a file and pretty print:% openssl x509 -in cert.pem -noout -text
Subject name
Subject public key
Issuer info
Validity dates
Key usage
CA signature…
Revocation list URL
X.509 certificate fields (1)Mandatory fields: Version Serial number — together with Issuer, uniquely
identifiers the certificate Signature algorithm — for the signature on this
certificate; usually sha1RSA; includes any parameters Issuer — name (e.g. CN = Microsoft Corp Enterprise CA
2) Valid from — usually the time when issued Valid to — expiry time Subject — distinguished name of the subject Public key — public key of the subject
7
X.509 certificate fields (2)Common extension fields: Key usage — bit field indicating usages for the subject key
(digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly, decipherOnly)
Subject alternative name — email address, DNS name, IP address, etc. Issuer alternative name Basic constraints — (1) is the subject a CA or an end entity, (2) maximum
length of delegation to sub-CAs after the subject Name constraints — limit the authority of the CA Certificate policies — list of OIDs to indicate policies for the certificate Policy constraints — certificate policies Extended key usage — list of OIDs for new usages, e.g. server
authentication, client authentication, code signing, email protection, EFS key, etc.
CRL distribution point — where to get the CRL for this certificate, and who issues CRLs
Authority info access — where to find information about the CA and its policies
8
Certificate chain Typical certificate chain:
1. Root CA self-signed certificate2. Root CA issues a CA certificate to a sub-CA3. Sub-CA issues end-entity certificate to a user, computer or
web server
Chain typically has 0..2 sub-CAs (Why?) Self-signed certificate is an X.509 certificate issued by CA to
itself; not really a certificate, just a way to store and transport the CA public key
9
CA hierarchy One root CA Each CA can delegate its
authority to sub-CAs All end-entities trust all CAs
to be honest and competent Original hope:
– One global hierarchy
Reality: – One hierarchy per
organization– Competing commercial root
CAs without hierarchy, e.g. Verisign
10
Contoso
Root CA
PKCA
Bob,
PKB
Charlie,
PKC
Contoso
Sales CA
PKSales
Contoso
Sales
Asia CA,
PKUS
Contoso
Sales
Euro CA
PKEuro
Contoso
Dev CA
PKDev
CA certificate
End-entity
certificate
Alice,
PKA
David,
PKD
Certificate path — original idea How can Bob check Alice’s
PK? Original idea
– En-entities (like Bob) know their nearest CA
– Each sub-CA certifies its parent CA in reverse direction
– CA path from root to Alicemeets reverse path from Bob’s nearest CA to root at some point → path from Bob to Alice
In practice, implementations work differently: one path from root CA to end entity
11
Contoso
Root CA
PKCA
Alice,
PKA
Bob,
PKB
Charlie,
PKC
Contoso
Sales CA
PKSales
Contoso
Sales
Asia CA,
PKUS
Contoso
Sales
Euro CA
PKEuro
Contoso
Dev CA
PKDev
David,
PKD
CA certificate
End-entity
certificate
Self-certificate
12
Certificate path End-entities (e.g. Bob)
know the root CA– Root CA’s PK stored as a
self-signed certificate
To verify Alice’s signature:– Bob needs the entire
certificate path from root CA to Alice (self-signed root certificate + 2 CA certificates + end-entity certificate)
– The root CA must be in Bob’s list of trusted root CAs
Contoso
Root CA
PKCA
Alice,
PKA
Bob,
PKB
Charlie,
PKC
Contoso
Sales CA
PKSales
Contoso
Sales
Asia CA,
PKUS
Contoso
Sales
Euro CA
PKEuro
Contoso
Dev CA
PKDev
David,
PKD
CA certificate
End-entity
certificate
Self-certificate
13
Certificate revocation When might CA need to revoke certificates?
– If the conditions for issuing the certificate no longer hold – If originally issued in error– If the subject key has been compromised
Certificate revocation list (CRL) = signed list of certificate serial numbers
Who issues the CRL? How to find it?– By default, CRL is signed by the CA that issued the
certificate– CRL distribution point and issuer can be specified in each
certificate
Only certificates are revoked, not keys– No mechanism for revoking the root key– Unlike PGP
14
X.509 CRL fields
Signature algorithm
Issuer — name
This update — time
Next update — time
For each revoked certificate:– Serial number
– Revocation date — (how would you use this information?)
– Extensions — reason code etc.
Signature
15
Setting up a PKI
Potential root CAs:– Commercial CA such as Verisign, Sonera, etc. usually
charges per certificate
– Windows root domain controller can act as an organizational CA
– Anyone can set up their own CA using Windows server or OpenSSL
The real costs: – Distributing the root key (self-signed certificate)
– Certificate enrolment — need to issue certificates for each user, computer, mobile device etc.
– Administering a secure CA and CRL server
!
Name and identity With certificates, it is possible to authenticate the name or
identifier of an entity– e.g. person, computer, web server, email address
What is the right name anyway?– wwwlogin.tkk.fi, security.tkk.fi, leakybox.cse.tkk.fi– George Bush, George W. Bush, George H. W. Bush– [email protected], [email protected], [email protected], [email protected],
Who decides who owns the name?– aalto.fi– Ville Valo on Facebook
Identity proofing: How is the identity of the subject verified? – Email– Extended validation certificates
Does knowing the name imply trust?– Should I order a second-hand camera from buycam.fi?– Should they post the camera to Tuomas Aura?
16
17
Cer
tifi
cate
:D
ata:
Ver
sio
n: 3
(0
x2)
Seri
al N
um
ber
:1
f:d
b:f
9:f
0:b
c:2
1:c
b:6
6:1
9:b
5:b
a:6
b:2
9:f
a:c8
:97
Sign
atu
re A
lgo
rith
m: s
ha1
Wit
hR
SAEn
cryp
tio
nIs
suer
: C=U
S, O
=Ver
iSig
n, I
nc.
, OU
=Ver
iSig
n T
rust
Net
wo
rk, O
U=T
erm
s o
f u
se a
t h
ttp
s://
ww
w.v
eris
ign
.co
m/r
pa
(c)0
6, C
N=V
eriS
ign
Cla
ss 3
Ext
end
ed
Val
idat
ion
SSL
SG
C C
AV
alid
ity
No
t B
efo
re:
Jun
2 0
0:0
0:0
0 2
01
0 G
MT
No
t A
fter
: Ju
n 4
23
:59
:59
20
11
GM
TSu
bje
ct: 1
.3.6
.1.4
.1.3
11.
60.2
.1.3
=FI/
2.5.
4.15
=V1.
0, C
lau
se 5
.(b
)/se
rial
Nu
mb
er=1
68
02
35
-8, C
=FI/
po
stal
Co
de=
00
10
0, S
T=U
USI
MA
A, L
=Hel
sin
ki/s
tree
tAd
dre
ss=A
leks
ante
rin
katu
36
B, O
=No
rdea
Ban
k Fi
nla
nd
Ab
p, O
U=E
lect
ron
ic B
anki
ng,
CN
=so
lo1
.no
rdea
.fi
Sub
ject
Pu
blic
Key
Info
:P
ub
lic K
ey A
lgo
rith
m: r
saEn
cryp
tio
nR
SA P
ub
lic K
ey: (
20
48
bit
)M
od
ulu
s (2
04
8 b
it):
00
:e6
:e2
:5c:
ae:a
5:d
4:b
c:2
6:1a
:cc:
f3:d
4:e
b:8
2:9
d:b
9:4
3:6
8:5
4:09
:57
:60:
22:2
0:ae
:a3
:ea:
32:
8d:
1d
:30
:28
:d5
:73:
5d:9
7:4
5:49
:bc:
3a:
3f:b
e:d
b:d
a:c4
:3b
:55
:2b
:b0
:9c:
44:0
5:b
7:e
d:8
5:87
:eb
:68:
6b:
47
:e7
:fe:
7b
:be:
75
:0b
:ae:
e1:7
8:18
:69:
10:f
e:d
8:
20
:64
:ee:
08:
f3:5
d:0
8:0d
:05:
c4:a
6:c
a:fe
:c5
:24:
3a:
10
:61
:e9:
45:9
8:e1
:11:
f9:a
5:5f
:80:
cb:9
f:8
6:0
a:1
f:d
e:f3
:a8
:61
:94
:c1
:6c:
c9:4
8:3
4:47
:5b
:ee:
14
:35
:7a:
e1:0
e:f2
:81:
5a:8
f:d
c:8
9:e
6:b
a:8
8:fb
:4
1:4
f:f0
:26
:d0
:56:
a7:0
4:1b
:f7
:2a:
6a:
d1:
f0:9
7:
c6:6
3:5
4:0
5:2a
:0f:
93:a
0:85
:ad
:5d
:9c:
26:
a6:5
7:
5b
:d4
:b2
:41
:0e:
a0:f
e:d
0:a
b:5
3:a
5:6
4:c8
:b1
:be:
24
:ac:
45
:ec:
54:
55:5
c:e3
:ac:
5d:9
4:1f
:bb
:82
:32:
cd:f
7:5
4:8
0:3
7:01
:a7
:28:
dc:
b2
:2d
:ce:
f6:9
4:cd
:6
7:4
e:ed
:5b
:de:
33
:bd
:ca:
36
:cc:
5e:
b3:
0f:a
7:5
8:ce
:75
:81
:69:
26:e
2:2
9:a6
:25:
99:0
f:60
:68:
45:f
a:a5
:6b
:ab
:fd
:e0
:6e:
92
:be:
f1:8
a:8
c:f3
:da:
6f:c
e:2
b:5
3Ex
po
nen
t: 6
55
37
(0x1
00
01
)X
50
9v3
ext
ensi
on
s:X
50
9v3
Bas
ic C
on
stra
ints
: C
A:F
ALS
EX
50
9v3
Su
bje
ct K
ey Id
enti
fier
: D
D:D
A:E
D:3
5:8B
:AA
:A9:
15:B
2:1
1:0
6:C
6:7C
:5A
:8D
:2F:
CB
:ED
:08:
F1X
50
9v3
Key
Usa
ge:
Dig
ital
Sig
nat
ure
, Key
En
cip
her
men
tX
50
9v3
Cer
tifi
cate
Po
licie
s:
Po
licy:
2.1
6.8
40.
1.11
373
3.1.
7.23
.6C
PS:
htt
ps:
//w
ww
.ver
isig
n.c
om
/rp
aX
50
9v3
CR
L D
istr
ibu
tio
n P
oin
ts:
UR
I:h
ttp
://E
VIn
tl-c
rl.v
eris
ign
.co
m/E
VIn
tl2
00
6.c
rlX
50
9v3
Ext
end
ed K
ey U
sage
: TL
S W
eb S
erve
r A
uth
enti
cati
on
, TL
S W
eb C
lien
t A
uth
enti
cati
on
, N
etsc
ape
Serv
er G
ated
Cry
pto
X5
09
v3 A
uth
ori
ty K
ey Id
enti
fier
: ke
yid
:4E:
43
:C8
:1D
:76:
EF:3
7:53
:7A
:4F:
F2:5
8:6
F:94
:F3
:38:
E2:D
5:B
D:D
FA
uth
ori
ty In
form
atio
n A
cces
s:
OC
SP -
UR
I:h
ttp
://E
VIn
tl-o
csp
.ver
isig
n.c
om
CA
Issu
ers
-U
RI:
htt
p:/
/EV
Intl
-aia
.ver
isig
n.c
om
/EV
Intl
20
06
.cer
1.3
.6.1
.5.5
.7.1
.12
: 0
`.^.
\0Z0
X0
V..
imag
e/gi
f0!0
.0...
+....
..K
k.(.
....R
8.)
.K..!
..0&
.$h
ttp
://l
ogo
.ver
isig
n.c
om
/vsl
ogo
1.g
ifSi
gnat
ure
Alg
ori
thm
: sh
a1W
ith
RSA
Encr
ypti
on
2d
:d3
:9c:
45
:bd
:d4
:49
:0e:
52:9
e:54
:98
:8f:
36:
e1:0
0:6
c:38
:5
8:1
a:4
7:f
2:7
7:d
c:1
5:45
:85
:da:
5d
:3f:
60:0
3:9a
:ab
:7f:
6a:
f8:5
e:3
d:3
2:4
1:93
:80:
b9
:d7
:bb
:6a:
e0:7
9:4
0:f7
:77:
2c:a
f:1
9:3
a:1
6:5
e:14
:83:
4a:9
9:f2
:f1
:90:
ab:e
d:b
3:3
1:0
3:50
:a5
:6
2:0
3:3
7:b
7:7
3:77
:59
:1d
:6e:
f8:c
5:2
0:17
:61
:9a:
9a:3
f:9
3:
ac:f
a:9
3:e
a:5
2:2
9:4
5:7
8:50
:56:
94:7
9:a
0:a
6:94
:a5
:93:
fc:
1f:
04
:2f:
db
:cf:
9c:
f3:c
8:0
b:2
e:44
:a5
:ce:
6f:9
4:2
7:b
c:0e
:fc
:9e:
81
:03
:15:
9d:b
6:5
f:7
5:67
:44:
12:4
c:d
8:5
e:3e
:8f:
21:
0b
:d9
:cb
:f1
:59
:ab
:b0
:42
:19:
a9:9
9:d
5:a
b:0
e:b
7:44
:06:
c0:
e8:1
5:b
4:a
8:5
4:06
:61
:09:
1a:3
a:7
1:3a
:8a:
17:
da:
ac:a
c:c5
:cf
:83
:2c:
85
:dd
:51:
ae:9
2:d
e:d
f:af
:5a:
a1:3
8:6
3:d
c:ee
:bd
:1
5:0
f:c9
:bb
:6f:
ee:4
5:9
2:40
:bb
:08:
51:3
a:67
:10
:a6
:c7:
87:
7f:
ab:d
a:ac
:0a:
0c:
38
:a5
:a2
:35
:6c:
59:5
a:6
5:d
9:91
:35:
c1:
a3:0
9:f
6:4
a:c8
:64:
76:8
6:a4
:f2
:3a:
e5:1
2:5
9:9f
:d9
:03
:ed
:cb
:02
:d2
:9d
Example: extended validation certificate
Network-security threat model
Traditional network-security model: trusted end nodes, unreliable network
End nodes send messages to the network and receive messages from it; the network may deliver, delete, modify and spoof messages
Metaphors: unreliable postman, bulletin board, dust bin
19
Network
=
AttackerAlice
Bob
Network security threats Traditional threats:
– Sniffing = attacker listens to network traffic– Spoofing = attacker sends unauthentic messages– Data modification (man in the middle) = attacker
intercepts and modifies data
Corresponding security requirements:– Data confidentiality– Data-origin authentication and data integrity– Q: Can there be integrity without authentication or
authentication without integrity?
Other treats: denial of service, server compromise, worms etc.
20
Secure web site (https)
22
HTTPS connections areencryptedauthenticatedpreventspoofing
HTTPS connections areencrypted and authenticated to prevent sniffing and spoofing
SSL/TLS in the protocol stack
SSL implements cryptographic encryption and authentication for TCP connections
SSL offers a secure socket API, similar to the TCP socket API, to applications
TLS is the standardized version of SSL– similar but not quite
compatible23
Applications:HTTP
Transport layer: TCP
Network layer: IP
Data link layer
Socket APISecure socket
API
SSL/TLS protocol SSL provides a secure connection over the insecure
network Two parts:
– Handshake i.e. authenticated key exchange creates a shared session key between the browser and the server
– Session protocol protects the confidentiality and intergrity of the session with symmetric encryption, message authentication codes, and the session key
Handshake may use digital signatures or RSA encryption Basic idea of the RSA-based handshake protocol:
– The server sends its certificate to the client, which thus learns the server name and public RSA key
– The browse generates random bytes, encrypts them with the servers RSA key, and sends to the server
Usually only the server authenticated
24
!
!
TLS handshake
25
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> A pplication Data
Trust chain In the handshake, browser receives a certificate chain
from the server Browser checks that the chain start with a (self-signed)
certificate that is in its trusted CA list Browser checks the certificate chain:
– Each certificate is signed with the subject key of the previous one
– All but last certificate are CA certificates– Some other details, e.g. CRL, key usage, constraints
If the certificate chain is valid, the last certificate binds the host name and the public key of the web server to each other– Public key used for server authentication in the handshake– Host name shown to user in the browser address bar
26
Certificate checking details1. Browser has a list of self-signed certificates for trusted root CAs2. In the SSL handshake, the browser receives a certificate chain from the server3. Browser checks that the root certificate in the received chain is in the trusted list4. Browser checks the validity of the certificate chain
A. Issuer of each certificate matches the subject of the previous certificateB. Signature of each certificate is verified with the subject public key of the previous certificateC. All certificates are CA certificates, except for the last one, which is an end-entity certificateD. Browser downloads and checks the CRL for every certificate that specifies one
5. Extended key usage field of the end-entity certificate must specify SLL server authentication: check that the certificate has been issued for this purpose
6. Any constraints in the certificates must also be checked7. Browser checks that the host name in the address bar matches the subject name
of the end-entity certificate8. Browser uses the subject key from the end-entity certificate in the authenticated
key exchange with the server9. The created session key is used to encrypt and authenticate data between the
browser and server
The user know that the web page shown in the browser belongs to the server whose name is shown in the address bar
27
28
Certificate of the web serverwebmail3.tkk.fi
Certificate of the web serverwebmail3.tkk.fi
Issuer is Sonera Class2 CAIssuer is Sonera Class2 CA
Thanks to the trustchainknowsserverwebmail3.tkk.fi
Thanks to the trustchain, the userknows that thisserver really is webmail3.tkk.fi
How does the userknowwebmailshouldname
How does the userknow that the webmail servershould have the name webmail3?
Sonera root CA wason the userthe certificateweb and to the root
Sonera root CA wason pre-installed in the browser; so the user downloadedthe self-signedcertificate from the web and added it to the list of trustedroot CAs
Exercises Set up your own CA with OpenSSL (or a commercial CA
implementation if you have access to one) and try to use it for protecting web access; what were the difficult steps?
What are extended validation certificates and how do they improve security?
Find several web and user certificates and compare the names and certification paths on them
Why do almost all web sites have certificate chains with two CAs and not just one?
Why is the front page of a web site often insecure (HTTP) even if the password entry and/or later data access are secure (HTTPS)? What security problems can this cause?
What actions are required from the user when connecting to a secure bank web site?
29