Trusttone

Member Area
Email Encryption Tutorial
2009.12.23 13:10:26 Rajesh Kanungo

Need for Email Privacy

Email Privacy is needed by enterprises for one or more of the following reasons:

  1. Regulatory and compliance requirements mandated by the laws of the land.
  2. Prevention of Industrial Espionage.
  3. Financial reasons.
  4. Protection of business communication.

Email is Inherently Non-Private

How Email Works

Email, for practical reasons, has been an open, unencrypted, store-and-forward messaging system. When a user (Sender) sends an email to another user (Recipient) over the Net, the Sender’s email application hands off the message to the email server specified in the mail account configuration. The email server then delivers the message to either the Recipient’s email server or some other email server for subsequent routing to the Recipient. Thus the message may pass through multiple email servers before it is delivered to the Recipient’s email server.

An email server is required to store messages for some time at least to allow for the cases where the next email server or the end user is not available to take delivery of the messages. An email server will make multiple attempts at trying to deliver email to the next email server.

The user’s email software is typically called the Mail User agent (MUA or simply a mailer). Typical mailers are Outlook, Outlook Express, etc.

Security Holes

Most of the email servers that an email traverses are generally not under the control of the sender’s enterprise. All the email will sit for some time on the disks of the email servers. The email can be read at leisure by hackers and the system administrators of the email servers. The email can also be intercepted in transit by packet sniffers placed any where along the route, including at the very enterprise the sender is sending from.

Solution Approaches

TLS for Protecting Emails

Transport Layer Security (TLS) is a protocol used to provide secure (encrypted and authenticated) connections. Some organization use TLS to establish a secure connection email between the email client and the email server or between email servers. TLS can work in two modes:

  1. Server only authentication mode
  2. Server and Client authentication mode.

In the server only authentication mode, the server is required to have an SSL certificate that enables it to authenticate itself to the client. In the case of server and client authentication, both the server and the client have an SSL certificate to enable mutual authentication without the need for passwords.

Operation

Email is sent securely by the mailer to its email server using TLS. Typically, the first email server belongs to the enterprise. The email then gets stored on the email server. Subsequent email servers may receive the email over TLS if they are configured to do so, each email server in turn storing the emails without any protection, until the email is delivered to the recipient’s mail server and then to the recipient's mailer. Connections along the whole route may or may not be over TLS since the sending organizatiion has no enforcement authority over all the mail servers and therefore cannot dictate the use of TLS by all of them.

Deployment

Deployment of TLS for email communication requires managing the following issues:

  1. Acquiring and managing the enterprise email server SSL certificate.
  2. Configuring the enterprise email server to enforce the use TLS for all connections.
  3. Requiring the use of TLS on subsequent hops from the enterprise email server. This is generally not possible if the email servers are not under the control of the enterprise.
  4. Optionally, when TLS client authentication is required, issuing user SSL certificates to each of the users and installing them on each user’s mailer.

Advantages

When TLS is used on the enterprise email server, the sender’s mailer can create a secure connection to it. Email can be scanned for viruses and spyware at the enterprise email server.

Disadvantages

Data in Transit Vulnerability

The route from one email server to another along the way may not be protected with TLS all the way through. There is no way to enforce This will leave the email message and its sensitive content wide open for anyone to see and even save for future use. Anyone with a PC and sufficient knowledge to sniff the network can 'capture' the email message for its worth.

Data at Rest Vulnerability

Let’s suppose for the moment that every route segment along the way is protected with TLS. This still leaves the email message and its sensitive content wide open at the intermediate email servers.

Let's give a 'human face' to this vulnerability. At every intermediate email server, the email message can be read by employees in charge of the server infrastructure or hackers who hacked into the infrastructure. The 'private' email message is no more private than a postcard. never mind that the postcard happens to contain social security numbers and other identity information!

Client Certificate Management Problem

Managing client certificates is a big challenge. Certificates expire, users may forget to install the certificates in the mailer, they may not configure the mailer to use the right settings, etc. System administrators spend enough time handling password issues; handling additional client certificate issues will be an extremely high burden for them.

Password based encryption

Many users have used password to encrypt documents before sending them to recipients. There are a variety of password based encryption tools available. For example, Microsoft Word, Microsoft Excel, PKZip, etc. provide password-based encryption.

Operation

A password is selected. It is either something the sender creates himself or uses a password generator for. The document is encrypted using the password. The document is then emailed to the recipient. The recipient is informed of the password through other channels, for example via telephone, via personal contact, or via another email.

