When people think of the Internet they normally refer to the Web, but studies suggest that the percentage of people using e-mail is much larger than the ones surfing the web.

E-mail is infiltrating all parts of our society, replacing paper office memos, helping colleagues keep in touch, and letting people share their thoughts and emotions around the globe. As more and more people are relying on e-mail as a means of communication, more e-mail content is requiring privacy. There always have been propriety ways to encrypt and secure electronic communication, but until recently there has been no standard solution that can work with a variety of e-mail clients. The S/MIME (Secure Multipurpose Internet Mail Extension) in one program that aims to answer these queries.

Why vulnerable?

S/MIME is not Internet specific standards, but it is most useful for Internet e-mail. On a private network, the sender connects directly to the sever. On the Internet, message bounces from place to place until they reach their destination. This means there are many more opportunities to temper with an Internet e-mail message.

Not all Internet communications has this characteristic. When you browse the Web, you directly connect to each server you visit. Because of this, Web communication can be made secure by securing the channel, the connection between your computer and the server. But Internet e-mail can pass through several severs before reaching its destination; so securing the channel is impossible. Instead, the message itself must be secured.

There are three types of e-mail security violations, snooping, tampering and forgery. Encryption techniques are used to protect against all these. Snooping means reading your private e-mail without authorization. Traditional single-key encryption can't stop snoopers. In single key encryption the same key is used both to encrypt the message and to decrypt it. This is unworkable for e-mail communication, because there is no safe way to transmit the key. It's unsafe to send the key unencrypted, and it's inconvenient to deliver keys manually to e-mail recipients who might be halfway around the world. One way to transmit a key safely is to use a technique called dual-key or asymmetric encryption, which has separate keys for encryption and decrypting. People's public keys are used to encrypt the message send to them, and they use their private keys to decrypt these messages. The two keys are mathematically related, but the private key cannot be derived from the public key, so the public key can be freely distributed. The private key need never leave the owner's computer. To send an encrypted message, you obtain the recipient's public key and encrypt the message using this key. Since decryption requires the associated private key, only the recipient will be able to read the message.

S/MIME protects against tampering, the second type of security violation, with a technique similar to a checksum. A harsh algorithm condenses the message contents into a unique digest, and then the digest is encrypted and sent along with the message. The recipient's S/MIME program decrypts the message and does its own computation of the digest. If the two match, then the message has arrived intact. If they don't, someone has tempered with the message and the S/MIME program will alert the recipient of this.

Signing and Trust

S/MIME protects against the third type of security violation, forgery. By signing or encrypting with a private key. A single public key is called a certificate and is sent along with the message. The simplest example of this is a self-signed certificate, a public signed by its associated private key. If the recipient can successfully decrypt the certificate with the sender's public key that confirms that the sender's private key was used to create the certificate.

But anyone can create a key pair, so this doesn't prove much. If this is the first time you have received a message from a certain person, then the public key is not your database and you can't verify it. So how do you know that the e-mail address isn't spoofed and the person really is who he or she claims to be?

A more secure type of certificate is one signed by a third party. But anyone can sign a public key, so simply having a certificate signed by a third party isn't proof of identity unless the signer is known and trusted. To this end, there are companies that set themselves up as certificate authorities, verifying the identity of the person holding the public key before signing it.

Even this isn't a perfect solution, however, lets say I work for a small company called XYZ. It has an internal e-mail system and acts as a certificate authority for its employees. But when I send you e-mail, how do you know that XYZ can be trusted to verify my identity, and how do you know that it really is XYZ that signed my public key if you don't have XYZ's public key in your database?

S/MIME addresses this problem by means of a trust hierarchy, also called a chain of trust. To reassure you, I also included XYZ's certificate, the public key of XYZ signed by yet another certificate authority. If the second signer is a service that you know and that you trust, then you can accept my certificate as valid. If the highest level of the chain of trust is known and trusted, then the certificate can be trusted.

