Mixed messages
Protecting email from prying eyes.
Maury Wright, Executive Editor

Internet email gets exposed to potentially prying eyes at dozens of stops en route to its destination. Moreover, exposure of sensitive data is only one of email's ills, as the recent "love bug" and older Melissa viruses have proven.

Widespread use of encryption and authentication could neutralize both the virus and privacy threats, and such tools exist today. Despite the upside, a combination of apathy and logistical issues has stymied the widespread use of privacy tools. And for some reason, users aren't demanding that the barriers to widespread deployment be dismantled.

My earlier experiments with firewalls (see the previous Inside the Digital Den articles "Splitting the pipe fantastic" and "Wide pipes shut") left me curious about encryption technology. As a telecommuter, I realized that even my email communications with the main office cross the unprotected Internet. Over the last decade, I've read sporadically about encryption, as I suspect many PC users have, but I've never taken the plunge with encryption tools.

It's time to reverse that trend, because encryption and authentication will be even more important in the convergence era. Wireless technologies will expose messages to even greater potential risks. Plus, authentication will allow us to expose interfaces in our eHomes to the outside world, which will allow outside entities (either ourselves or service providers) to interact with our smart appliances. So I set out to take the first step and place an ePadlock on my important messages.

As you may have guessed, encryption and authentication are two separate but interrelated concepts that have privacy and security implications. Encryption generally means that a message is encoded and that only a recipient possessing a key can decode the message. Authentication implies that one knows for certain the source of a message, and that the message hasn't been tampered with. In industry lingo, an authenticated message is in a state of non-repudiation, meaning the sender can't deny having sent it.

eKeys

Software that uses the public/private key concept makes both encryption and authentication possible. In this scenario, you have a secret private key. From the private key, an algorithm generates a unique public key, but the opposite action is impossible. You can freely publish your public key. As long as someone has your public key, they can encrypt a message and send it to you, and you can decrypt it using your private key.

Likewise, you can securely sign and thereby authenticate a message using your private key. The software uses the private key to provide an encrypted signature, yet leaves the text payload unencrypted. A recipient with a copy of your public key can decrypt the signature, thereby verifying the source and that the text payload was not tampered with. Messages can also be both encrypted and signed.

Sounds simple, but there's deep science behind both the encryption algorithms and the key-generation algorithms. And the marketplace has provided a number of choices, which, generally speaking, can't be broken without enormous effort. However, like many areas of the industry, choices aren't always good when it comes to furthering acceptance of an emerging technology. Inevitably, disagreements slow the establishment of an industry standard and delay proliferation. And like other convergence-era conundrums—rewritable DVD, new network technologies, or flash-memory formats—intellectual property rights play a key role, as rights owners hope to develop royalty revenue.

Secure email choices today come down to two alternatives, Secure Multipurpose Internet Messaging Extensions (S/MIME) and Open Pretty Good Privacy (OpenPGP). Each technology is being standardized in a separate Internet Engineering Task Force (IETF, www.ietf.org) working group. Perhaps the best way to follow the efforts, if you're interested, is via the Internet Mail Consortium (www.imc.org).

eStalemate

Surprisingly, I've yet to find anyone who claims that either technique surpasses the other at encryption or authentication. While the two do have technical differences, which the IMC Web site summarizes, observers generally judge their capabilities to be equal. Moreover, both technologies relied on some patented techniques in earlier incarnations, but the ongoing IETF efforts intend to yield standards that are unencumbered by intellectual property and royalty restraints.

Instead, the arguable differences presumably center on the potential Achilles heel of any public/private key system—key management. If you didn't realize the potential problem during the simplified discussion of encryption and authentication above, here it is. Establishing the authenticity of someone's public key is paramount to the success of the system.

PGP, OpenPGP's ancestor, was the creation of a solo programmer named Phil Zimmermann. PGP is a decade old, and its popularity grew largely through a grassroots effort, as individuals spread the non-commercial freeware version that's still available from MIT. Today, Network Associates (www.nai.com) owns PGP, but key patents expire this year. Moreover, with OpenPGP on the horizon, you can expect more PGP-based products to hit the market late this year.

Given its organic heritage, PGP has relied on a so-called web-of-trust model for public-key distribution. For example, if person X has a trusted public key for person Y, and person Y has a trusted public key for person Z, then person X can trust person Z's public key. Trust gets passed along as users sign copies of each others' keys, indicating that they believe the keys to be authentic.