Deployment

Users can use many password based encryption tools to encrypt and decrypt the documents. Nothing special is required except installing the software or using the ones built into the word processing software or other applications.

Advantages

Password based encryption is very easy to understand and use.

Disadvantages

Good passwords have the following characteristics:

  1. It should be extremely hard to guess a password.
  2. Human beings do not generate good passwords.
  3. It is hard to remember good passwords.
  4. Passwords should never be reused.
  5. Passwords should be communicated using a secure channel.

Most people end up reusing easy to remember passwords; a not very secure thing to do. When a user changes the password, the new password needs to be communicated to the recipient. Typically users send the password via email, or a phone call, sometimes leaving it in a voicemail. Sending a second email is as good as giving the secret away. Phone calls are inefficient and require the recipients to be available. Voicemail is fairly insecure. For high value information neither is secure. People will need to write the password down which is a security vulnerability if the password is complex and it is hard to understand the communication.

Not all password-based encryption software is good. There are password crackers available for Microsoft Office products. You need something that is verified by security experts.

Password based encryption prevents email virus and spam scanners to inspect the documents for malware. Most enterprises will have problems letting in or transmitting malware.

Password based encryption also prevents audit logging and tracking of Intellectual Property. The enterprise cannot comply with state and federal regulations regarding transmission of critical information, for example, an early disclosure of sales figures.

PKI based encryption

PKI based encryption is based on proven Public key based strong encryption. The most common for of Public Key Cryptography is RSA. Decryption is done using a separate private key and kept secret by the owner of the public key. The public key itself can be disseminated.

In order to ensure that a public key is associated with a particular user and only that user, an X.509 certificate is created with a digital signature from a known Certificate Authority (CA) like Verisign, GoDaddy, etc. The CA uses manual means (phone calls, signed certificates, etc.) to verify the identity of the user before handing out the certificates.

The entire infrastructure to create public and private keys, generating certificates, verification of certificates, the storage of certificates and private keys, etc. is called PKI.

Operation

The sender first gets the certificate belonging to a recipient and makes sure it is valid. The public key is then extracted from the recipient’s certificate and used to encrypt the email. Since public key encryption and decryption is relatively slow, the email is first encrypted using a secret key an encryption algorithm, for example AES or 3DES. The secret key is then encrypted using the public key of the recipient.

When the encrypted email gets to the recipient, she decrypts the secret key using her private key corresponding to the public key used for encryption. The secret key is then used to decrypt the message.

There is a standard for sending encrypted email, S/MIME, which is understood by most mailers and email servers.

Deployment

In general, the enterprise issues a certificate to a user. The user installs the certificate and the private key. This may be done under the auspices of a proper CA or the enterprise may act as its own CA to save money. The sender of the email requests the recipient(s) to send them their certificates. If the recipients do not have certificates they will need to get them from their own enterprises. Recipients not attached to an enterprise need to get individual certificates.

The sender installs the recipient’s certificate in his mailer and sends the email by selecting that option in the mailer. The recipient’s mailer generally can detect that the messages is in S/MIME format and goes about decrypting it using her private key.

Advantages

PKI based email encryption is proven to be very secure. It is almost impossible for lay humans to break the encryption. Once everything is installed in all the places, encryption and decryption is fairly seamless.

Disadvantages

There are several disadvantages with PKI based email encryption making it hard to deploy in reality with any effectives and adoption.

  1. Assumes everyone has a certificate. This has turned out to be very hard for an enterprise to do.
  2. Assumes everyone knows how to get a certificate. Users are completely unaware of how to run the software to create the correct request, deliver it to the CA, etc.
  3. Assumes users know how to install a certificate. Most users have problems with knowing what to do with the certificates once they get them.
  4. Assumes that users know how to send their certificates to senders who send who want to send them encrypted email.
  5. Assumes that users know how to inspect certificates purportedly sent by others for their authenticity. It is perfectly possible to spoof other people’s certificates using small differences in name or by using an untrusted CA.
  6. It is hard for two enterprises to enable mutual trust and they may not want to. Hence the certificates can be spoofed.
  7. Certificates expire or need to be revoked when employees leave.
  8. Certificate management is a very onerous task.

In general, PKI based email encryption provides security but comes at a very high cost of management and user training. Many times users simply give up because the recipient does not want to get a certificate or finds it to difficult to get one. The sender then finally gives up.