The most prominent certificate authority today is VeriSign. A VeriSign public key is readily available and is preloaded into most S/MIME programs, so its easy to verify a VeriSign signature. It offers two classes of individual certificate. The class 1 certificate verifies only the applicant's e-mail address. Class 2 certificate cost more and verifies the applicants mailing address as well as the e-mail address. You must enter private information to enable VeriSign to verify your identity, so the information must be transmitted over s secure connection. It cannot be sent through unsecured e-mail.

Portability

When using S/MIME, you need a means of securely transporting your private key between different computers or e-mail programs. Otherwise, the key pair that you use at work won't be usable on your notebook or home computer, and encrypted e-mail that you pick up from another machine will be unreadable. Also, if you change e-mail programs, you will have to get a new key pair and make sure everyone sending you e-mail uses it unless you have a way to export your private key from the old program and import the key into the new one.

The solution to this problem will eventually be Microsoft's PFX standard, which the company submitted as PKCS#12, or the 12th standard in the PKCS (Public Key Cryptography Standards) suite. So far only two vendors, Microsoft and Netscape have implemented PFX for importing and exporting private key.

Design consideration

The S/MIME specification is limited to consideration such as which hash algorithm to use and which symmetric cipher must be supported. It does not address design considerations. Because such issues are not spelled out, products can conform with the S/MIME specification but not meet the security goals of S/MIME.

For example, for the chain of trust method to work, as S/MIME program must have some sort of certificate management system that can set the trust level for certification and certificate authorities. If a certificate is compromised, you must have a way to mark it as not trusted. If a certificate authority is compromised, the certificate management system must be able to cascade the not trusted status down to all certificates signed by the authority. Thus a certificate management system is crucial for implementing S/MIME's chain of trust features, but not all S/MIME products have one.

Another important design consideration is the ability to associate multiple certificates with an e-mail address. Its common for people using S/MIME today to have multiple certificates. For example, a consultant may have a separate certificate for each company she works for. Not every S/MIME program offers the basic capability. Netscape Messenger allows only one certificate per person. It is also common to have multiple aliases for the same e-mail address, for example, scender@ud.com and scender@mail.ud.com. S/MIME programs, including Messenger and Outlook Express, accept only the e-mail address in the certificate as valid. You can explicitly accept a certificate that's invalid because of a name mismatch, but you can't encrypt a reply to the message unless you edit the address to match the certificate. The authors of the S/MIME specification are working on a solution that will allow multiple e-mail addresses to be associated with a certificate.

Interoperability

As mentioned earlier, S/MIME uses a hybrid approach for message encryption. The message is encrypted with a symmetric cipher, and then the symmetric key is encrypted with an asymmetric cipher for secure transmission. The strength of any encryption method is determined by the length of the key, the longer the key, the stronger the encryption.

The S/MIME specification mandates that all vendors must support at least one common symmetric encryption method. In version1 of the S/MIME specifications, this method was the RC2 algorithm with a 40-bit key. In Version 2 of the S/MIME specification, finalized later, the common encryption to Triple Des, an algorithm that uses a 178-bit key.

Vendors are free to use encryption even stronger then Triple DES if they want, and this creates a challenge for S/MIME products: how to know what type of encryption to use with a given recipient. A fairly recent addition to the S/MIME specification, called authenticated attributes, provides a way to exchange this information automatically. Only the Microsoft and Netscape products implement this method.

All S/MIME products available today support RC2-40 encryption, but not all products default to RC2-40. So even if all the products perfectly implemented every encryption algorithm, confusion over which algorithm to use could itself cause interoperability problems. Infect, not all S/MIME programs implement every encryption algorithm perfectly.

The spinning wheel

With its strong vendor backing, S/MIME will eventually deliver on its promise of broad scale e-mail security. But the specification itself is still very much in flux, and that creates interoperability problems. Also, vendors are still learning what features are necessary in a good S/MIME product. Many of the S/MIME products available today lack crucial features or suffer from design flaws. Once the S/MIME specification is finalized and the system is better understood, the market should start to see easy-to-use products that interoperate flawlessly.