1. Public Key Infrastructures
Andreas Hülsing

2. Key Exchange Problem Internet: 2016: 2,405,518,376 users
7,548,817,858,967,880,771 keys
≈7,5 * 1018 keys
n*(n-1)/2 keys = O(n2)
[From: ]

3. Solution 1: Key Server The key-server knows all secret keys!

4. Authentication Center
The authentication center (AC) in mobile communications knows all the keys.
It stores them in a database.
[From “IT-Sicherheit”, page 785, 800]

5. Solution 2: Use Public Key Crypto
Public-Key-Server
The server does not know any private information!

6. Asymmetric encryption problems
Public-Key-Server
Performance
Key availability
Key ownership
Key validity

7. Sdkfj ölakjs ödasjd följasö ldjföas jölakj
Hybrid encryption
symmetric session key
Bob’s
public
private
Sdkfj ölakjs ödasjd följasö ldjföas jölakj
encrypt
plaintext
decrypt
plaintext
decrypt
encrypt

8. Digital signature problems
Public-Key-Server
Key availability
Key ownership
Key validity

9. Key Validity?

10. Lifetime of Hash Functions
Source:

11. RSA - published in 1978
…using 200 digits provides a margin of safety against future developments…

12. RSA Factoring Challenge
number
digits
prize
factored
RSA-100
100
Apr. 1991
RSA-110
110
Apr. 1992
RSA-120
120
Jun. 1993
RSA-129
129
$100
Apr. 1994
RSA-130
130
Apr. 10, 1996
RSA-140
140
Feb. 2, 1999
RSA-150
150
Apr. 16, 2004
RSA-155
155
Aug. 22, 1999
RSA-160
160
Apr. 1, 2003
RSA-200
200
May 9, 2005
RSA-576
174
$10,000
Dec. 3, 2003
RSA-640
193
$20,000
Nov. 4, 2005
RSA-704
212
$30,000
July 2, 2012
RSA-768
232
$50,000
Dec. 12, 2009
RSA-896
270
$75,000
not factored
RSA-1024
309
$100,000
RSA-1536
463
$150,000
RSA-2048
617
$200,000
Challenge is no longer active, original webpage unavailable
but you can see results

13. ECC challenges ECC Field Size Days Date ECC2-79 79 352 1997 ECC2-89 89
11278
1998
ECC2K-95 97
8637
ECC2-97
180448
1999
ECC2K-108
109
1.3x10^6
2000
ECC2-109
2.1x10^7
2004
ECCp-79
146
ECCp-89
4360
ECCp-97
71982
ECCp-109
9x10^7
2002
[From

14. Moore’s Law

15. Improved Cryptanalysis
2013

16. Another Problem

17. Post-Quantum Crypto Hash-based signatures Lattice-based cryptography
Coding-based cryptography
Multivariate cryptography

18. Public key infrastructures

19. 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

20. 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

21. Authenticate Public Keys
Bind public key to electronic identity
Seal the binding
Answer for the binding
 Public key certificates

22. 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]

23. Public Key Certificate

24. Public Key Certificate
Digital Signature
Subject (Name)
Public-key
Binding eID  public key
protection of authenticity

25. Certificate Properties
Protected binding of a key to the key holder
Authenticity independent of means of transportation
Can be used online and offline
Proof of the binding
Can be used for key servers

26. Certificate Standards
X.509
X.509 (ITU-T)
PKIX (RFC 5280)
Pretty Good Privacy (PGP)
OpenPGP (RFC 4880)
GNU Privacy Guard (GnuPG or GPG)
Card Verifiable Certificates (CVC)
Even smaller than WAP certificates
Simple PKI / Simple Distributed Security Infrastructure
SPKI, pronounced spoo-key
SDSI, pronounced sudsy

27. Validity of Public Keys
Monitor binding public key  electronic identity  key owner
Establish time constraints
Provide means to revoke binding
 Certificate revocation

28. Certificate Revocation
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
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)

29. Certificate Revocation List

30. Publish Public Key Information
Directories
(L)DAP
Active Directory
Web pages
HTTP
File transfer
FTP
Services
OCSP
SCVP
draft-ietf-pkix-scvp-10 - Server-Based Certificate Validation Protocol ...

31. LDAP

32. 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

33. PSE: Smartcard

34. 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, …

35. 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

36. Trust Models

37. Trust
The perhaps most important part of a PKI is to establish trust in the binding between an entity and a certificate

38. Direct Trust User receives public key directly from owner OR
User verifies public key directly with owner

39. Most Common: Fingerprint comparison
Fingerprint = hash value of the certificate (incl. Signature)
(e.g. SHA1)

40. Face-to-Face Verification

41. Phone Verification

42. Web Page Verification

