Public Key Infrastructure PKIX digital certificates digital signatures

Public Key Infrastructure (PKIX) digital certificates – digital signatures I. PKIv 3 architectual model and datastructures conforming to ITU-T X. 509 Maximilian Buder II. Flexible and Scalable Public Key Security for SSH Andrej Masula 1

open systems interconnection – ITU-T X. 509 pki as a key management solution - all crypt. systems rely on a secure key distribution scheme - breaking the distribution schemes, means bringing down the crypt. system - possible key distribution schemes: - physical delivery by a secured out-of-band route like: - military (submarine) code-books - one-time pads used by the diplomatic corps - authentication key servers - eg kerberos, having a trusted online server - server has a unique secret key, which is shared with each client - server negotiates session keys on behalf of the clients - public notary (public key, PKIX) - an offline server, trusted by all clients - server signs public key certificates for all clients 2

open systems interconnection – ITU-T X. 509 pki – a key distribution scheme - an a-priori trusted publicly availible server - that certifies bindings between names and public keys from repositories and signs the assertion - digital signatures provide non-repudiation of certificate origin the assertion, public key and name, may be validated earlier by the signer through: 1. a challenge response protocol 2. presentation of the private key 3. or assertion by the subject through an ID 3

open systems interconnection – ITU-T X. 509 pki – architectural model - RA : = registration authority CA : = certification authority - end entity : = subject of the certificate repository : = distributed directory 4

open systems interconnection – ITU-T X. 509 pki – CA hierarchy / building trust - by a common point of trust, that is linked by a unbroken chain of trust with its end users, they shall authenticate - check by reference to a directory 5

open systems interconnection – ITU-T X. 509 pki – path validation - certificates (certs) are held in directories as attributes of the follwing types: - User. Cert, CACert, Cross. Cert. Pair - before two user mutually authenticate, the directory (X. 500) shall supply the complete cert. path und return cert. path - following assumptions ease the amount of information transmitted by the directory - validation of users served by the same cert. authority becomes trivial in a hierarchy, users should store all certs on a path to the root Cross. Cert. Pairs shorten the cert. path first trusted communication is stored by the users and eliminates duplicate requests to the directory 6

open systems interconnection – ITU-T X. 509 pki – hierarchy example 7

open systems interconnection – ITU-T X. 509 pki – hierarchy example - assumptions: every node knows his own key pair and the public key of its CA - A and B want to authenticate: - A aquires following certs from the directory: - X<<W>>, W<<V>>, V<<Y>>, Y<<Z>>, Z<<B>> - A also get the following return cert. path: - Z<<Y>>, Y<<V>>, V<<W>>, W<<X>>, X<<A>> 8

open systems interconnection – ITU-T X. 509 digital signatures (PKCS)– principles 9

open systems interconnection – ITU-T X. 509 digital signatures – hashing - hash functions in signature schemes are used: - to condense an arbitrary message length to a fixed size - SHA 1 (SHS): - 160 bit hash values - good hash functions h should have following properties: - h should destroy all homomorphic structures h should be run on the entire message h should be a math. one-way function h should resist collisions, meaning that two msg. are not digested to one and the same hashvalue 10

open systems interconnection – ITU-T X. 509 digital signatures - El. Gamal - El Gamal signature scheme as a basis for DSA/DSS - preliminary steps: - given a prime p, a random number g, private (key) random number x, compute: y=gx (mod p) - public key is: (y, g, p) - private key is (x) and must be kept secret 11

open systems interconnection – ITU-T X. 509 digital signatures - El. Gamal - signing a msg. M I. choose a random number k with: GCD(k, p-1)=1 II. compute: a= gk (mod p) III. use extended euclidean (inverse) algorithm to solve: M=x*a + k*b*(mod p-1) IV. the signature is (a, b) , the number k must be kept secret - verifying a signature (a, b) confirm: ya * ab(mod p) = g. M(mod p) 12

open systems interconnection – ITU-T X. 509 basic certificate fields - for signature calculations, a certificate (X. 509 v 3) is encoded conforming the ASN. 1 notation using distinguished encoding rules (DER) tbs. Certificate signature. Algorithm signature. Value 13

