I have had so many people in various businesses tell me that they do not need email encryption. That Email hacking is not a serious or meaningful threat.

For their sake and their correspondents’ sake, I hope that they are right but perhaps, just perhaps, they are wrong as my experience shows below.

A couple of months back I opened a trading account at a brokerage firm that has been on Barron’s top ten firms for a long time. I liked their service and their trading platform and went ahead with the application. During the application process, lo and behold their customer service representative sent me an email with pages from my filled out application that contained all my sensitive information including my Social Security Number! Now, imagine that email sitting on many email gateways en route and repeat after me with appropriate sarcasm, “No one needs email encryption”.

Yesterday (the event which prompted me to write this) I received an email from the mortgage company doing my refinance that contained my full credit card number. And they were merely forwarding the email that they received from Equifax (the credit score company). So Equifax originated an email with my name and full credit card number and sent it out by plain old email without protecting it! One would think that Equifax of all the companies in the world would understand the need to protect sensitive information. One would be wrong because Equifax thinks, “No one needs email encryption”.

Moral of the story: Either diligently avoid sending private sensitive information by email or protect it with encryption. Doing neither is just being negligent.

Tags: Encryption | email encryption | privacy-protected email | Secure email

Hits: 30 | Read more...

There are many email encryption products on the market with a variety of approaches to solving the problem. The problem of course is that of providing strong security guarantee while making it easy to use. This blog will briefly describe the types of products in the market with more details about differences between different TrustTone product offerings.

Email Encryption Desktop Clients

Client products perform email encryption at the originating user's desktop. Typically this is accomplished through a plug-in module that enhances the email application with encryption features. This approach generally limits the type of email applications supported by the product since the vendor has to make a marketing decision about how many email application plug-ins should be provided. Microsoft Outlook is by far the most universally (and generally the only one) supported by this approach. Even among the desktop products, technical approaches vary.

Password based

Some desktop client products use shared password approach. Sender and recipients must have a common secret password that can be used to encrypt the email message. This approach becomes very difficult to manage as number of users for email encryption grows. To manage passwords for emails between numerous users where each email message may contain more than one recipients is near impossible. This approach works fine for one-to-one or very-few-to-very-few users communicating with email encryption.

PKI based

Public Key Infrastructure (PKI) allows a user to send encrypted email to another user if both users have keys and certificates issued by recognized Certificate Authorities (CA). Most email applications such as MS Outloook, already support sending encrypted email using certificates. The problem is that a user to coordinate acquition and management of keys and certificates for all the users she wants to communicate with is a nightmare, given the case that many of the recipients do not belong to the same organizaition as the sender and do not share the same IT infrastructure.

IBE based

Identity Based Encryption (IBE) allows a sender to send encrypted message just by knowing a unique public identifier for the recipient. Typically email address serve as such a unique public identifier. Identity Based Encryption schemes typically use new cryptos (based on Weil-pair functions, Jacobian functions etc.) to provide this behavior.

With ubiquitous connectivity, it is also possible to create IBE like scheme by creating a transparent key and certificate management layer on top of legacy PKI technology. TrustTone products (both desktop and gateway) take this approach and create what we can Identity Based PKI or IBPKI.

IBE or IBPKI based products provide strong security and ease of use since the key and certificate management is completely hidden from the user and managed transparently by the system.

Email Encryption Gateways

Gateway products perform email encryption at the IT boundary of the organization. End users' emails are routed through the gateway which examines the content of the email message and determines based on policy rules defined by the organization to encrypt the outgoing email message or not. Incoming messages are similarly routed through the gateway which performs decryption of incoming encrypted messages as needed.

Email Encryption Hosted Service

Hosted email encryption service acts as a traditional email hosting service with a twist. The twist is that emails can be encrypted based on some policy rules. This approach works for very small to very large organizations. The disadvantage is that service provider has access to all encrypted emails. In some cases that may not be ok for compliance with regulations.

TrustTone Email Encryption Products

TrustTone currently provides client and gateway products. We will provide hostes service very soon.

The client product works for MS Outlook email application and as mentioned above, it is suitable for an individual user or a small organization (fewer than 10 users).

The gateway product works with all email applications and it is suitable for small, medium and large organizations. It is also the most appropriate solution for meeting compliance for privacy regulations since no private data or keys are passed through any third party infrastructures.

Tags: product selection | Encryption | email encryption

Hits: 418 | Read more...

There have been some articles and even tutorials describing TLS as a simple, interoperable technique for achieving private email communication that is safe from prying eyes of unauthorized users.

The notion is just pure nonsense and lulls non-technical users into a false sense of security. This blog explains how TLS fails to provide adequate protection to emails with sensitive information.

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 (called MTA) specified in the mail account configuration. This hand-off could be and should be done with TLS so that other users in the Sender’s organization cannot snoop the message content. The MTA 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.

Vulnerabilities in TLS for Email Encryption

Vulnerability #1

The route from one email server to another along the way may not be protected with TLS. 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.

Vulnerability #2

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!

Does that imply that TLS is useless?

No. Far from it, TLS is designed for and provides good protection for data sent from point 1 to point 2. But it does not provide protection over multiple hops as generally is the case with email transportation and it does not protect the data once it is at an intermediate server. TLS provides a protected ‘pipe’ through which unprotected email is sent. All the ‘joints’ and ‘pipes’ downstream have complete access to the unprotected data.

To truly protect private emails, one has to encrypt the data itself such that only Sender and Recipient can have access to the unprotected data. Every entity in-between must be unable to remove the protection layer and access the unprotected data.

What is the solution? Is it standard and interoperable?

SMIME is an industry standard for encrypting emails. This standard is recognized by almost all email applications and servers. The devil is in the details. Email encryption requires keys specific to the Sender and Recipient for every Sender and Recipient. And the right keys need to be distributed to the right parties. Vendors (including us) have created systems that do all of these transparently. However, these approaches are not standardized and therefore not interoperable. It is likely that a standard might emerge.

Summary

TLS is not the solution for implementing privacy-protected email. Standards-based email encryption systems are recommended for true privacy and compliance, with a caveat that interoperability between various systems is not quite there yet!

Not perfect, but that's the way to go for protection and compliance.

Tags: TLS | email encryption | privacy-protected email | Secure email

Hits: 738 | Read more...