PKI Architecture Lecture2

7/27/2019 PKI Architecture Lecture2

http://slidepdf.com/reader/full/pki-architecture-lecture2 1/59

1

PKI Architecture

Lecture #2



2

Scenario

• Alice received a document digitally signedby Bob

• Alice needs Bob’s public key to verify the

document • How does Alice ensure that the public key

which she is using is in fact Bob’s public key

and not of any other person impersonatingBob?

• Solution – Digital Certificate



3

Scenario….

• A Digital Certificate is a document that binds the

information of the certificate holder to a public

key.

• This certificate is digitally signed by a third party,also referred to as a Certification Authority (CA).

• Hence, to verify Bob’s certificate, Alice needs to

first obtain the CA’s public key.

• Alice can obtain the CA’s public key out−of−band.



4

Scenario…

• CAs can certify other CAs also

• Every entity can trust every other entity,

provided it is able to establish a chain from

its trusted CA to the other entity’s trusted

CA, called certificate path.

• The number of CAs in a certificate path and

the arrangement of these CAs determine the

different PKI architectures.



5

Types of PKI Architecture

• Single CA architecture

• Enterprise PKI architecture

• Hybrid PKI architecture

These different architectures are based on the

number of CAs, their arrangement, and therelationship between them.



6

Single CA Architecture

• Most basic type of PKI architecture.

• One CA who issues and distributescertificates and Certificate Revocation Lists

(CRLs) to the entities.• Entities use only those certificates that are

issued by this CA.

• All the entities in this architecturecommunicate with each other in a trustedenvironment



7


both of them can validate and verify each others certificates and then

communicate



8


• Quite Easy

• a single point of failure.

• If the private key of this CA is compromisedthen all certificates issued by this CA will

become invalid, and this might result in a

complete breakdown of the PKI system.

• every entity should immediately be

informed about it.



9


• CA needs to be re−established.

• All the certificates issued by the CA should

be deemed invalid and should be reissued.

• Suffers from scalability issues.



10

Basic Trust List Model

• An enhancement to the single CA architecture

• PKI services are provided by a number of CAs.

• These CAs do not establish a trust relationship

between them

• Entities have to maintain a list of CAs that they

trust

• The entities can work with only a single certificateor with CRLs that have been issued to them by any

of the CAs listed in the trust list.



11




12


• Problems:

– A user tends to add new CAs to list without the

CA’s knowledge.

– It is difficult for a user to discover a CA

compromise since there is no direct

relationship between the user and a CA



13

Certificate Paths

• Before a certificate can be used, it must bevalidated

• A chain of certificates or a certification path

between the certificate and an establishedpoint of trust must be established

• Every certificate within that path must be

checked• This process is referred to as certification

path processing



14

Certification path processing

• Path construction involves "building" one

or more candidate certification paths.

• Path validation includes making sure that

each certificate in the path is within its

established validity period, has not been

revoked, has integrity, etc and any

constraints levied on part or all of the

certification path are honored



15

Certificate Path Construction in a Single CA

• Simple as the architecture involves only one

trust point.

• there is no path construction in a single CA

architecture, and a single certificate

represents the entire path.



16

Certificate Path Construction

[CA−1 Alice]

[CA−1 Bob]

A single certificate is needed to connect the entity to the trust point.



17

Certificate path construction

CA-1

CA-2

CA-2

CA-3

CA-4

·[CA−1 Alice]

[CA−2 Alice]

· [CA−2 Bob]

· [CA−3

Bob] · [CA−4 Bob]



18

Enterprise PKI Architecture

• Single CA model can serve the requirementsof a small organization

• As the needs of the organization grow or

interoperability between different organizations increases, there arises a needfor delegating the task of a single CA.

• This requires the distribution of operationsof a single CA between multiple CAs that arearranged either in a hierarchy or mesh



19

Enterprise PKI Architecture

• Superior−subordinate(hierarchical PKI)

• Peer−to−peer (mesh PKI)



20

Hierarchical PKI Architecture

• PKI services are provided by multiple CAs.

• All CAs in a hierarchical PKI architecture

share a trust relationship among them.

• The CAs in this type of architecture are

connected through superior−subordinate

relationships.



21