open systems interconnection – ITU-T X. 509 basic certificate fields Certificate : : = SEQUENCE tbs. Certificate signature. Algorithm signature. Value { TBSCertificate, Algorithm. Identifier, BIT STRING } TBSCertificate : : = SEQUENCE { version [0] EXPLICIT Version DEFAULT v 1, serial. Number Certificate. Serial. Number, signature Algorithm. Identifier, issuer Name, validity Validity, subject Name, subject. Public. Key. Info Subject. Public. Key. Info, issuer. Unique. ID [1] IMPLICIT Unique. Identifier OPTIONAL, -- If present, version shall be v 2 or v 3 subject. Unique. ID [2] IMPLICIT Unique. Identifier OPTIONAL, -- If present, version shall be v 2 or v 3 extensions [3] EXPLICIT Extensions OPTIONAL -- If present, version shall be v 3 } 14

open systems interconnection – ITU-T X. 509 basic certificate fields – distinguished names Name : : = CHOICE { RDNSequence } RDNSequence : : = SEQUENCE OF Relative. Distinguished. Name : : = SET OF Attribute. Type. And. Value : : = SEQUENCE { type Attribute. Type, value Attribute. Value } Attribute. Type : : = OBJECT IDENTIFIER Attribute. Value : : = ANY DEFINED BY Attribute. Type - eg. country - eg. us, ger, etc. Directory. String : : = CHOICE { teletex. String Teletex. String (SIZE (1. . MAX)), printable. String Printable. String (SIZE (1. . MAX)), universal. String Universal. String (SIZE (1. . MAX)), utf 8 String UTF 8 String (SIZE (1. . MAX)), bmp. String BMPString (SIZE (1. . MAX)) } 15

open systems interconnection – ITU-T X. 509 basic certificate fields – validity Validity : : = SEQUENCE { not. Before Time, not. After Time } Time : : = CHOICE { utc. Time UTCTime, general. Time Generalized. Time } - not. Before and not. After <= 2049 in UTCTime - not. Before and not. After >= 2050 in Generalized. Time 16

open systems interconnection – ITU-T X. 509 basic certificate fields – subject public key info Subject. Public. Key. Info : : = SEQUENCE { algorithm Algorithm. Identifier, subject. Public. Key BIT STRING } Supported. Algorithms extensible ALGORITHM-ID : : = - Algorithm. Identifier wie bei signature. Algo. Identifier von tbs. Certificate {. . . , -- rsa. Public. Key | rsa. SHA-1 | rsa. MD 5 | rsa. MD 2 | dss. Public. Key | dsa. SHA-1 | dh. Public. Key } dsa. SHA-1 ALGORITHM-ID : : = { OID id-dsa-with-sha 1 } id-dsa-with-sha 1 OBJECT IDENTIFIER : : = { iso(1) member-body(2) us(840) x 9 -57 (10040) x 9 algorithm(4) 3 } 17

open systems interconnection – ITU-T X. 509 basic certificate fields – extensions Extensions : : = SEQUENCE SIZE (1. . MAX) OF Extension : : = SEQUENCE { extn. ID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extn. Value OCTET STRING } id-ce-key. Usage OBJECT IDENTIFIER : : = { id-ce 15 } 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) } - Example std. extension: - restriction of a multi-purpose key pair 18

open systems interconnection – ITU-T X. 509 CRLv 2 basic fields Certificate. List : : = SEQUENCE { tbs. Cert. List TBSCert. List, signature. Algorithm. Identifier, signature. Value BIT STRING } TBSCert. List : : = SEQUENCE { version Version OPTIONAL, signature Algorithm. Identifier, issuer Name, this. Update Time, next. Update Time OPTIONAL, revoked. Certificates SEQUENCE OF SEQUENCE { user. Certificate. Serial. Number, revocation. Date Time, crl. Entry. Extensions OPTIONAL } OPTIONAL, crl. Extensions [0] EXPLICIT Extensions OPTIONAL - signed list of revoked certificates (found at CRLdistributionpoints) - CRL extensions for special purpose CRL policy enforcement and future structural extension. eg. : - delta-CRL - only changes relative to a base CRL are published, thus allowing perfomance gains in processing CLR infos in locally stored databases } 19

open systems interconnection – ITU-T X. 509 pki – security considerations - CA policy statements may determine the methods used, to assert name and public keys and therefor affect the degree of trust put forward by other entities (cross-signing) or: - german Signature. Law (Sig. G) by 2001, which qualifies signatures - use of a single key pair for signing and other purposes is strongly discouraged (disclousure isssues, environmental aspects) - as allways, protection of private key is crucial (bogus certificates) - freshness of CRLs - path validation processes rely on certain knowledge (directory, path search in graph) 20

open systems interconnection – ITU-T X. 509 pki – security considerations - inconsistent application of name comparison might falsely accept/reject certificate paths 21

