CSE 4905 Publickey Infrastructure 8 1 How to

CSE 4905 Public-key Infrastructure 8 -1

How to distribute public key? v Public announcement? v Publically available directory? v Public-key authority? v Public-key certificate (e. g. , X. 509 certificates) 8 -2

What is a certificate? v At the highest level its someone vouching for a claim (using a digital signature), this claim is usually related to someone else’s identity 8 -3

Public-key certification: main idea v certification authority (CA): binds public key to v particular entity, E. E (person, router) registers its public key with CA. § E provides “proof of identity” to CA. § CA creates certificate binding E to its public key. § certificate containing E’s public key digitally signed by CA – CA says “this is E’s public key” Bob’s public key Bob’s identifying information + KB digital signature (encrypt) CA private key K CA + KB certificate for Bob’s public key, signed by CA 8 -4

Certification authorities v when Alice wants Bob’s public key: § gets Bob’s certificate (Bob or elsewhere). § apply CA’s public key to Bob’s certificate, get Bob’s public key + KB digital signature (decrypt) CA public key Bob’s public + K B key K+ CA 8 -5

Uses of certificates v v v Secure communication Notarization Time-Stamping Non-Repudiation Privilege Management § Authorization & Authentication § Authorization & Policy Authorities § Delegation • Blind vs. Auditable 8 -6

Certificate example 8 -8

Certificate example (cont’d) 8 -9

Fields in a certificate v v v v v Fingerprint Version number Serial number: unique # within the issuing CA Certificate signature algorithm Issuer Validity Subject name: the name of the user Subject’s public-key information Signature … 8 -10

Certificate misconceptions v Certificates Signature § Certificates are implemented using Signatures v Certificates Authentication § Authentication can be implemented using Certificates § Same for Authorization, etc. v Certificates are static § Change => Re-Issue v Certificates identify a public key, not a user or device 8 -11

Verifying a certificate v v Integrity: signature is valid Signed by a trusted CA § or certification path is rooted in a trusted CA v Certificate is valid now: § We are between Not Valid Before and Not Valid After time points in the certificate v v Not Revoked Use is consistent with the policy 8 -12

Stages of a certificate/key Key/Certificate Life Cycle Management § Identity Key. Focus on Key! Stages v Initialization v Issued (active) v Cancellation 8 -13

Initialization v Registration § Via RA § Identity verification § If on-line, should be protected+authenticated (? ) v v v Key pair generation Certificate creation & delivery [Key backup] (used in some settings) 8 -14

Key pair generation v Where? (by who? ) § § v CA RA Owner (e. g. within browser) Other Trusted 3 rd Party What for? § Non-repudiation owner generation v Single use keys: separate key pairs for authentication, confidentiality, etc. 8 -15

Certificate dissemination v v Out-of-band Public repositories § LDAP directories (and similar) § Used mostly for confidentiality v In-band § E. g. signed e-mail usually carries certificate Issues: § Privacy, scalability, etc. 8 -18

Key backup v Backup Escrow § Backup= only owner can retrieve the (lost) key § Escrow= organization/government can retrieve the key even against owner’s wish v Non-repudiation conflicts with Backup v Where & how to backup securely? ? ? 8 -19

Issued Phase v Certificate retrieval § To encrypt msg or verify signature v Certificate validation § Verify certificate integrity+validity v Key recovery § Key backup – automate as much as possible v Key update § When keys expire: new certificate [+new keys] 8 -20

Cert Cancellation v Certificate Expiration § Natural “peaceful” end of life v Certificate Revocation § Untimely death, possibly dangerous causes v Key history § For owner: e. g. to read old encrypted messages v Key archive § “For public”: audit, old sigs, disputes, etc. 8 -21

Certificate Expiration v v No action Certificate renewal § Same keys, same cert, but new dates § Preferably automatic § but watch for attributes change! v Certificate update § New keys, new certificate 8 -22

Certificate Revocation v Requested by § Owner, employer, arbiter, TTP, ? ? ? , … v Request sent to § RA/CA v Mechanisms for Revocation checks § Certificate Revocation Lists (CRLs) § On-line Certificate Status Protocol (OCSP) • Will it live? v v (SCVP) Example of CRL (binary, not readable) http: //tb. symcb. com/tb. crl Additional reading on CRLS 8 -23

Certificate revocation v v Certificate can be revoked before expiration time CA maintains a certificate revocation lists (CRL) CRL needs to signed by CA User needs to check whether certificate is in CRL 8 -24

Public Key Infrastructure v v More than just a single CA and users requesting public keys How to manage all of this worldwide? How do users know about a CAs? How do CAs verify users? 8 -25

Trust Models v v v Certificates at their core transfer trust They cannot create trust Who to trust? § Which certificates can be trusted v Source of Trust § How it is established? v Limiting/controlling trust in a given environment 8 -26

Common models v v CA Hierarchy Distributed § Cross-certification v v Web User-centric Tool 8 -27

What is Trust? v What really is a CA supposed to do? § A CAs only real job is to verify identity v We tend to think a CA is responsible for the actions of all their issued certificates, this is not their responsibility § Who’s responsibility is it? • The malicious site v There’s a big gap between issuing a certificate for a common name and certifying they are not malicious 8 -28

Hierarchy model v v Tree architecture Single Root CA § Number of subordinate CA’s • Etc… § Parent certifies children § Leaves are non-CA (end-) entities v v Typically CA either certifies other CA’s or endentities, but not both Everyone has Root CA PK 8 -29

Distributed v A set of independent hierarchies § May evolve as independent historically v Cross-certification or PKI networking § Connect the hierarchies v Fully-meshed – all CAs are cross-certified 8 -30

User centric v v v Each user is their own Root CA Trust decisions are made on case by case basis Good § User fully responsible for trust v Bad § User fully responsible for trust § Corporate/gov/etc. like to have central control • User-centric not friendly to centralized trust policies 8 -31

Exercise v What is a good setting for each type of model? § Hierarchy § Distributed § User centric v What do you think is done on the Internet? 8 -32

Internet trust v A bunch of root CAs pre-installed in browsers v The set of root CAs can be modified by users § But will it be? v Root CAs are unrelated (no crosscertification) § Except by “CA powers” of browser manufacturer § Browser manufacturer = (implicit) Root CA v https: //jhalderm. com/pub/papers/httpsimc 13. pdf 8 -33

In band certificate validation v Alice “trusts” CA 1 § Alice has CA 1’s PK in its browser • CA 1’s PK = “trust anchor” – “trust anchor” depends on the model v v v CA 1 certifies CA 2; CA 2 certifies CA 3 certifies Bob => Alice “trusts” Bob § Alice associates PK in Bob’s certificate with Bob 8 -34

Certificate Path Processing v Path construction § Aggregation of necessary certificates v Path validation § Checking the certificates and the keys • Includes all steps of certificate validation 8 -35

Path Construction v v “Just a [Shortest] Path graph algorithm” Not so simple – graph is not known § Edges (certificates) need to be queeried v Once Path Construction is done Path Validation is straight-forward v Usually up to person being verified to provide a good path 8 -36

Exercise 2 v Let’s Encrypt: free certificate issuance to all https: //letsencrypt. org/how-it-works v Good idea or bad? v 8 -37

PKI Pitfalls: How it goes wrong v Security breaches § Key compromises v Inherent difficulties § Revocation v Negligence § Certificates are routinely not checked or some of the attributes ignored § Alarms and warnings ignored (“certificate not valid. Press OK to proceed. ”) v Inconsistencies & human factors (“that’s not what I meant by this policy!”) 8 -38