Identity based encryption

Identity Based Encryption (IBE) is an approach to encryption that allows the sender to use the recipient’s email address to generate the public key. There are several encryption algorithms, all proprietary and under patent control. The recipient uses special software and server to create decrypt messages. Most IBE algorithms are considered cryptographically sound currently.

Operation

The sender uses the email address and some seed value it got from an IBE server to encrypt the email. The recipient contacts the IBE server and initializes itself. When it receives the encrypted messages, it is able to compute the private key and decrypt the message. Contact with the IBE server, the seeding, etc. depend on the IBE algorithms used.

Deployment

An enterprise installs an enterprise wide IBE server and a copy of the IBE client software on each of its users. The special software is generally in the form of a plugin for Outlook or other mailer.

Once everything is installed, users in an enterprise can send email to each other.

Advantages

Users can send each other email without worrying about recipient certificates.

Disadvantages

Both sender and recipient must use the same IBE server and must have the same software. This is hard to do between enterprises. The algorithms for encryption and decryption are patent protected and cannot be duplicated without substantial license cost. The software is also not available universally like RSA, AES, 3DES, etc. Unlike IBE, most new smart devices like smart cards, smart phones, secure USB, etc. understand RSA based X.509 certificates, AES, 3DES, etc. There is also just one original vendor of each algorithm and they will not interoperate unlike PKI based solutions.

Identity based encryption over PKI

Identity based encryption over PKI (IB-PKI) approaches the problem of certificate creation and distribution by automating it and hiding the complexity from users allowing users to send email to each other without worrying about acquiring recipient certificates. The users need to know only the email address of the recipient, just like in IBE, to send secure email.

Operation

PKI Benefits without PKI Problems

The goal is to realize the benefits of public key cryptography without the hassles of PKI deployment and also without the limitations of current PKI technology. The encryption technology is in public domain and free and clear of licenses.

Before DHCP (Dynamic Host Configuration Protocol), connecting to Internet was a difficult task that required technology savvy users and administrative effort. With DHCP even a technophobe can surf the Net by just plugging in.

Just as DHCP made Internet connectivity extremely easy, the TrustTone technology –Identifier Based PKI (IB-PKI) makes securing information extremely easy and enables new applications and markets. With IB-PKI, secure encrypted messages and documents, electronic signatures, authorization and access control, and secure business transactions are easily available to anyone on the Net.

Businesses can easily engage in secure electronic communication to other businesses or consumers, at will, without any prior setup. Government agencies can establish secure communication and transactions with various constituencies including but not limited to other agencies, scientists and other users.

The technology is the most useful enhancement to the Public Key Infrastructure and a critical piece of to enable business-to-business, business-to-consumer and consumer-to-consumer, easy, on-demand, secure transactions.

Without such an innovation to provide automatic, on-demand technology for authentication and accompanying large scale, global, security infrastructure of authentication, identity and trust, the growth of information security will be significantly limited.

Deployment

An IB-PKI server is installed which doles out standard X.509 certificates for everyone. Web-based email does not require a plugin. Outlook requires a plugin to insulate the user from all certificate and private key installation and lookup certificates for all recipients without the user being aware of any thing.

Advantages

  1. Users are unaware of any technology.
  2. Certificate installation and lookup is automated.
  3. Administrator does not have to bother with user certificate installation.
  4. Revocation is standards based and is easy for the administrator.
  5. Unlike PKI, IBPKI does not require senders to request certificates of recipients before hand; IBPKI will do the lookup for them in a secure manner and will hide the complexity from the user.
  6. Sending Secure Email at Will: Recipients do not need to request certificates for themselves before email can be sent to them by the sender.
  7. Works across enterprises.
  8. Uses S/MIME standard.
  9. Encryption and decryption uses standard PKI technology including X.509, RSA, AES, and 3DES.

Disadvantages

  1. No standards exist; which makes systems from different vendors un-interoperable
  2. IBPKI, like IBE, encrypts emails using keys associated with the recipient email address. If a sender sends an encrypted email to a wrong recipient by mistake, the recipient will be able to decrypt the message. This problem can be addressed by using rights management technology.

Disclosure: TrustTone Stealth products use IBPKI technology for email encryption.


Tags: email encryption | Encryption

 
2010.07.28 14:49:00

Reply
 
2010.08.03 14:31:12

Reply
 
Reply this post
Name:

E-mail:

  Enter text shown in left: