Figure 1: Asymmetric key encryption -- The highest security is obtained by employing asymmetric key pairs, as demonstrated by this form.


Figure 2: PGPKeys utility -- The PGPKeys utility (part of the PGP installation package) shows you the key ID for any key in your keyring file.


Figure 3: Digital signature file -- The encrypted digital signature can only be evaluated with your private key.

The case for digital signatures

A lot has been written recently about Internet security. It seems that crackers lurk on every corner of the Internet, waiting to hack your Web site and abscond with the important data driving your site. There have been several notable incidents where entire database files have been stolen from popular Web sites, exposing credit card and personal information to unauthorized use and identity theft.

While it's true there are people interested in wreaking havoc with your Web site and its server, the tools for protecting your Web server and its files are getting better. If nothing else, security awareness and the skill level of Web masters has improved considerably over time.

Another security issue has to do with protecting database files and the data they contain from unauthorized access. Although every credible database system includes user and workgroup security, there are times when you want to protect an entire database file, a text file, or other file from unauthorized access. There are also times you have to e-mail a file to another person, confident that the file won't be tampered with or accessed by an unauthorized person along the way.

That's what this article is about. You'll find enough information to use strong encryption to encrypt data files. You'll also see how to digitally sign a file so the authenticity of the file and its contents are guaranteed.

Digital signatures primer

To recap from my previous article, digital signatures are based on public key infrastructure (PKI) in which key pairs are used to encrypt and decrypt messages. Your public key is used (by anyone) to encrypt a message sent to you. You (and only you) use your private key to decrypt the message. No other key can decrypt a message encrypted with your public key. The reverse is also true.

A digital signature consists of a message digest, which is a fixed-length, hashed representation of the message content. The message digest is encrypted with the sender's private key. Upon receipt, the message digest is decrypted with the sender's public key, and compared with a fresh copy of the message digest prepared from the message body (keep in mind that a secure message sent to you was encrypted with your public key, and has been decrypted with your personal private key). If the message digest sent with the encrypted message matches the message digest prepared after decryption, you know the message and its origin are authentic.

PGP as a digital signature tool