open systems interconnection – ITU-T X. 509 Flexible and Scalable Public Key Security for SSH Overview - SSH – (the) secure shell - = replacement for telnet & Co. , ftp (since SSH 2) - great choices of SSH-Software - also Open Source products - most of them cannot handle certificates - this approach gives a way to build a flat trust-structure with the effect of secure public keys - alternative approach published in European Public Key Infrastructure Workshop 2004 (Euro. PKI 2004: Samos Island, Greece) 22

open systems interconnection – ITU-T X. 509 Flexible and Scalable Public Key Security for SSH Outline - What is SSH? How is it vulnerable? Alternative protocols and their drawbacks. The Solution: 1. Decentralized Minimal PKI Model 2. Partially Centralized Model - Conclusion 23

open systems interconnection – ITU-T X. 509 What is SSH? - SSH 1 and SSH 2 Protocols - SSH Client and Server Model - SSH Open Source Products - SSH and PKI 24

open systems interconnection – ITU-T X. 509 SSH 1 and SSH 2 protocols - SSH: Algorithm Negotiation» Authentication» Encryption - SSH 2 a rewrite of SSH 1 protocol, - SSH 2 offers greater portability and is better implemented than SSH 1, - SSH 2 adds a replacement for FTP, - SSH 2 uses a slightly different Key Exchange Mechanism, 25

open systems interconnection – ITU-T X. 509 SSH Client and Server Model - Transport Layer Key Exchange client server n 1 p, g 2 computes e = g^x mod p. (SSH_MSG_KEXDH_INIT), e 4 (SSH_MSG_KEXDH_REPLY), K_S || f || s verifies that K_S really is the host key 3 computes f = g^y mod p K = e^y mod p H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K) s = signature on H with its private host key. computes: K = f^x mod p H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K), and verifies the signature s on H. Transport Layer Key exchange 26

open systems interconnection – ITU-T X. 509 SSH Client and Server Model - User Authentication Layer client Pay load is: server Payload, signature 5 SSH_MSG_USERAUTH_REQUEST , username, service, "password", FALSE, plaintext password server checks whether the supplied password is acceptable for authentication, and if so, it checks whether the signature is correct. signature is: session identifier, payload encrypted with session key 7 27

open systems interconnection – ITU-T X. 509 SSH Client and Server Model - User Authentication Layer client Pay load is: server Payload, signature 5 SSH_MSG_USERAUTH_REQUEST , username, service, "password", FALSE, plaintext password server checks whether the supplied password is acceptable for authentication, and if so, it checks whether the signature is correct. signature is: session identifier, payload encrypted with session key User auth layer (using password) SSH_MSG_USERAUTH_SUCCESS OR _FAILURE 6 7 28

open systems interconnection – ITU-T X. 509 SSH Client and Server Model - User Authentication Layer client Pay load is: server Payload, signature 5 SSH_MSG_USERAUTH_REQUEST , username, service, "password", FALSE, plaintext password server checks whether the supplied password is acceptable for authentication, and if so, it checks whether the signature is correct. signature is: session identifier, payload encrypted with session key User auth layer (using password) SSH_MSG_USERAUTH_SUCCESS OR _FAILURE 6 request service if userauth_success 7 29

open systems interconnection – ITU-T X. 509 SSH Products Open Source - Open. SSH - Tera. Term SSH - Cygwin Open. SSH - Fi. SSH - Pu. TTY Commercial Products - SSH Clients and Servers (SSH Inc. ) - F-Secure SSH 30

open systems interconnection – ITU-T X. 509 SSH and PKI - Using Public Keys - Using Certificates: X 509, Open. PGP - No Certificate Verification in Open. SSH/Put. TTY/Tera. Term. SSH - Certificates essentially replace public keys - Most importantly, no Universal Trust Structure or Natural Hierarchy of Certifiers exists 31

open systems interconnection – ITU-T X. 509 How is it vulnerable? - The Man in the middle Attack - Spoofing Attack 32

open systems interconnection – ITU-T X. 509 The Man in the middle Attack 33

open systems interconnection – ITU-T X. 509 The Man in the middle Attack 34

open systems interconnection – ITU-T X. 509 The Man in the middle Attack 35

open systems interconnection – ITU-T X. 509 Spoofing attack 36

open systems interconnection – ITU-T X. 509 Spoofing attack 37

open systems interconnection – ITU-T X. 509 Spoofing attack 38

open systems interconnection – ITU-T X. 509 Spoofing attack 39

