ow would you create an application that enables a user to retrieve sensitive data from a database and secure it, preventing other users from tampering with it? The application would have the following feature requirements:

• The system must require the user to approve the data.
• The system must store proof that a specific user has read and approved the data.

Timestamps and passwords immediately come to mind, but are they the best solution for such strict data authentication requirements? Because Public Key Infrastructure (PKI) and Digital Signature technology commonly are used in security and privacy software for e-mail, you may not consider them as readily?but you should. PKI and Digital Signatures actually can fulfill the data requirements for your app quite well.

PKI is a framework for message protection and authentication that uses asymmetric encryption. Unlike symmetric encryption algorithms, in which the same key is used to both encrypt and decrypt data, an asymmetric algorithm generates a set of complimentary keys: one for encrypting data and the other for decrypting it. This eliminates the need to share the secret key and also removes the risk of someone intercepting it.

In this article, I will demonstrate how to utilize PKI and Digital Signatures in a sample application that enables users to digitally sign documents, keeping others from modifying them and allowing you to validate user data. The First Step in PKI and Signatures: A Key Pair
To use an asymmetric algorithm you first have to generate a key pair. The first key is the public key, which is published to a key server so it can be shared. The other key is the private key. It is stored locally and kept confidential. To communicate securely with someone, you retrieve the recipient’s public key from a key server and use it to encrypt the data you’re sending. Only a person with knowledge of the private key can decrypt the data. With this scheme, as long as the private key is kept confidential, no one can read a message meant for someone else.

This scheme, however, is not optimal. Asymmetric algorithms are slow. To speed things up, you need to minimize the length of the data that the asymmetric algorithm processes. You can first encrypt the data using a symmetric algorithm and then encrypt the secret key you used using an asymmetric algorithm and the recipient’s public key. This way, only the intended recipient can read the secret key and decrypt the data.

While they can be used for encryption, asymmetric algorithms are manly used in PKIs to generate signatures. Signatures are used to authenticate the origin of a message and to ensure that no one has tampered with the data in the message. Here’s how it works.

When a person is ready to send data, the person:

1. Generates a digest (a unique string) from the data using a hash algorithm. (Hash algorithms apply mathematical manipulations to the data to extrapolate the digest and are extremely difficult to reverse. Common hash algorithms include SHA-1 and MD5.)
2. Encrypts the digest using a symmetric algorithm and a randomly generated secret key.
3. Encrypts the secret key using an asymmetric algorithm and the sender’s private key and appends it to the encrypted digest.
4. Attaches the signature to the data and sends it off.

To validate the message, the recipient retrieves the sender’s public key from a common key server and reverses the process:

1. Decrypts the secret key.
2. Uses it to decrypt the message digest.
3. Regenerates the digest from the message data.
4. Compares the regenerated digest and the decrypted one. If they don’t match, the data was either tampered with or it was encrypted by someone other then the sender. Either way the information in the message can be discarded as invalid.

PKI in Your Apps
Now that you have an idea what PKI and Signatures are about, look at a sample application that uses this technology. The following are the application’s requirements:

The medical or quality assurance fields are logical areas for such an application, where test results need to be reviewed and approved by a specialist and proof needs to be kept for auditing purposes in case something goes wrong.

Also, for the sample application, I simulate keycard technology using a floppy disk. Keycards are often used in conjunction with a PKI to store a user’s private key information. Such an application requires a user to insert his or her keycard into a card reader and enter a password. The password is used to decrypt the private key information on the card. (If this concept sounds familiar, it should; your bank card uses a similar technology.)

Here’s how the application works:

1. The reviewer starts the application and uses the Document>Open menu, which displays a dialog listing the available documents in the database.
2. The reviewer selects a document from the list and opens it.
3. After he’s read through it, the reviewer clicks the Sign Document button on the toolbar.
4. The system requires the reviewer to insert his floppy disk (keycard) in drive A: and input his username and password.
5. The system validates the username and password against the information in the database.
6. The system uses the password to decrypt the Private Key data stored on the floppy disk.
7. The system uses the Private Key data to generate a signature for the document.
8. The signature is stored in the database, and the document is now considered approved (DocStatus=1).

You can download the full source code for this application. To better explain how the encryption and signing process works, I’ll drill down on two processes: signing a document and validating a signature.

Signing a Document Digitally
So how does one go about signing a document? As I stated earlier, a signature is a way of both making sure that the data in the document has not been tampered with and of authenticating the document as originating from the correct person. The first step in signing the document is to ask the user to insert his keycard (a floppy disk for the sample application) and then to prompt him for his username and password. The password is validated against the data contained in the database. It then is used to decrypt the private key information on the floppy disk (see Listing 1).

With the private key data retrieved, you can generate a signature for the document. Luckily, the RSA provider exposes a method for signing data, so you don’t need to bother with the intermediary steps. You can go right to generating the signature.

When dealing with the .NET framework’s Cryptography functions, all your strings have to be converted to and from byte arrays. Do this with the ByteArrayToSting() and StringTobyteArray() functions provided in the sample code. The following snippet shows how to use these functions:

'Initialize the RSA providerobjRSAProvider = New RSACryptoServiceProvider()'load up the stored private key dataobjRSAProvider.FromXmlString(strPrivateKeyData)'Generate the signaturearSignature = objRSAProvider.SignData(arDocText, "MD5")'Convert the signature to a string '(So we can easily store it)strSignature = ByteArrayToString(arSignature)

The hash algorithm is specified as a parameter when calling the SignData() method. In the sample application, you use the MD5 algorithm to generate the digest. To complete the operation, the generated signature is inserted into the database and the status of the document is changed to approved (DocStatus=1)Validating a Signature
To validate the signature, reverse the procedure:

1. Decrypt the secret key using the reviewer’s Public Key data.
2. Decrypt the stored digest using the secret key.
3. Regenerate the digest value from the saved document.
4. Validate the digest by comparing the two values.

If the digest strings are identical, then the data was not compromised and you can prove?with reasonable certainty?that the reviewer did indeed read and approve the data.

To make this work, retrieve the Pubic Key of the user who signed that data. (The user’s identity is stored in the Document table in the DocReviewer field. The user’s Public Key information is then retrieved from the KeyData field of the User table.) Here again the RSA provider has a function to help you:

'Validate the signature using 'the Reviewer's public key dataobjRSAProvider = New RSACryptoServiceProvider()objRSAProvider.FromXmlString(strPublicKeyData)arStoredSignature = StringToByteArray(strSignature)If  objRSAProvider.VerifyData(arDocText, "MD5", _   arStoredSignature) Then  MsgBox("Document is valid!", _         MsgBoxStyle.Exclamation, "Valid")Else  MsgBox("Document is NOT valid!", _         MsgBoxStyle.Critical, "Not Valid")End If

The VerifyData() function accepts the data, algorithm name, and signature value and returns a Boolean indicating success or failure.

Use What You’ve Learned
Now that you have gained a better understanding of Public Key Infrastructures and Digital Signatures, you can use them in real-life applications. Of course, commercial applications use a more complicated and robust approach in their PKI implementations. If you’re interested in learning more about cryptography and PKI, a good place to start is the RSA Labs Web site. It contains several documents explaining how the keys and signatures are generated.