S/MIME, meanwhile, developed more recently, driven by more of a corporate model. The forces behind S/MIME intended to develop a hierarchical system for public-key authentication and distribution that includes both enterprise networks and public-key repositories that rely on Certificate Authorities (CAs)—third parties that verify user identities. Realistically, the two models are just philosophies. You can use CAs today with OpenPGP, and you can use personal relationships for S/MIME key exchange.

The critical point you should grasp? Key management is and will be an obstacle to using any encryption or authentication tool ubiquitously. It's not even clear whether it's a solvable problem, given the wide sphere of contacts with which many of us communicate today via email. Ubiquitous use is, however a noble goal. It would eliminate email viruses immediately.

Obviously, encryption would also eliminate any prying eyes. It's unclear just how many people may have been victimized by information gleaned from unsecured email. Companies would be unlikely to admit such incidents for fear of sacrificing their credibility with customers and stockholders. But to avoid such eminently avoidable problems, the industry should move toward selective use of encryption, and via filtering and other techniques, prioritize authentic messages.

eCheap

Now that we've covered the obstacles associated with widespread use of privacy tools, let's discuss the good news. Encryption and privacy tools don't cost much, and other than key management, the actual mechanics of using the tools are simple.

You can get non-commercial freeware—in either S/MIME or PGP flavors—that integrates directly with popular email clients like Microsoft Outlook and Qualcomm Eudora. In addition to working within the email packages, these software products typically give you the ability to encrypt files manually using a GUI or command-line interface. Moreover, these programs come in versions for almost any operating system that you might encounter, although the Windows and Macintosh versions are by far the easiest to use.

My guess is that most people will pick an encryption technique based on their own email universe and specifically based on what package their contacts use. And incidentally, you can have both S/MIME and PGP installed in a single email client. Moreover, due to PGP's long heritage, you might have multiple signatures or keys that have relied on different versions of PGP with different algorithms.

I decided to use PGP for my experiments for several reasons. It's clear that PGP is more widely deployed today, although proponents of S/MIME claim that corporate support will make it the long-term winner. Most of the people I know who use encryption use some flavor of PGP.

I knew going in about the freeware PGP package, but having received a press release touting Network Associates' newest desktop suite, I started my research at that company's Web site. If you go this route, you could quickly become discouraged. The site includes links to four separate companies including McAfee, which is still a brand name for SOHO software titles including virus scanners, despite the fact that McAfee became Network Associates after several acquisitions including that of PGP Inc.

If, however, you go to the PGP Inc section of Network Associates' site, you get explicit instructions that non-corporate customers should proceed to the McAfee section of the site. But the McAfee section has no PGP software. Go figure.

It seems these folks are trying to run customers off, and even perseverance with the PGP site leaves you wondering how to buy the desktop PGP package. Ironically, a link to the MIT freeware pitches you on the benefits of paying for a single-user package, but it provides no enlightenment on how to do so.

I suspected that a trip to the local computer superstore might yield a product, but in this day and age that step shouldn't be necessary. I surfed over to Egghead.com, searched for encryption, and after wading through several pages of network hardware, cables, and other strange results, I found McAfee PGP.

I downloaded the $15 package, which promised to perform tasks the freeware wouldn't, such as encrypting my hard disk and securely removing traces of old deleted files. The package also suits my usage profile, which I believe fits the commercial definition and therefore falls beyond the terms of the freeware license. Note that Network Associates offers the same package, via site or seat licenses, to corporate users bundled with support for specific amounts of time.

eMail

Before installing the PGP package, I upgraded my Eudora email package to the latest revision, 4.3.1. I then installed PGP, and reopened Eudora to find a few new icons on the Eudora message menu and main toolbars. The program placed only the PGP key management and decryption icons on the main toolbar, but you can manually add others. You can also engage the capabilities of the PGP package from an icon on the Windows task bar.

I planned to start the evaluation by sending a self-decrypting message to my son's email account, which wasn't enhanced with PGP software. Supposedly, you encrypt the message and assign a passphrase that the recipient can use to decrypt the message. This is obviously far weaker encryption than the public/private keys offer, but I think it might just be sufficient for the needs of many people.

The manual instructs you to create the message normally, click on the encrypt and/or sign (authentication) icon(s) on the message toolbar, then click send. Before the send occurs, the PGP plugin should either ask you for the recipient's public key or ask you whether you want to use self-decrypting mode (which it inexplicably labels "conventional encryption"). To use the latter, you are prompted to provide a passphrase, and, if you've chosen to digitally sign the message, the passphrase you've associated with your private key.

Simple enough, yet, when I tried it, Eudora refused to send the message. After several attempts, I moved to my son's machine to try a different tack. I downloaded the freeware version of PGP and installed it on top of Eudora 4.1. After doing so I was able to send an encrypted message to my machine and successfully decrypt it using the passphrase.

