CMSC 414 Computer and Network Security Lecture 16 Jonathan Katz PKI and certificate authorities.
Download ReportTranscript CMSC 414 Computer and Network Security Lecture 16 Jonathan Katz PKI and certificate authorities.
CMSC 414 Computer and Network Security Lecture 16 Jonathan Katz PKI and certificate authorities “Public-key infrastructure” (PKI) In our discussion of public-key crypto, we have assumed users know each others’ public keys But how can public keys be reliably distributed? – Download from web page: insecure against man-in-themiddle attack – Can be obtained from CD-ROM or in person, but this is impractical in general One solution: bootstrap new public keys from public keys you already know! – Certificates vouch for binding of public keys to names PKI components Certificates – (Means for obtaining/retrieving certificates) – (Trust model/method for using certificates) “Trust anchors”/CAs – (Naming conventions; authentication policy) Revocation Certificates One party can vouch for the public key of another Cert(AB) = SignSKA(“B”, PKB, info) – “info” can include expiration time, restrictions, etc. Can view this as a directed edge in a graph: A/PKA B/PKB If you know A’s public key (and trust its certification), you can learn B’s public key Transitivity/“certificate chains” Can learn keys via multiple hops: PKA Cert(AB) PKB PKC Cert(BC) Semantics are slightly different here: you may trust A to certify B, but do you trust A to certify that B can certify others? Transitivity Can also infer trust from multiple (disjoint?) paths to the same public key for the same identity – Edges may also have weights indicating level of trust – A difficult problem in general PKA PKB PKD PKE Public keys already known PKC Obtaining certificates How does B get a certificate on its public key? For best security, done in some out-of-band manner – E.g., B shows a physical ID along with a USB stick containing its public key Other mechanisms possible – E.g., via email (under certain assumptions on reliability of email) Retrieving certificates How does A retrieve certificates for B? – “Trust anchors” = set of public keys already known to A (and trusted to certify others) Some possibilities: – B “collects” certificate(s) for itself, sends them all when starting a connection – A finds certificates/certificate chains beginning at its own trust anchors and terminating at B – A tells B its trust anchors; B (finds and) sends certificates or certificate chains beginning at those trust anchors and terminating at itself Trust anchors? Who are A’s trust anchors? Two main possibilities: – Certificate authorities – “Web of trust” CAs and certificates A certificate authority (CA) is a widely used trust anchor CA authentication policy determines the level of authentication needed to identify the principal before the certificate is issued CA issuance policy describes the principals to whom the CA will issue certificates A single entity can “act” as multiple CAs, each with their own policies… – Use distinct public keys (with different security) Example: Verisign Multiple levels of authentication – Verification of valid email address – Verification of name/address – Background check Different authentication policies with the same issuance policy (i.e., individuals) Another issuance policy for issuing certificates to corporations Trust How much to trust a particular certificate? Based on: – CA authentication policy – Rigor with which policy is followed – Security of CA’s secret key – … In practice (for most people), all CAs trusted equally Naming Identifiers correspond to principals – Must uniquely identify the principal – (Real) names alone are not enough! • Need disambiguation A principal may have multiple identifiers – Depending on that principal’s roles – E.g., work/personal Monopoly model A single CA certifies everyone Drawbacks – Single point of failure – Not very convenient – Complete monopoly… Monopoly model does not scale to the Internet, but may be used within a single organization Monopoly + RAs… The CA can appoint registration authorities (RAs) RAs check identities and vouch for keys, but the CA does all actual signing – More convenient – Not necessarily more secure (possibly less) RAs can be integrated into other models as well Monopoly + delegated CAs CA can issue certificates to other CAs – Vouch for their key and their trustworthiness as a CA – Delegated CA can sign certificates itself Users must now obtain a certificate chain 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: – Security can reduce to least secure trust anchor – Who says the user trusts the trust anchors? – Can users be tricked into using “bad” trust anchors? – Can public keys of “good” trust anchors be changed in the software? “Web of trust” model Users responsible for defining the trust anchors they want to use – E.g., their friends; people they met in person (“keysigning parties”) Drawbacks – Scalability/usability? – How much trust to place in a certificate chain PKI in the real world PKI is implemented in modern web browsers – Firefox: Tools →Options→Advanced →Encryption – IE/Chrome (via Windows): • Windows XP: Start →Run →”certmgr.msc” • Windows Vista and later: Start →”certmgr.msc” – “Trust” is only as good as your trust anchors • Do you know who your trust anchors are? “Web of trust” model – PGP keyserver (http://pgp.mit.edu) 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 Why use expiration dates at all? – Expiration dates improve efficiency – Revocation may not be implemented Cert. revocation lists (CRLs) CA issues signed list of (un-expired) revoked certificates – Must be updated and released periodically – Must include timestamp – Verifier must obtain most recent CRL before verifying a certificate Using “delta CRLs” improves efficiency OLRS (“On-line revocation server”) Also known as OCSP (“Online Certificate Status Protocol”) Verifier queries an OLRS to find out if a certificate is still valid – OLRS somewhat mitigates advantages of having a public-key model in the first place – But OLRS is not as security sensitive as a KDC/CA, and certs can be used even if OLRS is unavailable If OLRS has its own key, it can certify for a user that the user’s certificate is valid at a certain time Self revocation Sign a message revoking your own public key; send to the CA who issued your certificate This is how revocation is done in the web-of-trust model – Deposit revocation into keyserver Revocation in practice (2011) Browsers (or users) tend to ignore a failure to obtain a current CRL/connect to an OLRS http://www.imperialviolet.org/2011/03/18/revocation.html Google Chrome disabling revocation checks http://www.imperialviolet.org/2012/02/05/crlsets.html – Instead, pushing CRLs into software updates Midterm review A: 79-100 B: 65-78 C: 50-65 D/F: < 50 Re-grade policy: – Submit brief write-up of what question(s) should be regraded, and why – I will re-grade the entire exam