采用 Java 安全技术信任您的 e-mail(英文版)

Trusting your e-mail with Java security
Java technologies give you a complete and secure solution
Theodore J. Shrader
IBM
September 2000
内容：


Security requirements
Failing scenarios
Public and private keys
Signing a message
Signing with Java
PKCS and S/MIME
Encrypting messages
Conclusion
Resources
About the author

Internet transactions, especially messages, are the lifeblood of e-business. Ensuring their security is a requirement, not a luxury, for sensitive transactions. This article examines the Java technologies that developers can use to bring security to their e-business transactions, whether Internet messages or other types of operations. This article focuses on describing the security requirements and concepts, as well as demonstrating Java security technologies that can be used for authenticating and verifying the integrity of an e-mail message. This article also presents ways in which a message can be kept confidential by enshrouding its contents with secrecy.

Your e-mail application notifies you that Benjamin, a friend and fellow software engineer, has sent you mail from his account at Antietam Software. The message includes an attachment. Before opening it, you pause to wonder if your friend really sent the message. You know that Internet messages can easily be spoofed or their contents altered. How can you verify that the message originated from Ben and that its content is intact?
Security requirements
You抳e received a message, purportedly from Ben, but you can抰 be sure. You need to authenticate the sender of the message, but you also need to verify the integrity of the message, ensuring the original content remains intact and unaltered from its point of origin. In other words, you need to verify that Ben sent the original message and that the message you received is the same as the one Ben sent.
The two requirements of authentication and integrity have great benefit, but alone, they would allow anyone snooping on the wire to view the contents of the message, even if they couldn抰 change it. The contents of public messages need not be enshrouded, but private messages must be protected from unintended recipients. Our third security requirement, confidentiality, protects the contents of confidential messages from all eyes except those of the intended recipient. Lastly, we also need to provide a standard way in which senders and receivers can publicize information about themselves and trust information from others. A standard publication mechanism plays a key role in allowing the other requirements to work to their full potential.
In summary, our list of security requirements is:
Authentication
Integrity
Confidentiality
Publication
With these security requirements identified, we will examine possible actions that users and developers could try to fulfill their e-business security needs. Unfortunately, these possible actions each contain critical deficiencies and thus, fail to meet our security requirements. With the lessons learned from these failing scenarios, we will explore not only the promise but also the availability of public key technologies to provide these security requirements. We give particular emphasis to the use of public keys in the Java platform and to one of the most fundamental security operations -- signing and verifying data.
Failing scenarios
To fulfill our security requirements, we could take one of a number of actions:
Build a closed system.
Use a secret key.
Just open the message.
Each of the above routes is a possible action, although the last is of questionable value. Unfortunately, none of these actions fully meet all the requirements that we must have for a robust and secure e-business application. Let抯 examine these failing scenarios.
Building closed systems
Parties within a closed system shut themselves off from the outside world. They build direct connections and lock workstations behind secure doors to limit access and ensure protection.
One could argue that this solution addresses each of the four security requirements. The security controls, such as a badge or biometric reader, to the workstations hosting the applications provide a level of authentication and confidentiality. There could be integrity checks for transmitted and stored data, and an administrative authority would engage in a form of publication to ensure that users knew of the existence of other authorized users to the closed system.
For all the positive arguments, the very nature of a closed system is its greatest failing for those wishing to build a successful e-business. This utopian society works well for limited environments, but it becomes untenable for engaging the open world of the Internet. If you抮e a business, how can new customers find you and do business with you if your gates are closed to all outsiders?
Using a secret key
In the computing world, a key is a unique sequence of bits of a specified length based on the strength of the key. A secret key allows a special form of encryption where users can utilize a single key to both encrypt and decrypt data. For example, a cipher algorithm would take both a secret key and a plain text message to churn out encrypted text. The recipient of the encrypted text can use the same cipher algorithm along with the same secret key to unlock the secret message and gain access to the decrypted, original text.
Secret keys are well suited to address the confidentiality requirement. They are fast and reliable and this adds to their attraction, but where is the accountability? Anyone who owned the secret key could have sent the message. Additionally, if the secret key is lost or is compromised, all messages encrypted with the secret key are vulnerable. This loss leaves all past and current messages exposed. Even future ones can be unlocked if the users or administrators have not detected the loss of the key, as well as changed and redistributed a new secret key.
Secret keys provide a level of integrity -- if the encrypted text was altered, the encrypted text could not be decrypted to its original form -- but integrity without authentication of the sender or originator of the message is of little value. Secret keys do not even attempt to address publication. Everyone who needs the key in this security environment has it.
Opening the message
Certainly, you could open the message and allow your virus scanner to scrutinize the attachment, relying on it to detect malicious code. This route provides partial, but not complete protection. Remember that virus scanners only scan for known viruses and techniques. They cannot protect against a new virus and those for which a vaccine has not yet been developed. Virus scanners with up-to-date databases should be a standard security requirement on all workstations, but you cannot rely on virus scanners by themselves to provide complete protection to your important data.
This route addresses none of the security requirements. Indeed, this route actually flaunts them all.
So, if these possible solutions have failed or disqualified themselves due to their weakness, what technology can champion our security needs?
Public and private keys
Enter the technology and promise of public and private keys to address the security needs of e-business. This technology addresses the security requirements through what is commonly referred to as the Public Key Infrastructure (PKI). As described before, keys are a unique sequence of bits. Public key technologies require two keys: one public and one private. Information encrypted with either key only can be decrypted with the other key. For example, a private key can encrypt data and only the associated public key can decrypt the encrypted data. The reverse is also true. The difference between this method and the use of a secret key as described in the previous section is that the same key cannot be used to encrypt and decrypt information. Data encrypted by a public key cannot be decrypted by the same public key. Only the associated private key can decrypt the data.
There are two popular public and private key algorithms:
RSA -- Rivest, Shamir, and Adleman (authors of the RSA algorithm)
DSA -- Digital Signature Algorithm
RSA is the most commonly used since it can be used for both the encryption of hashed data and for general-purpose encryption. DSA can only be used to encrypt hashed data. As we will learn, encrypted hashes are known as signatures.
We抳e discussed a characteristic of public and private keys in that they can be used to encrypt data and that certainly addresses our confidentiality requirement. More importantly, the architecture of public and private keys allows the keys to be distributed to provide for accountability and communication. The owner of the key pair always keeps the private key hidden while freely sharing the public key with others through a trusted publication method known as a certificate. The certificate format provides a standard and trusted method for publication, fulfilling our fourth security requirement. The most popular form of a certificate is X.509, and these certificates store public keys at their heart.
By utilizing the nature of public and private keys, wherein the private key is kept hidden and accountable only to the owner of the key pair, we can leverage security algorithms, such as those that sign data, to authenticate senders of information and verify the integrity of the authenticated information.
Signing a message
Revisiting our initial example, you still need to determine if the message came from Ben and that the message was not altered after it was sent to fulfill the authentication and integrity security requirements. Ben can provide both if he signs the message. To do this, he would need to already own a private and public key pair and use a signature algorithm. (Signing does not provide for the confidentiality of the message, as that utilizes a different, yet complimentary encryption algorithm.) The signature algorithm is composed of two steps:
Hashing the data
Encrypting the hash
Hashing the data utilizes a digest algorithm to create a smaller, fixed-length representation of the information. Popular hash algorithms include MD5 and SHA1. Hash or digest algorithms have the following characteristics:
The original data cannot be reconstructed from the hash.
It is computationally infeasible for two sets of data to hash to the same value.
A small change in the original data will result in a large change in the hash value.
After Ben or his application hashes the original message, Ben would apply his private key to encrypt the hash of the data. The resulting encrypted hash forms the signature value of the message. Could Ben have encrypted the data with his private key and forgone the hash? Yes, but the encryption process consumes computing resources. It抯 much easier and faster to encrypt a smaller amount of data than a larger amount. That is why the signature process involves a hash of the data rather than the original data itself.
When you receive the signed message from Ben, you would need to verify its signature. As part of a signed message, you would not only receive the original message, but you would also get the signature bytes and Ben抯 signing certificate as well. You, or more likely your e-mail application, would first compute a hash of the original message using the same hash algorithm. Next, you would use Ben抯 public key to decrypt the signature. (Remember that the signing certificate contains Ben抯 public key.) This process yields the decrypted hash. If the decrypted hash and the computed hash were the same, you could be guaranteed that Ben and only Ben sent the message and that no one changed the message along the way.
Does the signature process address the authentication and integrity security requirements? Remember that only Ben has his private key, so only he could have created the signature of the message. If someone else had signed the message, you would not be able to decrypt the signature using Ben抯 public key and get the same decrypted hash that matched the computed hash of the message. If someone changed the contents of the message and the recipient tried to verify the message signature with Ben抯 public key, the computed hash would be different from the decrypted hash, since it was generated from the original message and Ben抯 private key. In this way, signatures guarantee authentication and integrity.
Popular signature algorithms include:
MD5withRSA
SHA1withRSA
SHA1withDSA
Note that the format of the signature algorithm takes the form of the hash algorithm name (MD5 or SHA1) and the hash encryption algorithm (RSA or DSA), which corresponds to the type of public key pair used in the signature algorithm.
We only touched upon the contents of a certificate. As described earlier, certificates hold public keys, but they also must provide a way to identify the public key as well as allow others to trust the contents of the certificate. Among other attributes, certificates identify who the public key belongs to through a subject distinguished name (SubjectDN), as well as who issued the certificate, the issuer distinguished name (IssuerDN). Certificate issuers are known as Certificate Authorities (CAs). The issuer of the certificate also tags the certificate with a serial number, includes a date range wherein the certificate is valid, and creates additional certificate extensions as needed. Once all the attributes are aggregated, the issuer signs the contents of the certificate with the issuer抯 private key.
The certificate signature allows you to verify the contents of the certificate in the same way that you verified the message. Your application抯 certificate database typically has a set of trusted CA certificates already installed. For example, upon installation, a Web browser typically includes a certificate database with a set of trusted CA certificates. You can add others as well.
As part of the message signature verification process in our initial example, your application would also validate the contents of Ben抯 certificate by verifying the signature on the certificate using the public key of the trusted issuer抯 certificate. You can determine which CA certificate issued a certificate by comparing the certificate抯 IssuerDN value against the value of the SubjectDN of the certificate CA. There may be more than one certificate involved in tracing Ben抯 certificate to a trusted CA certificate, creating a chain of certificates. Your application would need to verify the signature on each of the issuing certificates along the chain. There are other verification steps, such as checking if the certificate resides on a Certificate Revocation List (CRL), but verifying the signature of the certificates from the signing certificate to a trusted CA certificate, as well as checking the validity dates of each certificate in the trusted chain, are the most common.
Signing messages with Java technologies
The basic security objects, which include keys and certificates, and signing algorithms that we抳e described are included as part of the Java Cryptography Architecture (JCA). Objects and algorithms that deal with general-purpose encryption are part of the Java Cryptography Environment (JCE). The JCA is available with all Java Runtime Environments (JREs), while the distribution of the JCE is governed by export controls. (The restrictions on distributing the JCE are changing with JCE 1.2.1.)
In the following example, we show how to use the JCA to create a public and private key pair, to sign data, as well as to verify data. The public and private key pair is created at the same time using a KeyPairGenerator. We need to specify an algorithm type, as well as a key size. Remember that the larger the key size, the greater the security, yet the slower the performance. As you will find as you examine the certificates associated with many e-business sites, a public key algorithm type of RSA and key size of 1024 represent a happy medium with today抯 computing resources. Next, we get a Signature object, specify the signature algorithm as SHA1withRSA, prime the algorithm with the private key, and sign the message data.
On the verification side, we get a Signature object as before, but instead we prime it with the public key and original data. Calling the verify method with the parameter of the signature bytes returns whether or not the signature is valid and thus we can determine whether or not the message data originated from the entity represented by the public key and that the contents of the message data was not altered in transit. Unlike the verification algorithm, the signature algorithm did not take the public key to sign the data. If so, the recipient would not be able to verify the signature since only the sender has the private key.
The JCA signing example shows the signing and verification steps in one program. Typically, these actions would take place in different applications, since the sender and recipient are likely not to be the same entity. Also, the recipient typically will have the signer抯 certificate, not the raw public key. Thus, the recipient would need to extract the public key from the certificate, such as with the following Java statement:
PublicKey publicKey = cert.getPublicKey();

