Upload
owen-sanchez
View
213
Download
1
Embed Size (px)
Citation preview
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?