12.3 Signing and Verifying Transactions with PKCS and SMIME

12.3 Signing and Verifying Transactions with PKCS and S/MIME

With its platform independence and ease of programming, the Java language has become the language of e-business. The basic security objects, which include keys, certificates, message digests, and digital signatures, along with the related algorithms, are included as part of the JCA, as described in Section 11.1 on page 377. Objects and algorithms that deal with general-purpose encryption are part of the JCE, as described in Section 11.3 on page 416.

Most Internet and intranet transactions are conducted using one or more of the PKCS standards described in Section 12.1 on page 434. A well-designed GUI will not expose the PKCS implementations to users needing to know that PKCS standards and objects are being used under the covers. Even though they may be hidden by a GUI, the PKCS standards play a key role in ensuring that transactions are secure. In particular, most e-business transactions make use of the objects defined by PKCS#1 and PKCS#7.

Let us say that Bob wants to use his e-mail application to send a signed message to Alice. All Bob needs to do is compose the message and check the Sign box before sending the e-mail, as shown in Figure 12.1. When Alice receives the message, her e-mail application displays the message and an icon indicating that the message was signed and verified . Alice can rest assured that Bob sent the message and that the contents were not tampered with in transit.

Figure 12.1. Signing an E-Mail Message through a GUI

Sending signed data is a simple process for the user but is more complicated under the GUI. Developers of e-mail programs and any application that sends and receives signed data need to be involved in the intricacies of the signing and verification process.

Before delving into the details of the transaction, let us first examine the use of S/MIME. To send secure messages between parties, developers have created S/MIME implementations that extend the MIME standard. The S/MIME standard builds on the PKCS standards to allow applications to send secure data through such public mail protocols as SMTP. Today's applications implement the S/MIME V2 specifications. Work on the V3 specifications is under way.

S/MIME V2 builds on the PKCS#7 and PKCS#10 objects. The MIME file extensions convey the following types of supported objects:

• 7m ” EnvelopedData or SignedData with contents

• p7s ” SignedData with signature(s) only

• p7c ” SignedData with certificate(s) only

• p10 ” CertificationRequest object

Figure 12.2 shows how Bob can use an application, such as an e-mail program, to sign and send a message to Alice.

Figure 12.2. Sending a Signed Message with PKCS and S/MIME

Once Bob composes his message and clicks Send , the application extracts Bob's private key from the application's defined certificate database, as depicted in step 1 of Figure 12.2. The application then feeds the private key and message contents into a signing algorithm, such as MD5withRSA, and generates a signature. This signature, along with other information, is bundled into a signature-only SignedData object. Before sending the message, the application constructs a p7s S/MIME message with MIME header information, original message, and SignedData object, as depicted in step 2 of Figure 12.2. The MIME header includes such information as the content transfer encoding, which is base64 encoded for PKCS objects (see footnote 2 on page 77). Finally, the application sends the S/MIME message to Alice via SMTP.

Figure 12.3 shows how Alice's application receives and verifies Bob's message. Alice's application first verifies the MIME headers in the S/MIME message, as depicted in step 1 of Figure 12.3. If the headers indicate a pkcs7-signature type, the application extracts the signer's certificate corresponding to each SignerInfo object from the SignedData object and verifies it by tracing the certificate chain back to a known trusted root CA, as shown in step 2 of Figure 12.3. If the certificate is verified, the application extracts the signer's public key from the certificate and obtains the signature from each SignerInfo object in the SignedData object, as depicted in step 3 of Figure 12.3. The application verifies each signature with the message and corresponding public key, returning true or displaying a "Signed and Verified" GUI if the verification was successful.

Figure 12.3. Verifying a Signed Message with PKCS and S/MIME

12.3.1 Considerations on the PKCS#7 Standard

As we have seen, the PKCS#7 standard includes a host of widely used objects. The most popular objects are EnvelopedData and SignedData .

An EnvelopedData object allows a sender to encrypt data with a secret key. Typically, the application that creates the EnvelopedData object automatically creates the secret key so that the caller does not need to generate it. The secret key is also encrypted for each recipient, using the recipient's public key. Once the EnvelopedData object arrives, each recipient can use his or her private key to decrypt the secret key, which in turn can be used to decrypt the data. Popular encryption algorithms include Rivest's Cipher V2 (RC2), DES, and Triple-DES.

