X.509 key compromise


This is a theorotical question.
As we know, the X.509 certificates are signed by the private key of the certification authority (CA).
The certificate information is hashed using a hash algorithm and this hash is encrypted by private key of CA and then the result is attached to the certificate. This is how a signed certificate is created.

I want to know what will happen or what steps have to be taken if private key of CA is compromised?
What does the Ca needs to do in this case?
Who is Participating?
ParanormasticCryptographic EngineerCommented:
CA private key revocation is a big ordeal.  This is one of the primary reasons why it is best to have at least a 2 tier PKI with the root CA being offline (never connected to the network, domain, etc.) so you can give the highest level of assurance that that key will never be compromised (although there is always technically a chance, having it offline significantly reduces the likelihood).  That way you can sign the CRL to revoke the online subordinate CA that issues all your certs.

If the root is still good, then you can just sign a new sub CA and be back in business.  All of your previous certs will be revoked upon revocation of the CA cert, so they will all need to be reissued - if it were to happen it would be a good thing to dump the CA database (review that all certs are there by date as CA database likes to timeout - if so, filter by date and export each).  This log will also help you determine what certs need to get re-issued.

If your root CA gets compromised, there is no CRL that can properly "revoke" it - you need to rely on trusting parties to put that root cert in their untrusted publishers list, unless you're microsoft there's no way to force the rest of the world to do it - they have to take the time.  You would need to issue a new root cert and all certs below it, deploy the new root cert to everybody, and probably look for a new job.  

An online CA compromise sucks but is understandable since its on the wire; there is rarely a good excuse for the root besides being improperly set up or improperly secured.

In higher security environments, the room itself is like a vault - multiple person entry, biometric scanners, motion detectors in the room and above and below it, etc., multiple security cameras, safes to store backups in, etc. for physical security of the root key in particular.  Add to that using an HSM to protect the private key off the server which should be done for the offline and online CA servers.

So how can it be misused?  They can now assert that whatever they create - server, user account, email address, etc. - is valid within your organization.  They can issue a smartcard logon cert and log in, they can validate that their rogue web server collecting credit cards, etc., is owned by your company making you liable for it (at least until you spend hundreds of thousands in lawyer fees to prove your innocence - if you actually have enough evidence to prove it), they can send out business contracts to whomever with a signed email making it legitimate, they can send out a signed email breaking a contract or just cussing people out, they can issue a virus that is code signed so all your company trusts it, and the rest of the world will know that your PKI was cracked.  That's just a general feel for it...

Attackers don't pretend to sign certs for users - they actually sign certs for non-users.  Its like giving someone a fake ID manufacturing machine.

CA key compromise can be difficult to detect.  The best way is to have heavy audit logging of your CA and review it regularily.  Intrusion detection systems help, too, although tend to be costly.  Beyond that, once it happens and they actually use it for an attack - it may or may not be dramatic enough to be noticed immediately.  Some companies prefer to have their internal CA not publicly accessible so it can only be validated within the company, making abuse of a compromised key less likely and easier to control the damage - however this is not common as it is nice to have the functionality for business partners.
If the Key is compromised, you should have that key revoked as it is a huge security risk.  For example Microsoft had 2 of their VeriSign Private keys compromised through social engineering, they had to revoke the key so users know its untrusted.  You can see this even today if you go to internet explorer -> tools -> content -> certificates -> untrusted publishers

So push out a revoke of the key and the clients should know not to trust it
swaroop_dAuthor Commented:
Thanks a lot for that answer.
What can be the possible misuse of the compromised private key?
Can any attacker use that private key and pretend to be signing certificates for users?
How can a CA find out that the key has been compromised?
WEBINAR: 10 Easy Ways to Lose a Password

Join us on June 27th at 8 am PDT to learn about the methods that hackers use to lift real, working credentials from even the most security-savvy employees. We'll cover the importance of multi-factor authentication and how these solutions can better protect your business!

swaroop_dAuthor Commented:
Thanks for the answer.
ParanormasticCryptographic EngineerCommented:
Unless there is something you are still wondering about (if so please ask), could you close this out please, by accepting an answer.  If you are not sure how to do this, please ask.  Thanks!
swaroop_dAuthor Commented:
Just one more query before accepting the answer:

One thing is not clear from above reply:

Suppose CA has already issued 25 certificates, and then it knows that its private key is compromised, so what will happen to the status of those already issued certifcates ?

It makes sense that once CA revokes its private key, no user will trust anything being signed by the CA's private key after revocation.

Will all the certificates already issued will be termed invalid ? Do they need to be termed invalid?

ParanormasticCryptographic EngineerCommented:
When you revoke the CA cert, all certs issued from it are effectively revoked as well.  It is also common practice to revoke all certs first, extend the length of the CRL and publish one last CRL prior to revoking the CA cert.  Cuts all the guesswork out.

Some applications may still function, however, that do not do revocation checking.  EFS is one of them.  Also, some applications allow the user to bypass CRL checking and unfortunately it is getting to be common place as 'troubleshooting' (*cough) to do this instead of getting a proper fix - for example IE - Internet Options - Advanced tab - scroll to the bottom and look for:
"Check for publisher's certificate revocation" (this would be the CA cert)

"Check for server certificate revocation (requires restart)" (this would be the website cert)

I see people tell people to uncheck these all the time for a 'fix' for a cert issue - i.e. they are ignoring the problem so it no longer pops up a warning.  Just because it works doesn't make it right...  Scary.  This is part of the reason why it is common to revoke all the certs first prior to the CA cert - got twice the chance of it getting caught by the validation process.
I see your username is the source of info here Para :-)

Some applications may still function, however, that do not do revocation checking.  EFS is one of them"

That is kind of scary.A disgruntled ex helpdesk guy who was designated a recovery agent with his card that he doesnt hand back manages to logon to a laptop that hasnt downloaded the newest CRL (the one including his revoked cert) and the guy could decipher all EFS ciphered files correct?
ParanormasticCryptographic EngineerCommented:
DJM - technically - yes.  This is part of the reason why EFS DRA certs:
1. Should be associated to a unique user account (so the account itself can be disabled if necessary)
2. Should be restricted in issued and control - only highly trusted users should have access to the DRA cert.  I would not allow a standard helpdesk to be in control of it, unless maybe through scripted access (and I would still be hesistant about that).  Usually only enterprise admins should be in control of this level of cert.  In larger organizations that may have a dedicated PKI team then they may have access instead / in addition to the ent. admins.  In smaller companies, the admin and the CEO or CIO should have access.
3. Should be exported to .pfx file immediately after creation and stored in a secure fashion (i.e. locked up in a safe or offsited).  To use the DRA cert, you need to install it on the user workstation to use the private key (unless using smartcards) - after recovering you should remove the media (to protect against accidental deletion) and then delete the private key from the machine (delete the cert, then install a new copy of the .crt file that doesn't have the private key).
4. Upon replacement of any DRA cert, the GPO must be updated.  In addition to this, you should push a logon script to run the command 'cipher /u' to update all encrypted files with the new DRA cert(s).  As a side note, all of the DRA certs must be current - if any of these expires then you will not be able to update as they must be current in order to encrypt.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.