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
1
Introduction
• Public Key Infrastructure (PKI) – a mechanism of securely
distributing public keys
• important for wide-area trust management (e.g., for ecommerce)
• usually consists of
– a certification authority (CA) – the entity that signs the
certificates
– certificate repositories
– a certificate revocation mechanism
2
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
3
[Fred’s public key]
Alice
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
4
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
5
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)
6
Oligarchy Example:
Default Trusted Roots in IE
7
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
8
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
9
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
intranet
abc.com
nj.abc.com
alice@nj.abc.com
bob@nj.abc.com
ma.abc.com
carol@ma.abc.com
10
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
direct
abc.com
xyz.com
root server-based
root
server
abc.com
xyz.com
11
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
12
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?
13
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
14
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?
15
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)
16
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
17
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
18