PKI Architecture

Lecture #2

Scenario
Alice received a document digitally signed by Bob Alice needs Bobs public key to verify the document How does Alice ensure that the public key which she is using is in fact Bobs public key and not of any other person impersonating Bob? Solution Digital Certificate
2

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 Bobs certificate, Alice needs to first obtain the CAs public key. Alice can obtain the CAs public key outofband.

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 entitys trusted CA, called certificate path. The number of CAs in a certificate path and the arrangement of these CAs determine the different PKI architectures.
4

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 the relationship between them.
5

Single CA Architecture
Most basic type of PKI architecture. One CA who issues and distributes certificates and Certificate Revocation Lists (CRLs) to the entities. Entities use only those certificates that are issued by this CA. All the entities in this architecture communicate with each other in a trusted environment
6

Single CA Architecture

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

Single CA Architecture
Quite Easy a single point of failure. If the private key of this CA is compromised then 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.
8

Single CA Architecture
CA needs to be reestablished. All the certificates issued by the CA should be deemed invalid and should be reissued. Suffers from scalability issues.

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 certificate or with CRLs that have been issued to them by any of the CAs listed in the trust list.
10

Basic Trust List Model

11

Basic Trust List Model

Problems:
A user tends to add new CAs to list without the CAs knowledge. It is difficult for a user to discover a CA compromise since there is no direct relationship between the user and a CA

12

Certificate Paths
Before a certificate can be used, it must be validated A chain of certificates or a certification path between the certificate and an established point of trust must be established Every certificate within that path must be checked This process is referred to as certification path processing
13

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
14

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.

15

Certificate Path Construction

[CA1 Alice] [CA1 Bob]

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

16

Certificate path construction

CA-2 CA-1 CA-2 CA-3 CA-4

[CA1Alice] [CA2Alice]

[CA2 Bob] [CA3Bob] [CA4 Bob]

17

Enterprise PKI Architecture

Single CA model can serve the requirements of a small organization As the needs of the organization grow or interoperability between different organizations increases, there arises a need for delegating the task of a single CA. This requires the distribution of operations of a single CA between multiple CAs that are arranged either in a hierarchy or mesh
18

Enterprise PKI Architecture

Superiorsubordinate(hierarchical PKI) Peertopeer (mesh PKI)

19

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 superiorsubordinate relationships.

20

Hierarchical PKI Architecture

The CA hierarchy is an inverted tree Root CA and subordinate CAs subordinate CAs are like any other CA and perform all the functions of a CA they can also delegate the responsibility of certificate issuance to other subordinate CAs beneath them.
21

Hierarchical PKI Architecture

22

Adding new CA

23

Hierarchical PKI

24

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 their certificates and establish them again.
25

Compromise of a single CA
Assume that a single CA(not the root CA) has been compromised
The superior CA revokes the compromised CAs 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
26

Certificate Path Construction

Root CA

CA-3

CA-4

James CA-2 CA-5

CA-1

Smith For every entity there exists only one certification path 27

Alice

Bob

Certificate Path Construction

the certification path for Alice can be depicted as follows: [Root CA3]: [CA3 CA2]: [CA2 CA1]: [CA1 Alice] Bobs certification path can be depicted as follows: [Root CA3]: [CA3 CA2]: [CA2 CA1]: [CA1 Bob] Jamess certification path can be depicted as follows: [Root CA4]: [CA4 James]

28

Mesh PKI
The CAs have a peertopeer 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

29

Mesh PKI

30

Adding new CA
Can be easily added The new CA exchanges certificates with atleast one CA that is already a member of the mesh

31

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 as their trust points continue to communicate with other entities. Certificate of the compromised CA can be revoked by the CAs who have issued the certificates to that CA The compromise of the CA affects only the entities associated with that CA
32

Certificate Path Construction

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 path between any entity and a trust point.

33

Certificate Path Construction

34

Certificate Path Construction

Alice can construct the following certification path for Bob: [CA1 Bob] But for James, she can construct the following certification paths: [CA1 CA2]: [CA2 CA4]: [CA4 James] [CA1 CA3]: [CA3 CA2]:[CA2 CA4]: [CA4 James]
35

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
36

Hybrid PKI Architecture

37

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

38

Extended Trust List Architecture

Alice receives a certificate from CA1. 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.

39

Extended Trust List Architecture

40

Certificate Path Construction

Extended Trust List might contain both hierarchical and mesh 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 to the cache and search for the appropriate path with the help of the certification path value. This value is based on the complexity of the certification path. Simple certification paths are assigned a higher value than complex paths.
41

CrossCertified 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

42

CrossCertified Enterprise PKIs

43

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.

44

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
45

Bridge CA

46

Path Construction

47

Path Construction
Alice will construct the following certification path for Bob: [CA1 Bob] Alice will construct the following certification path for James: [CA1 Bridge CA]: [Bridge CA CA2]: [CA2 CA4]: [CA4 James] The following certification paths would be constructed by Alice for Charlie: [CA1 Bridge CA]: [Bridge CA CA3]: [CA3 CA5]: [CA5 Charlie] [CA1 Bridge CA]: [Bridge CA CA3]: [CA3 CA6]: [CA6 CA5]: [CA5 Charlie]

48

Path Construction Simple Hierarchy

User1 sends a digitally signed email to User2

49

Path Construction Simple Hierarchy

Construct a certification path between User1's certificate and a trust anchor recognized by User2. CA0,root CA is the common trust anchor for all users within this strict hierarchy User2 wants to know if CA0 has established a trust relationship (either directly or indirectly) with the issuer of User1's certificate (CA1). If the relying party software is able to resolve the certification path CA0->CA1->User1, then we would have a candidate certification path that could be submitted to the path validation logic.
50

Path Construction Simple Hierarchy

Paths are typically constructed in the forward direction we start with the target certificate and work our way to a recognized trust anchor

51

Path Construction Cross Enterprise PKI

User2 sends a digitally signed email to User3

52

Path Construction Cross 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 the issuedByThisCA certificates under CA7's directory entry, which, in turn, leads to the retrieval of the issuedByThisCA certificates under CA5's directory entry.

53

Path Construction Cross 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.

54

Forward versus Reverse Certification Path Construction

In a strict hierarchy, working in the forward direction makes sense We are always guaranteed to find the issuedToThisCA 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 forward direction 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.
55

Path construction- Fully distributed

56

Path construction- Fully distributed

BCA1 might be cross-certified with tens or even hundreds of other CAs and those CAs may be crosscertified with tens or hundreds more. If we are looking at the issuedToThisCA element only, we could encounter a large number of CAs that lead away from the path we are seeking. Attempting to construct every possible path in the forward direction is clearly less practical under these circumstances.
57

Path construction- Fully distributed

Constructing in the reverse direction also involves trial and error but we will always be working with a (partial) path emanating from the relying party's trust anchor since we are answering the question "who have you issued certificates to" rather than "who has issued certificates to you."
58

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.

59