Using PKCS and S/MIME
We抳e shown how to sign data using objects and algorithms in the JCA, but what about a higher level application of using public and private keys? Our earlier example centered on sending and receiving a signed message. To accomplish this, we need to build upon the technology and algorithms of public and private keys and utilize the Public Key Cryptography Standards (PKCS) and Secure/Multipurpose Internet Mail Extension (S/MIME) standards.
In the early 1990s, RSA and a consortium of companies created the PKCS standards to encompass the different technologies that used public keys. PKCS #7, Cryptographic Message Syntax (CMS), defines how the various objects that compose signed data should be packaged for interoperability. Note that we could accomplish signing data without the PKCS standards, but we don抰 have a standard way for all parties to group together the different objects and encode and decode them for interoperability. The SignedData object defines how the original message, the signing certificate(s), and the signature information should be packaged together. The S/MIME standards build upon the PKCS standards, primarily PKCS #7, to define how SignedData should be sent using the MIME standards already established.
The following Java pseudocode shows how much easier it is to sign and verify data using the PKCS #7 SignedData object than with the fundamental security objects available with the JCA.
// Signing data
    // Encapsulate the data to sign.
    Data data = new Data();
    data.setBytes(message);
    ContentInfo ci = new ContentInfo(data);
    // Create the SignedData object
        // and generate the signature at the same time.
    SignedData sd = new SignedData(ci, signingCert,
          signingPrivateKey, signingAlgorithm);
    // Verifying data
    // Verify the SignedData signature by retrieving one of the
    // signing certificates.  (The SignedData object could store
    // more than one signature depending upon the number of different
    // signers of the content.)
    // The issuerAndSerialNumber corresponds to the unique identifier
    // of a certificate (its IssuerDN and SerialNumber).
    Certificate cert = sd.getCertificate(issuerAndSerialNumber);
    // PKCS method extracts the public key from the certificate.
    // The SignedData object already contains the original content
    // and algorithms used to create the signature.
    if (sd.verify(cert)) {
          System.out.println("SignedData verified.");
      }

PKCS and S/MIME support is not yet a standard part of the Java Runtime Environment (JRE). Different companies currently provide their own classes and methods to implement PKCS and S/MIME in the Java language. IBM, Sun, and the Java community are working together to include PKCS as part of the JRE base classes. This effort will make the PKCS security technologies more of a commodity, allowing all Java developers to have a standard set of classes and methods with which to write and deliver successful e-business applications.
Encrypting messages
The signing process encrypts the hash of the data, not the data itself. We did not cover encrypting general-purpose data, but the technologies are similar. Public and private keys are typically used in conjunction with secret keys to send encrypted messages, since secret key algorithms encrypt and decrypt data much faster than public key algorithms. The PKCS standards also define how to package encrypted data in a standard fashion for interoperability.
For example, to send an encrypted message, the sender would generate a unique secret key for the transaction, encrypt the message with the secret key, and encrypt the secret key with the recipient抯 public key before sending the encrypted message and encrypted secret key to the recipient. The recipient decrypts the encrypted secret key with the recipient抯 private key and uses the decrypted secret key to decrypt the message. If someone other than the intended recipient captures the encrypted message, they could not decrypt the message since only the intended recipient holds the private key that can be used to unlock the encrypted secret key. Could the original message have been encrypted with the recipient抯 public key, forgoing the secret key altogether? Yes, but as mentioned earlier, secret keys are much faster at encrypting and decrypting bulk data.
Senders can encrypt a message as a one-step operation, or senders could combine the signing and encryption process to create a message that is first signed by the sender and then encrypted before being sent to the intended recipients.
Conclusion
The growing opportunity in e-business brings with it a growth in threats over the Internet. The possibility that the message you receive may not be from the person advertised on the message is very real. Senders, including you, need to guarantee to recipients that their messages can be authenticated and integrity verified. The technologies of public keys along with signature algorithms provide this degree of trust as part of the Java platform through the JCA. Additional standards, such as PKCS and S/MIME, help developers work with these security objects and resources at a higher level to deliver successful and secure e-business solutions.

这个。。这个。。这个~~~　不懂　哈哈`~

唉~````   英语还是不好