• The CA hierarchy is an inverted tree

• Root CA and subordinate CAs

• subordinate CAs are like any other CA andperform all the functions of a CA

• they can also delegate the responsibility of

certificate issuance to other subordinateCAs beneath them.



22




23

Adding new CA



24

Hierarchical PKI



25

Hierarchical PKI

• A single point of trust, the root CA

• Root CA controls the complete hierarchical PKI

architecture

• In case of a compromise of the root CA, the

complete PKI architecture will break down

• The compromise of subordinate CAs can still be

handled, as the superior CAs can revoke theircertificates and establish them again.



26

Compromise of a single CA

• Assume that a single CA(not the root CA)

has been compromised

– The superior CA revokes the compromised CA’s

certificate

– Once the compromised CA has been

reestablished it issues new certificates to all its

users– The superior CA then issues a new certificate to

the reestablished CA



27


CA-2

CA-1

Alice

Root CA

CA-4

CA-5

CA-3

Bob

James

Smith

For every entity there exists only one

certification path



28


• the certification path for Alice can be depicted as follows:

[Root CA−3]: [CA−3 CA−2]: [CA−2 CA−1]:[CA−1 Alice]

• Bob’s certification path can be depicted as follows: [Root CA−3]: [CA−3 CA−2]: [CA−2 CA−1]:[CA−1 Bob]

• James’s certification path can be depicted as follows:

[Root CA−4]: [CA−4 James]



29

Mesh PKI

• The CAs have a peer−to−peer relationship,

rather than a superior subordinate

relationship

• All CAs in a mesh PKI can be trust points

• Since CAs issue certificates to each other,

they share a bi-directional trust relationship



30

Mesh PKI



31

Adding new CA

• Can be easily added

• The new CA exchanges certificates with

atleast one CA that is already a member of

the mesh



32

Mesh PKI

• Multiple trust points

• Compromise of a single CA cannot

result in a breakdown of the complete PKI

• If a CA is compromised, entities with other CAs astheir trust points continue to communicate withother entities.

• Certificate of the compromised CA can be

revoked by the CAs who have issued the certificatesto that CA

• The compromise of the CA affects only

the entities associated with that CA



33


• Initiated at the trust point, and it moves towards

the issuer of the end entity certificate

• More complex since there are multiple choices, so

non deterministic path construction• The maximum length of a certification path in a

mesh PKI is the number of CAs in the PKI.

• There is usually more than one certification pathbetween any entity and a trust point.



34




35


• Alice can construct the followingcertification path for Bob:

[CA−1 Bob]

• But for James, she can construct thefollowing certification paths:

[CA−1 CA−2]: [CA−2 CA−4]: [CA−4

James][CA−1 CA−3]: [CA−3 CA−2]:[CA−2 CA−4]: [CA−4 James]



36

Hybrid PKI Architecture

• PKI-based applications may cross

boundaries between communities or

enterprises

• Hybrid architectures can be used to connect

community and enterprise PKIs

– extended trust list

– cross-certified enterprise PKIs

– bridge CA architecture



37

Hybrid PKI Architecture



38

Extended Trust List Architecture

• Each user maintains a list of trusted CAs

– each trust point in the list is a single CA, a

hierarchy, or a mesh

– a user trust any certification path that starts

with a trust point in the list



39


• Alice receives a certificate from CA−1.

• Alice must trust PKI2 and PKI3 to

communicate with James, Charlie, Smith,

and Robert.

• Alice can trust any one CA in PKI2 or PKI3,

or she can add the entire organization to her

trust list .



40




41


• Extended Trust List might contain both hierarchical andmesh PKI architecture.

• The extended Trust List generates a certificate cache.

• This cache consists of all the possible certification paths.

• Instead of constructing a certification path, we can refer tothe cache and search for the appropriate path with the helpof the certification path value.

• This value is based on the complexity of the certification

path.• Simple certification paths are assigned a higher value thancomplex paths.



42

Cross−Certified Enterprise PKIs

• A cross-certified enterprise PKI establishes

peer-to-peer trust relationship

• Each user maintains a single trust point,

the CA that issued the certificate

• Problem: building of certification paths

may be complex



43

Cross−Certified Enterprise PKIs



44

