I was wondering whether a CA has different private keys to sign certificates with? Is there a risk of crypto-analysis (or something similar) when a CA signs thousands of certificates with the same private key? Does this risk exist?
-
There's always a risk someone will guess your key however likeness is very small. In total they have as many keys as you can find in e.g. Windows or Web Browser, so it's not really many of them.– AriaCommented Jul 13, 2016 at 15:55
Add a comment
|
4 Answers
I was wondering whether a CA has different private keys to sign certificates with?
A CA will usually have a number of Intermediate Keys for use in signing customers' certificates. These Intermediate Keys are in turn signed by the CA's Root Key, which should be stored "offline" and only used rarely to sign those Intermediate Keys. The matching Root Certificate is what is widely distributed and found in your browsers Trusted Root Authorities.
Is there a risk of crypto-analysis (or something similar) when a CA signs thousands of certificates with the same private key? Does this risk exist?
No, to quote Wikipedia, "Every modern cipher attempts to provide protection against ciphertext-only attacks." So there's no real worry that the amount of signatures/encryptions performed with a key creates a risk of analysis that increases based on the amount of signature/encryptions it has performed.
(Of course, to be used in so many tasks, a key has to be somewhat accessible; that's why the Intermediate keys used for everyday signing are kept "online" and the Root key is generally air-gapped or kept offline. But this is a practical, operational consideration, not a cryptographic consideration.)
answered Jul 13, 2016 at 19:17
I was wondering whether a CA has different private keys to sign certificates with?
In general, no. There is one key pair - and thus private key - per certificate. Certificates can be rolled over to use a new key pair of course. Furthermore, in general, a CA manages multiple certificates for different purposes. The CA may also have different certificates for different signature algorithms, possibly to cover the same purpose (e.g. RSA and ECDSA).
Is there a risk of crypto-analysis (or something similar) when a CA signs thousands of certificates with the same private key? Does this risk exist?
Not from an algorithm point of view. RSA and ECDSA are secure to sign many documents or certificates for that matter. ECDSA is vulnerable if the random number generator is compromised though. All the more reason to use a well vetted implementation with a good DRBG, preferably in FIPS or CC certified hardware.
As other have mentioned, most of the certificate issuance is performed by intermediate CA certificates. That means that the private key of the root certificate is not directly accessible to attackers. If an intermediate is found to be compromised (detecting compromise is a topic all in itself) then the root can be used to revoke the intermediate certificate and issue a new one, with a different private key.
Of course, when signing large numbers of certificates, there may be procedural hazards. The CA is still supposed to validate that it signs certificates for the right entities. Furthermore it should for instance resist pressure to generate the key pair for clients at the location of the CA.
Neither of the above was handled well at DigiNotar to name just one example. But that has little to do with the signature algorithms by themselves.
What we consider to be a Certificate Authority is represented by a "Trusted Root Certificate" which is a self-signed certificate that is delivered by secure means (most often during the OS or browser installation process.) Typically a single Certificate Authority issues only one Trusted Root certificate, but not always. A company that operates as a CA is free to have multiple root certificates; Thawte has one trusted root for their high integrity clients (banks, software development houses) and a different trusted root for small businesses and home users.
There is also a hierarchical model of trust, where a CA signs a few Subordinate Certificate Authorities, each of which is responsible for signing many working certificates. This is useful primarily in private organizations for managing their internal key infrastructure. (Imagine the military has a single CA cert, and it is used to sign one SCA for the Army, one for the Navy; the Army uses their SCA to sign certificates issued to each soldier, the Navy uses theirs to sign certificates issued to each sailor, etc. And every certificate can be validated simply by walking the chain back to the single CA, so a Navy guy can trust an Army guy's certificate.)
Is there a security risk to reusing a key to sign many certificates? We can't say "no" with certainty, because it actually was a problem about 10 years ago. Researchers exploited a weakness in the collision resistance of MD5, allowing the forgery of new certificates assuming the attacker could get a CA to sign a new certificate request at precisely the correct time. As the appointed time approached, the attackers flooded the CA with signing requests, hoping one of them would return exactly the timestamp they had predicted. This attack instantly proved that collision resistance was a vital attribute in the real world, and caused MD5 to lose its status as a trustworthy cryptographic algorithm; millions of web sites were at risk until eventually all MD5 root certificates were revoked or expired. Project HashClash now offers a demonstration of this collision vulnerability, although no CAs use MD5 anymore.
Note that doesn't mean that one follows the other: different private keys would not have prevented that problem; they would simply have limited the scope of the problem to a smaller number of clients exposed to an MD5 hashed certificate. But if even one of their root certificates was compromised, the vendor would be completely untrustworthy and they'd quickly be out of business (see DigiNotar as an example of how quickly a CA business can collapse if they don't protect their private keys.)
This gets to the very core problem of trust. Either you have to verify everyone independently; or OS and browser providers have to verify every organization wanting to use encrypted communications; or you have to accept that trust can be delivered by someone capable of vetting others. Is it practical to require you to drive to your bank to get their certificate, and install it in your computer? Maybe. Is it practical to require you to drive to Seattle to get Amazon's certificate and install it in your browser? Maybe not. Is it practical for Microsoft to include 20 million certificates in their browser? Maybe not. Is it practical for you to trust your friends who went to Seattle to bring you back you a copy of Amazon's certificate? Maybe, but it's kind of clumsy. Having a finite number of top-level certificates is a practical approach that mostly works.
It's much easier to accept that Symantec checked out amazon.com and issued them a certificate; it's much easier to maintain trust when your browser includes only a few dozen CA certificates. As a side benefit, if some really smart people figure out that Symantec's certificate is not trustworthy, they will tell the world and it will quickly be removed in a software patch, protecting you much faster than if you had established trust on your own (how often would you drive back to your bank to check their certificate?)
answered Jul 13, 2016 at 18:56
According to PCI a CA private key must only have one purpose. A CA used for protecting key delivery (Remote key distribution) must not be used to protect POI firmware (protecting integrity of an application). So, one CA one private key, one key one purpose. A CA may sign "SUB CA's" where each SUB CA sign certificates for different purposes.