One can think of many attacks aimed at certifying authorities (see Question 125), all of which can be defended against.
For instance, an attacker may attempt to discover the private key of a certifying authority by reverse engineering the device in which it is stored. For this reason, a certifying authority must take extreme precautions to prevent illegitimate access to its private key; see Question 126 for discussion.
The certifying authority's key pair might be the target of an extensive cryptanalytic attack. For this reason, CAs should use long keys, and should also change keys regularly. Top-level certifying authorities need especially long keys, as it may not be practical for them to change keys frequently because the public key may be written into software used by a large number of verifiers.
What if an attacker breaks a CA's key, but the CA is no longer using it? Though the key has long since expired, the attacker, say Alice, can now forge a certificate dated 15 years ago attesting to a phony public key of some other person, say Bob; Alice can then forge a document with a signature of Bob dated 15 years ago, perhaps a will leaving everything to Alice. The underlying issue raised by this attack is how to authenticate a signed document dated many years ago; this issue is discussed in Question 108.
There are other attacks to consider that do not involve the compromise of a CA's private key. For instance, suppose Bob wishes to impersonate Alice. If Bob can convincingly sign messages as Alice, he can send a message to Alice's bank saying "I wish to withdraw $10,000 from my account. Please send me the money." To carry out this attack, Bob generates a key pair and sends the public key to a certifying authority saying "I'm Alice. Here is my public key. Please send me a certificate." If the CA is fooled and sends him such a certificate, he can then fool the bank, and his attack will succeed. In order to prevent such an attack, the CA must verify that a certificate request did indeed come from its purported author, i.e., it must require sufficient evidence that it is actually Alice who is requesting the certificate. The CA may, for example, require Alice to appear in person and show a birth certificate. Some CAs may require very little identification, but the bank should not honor messages authenticated with such low-assurance certificates. Every CA must publicly state its identification requirements and policies; others can then attach an appropriate level of confidence to the certificates.
In another attack, Bob bribes someone who works for the CA to issue to him a certificate in the name of Alice. Now Bob can send messages signed in Alice's name and anyone receiving such a message will believe it is authentic because a full and verifiable certificate chain will accompany the message. This attack can be hindered by requiring the cooperation of two (or more) employees to generate a certificate; the attacker now has to bribe two or more employees rather than one (see Question 126).
Unfortunately, there may be other ways to generate a forged certificate by bribing only one employee. If each certificate request is checked by only one employee, that one employee can be bribed and slip a false request into a stack of real certificate requests. Note that a corrupt employee cannot reveal the certifying authority's private key, as long as it is properly stored.
A CA should also be certain that a user possesses the private key corresponding to the public key that is certified; otherwise certain attacks become possible where the user attaches a certificate to a message signed by someone else (see [Kal93b]). (See also [MQV95] for discussion of this issue in the context of key agreement protocols.)
Note that these attacks on certifying authorities do not directly
threaten the privacy of messages between users, as might result
from an attack on a secret-key distribution center in a secret-key
cryptosystem.