King Mongkut’s University of Technology Faculty of Information Technology Network Security Prof. Reuven Aviv 6. Public Key Infrastructure Prof. R. Aviv,

King Mongkut’s University of Technology

Faculty of Information TechnologyNetwork SecurityProf. Reuven Aviv

6. Public Key Infrastructure

Prof. R. Aviv, 2008 Public Key Cryptography 1

Prof. Reuven Aviv, Nov 2006

Public Key Cryptography and PKI 2

OUTLINE

• 1. Party Authentication via certificates

• 2. Models for Public Key Infrastructure

• 3. Appendix: EFS – file encryption in WinXP

1. Party authentication by certificates

Dr. R. Aviv, Nov. 2006 Cryptography Short 3



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



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?



X.509 One Way Authentication

•How does A knows that B received the message?

•Why do we have

•both

•Timestamp and nonce?

•Again: How does B knows that the sender is A?



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?



•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



X.509 Two-way authentication



X.509 Three-way authentication

• Echoing signed nonces guarantee no-replay

• Required if clock synchronization is not good



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

2. Models for

Public Key Infrastructure (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?



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



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<> X1<<X2>> X2<<X1>>• A gets the X2<> certificate (from B)• A gets the X1<<X2>> certificate (from X2)• A extracts from X1<<X2>> the X2 public key• A extracts from X2<> the public key of B• Summarizing: A got the chain X1<<X2>> X2<>

• More generally: X1<<X2>> X2<<X3>> …XN<>

• Each pair must have issued certificates for each other

How A (and B) find the chains?



Certificate Path



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?



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



Trusted Root Certificates in my computer

Tool: mmc



oligarchy more secure than monopoly?

• Monopoly: corruption risks world security

• Oligarchy: Corruption in one root CA same

– More likely to happen in oligarchy!

• Oligarchy: CAs chosen 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



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



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



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<

Is this structure Fixed?



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?



Certificate Revocation List



Revocation List



3. Appendix

Storage of Secret Keys by Public Key Encryption

in the EFS system of Windows XP



EFS: Encrypting a directory/file in WinXP

• Users can encrypt file, directories

• Encryption by DES or 3DES

– Key (FEK) created during encryption



File Encryption in WinXP



Encrypting the File Encryption Key (FEK)

• The Operating System creates for the User a Pub

lic and Private keys

– using information in the User account, inc

luding his/her password

– (the keys are created once)

• The FEK is then encrypted by RSA using the Use

r’s public key



Encrypting The File Encryption Key (FEK)

• The encrypted FEK is written into to the file hea

der, in the Data Decryption Field (DDF)



Automatic creation of a my cert during encryption

Tool: Microsoft Management Console (mmc) Certificate Snap in



Personal certificate



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

Documents

King Mongkut’s University of Technology Faculty of Information Technology Network Security Prof. Reuven Aviv 6. Public Key Infrastructure Prof. R. Aviv,