In a recent post I posted some questions about IBE or Identity Based Encryption for email which some vendors are selling at the moment and suggesting that now their email is encrypted and secure from end to end. On Network Solutions web site they even talk about sending credit cards in email not being secure, thereby implying with IBE that would be secure.
I recently asked Voltage Security about their IBE product to explain some of the problems they would have to overcome to create the encrypted email solution they propose on their web site. Most of their answers sound pretty good, except I still have questions about #5 noted below.
They also sent me a sample message so I could see how their product works. I received a secure message with a graphic button that was blocked by our mail scanning/security products and an attached html file. When I click the button to retrieve the message I have to create a user name and password to read the message and get the private key to read the message. I can see this working for internal organizations but when sending information to potential customers - I can imagine some of them not understanding what this is or being apprehensive about filling something like this out or clicking on an html attachment from a vendor they never heard of or have not worked with before - at least until and unless people get used to this concept. This may be a good solution for internal organizations however, if you trust the vendor of this technology of course and have had your own technical gurus look into the actual details. I am not an encryption expert. I am only looking at the process of getting the mail encrypted from A to B. I cannot say whether the encryption is not decryptable by the company selling it to you, for instance. But here's the scoop on the process:
Once the recipient of an IBE email receives a key they no longer have to get the key for future messages. What happens if they use a different computer?
When a person moves to a different machine, the key is then fetched again from the key server for future and past messages. There is no limit on how many keys one user can fetch as long as they properly authenticate each and every time.
What happens if they log on to web mail on a public computer in an Internet cafe? Is their private key downloaded there for future users of that machine to potentially exploit?
In a public web mail instance, they would be using ZDM, that only caches a stateless cookie that can be set to expire to meet your internal security policies. Also, once an end-user “logs out”, the session cookie is terminated, mitigating any security threat by reading secure email on a public machine. By default, there is a configurable 1 hour session timeout in case the user forgets to logout. Our ZDM cookie security has been fully vetted/tested and is currently in use by several large banks, health organizations and retail companies.
What if someone can steal the private key from the recipient’s machine - since authentication only happens on the first email they could basically read any email after that point if they have the key?
One key is only good for less than 1 week. They would only be able to read secure messages for that one user that fall within that one week session (it’ll most likely be less than half a week). We can utilize any authentication method – email answerback, or one email to prove who you are, is a highly usable, widely used industry standard (see Amazon, Yahoo, Microsoft, banks, etc) but not the most robust authentication standard. We support two-factor authentication, Windows Domain authentication, and different groups of users can be forced to authenticate by different means. The encryption method is tied down to one authentication method, giving you the flexibility to meet your security needs for secure communications.
How does IBE work with email addresses and accounts sending mail from a web server to another address, such as an order receipt?
If you are talking about automated emails, the messages must simply flow through our Voltage SecureMail Gateway, and it will encrypt using the designated recipients individual email address. Nothing special has to happen to encrypt this type of mail flow.
IBE encrypts mail from me to the person I am sending the mail to – what happens when they reply? Is that message sent unencrypted back to me? So if I have my mail encrypted so support people at my mail provider cannot read my outgoing mail, then the customer replies back to me – and my mail is unencrypted coming back from them – so it doesn’t really help? Or…is the mail back encrypted as well even if that person isn’t using IBE?
If they reply to a secure message using our integrated desktop client or ZDM, then you can force the reply or forwarded message to be secure (called “Secure Conversation”). If they don’t ever decrypt the message and simply reply to you, then your message is sent back still in its encrypted form.
My follow up questions to the answer above:
If they do decrypt the message and reply – then is it sent back unencrypted if they are not using IBE themselves or one of your products?
Scenario:
A person comes to our web site and requests product info. We send a secure encrypted message. They are not using any of your products or IBE. They open and read the mail, hit reply and send us back a question. They have outlook or their webmail system set to include the original message in the reply.
Is all our initial information now unencrypted in his reply as it travels back to us? Or once they go through the steps to decrypt the mail are they now using ZDM?
Also what if that ZDM cookie expires? Then when they reply to the message is it sent back unencrypted? Or do they have to log back in each time they read the message to get the cookie?