Private Key Protection

What’s 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 can’t?

• 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 can’t– 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 CA’s 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 cont’d

• 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?