E-mail Encryption

E-mail Encryption: A Security Necessity

Secure Email

E-mail is an indispensable mode of communication that helped popularize the Internet in the 1990s. That’s when e-mail grew from the corporate and institutional sectors to evolve into the electronic medium that it is today, spanning personal and business users.

While email encryption has always been a good idea, laws such as HIPAA, HITECH, Sarbanes Oxley and a host of state regulations has moved email encryption from the fringe activity into a standard business practice.

See Also: HIPAA compliance in e-email encryption.

As email usage exploded, legitimate concerns have arisen over the privacy of email communications. To relate an email to Postal Service terms, it is similar to a postcard; the message contents may be accessible to others.

While in transit, e-mail messages are sent through one or more mail transfer agent servers until it reaches the destination e-mail server. Someone with access to this server can easily intercept and read the e-mail message. In addition, e-mail messages that travel through these mail transfer agent (mta) servers are very likely stored and backed up even after delivery to the recipient, and even if the recipient and the sender have deleted their copies of the message. This stored copy of the e-mail may be subject to snooping in the future, and persist indefinitely.

Free email encryption service advertisement. Lockbin.com

Additionally, the internet makes it easy to “spoof” the sender field of an email message, allowing nefarious individuals to misrepresent their identities. This has led to a phenomenon known as “phishing” and other forms of attacks over e-mail, underscoring the importance of the recipient being able to reasonably authenticate the sender's identity.

Businesses that utilize e-mail as a means of communication with customers, partners and employees now must comply with governmental regulations governing the privacy of customer, partner, and employee information. This means that in many instances, e-mail messages must be protected by some level of security.

E-mail encryption helps to address the above issues.

Cryptographic techniques for e-mail encryption

Two basic forms of cryptographic systems are utilized for e-mail encryption: symmetric and asymmetric. Both systems are standards and are used in several kinds of software applications.

Symmetric Cryptography

Symmetric Key Cryptography

In Symmetric systems, both recipient and sender share a common key or password that is used to decrypt and encrypt the message. Symmetric key has some advantages over asymmetric, including ease of usability, speed, management, and cost. Symmetric systems are often found in e-mail encryption software because of these benefits. Symmetric systems often implement key strengths of Data Encryption Standard (DES), Advanced Encryption Standard (AES) and Triple DES.

Today, symmetric key strengths of 256-bit and 128-bit are in common use. Use of a cipher less than 128-bits is not recommended.

Asymmetric Key Cryptography

In 1976, Whitfield Diffie and Martin Hellman developed asymmetric cryptography, which uses two keys: one public, the other private. The public key can be shared with everyone and is used to encrypt the message. The private or secret key should be known only to the recipient and will be used to decrypt the message.

Only the private key can decrypt a message that has been encrypted with the public key. Both the public and private keys are both required to enable the encryption and decryption the message. This is important because it provides an advantage in authentication over symmetric keys. However, as a trade off, it requires a robust public key infrastructure (PKI) in order to provide the public to anyone who may require it at any given time. This means that there is a need for an independent Certificate Authority (CA) for the global registry and management of the keys. These authorities have serious security requirements themselves.

E-mail encryption design approaches

In designing e-mail encryption systems, two competing philosophies has arisen. The Client-Based Method suggests that the sender of the email should be responsible for e- encryption. The Gateway-based Method suggests that the organization is responsible for e-mail security, and encryption should be performed on a server operating on the corporate network.

Gateway-based Email Cryptography

With this approach, the organization determines the e-mail encryption policies based on the security and regulatory compliance needs of the company and its industry. A product, typically referred to as a Gateway, operates on the corporate network in the e-mail flow and applies or enforces these policies. The Gateway might be a software application or an appliance.

A command exists in most current email servers to encrypt the traffic between them. STARTTLS aka RFC 2487, is a part of the Internet Message Access Protocol. Used in “Opportunistic encryption” mode, the sending server asks if the receiving server can use TLS. If so the rest of the exchange is conducted securely over TLS. Though this does not provide message level encryption, it does protect the email during its journey between servers.

Client-based

The Client-based approach applies encryption to email at the sender’s desktop. This gives individual users control over what and when to encrypt. This does, however, put a heavy responsibility on corporate users since each sender now must understand and interpret regulations and policies, which often leads to an inconsistent implementation of email encryption.

The Client-based approach requires that a piece of software be installed on the sender’s machine. This software may be in the form of a plug-in, like Encryptomatic’s MessageLock, that works with popular e-mail clients such as Microsoft Outlook.. When a user wishes to encrypt an e-mail, he then has the option of applying the encryption using this client application. Depending on the product, the recipient of the encrypted e-mail message may need special software to open the encrypted e-mail. MessageLock, for example, requires that a use have a zip utility that incorporates AES encryption, while other client applications may require the installation of a special single-use reader. Desktop clients are typically used in smaller organizations where a gateway solution is not viable, or as a supplement to gateway solutions when the organization has smaller clients who cannot practically implement a PKI solution. Sometimes client solutions are used for select teams of users, such as executives.

