Trusting Your E-mail with Java Security
By Theodore J. Shrader2003-12-04
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's 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's 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's public key to decrypt the signature. (Remember that the signing certificate contains Ben's 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's 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's public key, the computed hash would be different from the decrypted hash, since it was generated from the original message and Ben's 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's 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's 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's certificate by verifying the signature on the certificate using the public key of the trusted issuer's certificate. You can determine which CA certificate issued a certificate by comparing the certificate's IssuerDN value against the value of the SubjectDN of the certificate CA. There may be more than one certificate involved in tracing Ben's 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.
Tutorial Pages:
» Java technologies give you a complete and secure solution
» Security requirements
» Failing scenarios
» Building closed systems
» Using a secret key
» Opening the message
» Public and private keys
» Signing a message
» Signing messages with Java technologies
» Using PKCS and S/MIME
» Encrypting messages
» Conclusion
First published by IBM DeveloperWorks