43. Printed Media Verification
BNetzA publishes the public key

44. …and more e.g. public keys on software CD/DVD
~# gpg --list-public-keys
/root/.gnupg/pubring.gpg
pub 2048R/3D25D3D SuSE Security Team
pub 1024D/9C800ACA SuSE Package Signing Key
sub 2048g/ C [expires: ]

45. Summary: Direct Trust Establishes Bad scalability
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

46. PGP
(Pretty Good Privacy)

47. Web of Trust [From PGP-Pretty Good Privacy by Simon Garfinkel]

48. Web of Trust
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:

49. Key Validity Alice computes key validity using Bob’s signatures Carl
Dorian

50. Chaining Key Validity
Alice computes key validity using Bob’s and Carl’s signatures
Dorian
Alice
Bob
Carl
Eve

51. Public Keyring

52. Public Keyring
Alice’s public keyring

53. Key Validity vs. Owner Trust
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

54. Key Validity: Levels no answer unknown marginal complete (ultimate)
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).

55. Owner Trust: Levels unknown none marginal complete ultimate
Nothing can be said about the owner's judgment in 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 key signing.
ultimate
The owner is known to put great care in key signing, and is allowed to make trust decisions for you.

56. Assigning Key Validity
Manually (Key Signing) OR
computed from the trust in the corresponding signers, only considering signers with key validity “complete” (or better).

57. Assigning Key Validity
Alice signs the public key of other users.

58. Key Signing: Direct Trust
Bob’s key validity is complete for Alice because she decided it when signing the key after verifying the fingerprint.

59. Key Validity Computation: “complete” (1)
If the key is signed by at least one user with owner trust complete.

60. Key Validity Computation: “complete” (2)
If the key is signed by at least x (here x=2) names with owner trust marginal.

61. Key Validity Computation: “marginal”
If the key is signed by less than x (here x=2) names with owner trust marginal.

62. Key Validity Computation: “unknown”
If the key is signed by no one with owner trust at least marginal

63. Assigning Owner Trust Manually (Trust Setting) OR
computed from the owner trust of signers only using “ultimate” valid keys.

64. Trust Anchor: Owner Trust
Alice assigns owner trust to users.

65. “Simple” PGP Alice signs Bob’s key (level 0) and trusts him.
Alice uses Bob’s signatures on Dorian’s and Frank’s keys.

66. Trusted Introducers 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

67. PGP Certificates

68. PGP Certificates: Content
[From

69. How to share Keys with PGP
Attach to mail
Use Key Server
→ Still need to verify key validity!

70. PGP Keys

71. PGP Keyserver Synchronization Graph

72. 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

73. X.509

74. Example: Secured Website
TODO: adapt to Firefox 4 |

75. Click once

76. Click on button
TODO: adapt to Firefox 4 |

77. Click on view
TODO: adapt to Firefox 4 |

78. Click on details

79. The browser is shipped with trusted authorities
In the browser
TODO: adapt to Firefox 4
The browser is shipped with trusted authorities |

80. Built-in object token
TODO: adapt to Firefox 4

81. Certification Authority (CA)
Hierarchical trust
Certification Authority (CA)
trust anchor
issues certificates
Alice
Bob
Carl

82. Hierarchical trust Why does Alice trust in Doris’ key? DFN PCA root CA
TUD CA
Uni Gießen
TUD Student CA
TUD Employee CA
Alice
Bob
Carl
Doris
Emil

83. Hierarchical trust Why does Alice trust in Doris’ key? DFN PCA root CA
TUD CA
Uni Gießen
TUD Student CA
TUD Employee CA
Alice
Bob
Carl
Doris
Emil

84. Hierarchical trust DFN PCA DFN PCA Emil to Alice TUD CA TUD CA
Uni Gießen
TUD Student CA
TUD Student CA
TUD Employee CA
Alice
Alice
Bob
Carl
Doris
Emil
Trust anchor
Public-key in question
Certification path
Intermediate CAs

85. Trust models in multiple hierarchies
When does Alice accept the certificate of Fred?
TC2
TC3
TC4
TC5
TC6
TC7
Alice
Bob
Carl
Doris
Emil
Fred
Gerd
Hans

86. Method 1: Trusted List 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)
TC2
TC3
TC4
TC5
TC6
TC7
Alice
Bob
Carl
Doris
Emil
Fred
Gerd
Hans

87. Trusted List: certification path
Alice to Fred
TC2
TC3
TC4
TC5
TC6
TC7
Alice
Bob
Carl
Doris
Emil
Fred
Gerd
Hans

88. Trusted List: Example

89. Trusted List: Example

