Private Key Protection

Whats it about Without the private key, the certificate is useless One of two main purposes of cert: –Prove possession of private key –Without revealing information about private key Thus it is necessary to protect the private key

Use of Certificates Personal certificates –Private key activated by person at time of use –Private key activated once, then held open Host certificates –Private key unprotected (use when booted) –Or protected (passphrase when starting) CA certificates –Private key activated when signing

Protection of Private Key Software vs Hardware Passphrase, no passphrase Subject certificates can be revoked and reissued But what if they cant? E.g., VOMS. Or the CA itself?

Protection from what? Compromise… –Attacker is able to use key –Normal confidentiality issues Loss… –Legitimate user unable to use key –Normal curation and storage issues

Compromise and Loss Compromise –Stolen key (unencrypted) –Break into machine with unencrypted key –Disgruntled employee vanishing with key material –Key stored on NFS partition with weak passphrase? Loss –Somebody steals all the copies of your keys –(We tell users to create backups, CAs are backed up) –ROBAB –Not just key, also crucial procedures

Consequences of Compromise Attacker can use the private key maliciously Worse, loss of trust in legitimate signatures => key cannot be used Potentially loss of trust in infrastructure and ops

Recovery from Compromise Announce revocation Subject certificates can be revoked and reissued But sometimes they cant –When the trust is in the certificate –Not the DN –Cf VOMS. Or the CA!

Consequences of Loss Entity unable to use private key (duh) Potentially loss of trust in infrastructure and ops Potentially expensive recovery (e.g. from ROBAB)

Recovery from Loss Similar to compromise! New certificate must be created and distributed Means to re-establish trust Re-establish procedures

Preventing Loss AND Compromise Confidential Curation? Keep multiple separate copies –Which is good for curation purposes –But can be bad for confidentiality Documented and tested recovery procedures –Which is good for curation purposes –But can be bad for confidentiality More than one person can access backup –Which is good for curation purposes –But can be bad for confidentiality

Between a rock and a hard place Does it make sense to define these: –Suspected compromise –Potential compromise –Possible compromise And if so, what are they? Tetrapilectomy (Eco) If the CAs private key is compromised or suspected compromised…

Other variations

How to store a key for 10+ years Print on paper… (scannable font) Store in a safe location…how to one? –In a lab where access is guaranteed to: cleaners, health and safety inspectors, electricians, … –Truly safe locations are expensive (hard to argue business case) –Off site? –Accessed by legitimate users (ROBAB)?

n-of-m protection Shamir secret sharing (3-5, 4-7, 5-9, …) –Can re-encode easily 2048 bit key: large numbers –Only need 1024 secret bits, modulus is public! Needs programming! Need HLL native bigint implementation –Lisp, Java, Python, Caml Multiple implementations? (stable languages, not latest fad)

Secret Sharing contd Now, each share is >= 1024 bits (or so, depending on parameter choice) 2**1024 = 10**309 = 16 ** 256 = 36**198 Not rememberable – must be written down Share holder must understand how to use it… Stable member of staff…? Testing? Rekeying? Rekeying regularly?