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 Monopoly single 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 Variants Monopoly + 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.comma.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.comxyz.com direct abc.comxyz.com root server-based root 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