Methods of Message Retrieval

Another question for e-mail encryption is how the recipient receives the encrypted e-mail – is it delivered in their e-mail inbox, or they are referred to an online “mail Box” in where they can retrieve the encrypted message. In the “in box” delivery model, the encrypted e-mail is delivered the user’s email inbox, where they can open the encrypted message after providing the appropriate password or credentials. In the “mail Box” model, the user receives an e-mail with a hyperlink to the encrypted message. The user then follows the hyperlink to arrive at a website where they submit their credentials and are then able to view the decrypted message.

Standard approaches to e-mail encryption

The need for e-mail encryption has lead to a variety of solutions – some from standards bodies, and some from the marketplace.

S/MIME

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption signing e-mail. S/MIME was developed by RSA Data Security, Inc. S/MIME provides the cryptographic security services for authentication, message integrity, and non-repudiation by combining a digital signature with encryption. Before S/MIME can be used in an application, the user must obtain and successfully install a unique key/certificate from a Certificate Authority (CA) or from a public CA. Encryption requires storing the destination party's certificate, a process that is typically automated when receiving a message from the party with a valid signing certificate attached.

While it is technically possible to send a message encrypted (using the destination party certificate) without having one's own certificate to digitally sign, practically the S/MIME clients will make you install your own certificate before they allow encrypting to others.

A typical personal certificate verifies the owner's identity only in terms of binding them to an e-mail address. It does not verify the person's name or business. The latter, if needed (e.g. for signing contracts), can be obtained (usually at a cost) through CA's that offer further verification (digital notary) services or managed PKI service.

PGP and OpenPGP

Pretty Good Privacy (PGP) is a standard that delivers cryptographic privacy authentication. The first version of PGP, by designer and developer Phil Zimmermann, was released as an open standard. Zimmermann and others have developed subsequent versions. Eventually, the PGP secure e-mail offering was adopted as an Internet standards-track specification known as OpenPGP. OpenPGP is now an open standard with PGP. PGP and OpenPGP require a client or plug-in. PGP uses both public-key cryptography and symmetric key cryptography.

PostX Registered Envelope Encryption and Security

The PostX Registered Envelope is a secure delivery model for PostX Envelope. The Registered Envelope uses online authentication for decryption key retrieval to provide secure auditable message delivery. The Registered Envelope delivers both the encrypted payload and necessary decryption code via an e-mail attachment to the recipient.

The E-mail payload is encrypted with a unique (per message) secure random session key. The session key is stored in the PostX KeyServer (and is not sent with the message itself). Encryption algorithms supported are AES (in CBC mode with ISO-10126 padding) and ARC4. The Registered Envelope model requires online authentication and online key retrieval. Both authentication and key retrieval are conducted over SSL (HTTPS). PostX also supports both SAML and Liberty Alliance standards for recipient authentication.  A problem with this system is that email attachments sometimes do not arrive with the email, being stripped by firewalls based on security policies at individual organizations.

Identity-Based Encryption

In the 1980’s, identity based encryption (IBE) methods were developed for e-mail by RSA and others to communicate securely in ad hoc environments. In this model, the e-mail address of the recipient is used to perform the e-mail encryption. In order to provide the strength of a password or authentication, identity-based encryption requires client software. Voltage Security [2] has developed an asymmetric IBE model where the sender can encrypt the e-mail message with the recipient’s e-mail address and the recipient contacts the Key Server. The key server authenticates the recipient and returns a private key, which can then be used to decrypt the message.

Pull solution

In the late 1990’s, PKI and S/MIME failed to deliver on the promise of e-mail encryption for ad hoc needs. Out of this failure, the secure messaging solution for adhoc situations that evolved was to “pull” the recipient into a secure message inbox. In this inbox, the recipient can perform all of the e-mail functions in a branded environment. This model solved the send to anyone problem, but increased the costs of the solution during its lifecycle.

In order to maintain the system, the enterprise basically becomes an ISP because it must manage the database, and related systems, to keep the inbox alive and auditable for users. As a result of the costs and the organizations desire to proactively reach out to their users, most organizations are selecting push solutions. A subsequent vulnerability of this system is phishing, where an attacker tries to lure the recipient to a dummy website.

To learn about the email encryption solutions offered by Encryptomatic LLC, visit our solution overview page.
Lockbin free email encryption service also offers an Outlook add-in. Learn more about Lockbin.

NEXT: HIPAA compliance in e-email encryption.

Thanks to Wikipedia for contributions to this article.