rsa-faq.txt

汇聚各种应用密码学密码算法技术源码

Once generated, a user must register his or her public key with some
central administration, called a certifying authority. The certifying 
authority returns to the user a certificate attesting to the veracity of 
the user's public key along with other information (see Questions 3.5 
and following). Most users should not obtain more than one certificate for
the same key, in order to simplify various bookkeeping tasks associated
with the key.


3.4 Should a public key or private key be shared among users?

In RSA, each person should have a unique modulus and private exponent, i.e., 
a unique private key. The public exponent, on the other hand, can be common 
to a group of users without security being compromised. Some public exponents 
in common use today are 3 and 2^{16}+1; because these numbers are small, 
the public-key operations (encryption and signature verification) are fast 
relative to the private key operations (decryption and signing). If one 
public exponent becomes a standard, software and hardware can be optimized 
for that value.

In public-key systems based on discrete logarithms, such as ElGamal,
Diffie-Hellman, or DSS, it has often been suggested that a group of 
people should share a modulus. This would make breaking a key more
attractive to an attacker, however, because one could break every
key with only slightly more effort than it would take to break a
single key. To an attacker, therefore, the average cost to break a 
key is much lower with a common modulus than if every key has a distinct 
modulus. Thus one should be very cautious about using a common modulus; 
if a common modulus is chosen, it should be very large. 


3.5 What are certificates?

Certificates are digital documents attesting to the binding of a public key 
to an individual or other entity. They allow verification of the claim that 
a given public key does in fact belong to a given individual. Certificates 
help prevent someone from using a phony key to impersonate someone else.

In their simplest form, certificates contain a public key and a name. As
commonly used, they also contain the expiration date of the key, the name 
of the certifying authority that issued the certificate, the serial number 
of the certificate, and perhaps other information. Most importantly, it 
contains the digital signature of the certificate issuer. The most widely 
accepted format for certificates is defined by the CCITT X.509 international 
standard [19]; thus certificates can be read or written by any application 
complying with X.509. Further refinements are found in the PKCS set of 
standards (see Question 8.9), and the PEM standard (see Question 8.7). A 
detailed discussion of certificate format can also be found in Kent [40].

A certificate is issued by a certifying authority (see Question 3.7) 
and signed with the certifying authority's private key.


3.6 How are certificates used?

A certificate is displayed in order to generate confidence in the 
legitimacy of a public key. Someone verifying a signature can also 
verify the signer's certificate, to insure that no forgery or false 
representation has occurred. These steps can be performed with greater 
or lesser rigor depending on the context. 

The most secure use of authentication involves enclosing one or more 
certificates with every signed message. The receiver of the message
would verify the certificate using the certifying authority's public
key and, now confident of the public key of the sender, verify the message's 
signature. There may be two or more certificates enclosed with the message, 
forming a hierarchical chain, wherein one certificate testifies to the 
authenticity of the previous certificate. At the end of a certificate 
hierarchy is a top-level certifying authority, which is trusted without a 
certificate from any other certifying authority. The public key of the 
top-level certifying authority must be independently known, for example by 
being widely published.

The more familiar the sender is to the receiver of the message, the less 
need there is to enclose, and to verify, certificates. If Alice sends 
messages to Bob every day, Alice can enclose a certificate chain on the 
first day, which Bob verifies. Bob thereafter stores Alice's public key 
and no more certificates or certificate verifications are necessary. A sender 
whose company is known to the receiver may need to enclose only one 
certificate (issued by the company), whereas a sender whose company is 
unknown to the receiver may need to enclose two certificates. A good rule of 
thumb is to enclose just enough of a certificate chain so that the issuer of 
the highest level certificate in the chain is well-known to the receiver.

According to the PKCS standards for public-key cryptography (see Question
8.9), every signature points to a certificate that validates the public 
key of the signer. Specifically, each signature contains the name of the 
issuer of the certificate and the serial number of the certificate. Thus 
even if no certificates are enclosed with a message, a verifier can still 
use the certificate chain to check the status of the public key.


3.7 Who issues certificates and how?

Certificates are issued by a certifying authority (CA), which can be any 
trusted central administration willing to vouch for the identities of those 
to whom it issues certificates. A company may issue certificates to its 
employees, a university to its students, a town to its citizens. In 
order to prevent forged certificates, the CA's public key must be trustworthy: 
a CA must either publicize its public key or provide a certificate from a 
higher-level CA attesting to the validity of its public key. The latter
solution gives rise to hierarchies of CAs.