open systems interconnection – ITU-T X. 509 Alternative protocols and their drawbacks. Components needed for a Traditional PKI solution Protocols that require a Public Key Infrastructure: - TLS using certificates (for user & server) - TTLS Protocols that require specific hardware: - TLS using smart cards 40

open systems interconnection – ITU-T X. 509 Components needed for a Traditional PKI solution - A Network of Certificate Authorities/ Registration Authorities, - Secure Certificate Management, Storage and Retrieval mechanisms on the client, - Trust Paths for the server certificates on the client, - Unique and ‘Sensible’ Bindings between public keys and server names in certificates, - Certificate Revocation mechanisms 41

open systems interconnection – ITU-T X. 509 The Solution - Goals - Creating a “Poor Man’s” Certificate - Decentralized Approach. (Implemented) - Semi-centralized Approach. - SSH Protocol Architecture 42

open systems interconnection – ITU-T X. 509 Goals - The solution should enable users from borrowed (but trusted) clients to establish trusted connections to their home machines. - The solution should be adoptable in the near-term in similar infrastructure (“small delta”). - The solution should accommodate users in domains where sysadmins can set up trustable and usable CA services. 43

open systems interconnection – ITU-T X. 509 Goals - The solution should accommodate users in domains where no such services exist. - The solution should not require that a new universal PKI hierarchy be established before any of this works. - The solution should not require that a user memorize the fingerprints of all servers he wishes to interact with. 44

open systems interconnection – ITU-T X. 509 Creating a “Poor Man’s” Certificate - Modifying SSH protocol violates “small delta” change restriction - Therefore, non SSH mechanism to be used to retrieve server public key - Poor Man’s Certificate: Use HMAC to retrieve server public key securely 45

open systems interconnection – ITU-T X. 509 Creating a “Poor Man’s” Certificate HMAC (Hashed Message Authentication Code) is a Keyed MAC Algorithm: - take message M and a secret key k and produces a MAC value Mac(M, k) - infeasible to find another M’, k’ pair that generate the same keyed MAC (collision resistant) - It’s like digital signature, but with symmetric key instead of a key pair 46

open systems interconnection – ITU-T X. 509 Decentralized Approach - no Third Party involved - individually maintained by user - user must have access to a web server to retrieve files - hashstore-file containing a list of server names, and (for each server) the keyed MAC 47

open systems interconnection – ITU-T X. 509 Decentralized Approach – create hashstore-file - configurator program produces pairs of (server name – keyed MAC) - program input = passphrase, target server name(s), path to public keys of this server(s) - a symmetric (secret) key is generated from passphrase - symmetric key is used to calculate keyed MAC - keyed MAC = hashed public key of server - hashstore-file is stored under public access (Web-Server) 48

open systems interconnection – ITU-T X. 509 Decentralized Approach 49

open systems interconnection – ITU-T X. 509 Decentralized Approach 50

open systems interconnection – ITU-T X. 509 Decentralized Approach 51

open systems interconnection – ITU-T X. 509 Decentralized Approach 52

open systems interconnection – ITU-T X. 509 Decentralized Approach 53

open systems interconnection – ITU-T X. 509 Decentralized Approach 54

open systems interconnection – ITU-T X. 509 Decentralized Approach 55

open systems interconnection – ITU-T X. 509 Semi-Centralized Approach - Proposed and evaluated, not completely implemented. - Requires maintenance by Sys-Admins - Requires LDAP server and a CA - Preferably using server certificates instead of server public keys 56

open systems interconnection – ITU-T X. 509 Conclusion - “Decentralized non-CA approach” is easy to use and deployed - It enables users from borrowed clients to establish trusted connections. - It requires only a small delta change from the current infrastructure. - It accommodate users in domains where sys-admins can set up trustable and usable CA services. 57

open systems interconnection – ITU-T X. 509 Conclusion - This solution does not require that a new universal PKI hierarchy be established before any of this works. - It does not require that a user memorize the fingerprints of all servers he wishes to interact with. - This solution brings public-key security to SSH in a flexible and scalable way. 58

open systems interconnection – ITU-T X. 509 Sources? - ITU-T Recommendation X. 509, 3/2000 - paper: Flexible and Scalable Public Key Security for SSH authors: Yasir Ali , Sean Smith (Dartmouth College), 2003 - Security Engineering, Ross Anderson, 2001 - Wikipedia - XML-Security, Blake Dournaee, RSA Press, 2002 59

open systems interconnection – ITU-T X. 509 - Discussion ? 60