Pretty Good Privacy is a strong encryption product available as a free download (http://www.pgpi.com) for personal use. You can also get it as a licensed product for incorporation into commercial applications (see the Network Associates Web site at http://www.nai.com). For more on PGP, refer to my previous article.

Although PGP installs a nice e-mail add-in to Outlook, those capabilities don't address the need for automatically creating and attaching digital signatures to e-mail and files. Although PGP supports encryption and digital signatures as a manual process, you must be able to program these operations through code. The presence of an API extends PGP's capabilities as a VBA programmer's tool.

PGP is distributed in a variety of installation packages. You can use the international edition's strong encryption in any country where 128-bit encryption is allowed. The U.S. version of PGP provides for encryption keys as large as 4096 bits.

Another interesting version of PGP is the PGP Software Development Kit (SDK). The PGP SDK includes the complete PGP source code (in the C language) as well as pre-compiled DLLs. A proficient programmer can incorporate the PGP source code into an application by adding the C code or using the API-style DLLs to access PGP's features.

Here's the bad news. The PGP SDK is accompanied by a dense, technical, 400-page user guide that explains how to use each of the several PGP functions in its C-language context. A proficient C developer would have to spend quite a while studying the SDK user guide to provide even the simplest strong encryption to an application written in C. I think it's safe to say that most VBA developers -- particularly those lacking C experience -- would fail to incorporate the PGP SDK into an Access or VB application. It's simply too complex to tackle without significant C programming practice.

The good news is that Gerard R. Thomas has spent the time and effort to produce a COM object (NSDPGP.DLL) that wraps up the complexity of the PGP API. This COM object exposes most of PGP's capabilities in just a few properties and methods. It is available for free download at:

http://community.wow.net/grt/nsdpgp_dll.htm

Thomas's COM wrapper greatly simplifies the process of adding strong encryption to VBA applications.

Getting started with the PGP COM wrapper

Before you can take advantage of the PGP COM wrapper, you must first download and install PGP on your computer. The PGP DLLs must be present on all machines before the PGP COM wrapper will work. (Visit the PGP home page to download the latest version of PGP.) Because of the export limitations imposed by the U.S. government, Network Associates (PGP's vendor) requires you to register your copy of PGP before downloading.

Next, download the Grohm128.zip file (it contains NSDPGP, the COM object package), unzip it, and run the setup program. (The instructions are given in the Readme.txt file accompanying the Zip file.)

As a convenience, Thomas has graciously made the Zip file available on this issue's Professional Resource CD. He imposes no restrictions on sharing his COM object.

Finally, decide what type of encryption you want to apply in your application. NSDPGP performs a number of asymmetric key tasks such as PKI encryption and decryption on files, applying digital signatures to files, and verifying the digital signature accompanying a file.

In either case, start by setting a VBA reference to the PGP COM Interface (use Project > References in VB, Tools > References in Access). After you've referenced the appropriate COM object, use standard COM programming techniques to create and instantiate COM objects in VBA code, then use the exposed properties and methods to encrypt, decrypt, and sign strings and files.

The methods suffixed with "ex" require private and public keys and perform their tasks using the public key infrastructure (PKI) discussed in the previous article. In this article, I only discuss a few of these methods, but the code in this article is similar to the code required for all of the NSDPGP methods.

Table 1: NSDPGP methods -- NSDPGP provides all the necessary functions for symmetric and asymmetric encryption and digital signatures.
Method	Task
EncryptFile, EncryptFileEx	Encrypts an entire file
DecryptFile, DecryptFileEx	Decrypts a file
SignFile, SignFileEx	Provides a digital signature
VerifyFile, VerifyFileEx	Verifies a digital signature
WipeFile, WipeFileEx	Wipes all traces of a file from the disk

Table 1 lists the methods supported by the NSDPGP COM object and briefly describes the role of each method.

About cipher algorithms

The three ciphers incorporated into PGP (Triple-DES, CAST-5, and IDEA) use large keys based on the passphrase you submit as the argument to the Encrypt function. Triple-DES is a 64-bit cipher based on 64-bit keys while IDEA and CAST are based on 128-bit keys. However, IDEA isn't a public domain algorithm, leaving CAST or Data Encryption Standard (DES) as the logical choice in most applications. (Triple-DES is the 56-bit DES algorithm applied three times to the data, yielding a 168-bit key combination.)

Of the three ciphers available through the NSDPGP object's Encrypt method, CAST is probably your best bet. CAST uses 128-bit keys, is fast, and has never been broken. CAST is highly resistant to decryption techniques that have succeeded against IDEA and DES.

DES is an older encryption algorithm invented in the 1970s. Because it uses 56-bit keys, it is considered less secure than more modern 128-bit algorithms.

Regardless of the cipher you select, as long as you keep the passphrase secret, NSDPGP will strongly encrypt your data files.

Using NSDPGP

NSDPGP provides access to some of the more advanced PGP encryption features. A complete discussion of all the members of the NSDPGP object is beyond the scope of this article, so I'll concentrate on encrypting files and preparing digital signatures for files. I'll also focus on the asymmetric key capabilities of NSDPGP (NSDPGP also performs simple encryption and simple signatures). As you'll see, you'll have to use PGP to prepare an asymmetric key pair available to perform many of the functions available through NSDPGP.

This issue's Professional Resource CD includes the application you see in figure 1. This form includes all the code described later in this article, as well as other logic involved in the encryption process.

Encrypting and signing a file

The first task I examine is encrypting a file using strong encryption and a public key. This is the situation where you are sending a file to someone as an e-mail attachment and you want only the recipient to be able to decrypt the file.

NSDPGP must be able to access the recipient's public key in the PGP public keyring on your computer. You add keys to your keyring through the PGPKeys utility that comes with PGP. This small application lets you visit the PGP key server, and select keys to add to your keyring, based on the public key owner's e-mail address. For instance, I might add the key belonging to wagonwheel_mason@earthlink.net to my keyring. I can then use the key ID (0x62CF96C7) associated with this key to prepare digital signatures for my files.

The syntax to encrypt a file is:

NSDPGP.EncryptFileEx(RcptKeyID, SignKeyID, _
   InFile, OutFile, Password)

The RcptKeyID and SignKeyID values are hexadecimal values associated with the public and private keys of the recipient and sender, respectively. The key ID value is accessible through the PGPKeys applet. InFile and OutFile are the plain text and encrypted files, respectively, and Password is the case-sensitive passphrase necessary to access the private keyring on the signer's computer.

Assume I want to encrypt and digitally sign a file named Message.txt and send it to Wagonwheel Mason. The code to perform these tasks is:

Dim pgp As New NSDPGP.NSDPGP
Call pgp.EncryptFileEx( _
   RcptKeyID:="0x62CF96C7", _
   SignKeyID:="0x5F16C477", _
   InFile:="Message.txt", _
   OutFile:="Message.txt.pgp", _
   Password:="let slip the dogs of war")

The recipient and signer key IDs are taken from the PGPKeys utility (figure 2). InFile, of course, is the unencrypted file (which could be an Access .MDB or a SQL Server MDF file). The passphrase is required so NSDPGP can access the private keyring on my computer to verify the signer's key, but isn't needed to decrypt the file.

Upon receipt, Wagonwheel uses PGP, his own passphrase, and his private key to decrypt the message. PGP then uses my public key (stored in Wagonwheel's public keyring) to verify the digital signature. Because the file has been encrypted with Wagonwheel's public key, only his private key can decrypt the file. And, because I used my private key to prepare the digital signature, Wagonwheel's machine is able to verify the authenticity and content of the file.

Signing without encrypting

Although most examples you'll see of preparing digital signatures with PGP involve an encryption step (as in the previous example), it isn't necessary to encrypt the file. Sometimes you want to circulate a memo or other document in plain text, yet you want to know whether anyone has altered the document since it was originally sent.

However, it isn't always a good idea to directly attach a digital signature to a binary file such as a Word document or Access database file. It is unlikely the file's host application will be able to open the signed file.

In this case, you'll want to prepare a separate signature file. The signature file contains the message digest of the plain text file, and is encrypted with your public key. This means, of course, that you and only you can use your private key to decrypt the signature file and verify the contents of the plain text file.

The code required to prepare an external signature file isn't extensive:

Dim pgp As New NSDPGP.NSDPGP
Call pgp.SignFileEx( _
   Hash:=2, _
   SignKeyID:="0x5F16C477", _
   InFile:=""Message.txt", _
   SigFile:="Message.txt.sig", _
   Password:="let slip the dogs of war")

Hash is the secure hash algorithm to use when producing the message digest (2 means to use SHA-1), SignKeyID is the key ID of the file's signer, InFile is the name of the plain text file, SigFile is the text file to contain the digital signature, and Password is the passphrase necessary to access the private keyring on the computer.

The result of this function is a separate text file containing the digital signature as shown in figure 3.

The code to verify the contents of the signature file is not difficult. The arguments to VerifyFileEx are the same as the same-named arguments to SignFileEx:

Dim pgp As New NSDPGP.NSDPGP
Call pgp.VerifyFileEx( _
   SigInfoFile:="Message.txt.SigInfo", _
   InFile:="Message.txt", _
   SigFile:="Message.txt.sig")

Notice that you don't need the passphrase, signer's key ID, and other information to verify the signature. The .SIG file contains all this information.

NSDPGP writes a signature information file (Mes-sage.txt.SigInfo) containing a message indicating the state of the verification operation. The signature file is a plain text file and contains a string such as:

SIGSTS_VERIFIED  Good signature  Signed by Michael Groh
<mikegroh@earthlink.net> Mon Oct 22 08:24:26 2001  
Key ID 0x5F16C477

Personally, I'd prefer that the verification method simply return True or False indicating success or failure. The VerifyFileEx method in NSDPGP requires you to open the text file, read in the string it contains, and parse it for the success message. However, leaving a permanent disk file isn't all bad.

Understanding hash algorithms

Let's spend a moment on the digital signature's hash argument. There are a number of different algorithms for performing the hash on the file contents, including Secure Hash Algorithm (SHA), Message Digest 5 (MD5), and RIPE-MD (a European-developed digest algorithm).

Of these algorithms, SHA-1 is probably your best bet. SHA-1 was developed by the National Security Agency (NSA) as a standard secure hash algorithm on behalf of the National Institute of Standards and Technology (NIST). SHA-1 has never been broken and represents an extremely secure method of preparing digital signatures. Because the message digest is protected with a large private key, there is no chance someone will be able to modify the file's contents and regenerate the message digest without detection.

About those passphrases

Remember, you should never directly program a password or passphrase in plain text within your application. During compilation, string literals are preserved in the executable and you can read them by opening the executable in a word processor. You should always hide the human-readable representation of the passphrase.

For instance, you can hide the content of the passphrase by building it up from the ASCII values of its constituent characters:

Public Function Passphrase() As String
  'Plain text passphrase: let slip the dogs of war
  Passphrase = Chr(108) & Chr(101) & Chr(116) _
     & Chr(32) & Chr(115) & Chr(108) & Chr(105) _
     & Chr(112) & Chr(32) & Chr(116) & Chr(104) _
     & Chr(101) & Chr(32) & Chr(100) & Chr(111) _
     & Chr(103) & Chr(115) & Chr(32) & Chr(111) _
     & Chr(102) & Chr(32) & Chr(119) & Chr(97) & Chr(114)
End Function

At runtime, "Passphrase" returns a meaningful string without preserving a string literal in the executable.

Additionally, the passphrase should be something as bizarre and hard-to-guess as possible ("let slip the dogs of war" is neither!). To complicate the passphrase, make it up of random words, then specify its characters in reverse order (raw fo sgod eht pils tel), or transpose alternate characters (el tlspit ehd go sfow ra). These simple transformations, which aren't difficult to program in VBA, make even a recognizable phrase difficult to crack. Thanks to Paul Sheriff for these passphrase-hiding suggestions!

Wrap Up

Incorporating strong encryption into Access and Visual Basic applications doesn't require extraordinary skills or effort. VBA developers can leverage the hard work of cryptographers who've devoted their lifetimes to the study of privacy and security.

Strong encryption is becoming more common in database and Web applications, and with good reason. A truly secure Web site or database application can't rely on workgroup or operating system security to protect the data managed by the application. Strong encryption and digital signatures guarantee the security and integrity of database data, files, and other important application resources.

If you choose to use PGP or its libraries as part of a commercial application, you must contact Network Associates (http://www.nai.com or 408-988-3832) and arrange for a software license. You can, however, use PGP and the PGP DLLs for personal use.