CMSC 414 Computer (and Network) Security Lecture 17 Jonathan Katz

More on PKI (Chapter 15, KPS)

PKI components  CAs…  Repository for retrieving certificates  Revocation method  Method for evaluating a chain based on known “trust anchors”  (Orthogonal issue: how are the keys of the trust anchors distributed?)

Some terminology  If A signs a certificate for B’s name/key, then A is the issuer and B is the subject  If A wants to find a path to B’s key, then B is the target and A is the verifier  A trust anchor is a public key that the verifier trusts to sign certificates (typically known to the verifier through some out-of-band mechanism)

Trust models  Define how a verifier chooses trust anchors, and what certification paths create a legal chain from trust anchor to target

Monopoly model  A single CA certifies everyone  Drawbacks –Single point of failure –Not very convenient –Complete monopoly…  Pure monopoly not used in practice

Monopoly + RAs…  The CA can appoint RAs  RAs check identities and vouch for keys, but the CA does all actual signing –Certainly more convenient –Not necessarily more secure  (Note: RAs can be integrated into other models as well)

Monopoly + delegated CAs  As seen in class last time…  CA can issue certificates to other CAs –Vouch for their key and also their trustworthiness as a CA –Delegated CA can sign certificates itself  (Note: delegation can be incorporated into other models as well)

Oligarchy  Multiple trust anchors –E.g., multiple keys pre-configured in software –User can add/remove trust anchors  Issues: –Less resistant to compromise! –Who says the user trusts the trust anchors? –Can user be tricked into adding or using a “bad” anchor?

Anarchy model  Users responsible for defining the trust anchors they want to use  Drawbacks –Scalability? –How much trust to place in a certificate chain

“Top down” w/ name constraints  Like monopoly model with delegated CAs –But delegated CAs are only allowed to certify their portions of the namespace –This makes it easier to find a certificate chain, and also is more likely to be trustworthy

Revocation  Revocation is a key component of a PKI –Secret keys stolen/compromised, user leaves organization, etc.  This is in addition to expiration dates included in certificates –Certificate might need to be revoked before expiration date –Expiration dates improve efficiency

Cert. revocation lists (CRLs)  CA issues signed list of (un-expired) revoked keys –Must be updated and released periodically –Must include timestamp –Verifier must obtain most recent CRLs before verifying a certificate  Using “delta CRLs” improves efficiency

OLRS  “On-line revocation server”  Verifier queries an OLRS to find out if a certificate is still valid  If OLRS has its own key, it can certify that a certificate is valid at a certain time

“Good lists”  The previous approaches basically use lists of “bad” certificates  Also possible to use a list containing only “good” certificates –Likely to be less efficient

Directories  PKIs do not require directories –Users can store and present their own certificate chains to a trust anchor  Directories can make things easier, and enable non-interactive setup

Finding certificate chains  Two approaches: work “forward” from target toward a trust anchor, or “backward” from trust anchor to target  The better approach depends on implementation details –For example, in system with name constraints, easier to work “backward”

Final notes: PKI in practice  PKIs are implemented in web browsers!  Security notes: –A certificate is meaningless without verifying the name in the certificate –A certificate from an unknown CA is useless –“Trust” is only as good as your trust anchors Do you know who your trust anchors are?