90. Method 2: Common Root
Every user who trusts TC1, accepts every other end-user certificate.
TC1
TC2
TC3
TC4
TC5
TC6
TC7
Alice
Bob
Carl
Doris
Emil
Fred
Gerd
Hans

91. Common Root: certification path
Alice to Fred
TC1
TC2
TC3
TC4
TC5
TC6
TC7
Alice
Bob
Carl
Doris
Emil
Fred
Gerd
Hans

92. Method 3: Cross-certification
TC2
TC3
TC4
TC5
TC6
TC7
Alice
Bob
Carl
Doris
Emil
Fred
Gerd
Hans
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
Not always bilateral

93. Cross-certification Alice to Fred TC2 TC3 TC4 TC5 TC6 TC7 Alice Bob
Carl
Doris
Emil
Fred
Gerd
Hans

94. Cross-certification: Another possibility
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
TC3
TC4
TC5
TC6
TC7
Alice
Bob
Carl
Doris
Emil
Fred
Gerd
Hans

95. Cross-certification: Another possibility
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.
TC2
TC3
TC4
TC5
TC6
TC7
Alice
Bob
Carl
Doris
Emil
Fred
Gerd
Hans

96. n*(n-1) cross-certificats = O(n2)
Cross-certification
n*(n-1) cross-certificats = O(n2)
n*(n-1) cross-certificats = O(n2)

97. 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
Bridge TC
TC3
TC4
TC5
TC6
TC7
Alice
Bob
Carl
Doris
Emil
Fred
Gerd
Hans

98. Bridge: certification path
Alice to Fred
Bridge enforces minimal policy
TC2
Bridge TC
TC3
TC4
TC5
TC6
TC7
Alice
Bob
Carl
Doris
Emil
Fred
Gerd
Hans

99. 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.

100. European Bridge-CA
URL:

101. Certification Path Validation

102. Shell model PKIX: sig time und verification time identisch
CDC shell modell: signature time muss <= verification time sein UND innerhalb des gültigkeitszeitraums der zertifikatskette liegen.

103. Modified or hybrid model

104. Chain model
4. Dezember 2018
Martin: why would CA issue a certificate longer (time) than herself?? |

105. Time Sig. valid creation Shell model Signature valid verification
Certificate 1
Certificate 2
Certificate 3
Signed Document
Time
Sig. valid creation
Shell model
Signature valid
verification
Signature invalid
verification

106. Time Sig. valid creation Chain model Signature valid verification
Certificate 1
Certificate 2
Certificate 3
Signed Document
Time
Sig. valid creation
Chain model
Signature valid
verification

107. ! ? Chain model: multiple- validation Time Signature verification:
Certificate 1
Certificate 2 !
Certificate 3
Chain model:
multiple-
validation
Document A
Document B
Document C ?
Time
Signature verification:
Document A
Document B
Document C

108. Algorithms Certificate 1 Certificate 2 Time Shell model Hybrid model
Signature valid
Signature invalid
Shell model
Sig. valid creation
Cert 1 = root
Cert 2 = sub
Hybrid model
Signature valid
Sig. valid creation
Chain model
Signature valid

109. Root CA CA Participant 1 2 3 4 5 6 Time [a] Hybrid model Chain model
Sig. valid creation (max. 1 a)
Root ca wechselt mit neuen certs zu neuen schlüsseln
Hybrid model
Signature valid
Sig. valid creation (max. 3 a)
Chain model
Signature valid

110. X.509 Certificates

111. X.509 Certificates Relevant Standard: X.509 (ITU-T) PKIX (RFC 5280)
Encoding:
Abstract Syntax Notation Nr.1: ASN.1
Distinguished Encoding Rules: DER
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

112. X.509 Certificates

113. X.509 Certificates: Contents
Version (0=v1, 1=v2, 2=v3)
Serial Number (Unique within PKI)
Certificate Signature Algorithm
Issuer
Validity Period
Subject
Subject Public Key Info
Version 1 (1988)
Subject Unique ID (worldwide unique)
Issuer Unique ID (worldwide unique)
Version 2 (1993)
Extensions
Version 3 (1997)

114. 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

115. X.509 (Non)critical extensions
Known
valid
Unknown
invalid

116. Key Usage digitalSignature (0), nonRepudiation (1),
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) }
(pp 29ff)

117. Extended Key Usage (1) Code signing OCSP signing Timestamping
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

118. 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

119. Johannes Braun, Johannes Buchmann, Alexander Wiesmaier
Based on a lecture by
Johannes Braun, Johannes Buchmann, Alexander Wiesmaier
vorlesung/pki/pki-unterlagen-kopie-1/
Book: J. Buchmann, E. Karatsiolis, and A. Wiesmaier Introduction to Public Key Infrastructures Springer-Verlag Berlin Heidelberg, 2013.