A SignedData object allows a sender to package and sign data and a recipient to verify the signed data. This object contains a number of attributes and subobjects.

1. The top layer is composed of the digest algorithm, encapsulated contents, a set of certificates, and a set of CRLs. Applications can use CRLs to determine whether the certificates are still valid and have not been revoked by the issuing CAs.

2. A set of SignerInfo objects forms the second layer. Each SignerInfo object includes the issuer and serial number corresponding to a certificate in the parent SignedData certificate set, the message-digest and digital-signature algorithms, signed and unsigned attributes, and the signature value itself. Popular message-digest and digital-signature algorithms include SHA1withSA and MD5withRSA.

Note that not all fields are required. For example, CRLs are rarely packaged with SignedData objects. Additionally, the SignedData object is structured to allow more than one user or entity to sign the data. Each signer is represented by a SignerInfo object. No matter how many users sign the data, the SignedData object does not replicate the data to be signed. The data is enclosed once at the top layer in the encapsulated contents.

The fact that not all fields are required means that applications can use the SignedData object in a variety of forms.

1. The first form a SignedData object can take packages the signed contents and at least one signature. When populated with contents and one or more SignerInfo objects, recipients of the SignedData object can verify that the contents were signed by the entities whose certificates correspond to the SignerInfo objects.

2. However, senders often construct the SignedData object without contents and wind up sending the contents along with the separate SignedData object to recipients. This second form is known as a signature-only SignedData object ( p7s type). A signature-only SignedData object contains the signature value and information about the signer to allow recipients to take these values along with the detached message and verify the signature normally. Recipients cannot use the SignedData object itself to verify the signature on each SignerInfo object, as the verification algorithm requires the detached contents to be included as part of its parameters.

3. The third most popular form of the SignedData object is known as certificate-only ( p7s type). Section 12.1.6 on page 437 discussed how users can send a PKCS#10 message to a CA to request a certificate. In response, the CA sends back a certificate-only SignedData object. This object contains only a certificate, not any signed contents or SignerInfo objects, as there were no contents to sign.

The PKCS#7 standard allows objects to be wrapped within other objects. For example, a user can seal a message first by signing the message ”by creating a SignedData object ”and then encrypting the SignedData object by creating an EnvelopedData object that takes the SignedData object as its contents to encrypt. To unseal a message, a recipient first decrypts the sealed object to gain access to the SignedData and then verifies the signature for each of the SignerInfo objects contained in the SignedData object before extracting the enclosed message.

The PKCS#7 standard has continued to evolve . The most recent version of the standard is reflected in Request for Comments 2630. ^[3] This version upgrades the objects and attributes to support additional functionality.

^[3] See http://www.ietf.org/rfc/rfc2630.txt.

12.3.2 Using PKCS and S/MIME

Section 11.2.9 on page 400 includes several examples showing how to use the JCA API and algorithms to create and verify digital signatures. What about a higher-level application using public and private keys? To accomplish this, we need to build on the technology and algorithms of public and private keys and use the PKCS and S/MIME standards. PKCS#7 defines how the various objects that compose signed data should be packaged for interoperability. Although we could accomplish signing data without the PKCS standards, we would not have a uniform way for all parties to group together the various objects and encode and decode them for interoperability. The SignedData object defines how the original message, the signing certificate, and the signature information should be packaged together. The S/MIME standards build on the PKCS standards, including PKCS#7, to define how SignedData should be sent using the already established MIME standards.

The Java pseudocode in Listing 12.1 and Listing 12.2 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.

Listing 12.1. Signing Data with PKCS and S/MIME in Java

 // Encapsulate the data to sign. Data data = new Data(); data.setBytes(message); ContentInfo ci = new ContentInfo(data); // Create the SignedData object and simultaneously generate // the digital signature. SignedData sd = new SignedData(ci, signingCert,    signingPrivateKey, signingAlgorithm); 

Listing 12.2. Signature Verification with PKCS and S/MIME in Java

 // Verify the signature by retrieving one of the signing // certificates from the SignedData object. Note that the // SignedData object could store more than one signature // depending upon the number of different signers of the // content. The issuerDNAndSN variable corresponds to // the unique identifier of a certificate (its issuer's // Distinguished Name (DN) and Serial Number (SN). Certificate cert = sd.getCertificate(issuerDNAndSN); // The PKCS method verify() on the SignedData object // automatically 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))    return true;