1

Lecture 13: Public Key Infrastructure

• terms• PKI trust models

– monopoly• with registration authorities• with delegated certificate authorities

– oligarchy– anarchy– name constraints

• top-down• bottom-up

• certificate revocation• certificate storage and lookup• certificate constraints and policies• standards: X.509, PKIX

2

Introduction• Public Key Infrastructure (PKI) – a mechanism of securely

distributing public keys• important for wide-area trust management (e.g., for e-

commerce)• usually consists of

– a certification authority (CA) – the entity that signs the certificates

– certificate repositories– a certificate revocation mechanism

3

Terms• principal – any party that has a public (and private) key• certificate – a signed message containing a public key of a particular

principal – issuer – signer of the certificate– subject – party whose public key is signed

if a party has the certificate and trusts the issuer, the party can transitively use the subject as the issuer to obtain certificates from it

• verifier(relying party) – a party evaluating the chain of certificates• target – the intended destination of the verifier in the chain• trust anchor – public key that the verifier trusts through external means

(obtained securely)

example: is Bob has Ted’s public key as a trust anchor, Bob can get Fred’s public key through Carol and Alice

[Carol’s public key]Ted [Alice’s public key]Carol [Fred’s public key]Alice

4

Monopolysingle organization is the CA for everyone• adv: simple to understand and implement• problems:

– no such universally-trusted organization– requires everyone to authenticate physically with the same

CA– compromise recovery is difficult (due to single embedded

public key)– once established, CA can abuse its position (excessive

pricing, etc.)– requires perfect security at CA

5

Monopoly VariantsMonopoly + registration authorities• Registration Authority (RA) – an entity that the central CA trusts to

do initial processing and authentication before the CA issues the certificate

• verifiers trust only the CAs– Solves the problem of physically meeting the CA. Other

problems remain.

Monopoly + delegated CAs• central CA establishes trust relationships with delegated CAs• verifiers have central CA as the trust anchor but may proceed to

delegated CAs in their verification chains– similar to CA+RA but– less efficient than RAs for verifier (chain for certs to verify)– faster than with RA to obtain target certificate

both variants can be incorporated to other (non-monopoly) models

6

Oligarchy• many root CAs exist and can be used by verifiers as trust

anchors• model for web security

– browsers come configured with 50 or so trusted CA’s public keys

• Usually, can add or delete from that set• Solves the problems of single authority (e.g., potential excessive

pricing)• problem: less secure

– overall security depends on all configured keys– naïve users can be tricked into using platform with bogus

keys, or adding bogus ones (easier to do this than install malicious software)

7

Oligarchy Example:Default Trusted Roots in IE

8

Anarchy

• each user decides whom to trust and how to authenticate their public keys

• certificates issued by arbitrary parties can be stored in public databases, which can be searched to find a path of trust to a desired party

• works well for informal, non-sensitive applications (e.g., PGP)• problems

– does not scale (too many certs, computationally too difficult to find path)

– no practical way to tell if path should be trusted– too much work and too many decisions for user

9

Top-Down with Name Constraints

• assumes hierarchical names• each CA only trusted for the part of the namespace rooted at its

name• can apply to delegated CAs or RAs• easier to find appropriate chain• more secure in practice – a sensible policy that users don’t have

to think about• problem – still have to agree on root and other problems of

monopoly model

10

Bottom-Up with Name Constraints

• two organizing principles: intranet and extranet• intranet forms a tree

– each node is a CA responsible for its subtree – each node has a parent cert (up) and child cert (down)– to navigate: the verifier traverses the tree using parent and

child as its trust anchors

abc.com

nj.abc.com ma.abc.com

alice@nj.abc.com bob@nj.abc.com carol@ma.abc.com

intranet

11

Bottom-Up: Extranets• roots of each organization establish peer trust relations (crosslinks)

– directly– through designated root service companies (easy to manage trust

relationships• advantages for bottom-up:

– for intranet, no need for outside organization– security within your organization is controlled by your organization– no single compromised key requires massive reconfiguration– easy configuration: public key you start with is your own

abc.com xyz.com

direct

abc.com xyz.com

root server-basedroot server

12

Certificate Revocation

• certificates have expiration dates (relatively long – one-two years)?

• if key is compromised, need a fast way to revoke the certificate

• techniques

– Certificate Revocation List (CRL): CA periodically issues a signed and dated list of revoked certs (may be incremental)

– On-Line Revocation Server (OLRS): can be queried over the net by verifiers to confirm the status of a cert

• unlike CA – can be online since compromise damage is minimal (why?)

• a principal can proactively refresh her certificate at OLRS

– good list – instead of storing (or issuing) the list of revoked certs, CA or OLRS can issue the list of certs that are still valid

• diallows the bad guys to use “undocumented” cert

13

Certificate Storage

• who should store certificate? subject or issuer or both?

• subject

– easy to implement top-down schemes

– unclear if the issuer has the right to store at subjects’s space

• consider IRS – a lot of people could sign for it, should IRS store those certs?

• issuer

– cross-links and bottom-up links are easier to implement (cert is for the benefit of the issuer)

– a problem if a lot of subjects

• how to handle revocation? – the subject should notify all issuers– how does place of storage affect revocation?

14

Certificate Lookup

• can be started with – subject sending its certs to the verifier (requires both parties

to communicate before message encryption is possible)– directory lookup

• directory – distributed hierarchical database indexed by hierarchical name– DNS, X.500 (LDAP)

• it will be desirable that a PKI uses existing directories to store certs– automates the process of cert lookup– currently deployed PKIs don’t use such directories

15

Constraints, Policies and Building Cert Chains

certificates may contain policies and constraints• constraint – determines the subjects the issuer is trusted to

certify– ex: only subjects in the subtree below, no more than two

crosslinks away, etc.• policy – an arbitrary mechanism to be enforced on certificate

propagation– ex: policy=security level, value=confidential

• to get from anchor to target the verifier needs to build a certificate chain, two ways– forward: from target – does not work well if have constraints

and policies– reverse: from trust anchor – okay with constrains&policies

how does place of cert storage (subject/issuer) affect the direction of chain building?

16

X.509• dominant certificate standard• versions 1 and 2 – allowed only X.500 names • fields (v3):

– version– serial number– signature algorithm identifier– issuer– validity period– subject– subject public key information– signature– standard extensions (key usage limitation, etc.)– other extensions (application & CA specific)

17

Other Certificate Standards

• PKIX: Internet standard for X.509-based PKI• SPKI: a competing IETF based on syntax alternative to X.509

SDSI: a proposal within SPKI for certificates with relative names only

18

Authorization

• authorization – allowing or denying a user to access a particular resource

• ACLs, capabilities– makes a difference whether you can answer “who has

access to that” or “what can he do”• Reuse of names, or keys as names• Groups, roles, nesting