+ All Categories
Home > Documents > Certificates and network security - Aalto · Certificates and network security. Outline X.509...

Certificates and network security - Aalto · Certificates and network security. Outline X.509...

Date post: 28-Jul-2018
Category:
Upload: hadiep
View: 242 times
Download: 0 times
Share this document with a friend
30
Tuomas Aura T-110.4206 Information security technology Certificates and network security
Transcript

Tuomas AuraT-110.4206 Information security technology

Certificates and network security

Outline

X.509 certificates

Network security basics

Secure socket layer

(More in the course T-110.5240 Network security, period II)

2

X.509 CERTIFICATES

3

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],

[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 BASICS

18

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 SOCKET LAYER

21

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

Related reading

Stallings and Brown: Computer security, principles and practice, 2008, chapters 21-22

– other Stallings books have similar sections

Dieter Gollmann: Computer Security, 2nd ed., chapter 12-13

Matt Bishop: Introduction to computer security, chapter 13

30


Recommended