Digital Signatures Are Key to E-Mail Security

Building the Infrastructure

Most organizations use a PKI (public key infrastructure) for their digital signatures and the certificates that embody the signatures. A PKI implementation includes:

Not surprisingly, the need to put all these complex pieces in place can make you think twice about implementing a digital signature system for e-mail. But the pain is usually worth the payoff.

Public and Private Keys

Digitally signed e-mail starts with a couple of keys that work together to encrypt the certificate or statement of the sender's identity and then decrypt that certificate on the receiving end. For security's sake, they can't be the same key, so you use public and private keys.The idea behind the private/public key pair is that only one entity or user can sign a message to encrypt the certificate and virtually anyone can read the message by decrypting the certificate. Digital signatures use an asymmetrical encryption algorithm, where the private key encrypts the message and the public key decrypts it.

In reality, users have no idea what their private keys are--and they don't need to know. Their messaging application accesses the key automatically, without their intervention. When a recipient gets a message with a certificate, his or her application goes to the certificate authority to get a public key. The certificate is decrypted by the e-mail client, the sender's identity is established, and the message is then delivered.

It's the CA's responsibility to manage the public keys, and it's your responsibility to manage the certificates themselves (the private keys). Some certificates are assured only by the sender--so-called "self-signed certificates"--but they don't offer the same level of identity assurance as certificates backed by a real CA. Managing certificates can mean a significant investment in physical infrastructure and time to develop the policies and procedures for safe deployment and storage. But you must keep your digital certificates truly secure--a compromised certificate store is akin a lost wallet, with your driver's license, credit cards and Social Security card.

You also must keep the certificate database safe from disaster, since losing the ability to confirm identities can impair your ability to conduct business electronically. If your organization doesn't have a solid disaster-recovery plan, deploying a digital signature scheme for e-mail can help spur such a plan.

Your may need to purchase additional devices to ensure the certificate database is constantly available and consistently backed up to an off-site location. And you must also buy certificate management as well. You can minimize cash outlay if the appropriate hardware is in place and the software is part of the network operating environment. Even so, you'll still incur implementation costs. But the offsetting ROI is the secured transactions and assured identity for your users when they communicate with customers, suppliers and partners. Many vendors offer products to manage certificates and signatures: Entrust, Tumbleweed and VeriSign, for example, sell products designed for e-mail certificate deployment; Authentica, PGP, PostX, Proofpoint and Sigaba offer secure mail software.

To encrypt a certificate or sign an e-mail message, an algorithm must hash the certificate--that is, it assigns a numerical value to the certificate's contents. For speed and security, a message's certificate may be based on the hash result rather than the message itself, because there's a smaller amount of data handled in the signing process (see "Creating a Digital Signature").

SHA (Secure Hash Algorithm), the most common hashing algorithm, creates a number that is 160 bits long. While it's easy to create the hash value from the contents (and re-create the value to check against the original, ensuring the contents of the e-mail message hasn't changed), it's impossible to re-create the original contents from the hash value. A valid hash can be derived solely from the e-mail message's digest, so a service provider can create the hash value without ever taking possession of an e-mail's contents.

Most certificate authorities and certificate systems use the SHA-1 hash algorithm. But researchers recently found a vulnerability in SHA-1: It's possible for an attacker to produce a "collision," where two input streams generate the same hash result in dramatically less computational time than the algorithm analysis had predicted.So far, there have been no reports of attacks based on this vulnerability. But many security experts recommend using another hash function to ensure security for signed messages and certificates. PKI and messaging vendors have begun to consider other algorithms, and any variant of the SHA-2 algorithm (SHA-256, SHA-384, SHA-512) is considered more resistant to attack than the 160-bit SHA-1.

Standard Identity

The security of the certificate process is crucial to trusting your digital signatures. Third-party certificate authorities such as VeriSign verify the identity of the organizations or individuals purchasing certificates and then use PKI for storing and managing the certificates they issue.

Meanwhile, there are a handful of standards for e-mail digital signatures. Secure/MIME is the most commonly deployed standard for adding certificates to e-mail. S/MIME comes with Microsoft e-mail clients and must be implemented if you put Outlook Web Mail in the field. It also comes with Mozilla, Lotus Notes and most other e-mail clients with any significant market presence.

The certificates themselves are defined in various IETF X.509 working group documents. RFC 2459, for example, defines the basic certificate structure. There isn't yet a standard for certificates, allowing wiggle room for how vendors implement X.509 in their products. Interoperability should improve as the IETF moves closer to approval of its certificate specification as a standard.Your digital-signature project will likely be a workstation-based system, where you assign certificates to individual users or groups within your organization and give client-side software instructions to use the certificates in sending messages. How you manage certificate distribution and the integration of certificate management into your network authentication and directory infrastructures will vary according to your individual network management architecture and system.

If your network-identity directory is based on a single vendor with integrated identity-management features--such as Microsoft, Novell or Sun--you may want to explore the certificate-management capabilities of your primary vendor to ease the rollout. If you have a more heterogeneous network or need specific features not found in the basic network infrastructure, many third-party identity-management packages are available.

Meanwhile, you can use certificates in situations that require user verification--application macros, Web-based applications and intranet security, for example. And you can use the same cert across multiple apps, too.

The Sign of Authority

Working with a CA and managing certificates is the first step in the process of digitally signing e-mail. Whether you're requesting the certificate as an individual or an organization, you must provide proof to the certificate authority that you are who you say you are. The process may vary from CA to CA.If you're a large organization, decide up front whether you want to sign e-mail from the organization itself, a department, a group or individuals within the organization. That will determine the number of certificates and certificate-management requirements and costs.

Certificate management is essential because the scale of the database and reach of the policies required will vary, depending on whether you're deploying dozens or thousands of certificates. Getting certificates from a commercial CA can be expensive, since each certificate must be purchased separately and renewed regularly.

If you'll have thousands of certificates, consider becoming a certificate sub-authority, where you work with a CA to provide your own certificates to certain groups or individuals. Although you won't have to pay for each certificate individually, your organization will still bear the overhead costs of administering and storing both its private keys and the public keys for the certificates it issues.

These costs will vary by organization. But if you're a large enterprise, the scales can easily tip toward being a sub-authority, especially if you want to expand your digital certificates to applications other than e-mail.

Curtis Franklin Jr. is a senior technology editor for Network Computing. He has been writing about the computer and network industries since 1985. Write to him at [email protected]. 0