Path Construction

• Users construct different certification path

for the same entity certificate

• Path begins with the trust point of the

native PKI

• The straight forward path construction

method is used within a hierarchy, but this

ends when an outside root is reached.



45

Bridge CA

• A special CA, called the bridge CA, is an

intermediary that establishes peer-to-peer

relationships with enterprise PKIs

• A CA that enters into a trust relationship

with the bridge CA is termed a principal CA

• Also known as hub and spoke PKI as it connects

multiple PKIs at a common point • If a principal CA is compromised, bridge CA

revokes its certificate



46

Bridge CA



47

Path Construction



48

Path Construction

• Alice will construct the following certification path for Bob:[CA−1 Bob]

• Alice will construct the following certification path for James:

[CA−1 Bridge CA]: [Bridge CA CA−2]: [CA−2 CA−4]: [CA−4 James]

• The following certification paths would be constructed by Alice for Charlie:

[CA−1 Bridge CA]: [Bridge CA CA−3]: [CA−3 CA−5]: [CA−5 Charlie]

[CA−1 Bridge CA]: [Bridge CA CA−3]: [CA−3 CA−6]: [CA−6

CA−5]: [CA−5 Charlie]

P h C i Si l



49

Path Construction – Simple

Hierarchy

User1 sends a digitally signed email to User2

P h C i Si l



50


Hierarchy

• Construct a certification path between User1'scertificate and a trust anchor recognized by User2.

• CA0,root CA is the common trust anchor for allusers within this strict hierarchy

• User2 wants to know if CA0 has established a trust relationship (either directly or indirectly) with theissuer of User1's certificate (CA1).

• If the relying party software is able to resolve the

certification path CA0->CA1->User1, then wewould have a candidate certification path that could be submitted to the path validation logic.

P h C i Si l



51


Hierarchy

• Paths are typically constructed in the

forward direction

• we start with the target certificate and work

our way to a recognized trust anchor

P th C t ti C



52

Path Construction – Cross

Enterprise PKI

User2 sends a digitally signed email to User3

P th C t ti C



53


Enterprise PKI• Construct a certification path between User2's verification

certificate and a trust anchor that User3 recognizes(CA7)

• Work our way "out" from the relying party's trust anchor(CA7) to eventually discover the crosscertificate

that CA5 issued to CA0• path construction in the reverse direction and it produces

a partial path CA7->CA5->CA0

• This partial path is constructed by retrieving theissuedByThisCA certificates under CA7's directory entry,

which, in turn, leads to the retrieval of theissuedByThisCA certificates under CA5's directory entry.

P th C t ti C



54


Enterprise PKI

• Try to construct the rest of the path in the

forward direction

• we work our way back from the target

certificate to CA0.

• CA7->CA5->CA0->CA2->CA4->User2.

Forward versus Reverse



55

Forward versus ReverseCertification Path Construction

• In a strict hierarchy, working in the forwarddirection makes sense

• We are always guaranteed to find theissuedToThisCA element of the cross-certificate

pair attribute populated with the certificate(s)that have been issued to each subordinate CA.

• When we encounter a distributed trust model,building certification paths in the forwarddirection can become much less efficient.

• We may encounter tens or even hundreds of forward elements associated with a given CA, not just one or two.

P th t ti F ll



56

Path construction- Fully

distributed

P th t ti F ll



57


distributed

• BCA1 might be cross-certified with tensor even hundreds of other CAs and those CAsmay be crosscertified with tens or hundredsmore.

• If we are looking at the issuedToThisCAelement only, we could encounter a largenumber of CAs that lead away from the path weare seeking.

• Attempting to construct every possible path inthe forward direction is clearly less practical

• under these circumstances.

P th t ti F ll



58


distributed

• Constructing in the reverse direction also

involves trial and error

• but we will always be working with a

(partial) path emanating from the relyingparty's trust anchor since we are

answering the question "who have you

issued certificates to" rather than "who hasissued certificates to you."



59

Conclusion

• Certification path construction in the

forward direction is optimal for hierarchical

trust models

• Certification path construction in the

reverse direction is optimal for distributed

trust models.

PKI Architecture Lecture2

Documents

Transcript of PKI Architecture Lecture2