I then went through the process of emailing the public keys between the machines. After doing so, I could send encrypted messages from my son's PC to my own, but efforts to send an encrypted message the other way resulted in Eudora acting as if the send command never came. The send command would spur the request for a public key choice and digital-signature passphrase, but no sending ever commenced.

Frustrated, I went to both the PGP Inc and Eudora support sites. Not being a corporate customer and lacking a password, I couldn't access the PGP support site. I was again directed to the McAfee site, which has no PGP support info other than an email address—not even a FAQ or a list of common problems. Eudora's site isn't much better, although it does list common problems.

But the Eudora site did point me toward an independent Internet mail group focused on Eudora for Windows. There, I learned that my problems weren't unique. Contributors claimed that since Eudora 4 shipped, it's been plagued by incompatibilities with the PGP plugin. I have no way of judging the claims, but the participants in the group seem convinced that it's a Eudora problem. Over the years, however, I've found Eudora to be better than average in terms of quality and support. The incompatibility is even harder to grasp given that prior to version 4, Eudora included PGP on its installation CD.

eHelp

Anyway, the mail group provided me with a solution—simply avoid using the icons that PGP places on the Eudora toolbars. It seems the buttons work inconsistently, depending on which revision of Eudora you have installed. Once I began to use the PGP icons in the Windows task bar, I had no further problems. In fact, you can launch the PGP icon into a floating toolbar that offers buttons for encrypt, sign, encrypt and sign, and decrypt. Strangely, the decrypt button on the main Eudora toolbar functioned correctly in every case.

With PGP working on two machines, I experimented with several scenarios involving transmission of public keys.

You can send a public key in unprotected email, but nothing guarantees that it arrives unaltered. So I successfully sent a public key in a self-decrypting email. Anyone can do this and verbally provide the passphrase via phone or some other old-fashioned transmission medium. In fact, I sent my public key both as encrypted text and a second time stored within an encrypted Word file.

Using the text file to add the key to a key ring is extraordinarily simple. Once you decrypt the file, you simply highlight the key, which appears like several paragraphs of random typing (Figure 1). You then copy and paste the key into the PGP key window, which asks you if you want to import a new public key. The PGP key window also allows you to manually import and export keys to or from files.

In Eudora, incoming email attachments get stored in an "attachment" directory. When you receive an encrypted email, it always shows up as a file attachment. When you decrypt the email, the text portion of the message appears in the email window immediately. If the message also had an encrypted file attached to it, the decrypted file shows up in the attachment directory alongside other files that have arrived unencrypted.

When I sent the public key in a Word file, I had to take several steps to add it to the PGP key ring. For some reason, I couldn't paste the key directly from Word into the PGP key window. The key program claimed it was an invalid key. But once I saved the Word document as a text file, I was able to import the text file as a new key.

If you choose to simply sign and authenticate a message rather than encrypting it, you get the before and after decryption results shown in Figure 2 and Figure 3. The privacy proponents you run into in Internet newsgroups and mailing lists tend to use an authenticated signature on each posting and on every email they send.

So just how will we manage key distribution going forward? I suspect that I will have a relatively small universe of secured correspondents to which I can send my key in self-decrypting format. But Network Associates, among others, is trying to enable the long envisioned day of public-key repositories that anyone can access to find anyone else's public key. The PGP program encourages you to register your key. In fact, you can even get a standard CA, called X.509, for your PGP public key. Many S/MIME proponents claim incorrectly that the X.509 ANSI standard CA is a unique S/MIME feature.

You can also turn to companies that are making a business out of verifying public keys. For example, VeriSign will validate your key and provide a signed CA that you can send to your contacts. The service costs $15/year for individuals, and you can try it free for 60 days. The company's real focus, however, is serving the corporate world with CAs and other so-called trust services.

Several other Web-based email security sites have emerged. These typically give you access to a secure network. See www.zixmail.com and www.1on1mail.com for examples. If you want to try S/MIME, you can download a non-commercial freeware version at www.worldtalk.com/Products/SMIME%20Everywhere/sme.shtm, along with technical information that's heavily biased toward the advantages of S/MIME.

Going forward, the use of encryption and authentication will get easier. Just as vendors such as Qualcomm have over the years integrated into their email packages the ability to read formats like MIME automatically, so will they integrate support for the OpenPGP and S/MIME formats. Perhaps the industry will even develop automatic retrieval schemes for public keys. Now, if only they could do the same for our car keys.