Public Key Infrastructures Andreas Hlsing Key Exchange Problem
Public Key Infrastructures Andreas Hülsing
Key Exchange Problem Internet: 2016: 2, 405, 518, 376 users 2017: 3, 885, 567, 619 users 7, 548, 817, 858, 967, 880, 771 keys ≈7, 5 * 1018 keys [From: http: //www. internetworldstats. com/stats. htm ] 19 -5 -2021 PAGE 1 n*(n-1)/2 keys = O(n 2)
Solution 1: Key Server Key-Server The key-server knows all secret keys! 19 -5 -2021 PAGE 2
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] 19 -5 -2021 PAGE 3
Solution 2: Use Public Key Crypto Public-Key-Server The server does not know any private information! 19 -5 -2021 PAGE 4
Asymmetric encryption problems § Performance § Key availability § Key ownership § Key validity Public-Key-Server 19 -5 -2021 PAGE 5
Hybrid encryption symmetric session key plaintext Sdkfj ölakjs ödasjd följasö ldjföas jölakj encrypt Bob’s public decrypt Bob’s private 19 -5 -2021 PAGE 6 plaintext
Digital signature problems § Key availability § Key ownership § Key validity Public-Key-Server 19 -5 -2021 PAGE 7
Key Validity? 19 -5 -2021 PAGE 8
Lifetime of Hash Functions Source: http: //valerieaurora. org/hash. html 19 -5 -2021 PAGE 9
RSA - published in 1978 …using 200 digits provides a margin of safety against future developments… 19 -5 -2021 PAGE 10
RSA Factoring Challenge number digits prize factored RSA-100 Apr. 1991 RSA-110 Apr. 1992 RSA-120 Jun. 1993 RSA-129 RSA-130 Apr. 10, 1996 RSA-140 Feb. 2, 1999 RSA-150 Apr. 16, 2004 RSA-155 Aug. 22, 1999 RSA-160 Apr. 1, 2003 RSA-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 not factored RSA-1536 463 $150, 000 not factored RSA-2048 617 $200, 000 not factored $100 Apr. 1994 19 -5 -2021 PAGE 11 Challenge is no longer active, original webpage unavailable but you can see results https: //en. wikipedia. org/wiki/ RSA_Factoring_Challenge
ECC challenges ECC Field Size Days Date ECC 2 -79 79 352 1997 ECC 2 -89 89 11278 1998 ECC 2 K-95 97 8637 1998 ECC 2 -97 97 180448 1999 ECC 2 K-108 109 1. 3 x 10^6 2000 ECC 2 -109 2. 1 x 10^7 2004 ECCp-79 79 146 1997 ECCp-89 89 4360 1998 ECCp-97 97 71982 1998 ECCp-109 9 x 10^7 2002 [From www. certicom. com/images/pdfs/challenge-2009. pdf] 19 -5 -2021 PAGE 12
Moore’s Law 19 -5 -2021 PAGE 13
Improved Cryptanalysis 2013 19 -5 -2021 PAGE 14
Another Problem 19 -5 -2021 PAGE 15
Post-Quantum Crypto • Hash-based signatures • Lattice-based cryptography • Coding-based cryptography • Multivariate cryptography 19 -5 -2021 PAGE 16
Public key infrastructures 19 -5 -2021 PAGE 17
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 19 -5 -2021 PAGE 18
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 19 -5 -2021 PAGE 19
Authenticate Public Keys • Bind public key to electronic identity • Seal the binding • Answer for the binding Public key certificates 19 -5 -2021 PAGE 20
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] 19 -5 -2021 PAGE 21
Public Key Certificate 19 -5 -2021 PAGE 22
Public Key Certificate Subject (Name) Public-key Binding e. ID public key protection of authenticity Digital Signature 19 -5 -2021 PAGE 23
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 19 -5 -2021 PAGE 24
Certificate Standards • X. 509 (ITU-T) • PKIX (RFC 5280) • Pretty Good Privacy (PGP) • Open. PGP (RFC 4880) • GNU Privacy Guard (Gnu. PG or GPG) • Card Verifiable Certificates (CVC) • Compact certificates • Simple PKI / Simple Distributed Security Infrastructure • SPKI, pronounced spoo-key • SDSI, pronounced sudsy 19 -5 -2021 PAGE 25
Validity of Public Keys • Monitor binding public key electronic identity key owner • Establish time constraints • Provide means to revoke binding Certificate revocation 19 -5 -2021 PAGE 26
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 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) 19 -5 -2021 PAGE 27
Example: Certificate Revocation List 19 -5 -2021 PAGE 28
Publish Public Key Information • Directories • (L)DAP • Active Directory • Web pages • HTTP • File transfer • FTP • Services • OCSP 19 -5 -2021 PAGE 29
Example: LDAP 19 -5 -2021 PAGE 30
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 19 -5 -2021 PAGE 31
Example PSE: Smartcard 19 -5 -2021 PAGE 32
Interoperability • Comply to accepted (international) standards • Certificates / revocations − X. 509, PGP, … • Directory services − (L)DAP, Active Directory, … • Cryptographic algorithms / protocols / formats − PKCS, RFC, … • Constraints on content and processing − PKIX, ISIS-MTT, … 19 -5 -2021 PAGE 33
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 19 -5 -2021 PAGE 34
Trust Models 19 -5 -2021 PAGE 35
Trust The perhaps most important part of a PKI is to establish trust in the binding between an entity and a certificate 19 -5 -2021 PAGE 36
Direct Trust • User receives public key directly from owner OR • User verifies public key directly with owner 19 -5 -2021 PAGE 37
Most Common: Fingerprint comparison Fingerprint = hash value of the certificate (incl. Signature) (e. g. SHA 1) 19 -5 -2021 PAGE 38
Face-to-Face Verification 19 -5 -2021 PAGE 39
Phone Verification 19 -5 -2021 PAGE 40
Web Page Verification http: //www. cacert. org/index. php? id=3 19 -5 -2021 PAGE 41
Printed Media Verification BNetz. A publishes the public key 19 -5 -2021 PAGE 42
…and more e. g. public keys on software CD/DVD / In preinstalled OS ~# gpg --list-public-keys /root/. gnupg/pubring. gpg ------------pub 2048 R/3 D 25 D 3 D 9 1999 -03 -06 Su. SE Security Team <security@suse. de> pub 1024 D/9 C 800 ACA 2000 -10 -19 Su. SE Package Signing Key <build@suse. de> sub 2048 g/8495160 C 2000 -10 -19 [expires: 2006 -02 -12] 19 -5 -2021 PAGE 43
Summary: Direct Trust • Establishes • Which keys are authentic • Why they are considered authentic • Bad scalability • n * (n-1) = O(n 2) verifications • Worse complexity than secret key exchange! • Basis for all other trust models • To be seen 19 -5 -2021 PAGE 44
PGP (Pretty Good Privacy) 19 -5 -2021 PAGE 45
Web of Trust [From PGP-Pretty Good Privacy by Simon Garfinkel] 19 -5 -2021 PAGE 46
Web of Trust A web of trust is a concept used in PGP, Gnu. PG, and other Open. PGP-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 19 -5 -2021 PAGE 47
Key Validity • Alice computes key validity using Bob’s signatures Carl Alice Bob Dorian 19 -5 -2021 PAGE 48
Chaining Key Validity • Alice computes key validity using Bob’s and Carl’s signatures Dorian Alice Bob Carl Eve 19 -5 -2021 PAGE 49
Public Keyring 19 -5 -2021 PAGE 50
Public Keyring § Alice’s public keyring 19 -5 -2021 PAGE 51
Key Validity vs. Owner Trust • 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 19 -5 -2021 PAGE 52
Key Validity: Levels • 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). 19 -5 -2021 PAGE 53
Owner Trust: Levels • unknown • 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. 19 -5 -2021 PAGE 54
Assigning Key Validity • Manually (Key Signing) OR • computed from the trust in the corresponding signers, only considering signers with key validity “complete” (or better). 19 -5 -2021 PAGE 55
Assigning Key Validity Alice signs the public key of other users. 19 -5 -2021 PAGE 56
Key Signing: Direct Trust Bob’s key validity is complete for Alice because she decided it when signing the key after verifying the fingerprint. 19 -5 -2021 PAGE 57
Key Validity Computation: “complete” (1) § If the key is signed by at least one user with owner trust complete. 19 -5 -2021 PAGE 58
Key Validity Computation: “complete” (2) § If the key is signed by at least x (here x=2) names with owner trust marginal. 19 -5 -2021 PAGE 59
Key Validity Computation: “marginal” § If the key is signed by less than x (here x=2) names with owner trust marginal. 19 -5 -2021 PAGE 60
Key Validity Computation: “unknown” § If the key is signed by no one with owner trust at least marginal 19 -5 -2021 PAGE 61
Assigning Owner Trust • Manually (Trust Setting) OR • computed from the owner trust of signers only using “ultimate” valid keys. 19 -5 -2021 PAGE 62
Trust Anchor: Owner Trust § Alice assigns owner trust to users. 19 -5 -2021 PAGE 63
“Simple” PGP § Alice signs Bob’s key (level 0) and trusts him. § Alice uses Bob’s signatures on Dorian’s and Frank’s keys. 19 -5 -2021 PAGE 64
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 19 -5 -2021 PAGE 65
PGP Certificates 19 -5 -2021 PAGE 66
PGP Certificates: Content [From http: //www. ece. cmu. edu/~adrian/630 -f 04/PGP-intro. html] 19 -5 -2021 PAGE 67
How to share Keys with PGP • Attach to mail • Use Key Server → Still need to verify key validity! 19 -5 -2021 PAGE 68
PGP Keys http: //pgp. jjim. de/sks/ 19 -5 -2021 PAGE 69
PGP Keyserver Synchronization Graph • http: //www. rediris. es/keyserver/graph. html
PGP Revocation • Uses Key Revocation Certificate • generated during Key. Gen using private key • Uploading Key Revocation Certificate to one of the public key servers revokes key pair. • Key Revocation Certificate can contain new User. ID 19 -5 -2021 PAGE 71
X. 509 19 -5 -2021 PAGE 72
Example: Secured Website
Click once 19 -5 -2021 PAGE 74
Click on button
Click on view
Click on details 19 -5 -2021 PAGE 77
In the browser The browser is shipped with trusted authorities
Built-in object token
Hierarchical trust Certification Authority (CA) trust anchor issues certificates Alice Bob Carl
Hierarchical trust § Why does Alice trust in Doris’ key? DFN PCA TUD Student CA TUD Employee CA Alice Carl Bob root CA Uni Gießen Doris Emil
Hierarchical trust § Why does Alice trust in Doris’ key? DFN PCA TUD Student CA TUD Employee CA Alice Carl Bob root CA Uni Gießen Doris Emil
Hierarchical trust DFN PCA Emil to Alice TUD CA TUD Student CA Alice Bob Trust anchor Public-key in question Certification path Intermediate CAs Uni Gießen TUD Employee CA Carl Doris Emil
Trust models in multiple hierarchies § When does Alice accept the certificate of Fred? TC 2 TC 4 Alice Bob TC 3 TC 5 Carl Doris Emil TC 6 Fred TC 7 Gerd Hans
Method 1: Trusted List § § Every participant has a list of trusted CAs. Alice trusts TC 2 and TC 3 Every user maintains an own list (like in the Web of Trust) Used in Web Browsers (preinstalled + user defined) TC 2 TC 4 Alice Bob TC 3 TC 5 Carl Doris Emil TC 6 Fred TC 7 Gerd Hans
Trusted List: certification path § Alice to Fred TC 2 TC 4 Alice Bob TC 3 TC 5 Carl Doris Emil TC 6 Fred TC 7 Gerd Hans
Trusted List: Example
Trusted List: Example
Method 2: Common Root § Every user who trusts TC 1, accepts every other end-user certificate. TC 1 TC 2 TC 4 Alice Bob TC 3 TC 5 Carl Doris Emil TC 6 Fred TC 7 Gerd Hans
Common Root: certification path § Alice to Fred TC 1 TC 2 TC 4 Alice Bob TC 3 TC 5 Carl Doris Emil TC 6 Fred TC 7 Gerd Hans
Method 3: Cross-certification TC 2 TC 3 TC 4 Alice Bob TC 5 Carl Doris TC 2 issues a CA-certificate for TC 3 issues a CA-certificate for TC 2. Emil TC 6 Fred TC 7 Gerd Hans Not always bilateral Every user who trusts TC 3, accepts every certificate, that was issued by TC 2 (or a subordinate CA). Every user who trusts TC 2, accepts every certificate, that was issued by TC 3 (or a subordinate CA).
Cross-certification § Alice to Fred TC 2 TC 4 Alice Bob TC 3 TC 5 Carl Doris Emil TC 6 Fred TC 7 Gerd Hans
Cross-certification: Another possibility TC 2 issues one CA-certificate to TC 7 and vice versa. Hans accepts the certificate of Emil and vice versa. Emil does not accept the certificate of Fred. TC 2 TC 4 Alice Bob TC 3 TC 5 Carl Doris Emil TC 6 Fred TC 7 Gerd Hans
Cross-certification: Another possibility TC 4 issues one CA-certificate to TC 6 and vice versa. Alice accepts the certificate of Fred and vice versa. Fred does not accept the certificate of Emil. TC 2 TC 4 Alice Bob TC 3 TC 5 Carl Doris Emil TC 6 Fred TC 7 Gerd Hans
Cross-certification n*(n-1) cross-certificats = O(n 2)
Method 4: Bridge Idea: Bridge TC has cross-certifications with TC 2 and TC 3. Alice accepts all certificates beneath TC 3. Fred accepts all certificates beneath TC 2 TC 4 Alice Bob Bridge TC TC 5 Carl Doris Emil TC 3 TC 6 Fred TC 7 Gerd Hans
Bridge: certification path § Alice to Fred § Bridge enforces minimal policy TC 2 TC 4 Alice Bob Bridge TC TC 5 Carl Doris Emil TC 3 TC 6 Fred TC 7 Gerd Hans
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.
European Bridge-CA URL: http: //www. bridge-ca. org
Certification Path Validation 19 -5 -2021 PAGE 106
Shell model
Modified or hybrid model
Chain model
Certificate 1 Certificate 2 Certificate 3 Signed Document Time Sig. valid creation Shell model Signature valid verification Signature invalid verification
Certificate 1 Certificate 2 Certificate 3 Signed Document Time Sig. valid creation Chain model Signature valid verification
Certificate 1 Certificate 2 ! Certificate 3 Chain model: multiplevalidation Document A Document B ? Document C Time Signature verification: Document A Document B Document C
Algorithms Certificate 1 Certificate 2 Time Shell model Signature valid Sig. valid creation Hybrid model Signature valid Sig. valid creation Chain model Signature valid Signature invalid
Root CA CA Participant 1 2 3 4 5 6 Time [a] Sig. valid creation (max. 1 a) Hybrid model Signature valid Sig. valid creation (max. 3 a) Chain model Signature valid
X. 509 Certificates 19 -5 -2021 PAGE 115
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 19 -5 -2021 PAGE 116
X. 509 Certificates
X. 509 Certificates: Contents Version 1 (1988) Version 2 (1993) Version 3 (1997) Version (0=v 1, 1=v 2, 2=v 3) Serial Number (Unique within PKI) Certificate Signature Algorithm Issuer Validity Period Subject Public Key Info Subject Unique ID (worldwide unique) Issuer Unique ID (worldwide unique) Extensions 19 -5 -2021 PAGE 118
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 19 -5 -2021 PAGE 119
X. 509 (Non)critical extensions Critical Non-Critical Known valid Unknown invalid 19 -5 -2021 PAGE 120
Key Usage Defines the purpose of the key contained in the certificate. Key. Usage : : = BIT STRING { digital. Signature non. Repudiation key. Encipherment data. Encipherment key. Agreement key. Cert. Sign c. RLSign encipher. Only decipher. Only (0), (1), (2), (3), (4), (5), (6), (7), (8) } http: //www. ietf. org/rfc 5280. txt (pp 29 ff) 19 -5 -2021 PAGE 121
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 Ext. Key. Usage. Syntax : : = SEQUENCE SIZE (1. . MAX) OF Key. Purpose. Id : : = OBJECT IDENTIFIER 19 -5 -2021 PAGE 122
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 19 -5 -2021 PAGE 123
Based on a lecture by Johannes Braun, Johannes Buchmann, Alexander Wiesmaier https: //www. cdc. informatik. tu-darmstadt. de/en/students/teaching/ss 14/ vorlesung/pki-unterlagen-kopie-1/ Book: J. Buchmann, E. Karatsiolis, and A. Wiesmaier Introduction to Public Key Infrastructures Springer-Verlag Berlin Heidelberg, 2013. 19 -5 -2021 PAGE 124
- Slides: 119