Certificate issuance proceeds as follows. Alice generates her own key 
pair and sends the public key to an appropriate CA with some proof of her 
identification. The CA checks the identification and takes any other steps
necessary to assure itself that the request really did come from Alice, and 
then sends her a certificate attesting to the binding between Alice and her 
public key, along with a hierarchy of certificates verifying the CA's public 
key. Alice can present this certificate chain whenever desired in order to 
demonstrate the legitimacy of her public key. 

Since the CA must check for proper identification, organizations will find 
it convenient to act as a CA for its own members and employees. There will 
also be CAs that issue certificates to unaffiliated individuals.

Different CAs may issue certificates with varying levels of identification 
requirements. One CA may insist on seeing a driver's license, another may 
want the certificate request form to be notarized, yet another may want 
fingerprints of anyone requesting a certificate. Each CA should publish 
its own identification requirements and standards, so that verifiers 
can attach the appropriate level of confidence in the certified name-key 
bindings.

An example of a certificate-issuing protocol is Apple Computer's Open 
Collaborative Environment (OCE). Apple OCE users can generate a key 
pair and then request and receive a certificate for the public key; the
certificate request must be notarized.


3.8 What is a CSU, or, How do certifying authorities store their private keys?

It is extremely important that private keys of certifying authorities are 
stored securely, because compromise would enable undetectable forgeries. 
One way to achieve the desired security is to store the key in a tamperproof
box; such a box is called a Certificate Signing Unit, or CSU. The CSU would, 
preferably, destroy its contents if ever opened, and be shielded against 
attacks using electromagnetic radiation. Not even employees of the certifying 
authority should have access to the private key itself, but only the ability 
to use the private key in the process of issuing certificates. 

There are many possible designs for CSUs; here is a description of one design
found in some current implementations. The CSU is activated by a set of data 
keys, which are physical keys capable of storing digital information. The 
data keys use secret-sharing technology such that several people must all 
use their data keys to activate the CSU. This prevents one disgruntled CA 
employee from producing phony certificates. 

Note that if the CSU is destroyed, say in a fire, no security is compromised.
Certificates signed by the CSU are still valid, as long as the verifier uses 
the correct public key. Some CSUs will be manufactured so that a lost private 
key can be restored into a new CSU. See Question 3.10 for discussion of 
lost CA private keys.

Bolt, Beranek, and Newman (BBN) currently sells a CSU, and RSA Data Security
sells a full-fledged certificate issuing system built around the BBN CSU.


3.9 Are certifying authorities susceptible to attack?

One can think of many attacks aimed at the certifying authority, which must
be prepared against them.

Consider the following attack. 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.

An attacker who discovers the private key of a certifying authority could 
then forge certificates. For this reason, a certifying authority must take 
extreme precautions to prevent illegitimate access to its private key. The 
private key should be kept in a high-security box, known as a Certificate 
Signing Unit, or CSU (see Question 3.8).

The certifying authority's public key might be the target of an extensive 
factoring attack. For this reason, CAs should use very long keys, preferably 
1000 bits or longer, and should also change keys regularly. Top-level 
certifying authorities are exceptions: it may not be practical for them to 
change keys frequently because the key may be written into software used 
by a large number of verifiers.

In another attack, Alice bribes Bob, who works for the certifying authority, 
to issue to her a certificate in the name of Fred. Now Alice can send 
messages signed in Fred's name and anyone receiving such a message will 
believe it 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 employees rather than one. For example, in 
some of today's CSUs, three employees must each insert a data key containing 
secret information in order to authorize the CSU to generate certificates. 
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.

Another attack involves forging old documents. Alice tries to factor the 
modulus of the certifying authority. It takes her 15 years, but she finally 
succeeds, and she now has the old private key of the certifying authority. 
The key has long since expired, but she can forge a certificate dated 15 
years ago attesting to a phony public key of some other person, say Bob; she 
can now forge a document with a signature of Bob dated 15 year 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 3.17.

Note that these attacks on certifying authorities do not threaten the 
privacy of messages between users, as might result from an attack on a 
secret-key distribution center.


3.10 What if the certifying authority's key is lost or compromised? 

If the certifying authority's key is lost or destroyed but not compromised, 
certificates signed with the old key are still valid, as long as the verifier
knows to use the old public key to verify the certificate. 

In some CSU designs, encrypted backup copies of the CA's private key are
kept. A CA which loses its key can then restore it by loading the encrypted 
backup into the CSU, which can decrypt it using some unique information 
stored inside the CSU; the encrypted backup can only be decrypted using the 
CSU. If the CSU itself is destroyed, the manufacturer may be able to supply 
another with the same internal information, thus allowing recovery of the key. 

A compromised CA key is a much more dangerous situation. An attacker