340 likes | 561 Views
King Mongkut’s University of Technology Faculty of Information Technology Network Security Prof. Reuven Aviv. 6. Public Key Infrastructure. OUTLINE. 1. Party Authentication via certificates 2. Models for Public Key Infrastructure 3. Appendix: EFS – file encryption in WinXP.
E N D
King Mongkut’s University of TechnologyFaculty of Information TechnologyNetwork SecurityProf. Reuven Aviv 6. Public Key Infrastructure Public Key Cryptography
OUTLINE • 1. Party Authentication via certificates • 2. Models for Public Key Infrastructure • 3. Appendix: EFS – file encryption in WinXP Public Key Cryptography and PKI
1. Party authentication by certificates Cryptography Short
Party authentication (X.509) • Party A present an X.509 certificates to party B • B validated the certificate of A • B knows a pair (IDA, KUA) • B learns the identity of A (B authenticates A) • By receiving a proof from A that it knows the private key KRA associated with the public key presented in the certificate • Proof: A signs some data; B verifies the signature Public Key Cryptography and PKI
X.509 Single message Authentication • Single message from A to B, establishing: • Identity of A: message originated from A • Message intended for B; Integrity of message • Originality (no replay) of message • Message: valid-period, B id, nonce, Data, sigA • AB: A{tA, rA, B id, Data} • Nonce rA kept by receiver for future use. Why? • Message may include session key (Kab) why? • encrypted by B public key why? Public Key Cryptography and PKI
X.509 One Way Authentication • Why do we have • both • Timestamp and nonce? • Again: How does B knows that the sender is A? • How does A knows that B received the message? Public Key Cryptography and PKI
X.509 two way authentication • Two messages exchanged between A and B • Establishing same as in one-way, and • That message from A received correctly by B • Identity of B; reply originated from B • That reply was intended to A • Integrity and originality of reply • AB: A{tA, rA, B id, Data, EKUB[Kab]} • BA: B{tB, rB, A id, rA, Data, EKUB[Kba]} What does a M.I.M know or change? Public Key Cryptography and PKI
Digital signing of the certificate:Notations • Two notations • CA<<A>> = CA{V, SN, AI, CA, TA, A, Ap} • LHS: <<A>> signed by CA • RHS: {…} signed by CA Public Key Cryptography and PKI
X.509 Two-way authentication Public Key Cryptography and PKI
X.509 Three-way authentication • Echoing signed nonces guarantee no-replay • Required if clock synchronization is not good Public Key Cryptography and PKI
A one-time session key usage scenario • A and B present their certificates to each other • A creates a one-time random session key Ks • A B 3 parts message • Data encrypted (e.g by AES) using one-time Ks • Ks encrypted by KUB • sigA • B verifies A signature how? • If verified, B knows his party ID is IDA • B, and Only B, can decrypt the session key why? • only B can correctly decrypt the message Public Key Cryptography and PKI
2. Models for Public Key Infrastructure (PKI) Public Key Cryptography and PKI
How many CAs do we need? • Monopoly Trust Model • All use one, trusted CA, know its public key • How do they know it? • Parties can send certificates directly to others • Party B can verify authenticity of a certificate by decrypting the signature of the CA • What are the problems? Public Key Cryptography and PKI
Monopoly Trust Model: Problems • There is no single trusted organization • all OS include with CA’s KUCA – hard to change • How a remote CA can validate your identity? • solution: monopoly + Registration Authorities (RAs) in charge of mapping names to KU • The monopoly will charge whatever it wants Public Key Cryptography and PKI
Chains of certificates • A obtained certificate issued/signed by X1 • B obtained certificate issued/signed by X2 • X1, X2 obtained certificates issued/signed by each other • X1<<A>> X2<<B>> X1<<X2>> X2<<X1>> • A gets the X2<<B>> certificate (from B) • A gets the X1<<X2>> certificate (from X2) • A extracts from X1<<X2>> the X2 public key • A extracts from X2<<B>> the public key of B • Summarizing: A got the chain X1<<X2>> X2<<B>> • More generally: X1<<X2>> X2<<X3>> …XN<<B>> • Each pair must have issued certificates for each other How A (and B) find the chains? Public Key Cryptography and PKI
Certificate Path Public Key Cryptography and PKI
Monopoly with delegated CAs Trust Model • One root CA issues certificates to other CAs • Certificates authorize holders to issue certs • A tree of CAs • Each certificate is the end of a chain of certs • Root CA also called trust anchor • Who issues the certificate of the trust anchor? • Problems? Public Key Cryptography and PKI
Oligarchy Trust model • OS preconfigured with a list of trusted root CAs • Their self issued certificates added to the OS • OS also include list of certs of intermediaries • All certificates form a forest • User can add or delete entries from lists • Very common in practice • Browser rely on these lists Public Key Cryptography and PKI
Trusted Root Certificates in my computer Tool: mmc Public Key Cryptography and PKI
oligarchy more secure than monopoly? • Monopoly: corruption risks world security • Oligarchy: Corruption in one root CA same • More likely to happen in oligarchy! • Oligarchy: CAschosen by vendor, so what? • Easy to trick users to add new “trusted” CAs • Malicious users can change lists in a public host • Hardly noticeable in long lists Public Key Cryptography and PKI
Anarchy Trust Model • users responsible for configuring root CAs • People he/she trusts • then anyone can issue certificates • Volunteers keep certificates in a database • To find a cert: search for a chain in the DB • Can we really trust a chain of certificates? • Not scalable • idea: several chains lead to cert –> trusted cert • Used in Pretty Good Privacy (PGP) software Public Key Cryptography and PKI
Bottom UP hierarchy • Hierarchical namespace • Like A, A/B/X, A/B/X/Y • According to organizational structure • Namespace is a forest • Each node associated with a CA • Each organization node issue its own certificates • Each CA signs certs of children and parent • Also cross signature (links) within the forest • Each certificate has a root CA • A: find a cert of B: go up in forest, look for cross Public Key Cryptography and PKI
CA Hierarchy • A wants to get B public key. He gets the following certificates (right to left) • X<<W>> W<<V>> V<<Y>> Y<<Z>> Z<<B> Is this structure Fixed? Public Key Cryptography and PKI
Revocation of Certificates • Reasons for revocation: • secret key is assumed to be compromised. • The user is no longer certified by this CA. • CA’s certificate is assumed compromised. • CA issues a Certificate Revocation List (CRL) • cert identified by its issuer and the serial num • User that gets a certificate should consult that list • User maintains cache of certificates and CRLs • how the integrity of list is kept? Public Key Cryptography and PKI
Certificate Revocation List Public Key Cryptography and PKI
Revocation List Public Key Cryptography and PKI
3. Appendix Storage of Secret Keys by Public Key Encryption in the EFS system of Windows XP Public Key Cryptography and PKI
EFS: Encrypting a directory/file in WinXP • Users can encrypt file, directories • Encryption by DES or 3DES • Key (FEK) created during encryption Public Key Cryptography and PKI
File Encryption in WinXP Public Key Cryptography and PKI
Encrypting the File Encryption Key (FEK) • The Operating System creates for the User a Public and Private keys • using information in the User account, including his/her password • (the keys are created once) • The FEK is then encrypted by RSA using the User’s public key Public Key Cryptography and PKI
Encrypting The File Encryption Key (FEK) • The encrypted FEK is written into to the file header, in the Data Decryption Field (DDF) Public Key Cryptography and PKI
Automatic creation of a my cert during encryption Tool: Microsoft Management Console (mmc) Certificate Snap in Public Key Cryptography and PKI
Personal certificate Public Key Cryptography and PKI
Data Recovery Agents • OS Assign Recovery Agents (e.g. admin) also have (different) private and public keys. • For each RA the encrypted FEK is written into the Data Recovery Field (DRF) in the File header Public Key Cryptography and PKI