Public Key Infrastructures · 2015-05-19 · A web of trust is a concept used in PGP, GnuPG, and...

Preview:

Citation preview

Public Key

Infrastructures

Andreas Hülsing

Based on a lecture by

Johannes Braun, Johannes Buchmann, Alexander

Wiesmaier

https://www.cdc.informatik.tu-darmstadt.de/en/students/teaching/ss14/

vorlesung/pki/pki-unterlagen-kopie-1/

Book: J. Buchmann, E. Karatsiolis, and A. Wiesmaier

Introduction to Public Key Infrastructures

Springer-Verlag Berlin Heidelberg, 2013.

PAGE 119-5-2015

Key Exchange Problem

PAGE 219-5-2015

n*(n-1)/2 keys = O(n2)

[From: http://www.internetworldstats.com/stats.htm , June 30, 2012]

Internet: 2,405,518,376 users

2,892,056,568,246,079,500 keys≈2,9* 1018 keys

Solution 1: Key Server

PAGE 319-5-2015

Key-Server

The key-server knows all secret keys!

Authentication Center

PAGE 419-5-2015

• The authentication center (AC) in mobile

communications knows all the keys.

It stores them in a database.[From “IT-Sicherheit”, page 785, 800]

Solution 2: Use Public Key Crypto

PAGE 519-5-2015

Public-Key-Server

The server does not know any private information!

Asymmetric encryption problems

Performance

Key availability

Key ownership

Key validity

Public-Key-Server

PAGE 619-5-2015

Hybrid encryption

PAGE 719-5-2015

plaintextdecrypt

Sdkfj

kj

djd

fj

djf

jkj

encryptplaintext

decryptencrypt

symmetric session key

Bob’s

public

Bob’s

private

Digital signature problems

PAGE 819-5-2015

Key availability

Key ownership

Key validity

Public-Key-Server

Public Key Infrastructures

… a public key infrastructure (PKI) is designed to

facilitate the use of public key cryptography.

Source: Housley, R. and Polk, T.: Planning for PKI; Wiley 2001

PAGE 1019-5-2015

Tasks of a PKI

• Assure that the public key is available

• Assure that the public key is authentic

• Assure that the public key is valid

• Enforce security and interoperability

PAGE 1119-5-2015

Authenticate Public Keys

• Bind public key to electronic identity

• Seal the binding

• Answer for the binding

Public key certificates

PAGE 1219-5-2015

Public Key Certificate

Public key certificates are data structures that bind

public key values to subjects. The binding is

asserted by having a trusted CA digitally sign each

certificate …

[From RFC 5280]

PAGE 1319-5-2015

Public Key Certificate

PAGE 1419-5-2015

Public Key Certificate

PAGE 1519-5-2015

Digital Signature

Subject (Name)

Public-keyBinding eID public key

protection of authenticity

Certificate Properties

• Protected binding of a key to the key holder

• Its authenticity is independent of the means of

transportation

• It can be used online and offline

• It is a proof of the binding

• It can be used for key servers

PAGE 1619-5-2015

Certificate Standards

PAGE 1719-5-2015

• X.509• X.509 (ITU-T)

• PKIX (RFC 5280)

• Pretty Good Privacy (PGP)• OpenPGP (RFC 4880)

• GNU Privacy Guard (GnuPG or GPG)

• WAP certificates• Like X.509 certificates but smaller

• Card Verifiable Certificates (CVC)• Even smaller than WAP certificates

• Simple PKI / Simple Distributed Security Infrastructure• SPKI, pronounced spoo-key

• SDSI, pronounced sudsy

Validity of Public Keys

• Monitor binding public key electronic identity

key owner

• Establish time constraints

• Provide means to revoke binding

Certificate revocation

PAGE 1819-5-2015

Certificate Revocation

PAGE 1919-5-2015

• Abortive ending of the binding between

• subject and key (public key certificate)

OR

• subject and attributes (attribute certificate)

• The revocation is initiated by

• the subject

OR

• the issuer

• Typical frequency (assumption):

• 10% of the issued certificates will be revoked (See: “Selecting

Revocation Solutions for PKI” by Årnes, Just, Knapskog, Lloyd and Meijer)

Certificate Revocation List

PAGE 2019-5-2015

Publish Public Key Information

PAGE 2119-5-2015

• Directories• (L)DAP

• Active Directory

• Web pages• HTTP

• File transfer• FTP

• Services

• OCSP

• SCVP

LDAP

PAGE 2219-5-2015

Security of Key Pairs

Select suitable algorithms and key sizes

Monitor possible security threads and react adequately

Provide suitable means to generate key pairs

Provide suitable formats and media to store private keys

Provide suitable means of delivering private keys

Personal security environments

PAGE 2319-5-2015

PSE: Smartcard

PAGE 2419-5-2015

Interoperability

• Comply to accepted (international) standards

• Certificates / revocations

− X.509, PGP, SPKI/SDSI, …

• Directory services

− (L)DAP, Active Directory, …

• Cryptographic algorithms / protocols / formats

− PKCS, RFC, …

• Constraints on content and processing

− PKIX, ISIS-MTT, …

PAGE 2519-5-2015

Policy Enforcement

• Certificate policy (CP)

• States what to comply to

• Certificate practice statement (CPS)

• States how to comply

• Policies are enforced by the PKI through:

• Selecting standards, parameters, hardware, …

• Monitor behavior of involved parties

• Reacting on infringement of the policy

PAGE 2619-5-2015

Trust Models

PAGE 2719-5-2015

Trust

The perhaps most important part of a PKI is to

establish trust in the binding between an entity and a

certificate

PAGE 2819-5-2015

Direct Trust

PAGE 2919-5-2015

• User receives public key directly from owner

OR

• User verifies public key directly with owner

Most Common: Fingerprint comparison

PAGE 3019-5-2015

Fingerprint = hash value of the certificate (incl. Signature) (e.g. SHA1)

Face-to-Face Verification

PAGE 3119-5-2015

Phone Verification

PAGE 3219-5-2015

Web Page Verification

PAGE 3319-5-2015

http://www.cacert.org/index.php?id=3

Printed Media Verification

PAGE 3419-5-2015

BNetzA publishes the public key

…and more

PAGE 3519-5-2015

~# gpg --list-public-keys

/root/.gnupg/pubring.gpg

------------------------

pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team

<security@suse.de>

pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key

<build@suse.de>

sub 2048g/8495160C 2000-10-19 [expires: 2006-02-12]

e.g. public keys on software CD/DVD

Summary: Direct Trust

• Establishes• Which keys are authentic

• Why they are considered authentic

• Bad scalability• n * (n-1) = O(n2) verifications

• Worse complexity than secret key exchange!

• Basis for all other trust models• To be seen

PAGE 3619-5-2015

PGP(Pretty Good Privacy)

PAGE 3719-5-2015

Web of Trust

PAGE 3819-5-2015

[From PGP-Pretty Good Privacy by Simon Garfinkel]

Web of Trust

PAGE 3919-5-2015

A web of trust is a concept used in PGP, GnuPG, and

other OpenPGP-compatible systems to establish the

authenticity of the binding between a public key and a

user.

Its decentralized trust model is an alternative to the

centralized trust model of a public key infrastructure

(PKI), which relies exclusively on a certificate authority

(or a hierarchy of such).

Source: http://en.wikipedia.org/wiki/Web_of_trust

Key Validity

PAGE 4019-5-2015

• Alice computes key validity using Bob’s signatures

Carl

Dorian

BobAlice

Chaining Key Validity

PAGE 4119-5-2015

• Alice computes key validity using Bob’s and Carl’s

signatures

Alice Bob Carl

Dorian

Eve

Public Keyring

PAGE 4219-5-2015

Public Keyring

PAGE 4319-5-2015

Alice’s public keyring

Key Validity vs. Owner Trust

PAGE 4419-5-2015

• Key Validity:

• Is the key owner who he claims to be?

• Levels: no answer; unknown; marginal; complete;

ultimate

• Owner trust:

• Is the key owner reliable? (in respect to signing keys of others)

• Levels: unknown; none; marginal; complete; ultimate

Key Validity: Levels

PAGE 4519-5-2015

• no answer

• Nothing is said about this key.

• unknown

• Nothing is known about this key.

• marginal

• The key probably belongs to the name.

• complete

• The key definitely belongs to the name.

• (ultimate)

• (Own keys).

Owner Trust: Levels

PAGE 4619-5-2015

• unknown

• Nothing can be said about the owner's judgmentin key signing.

• none

• The owner is known to improperly sign keys.

• marginal

• The owner is known to properly sign keys.

• complete

• The owner is known to put great care in keysigning.

• ultimate

• The owner is known to put great care in keysigning, and is allowed to make trust decisions foryou.

Assigning Key Validity

• Manually (Key Signing)

OR

• computed from the trust in the corresponding

signers, only considering signers with key validity

“complete” (or better).

PAGE 4719-5-2015

Assigning Key Validity

PAGE 4819-5-2015

Alice signs the public key of other users.

Key Signing: Direct Trust

PAGE 4919-5-2015

Bob’s key validity is complete for Alice because she decided it when signing the key after verifying the fingerprint.

Key Validity Computation: “complete” (1)

PAGE 5019-5-2015

If the key is signed by at least one user with owner trust complete.

Key Validity Computation: “complete” (2)

PAGE 5119-5-2015

If the key is signed by at least x (here x=2) names with owner trust marginal.

Key Validity Computation: “marginal”

PAGE 5219-5-2015

If the key is signed by less than x (here x=2) names with owner trust marginal.

Key Validity Computation: “unknown”

PAGE 5319-5-2015

If the key is signed by no name with at least owner trust marginal

Assigning Owner Trust

• Manually (Trust Setting)

OR

• computed from the owner trust of signers only using

“ultimate” valid keys.

PAGE 5419-5-2015

Trust Anchor: Owner Trust

PAGE 5519-5-2015

Alice assigns owner trust to users.

“Simple” PGP

PAGE 5619-5-2015

Alice signs Bob’s key (level 0) and trusts him. Alice uses Bob’s signatures on Dorian’s and Frank’s

keys.

Trusted Introducers

PAGE 5719-5-2015

Alice signs Bob’s key (level 1) and trusts him. Bob signs Carl’s key (level 0) and trusts him. Alice uses Carl’s signatures on Dorian’s and Frank’s

keys. Bob = Trusted Introducer

By allowing more intermediate signers (level >1), Bob becomes a Meta Introducer

PGP Certificates

PAGE 5819-5-2015

PGP Certificates: Content

PAGE 5919-5-2015

[From http://www.ece.cmu.edu/~adrian/630-f04/PGP-intro.html]

How to share Keys with PGP

• Attach to mail

• Use Key Server

→ Still need to verify key validity!

PAGE 6019-5-2015

PGP Keys

PAGE 6119-5-2015

http://pgp.jjim.de/sks/

• http://www.rediris.es/keyserver/graph.html

PGP Keyserver Synchronization Graph

PGP Revocation

• Uses Key Revocation Certificate

• generated during KeyGen using private key

• Uploading Key Revocation Certificate to one of the

public key servers revokes key pair.

• Key Revocation Certificate can contain new UserID

PAGE 6319-5-2015

X.509

PAGE 6419-5-2015

Example: Secured Website

Click once

PAGE 6619-5-2015

Click on button

Click on view

Click on details

PAGE 6919-5-2015

In the browser

The browser is shipped with trusted authorities

Built-in object token

Bob Carl

Hierarchical trust

Alice

Certification Authority (CA) trust anchor

issues certificates

DFN PCA

TUD CA Uni Gießen

Alice Bob Carl Doris Emil

TUD Student CA TUD Employee CA

Hierarchical trust

root CA

Why does Alice trust in Doris’ key?

Why does Alice trust in Doris’ key?

DFN PCA

TUD CA Uni Gießen

Alice Bob Carl Doris Emil

TUD Student CA TUD Employee CA

Hierarchical trust

root CA

Alice

TUD Student CA

TUD CA

TUD Employee CATUD Student CA

DFN PCADFN PCA

TUD CA Uni Gießen

Alice Bob Carl Doris Emil

Hierarchical trust

Emil to Alice

Trust anchor

Certification path

Public-key in question

Intermediate CAs

Trust models in multiple hierarchies

TC2

Alice Bob Carl Doris Emil

TC4 TC5

TC3

TC6 TC7

Fred Gerd Hans

When does Alice accept the certificate of Fred?

Method 1: Trusted List

TC2

Alice Bob Carl Doris Emil

TC4 TC5

TC3

TC6 TC7

Fred Gerd Hans

Every participant has a list of trusted CAs. Alice trusts TC2 and TC3 Every user maintains an own list (like in the Web of Trust) Used in Web Browsers (preinstalled + user defined)

Trusted List: certification path

TC2

Alice Bob Carl Doris Emil

TC4 TC5

TC3

TC6 TC7

Fred Gerd Hans

Alice to Fred

Trusted List: Example

Trusted List: Example

Method 2: Common Root

Every user who trusts TC1, accepts every other end-user certificate.

TC2

Alice Bob Carl Doris Emil

TC4 TC5

TC3

TC6 TC7

Fred Gerd Hans

TC1

Common Root: certification path

TC2

Alice Bob Carl Doris Emil

TC4 TC5

TC3

TC6 TC7

Fred Gerd Hans

TC1

Alice to Fred

Method 3: Cross-certification

TC2 issues a CA-certificate for TC3.

TC3 issues a CA-certificate for TC2.

Every user who trusts TC3, accepts every certificate, that was issued by TC2

(or a subordinate CA). Every user who trusts TC2, accepts every certificate, that was issued by TC3

(or a subordinate CA).

Not always bilateral

TC2

Alice Bob Carl Doris Emil

TC4 TC5

TC3

TC6 TC7

Fred Gerd Hans

Cross-certification

TC2

Alice Bob Carl Doris Emil

TC4 TC5

TC3

TC6 TC7

Fred Gerd Hans

Alice to Fred

Cross-certification: Another possibility

TC2

Alice Bob Carl Doris Emil

TC4 TC5

TC3

TC6 TC7

Fred Gerd Hans

TC2 issues one CA-certificate to TC7 and vice versa.

Hans accepts the certificate of Emil and vice versa.

Emil does not accept the certificate of Fred.

TC2

Alice Bob Carl Doris Emil

TC4 TC5

TC3

TC6 TC7

Fred Gerd Hans

TC4 issues one CA-certificate to TC6 and vice versa.

Alice accepts the certificate of Fred and vice versa.

Fred does not accept the certificate of Emil.

Cross-certification: Another possibility

Cross-certification

n*(n-1) cross-certificats =

O(n2)

n*(n-1) cross-certificats =

O(n2)

Method 4: Bridge

Idea: Bridge TC has cross-certifications with TC2 and TC3.

Alice accepts all certificates beneath TC3.

Fred accepts all certificates beneath TC2.

TC2

Alice Bob Carl Doris Emil

TC4 TC5

TC3

TC6 TC7

Fred Gerd Hans

Bridge TC

Bridge: certification path

TC2

Alice Bob Carl Doris Emil

TC4 TC5

TC3

TC6 TC7

Fred Gerd Hans

Bridge TC

Alice to Fred

Bridge enforces minimal policy

Bridge Trust Center

• The bridge TC acts as a connector.

• This TC is not subordinate to a third CA.

• Interesting for corporate CAs that:

• want to enable secure communication for their users outside the organisation’s borders.

• do not want to be subordinate to a third CA.

URL: http://www.bridge-ca.org

European Bridge-CA

Certification Path Validation

PAGE 9819-5-2015

Shell model

time

root

certificate

CA

certificate

participant

certificate

signature

time

verification

time

Modified or hybrid model

time

root

certificate

CA

certificate

participant

certificate

signature

time

verification

time

Chain model

time

root

certificate

CA

certificate

participant

certificate

signature

time

verification

time

Shell model

Certificate 1

Certificate 2

Certificate 3

Signed Document

Sig. valid creation

Signature valid verification

Signature invalid verification

Time

Signed Document

Chain model

Sig. valid creation

Signature valid

Certificate 1

Certificate 3

Certificate 2

verification

Time

Chain model:

multiple-

validation Document A

Document B

Document C

Signature verification:

Certificate 1

Certificate 3

Certificate 2

Document A

Time

Document B

Document C

?

!

Algorithms

Certificate 1

Certificate 2

Shell model

Chain model

Hybrid model

Time

Signature valid Signature invalid

Sig. valid creation

Signature valid

Sig. valid creation

Signature valid

Root CA

CA

Participant

Chain model

Hybrid model

Time [a]

Sig. valid creation (max. 3 a)

Signature valid

Sig. valid creation (max. 1 a)

Signature valid

1 2 3 4 5 6

X.509 Certificates

PAGE 10719-5-2015

X.509 Certificates

Relevant Standard:

X.509 (ITU-T)

PKIX (RFC 5280)

Content (excerpt):

Name / Pseudonym of the holder

Public Key (and algorithm) of the holder

Unique ID of the certificate

Validity period of the certificate

Identity of the certificate issuer

Key usage limitation for the public keys

Encoding:

Abstract Syntax Notation Nr.1: ASN.1

Distinguished Encoding Rules: DER

PAGE 10819-5-2015

X.509 Certificates

X.509 Certificates: Contents

Version (0=v1, 1=v2, 2=v3)Serial Number (Unique within PKI)Certificate Signature AlgorithmIssuerValidity PeriodSubjectSubject Public Key Info

Version 1

(1988)

Subject Unique ID (worldwide unique)Issuer Unique ID (worldwide unique)Version 2

(1993)

ExtensionsVersion 3

(1997)

PAGE 11019-5-2015

X.509 Extensions: Properties

• Assignment of extra attributes to

• the owner

• public or private key

• issuer

• Support for better certificate management

• Arbitrary extensions Bad interoperability

PAGE 11119-5-2015

X.509 (Non)critical extensions

Critical Non-Critical

Known valid valid

Unknown invalid valid

PAGE 11219-5-2015

Key Usage

Defines the purpose of the key contained in the certificate.

KeyUsage ::= BIT STRING {

digitalSignature (0),

nonRepudiation (1),

keyEncipherment (2),

dataEncipherment (3),

keyAgreement (4),

keyCertSign (5),

cRLSign (6),

encipherOnly (7),

decipherOnly (8) }

http://www.ietf.org/rfc/rfc5280.txt (pp 29ff)

PAGE 11319-5-2015

Extended Key Usage (1)

Indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension

For example:

• Code signing

• OCSP signing

• Timestamping

ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId

KeyPurposeId ::= OBJECT IDENTIFIER

PAGE 11419-5-2015

Extended Key Usage (2)

If a certificate contains both a key usage extension and

an extended key usage extension, then both

extensions MUST be processed independently and the

certificate MUST only be used for a purpose consistent

with both extensions. If there is no purpose consistent

with both extensions, then the certificate MUST NOT

be used for any purpose.

Source: RFC 4334

PAGE 11519-5-2015

Recommended