While researching so called HIPAA compliant email providers, I came across Cisco Registered Envelope Service(CRES), which claims to be HIPAA compliant.

According to this instruction, upon receiving an email (e.g. from the physician) containing an encrypted message as the attachment, all the recipient (e.g. the patient) needs to do to open the message can be summarized as:

1) download the the attachment as an html file.

2) open the html file, click the registration link inside, and the recipient will be taken to cisco's website to register for an account.

3) finish the registration (typical name, password, security QA type of registration)

4) receive a confirmation email and active the account

5) open the html file downloaded in step 1) again, enter account password used in step 3), the message will decrypt itself.

You can read the details in the section Steps to Opening Your First Password-Protected Envelope starting on page 8.

Of course, once this initial handshake is done, subsequent communications can be regarded as secure. But how can this initial handshake provide any security above the security of plain email itself, when an obvious attack is:

a) hijack the email

b) finish the registration process pretending to be the recipient, hijacking the confirmation email

c) open the encrypted message

Well, well, the message is encrypted, so HIPAA compliant. But how is this even close to a secure solution?

Somewhat relevant: spammers might be faking the CRES emails as a new spamming tactic. Obviously, attackers can do the same to hijack the email account.


You have to start somewhere. Yes, it is possible for the initial introductory email to be hijacked, but this is true of many secure messaging systems.

In a perfect world, presumably step 3 would require the user to enter in information that would not be known to an attacker, such as a social security number, medical account number, date of birth, etc. This would be sufficient for confirming the identity during account setup.

That being said, it doesn't appear that Cisco CRES has that option, or if it does, it isn't normally used (I already found 2 banks that use CRES in the same way you described). Thus, I agree with you that if the initial email is intercepted, the security breaks down.

| improve this answer | |
  • 1
    Of course, requiring stuff like SSN, account number could make users more receptive to phishing attacks... – SomeoneSomewhereSupportsMonica Mar 8 '16 at 21:19
  • @SomeoneSomewhere - I definitely agree. That is a great argument for why not to implement additional security confirmations. In practice, successful phishing attacks are much more likely than an email being intercepted. Even more true considering a single initial email must be intercepted... – TTT Mar 8 '16 at 22:14
  • Given that a lot of initial emails are also the final, the value of this security scheme seems highly doubtful. Just consider how often you get emails from your contacts that ask you to "chek ou t dis braking news" followed by a link to an obscure destination. A lot of people's email accounts have already, unknown to their owners, fallen to the dark side. In addition, should the initial email get sent to a wrong recipient, which is not unusual either, the information inside would be considered exposed. – icehenge Mar 9 '16 at 0:01
  • @icehenge - I don't disagree with you, however, most of the time when you receive the type of email you described, it is typically not because the email address has been compromised. If you look closely at the sent from address, usually it is not actually sent from someone you know; they are just spoofing the from address instead, or perhaps even just the person's name. Usually this happens because someone's address book has been compromised, which would not be a threat to receiving an initial secure email. – TTT Mar 9 '16 at 1:58
  • @TTT - Nice to know -- never investigated that before. But still, there are all kinds of ways an email account could be compromised or emails hijacked. That's why sending plain emails containing financial and personal health information is a big no no. Unfortunately, I think we all agree now the problem with CRES is that subsequent emails are secure only if the initial email is secure, and the initial email is only as secure as a plain email. Worse, people who are non-experts are given this false sense of security and belief that they can just send whatever they want with it. – icehenge Mar 10 '16 at 18:03

I'm actually the guy that invented the Cisco Registered Envelope. It was created in a startup called PostX originally. In the beginning we didn't do registration like that we made customer supply passwords for everyone. The problem is how do you do that if you are sending a message to someone outside your org (or someone you've never talked to before), I mean you could call them on the phone and say I'm making your password : xyz. Obviously, asymmetric/certificate based solutions solve that man in the middle problem, however, they have there own host of problems and complexities that they bring to the table. The original PostX product supported S/MIME, PGP, Secure WebMail portal, Envelopes using our SaaS key service, Envelopes using the customers database or LDAP system, Envelopes using a shared secret key that worked offline, and probably a few more embodiments.
Here's what it ended coming down to in the market. All of these different methods have their plusses and minuses. Sure, setting up S/MIME is super secure, but it's also complicated and requires a ton of pre-arrangement. The benefit of the Cisco Registered Envelope, is you could literally send an email to a new recipient and the appliance could detect that a possible HIPAA violation might be happening and automatically encrypt the message with a one time key and go ahead and send the encrypted message to the recipient before they have even registered. You are correct that if someone intercepts that first message, there will be problems, but you already have problems if someone is in your email. Ultimately, most companies realized that other encrypted email solutions were too complicated or required you to store the messages forever on a website, and the prevailing thinking was if it was too hard (like S/MIME) people would just send it in the clear. We basically used to say, there is a line with security on one end and ease of use on the other end and it just depends on where you want to live on that line. The great thing about CRES technology with the HIPAA lexicon, the sender literally has to do nothing to trigger encryption. If the words "reserve room 6 for surgery for Michael Johnson" show up in an email, and the customers has the HIPAA scanner turned on that email will get automatically encrypted. There is one final benefit of this model. With PostX/Cisco acting as the key warehouse, if you get CRES from multiple different companies, multiple senders - you use the same password with all of them because your password is between you and Cisco. A few more benefits : Each message has a unique key - which also allows you to retract a sent email by disabling that key. It also supports an anti-phishing pass-phrase that again is the same regardless what org is sending to you (you pick a phrase or word that shows up on the outside of the envelope, you don't see that phrase don't enter your password). Obviously, as the inventor I am a little biased, we had reasonable success with the product give how little people seem to care about encrypting email, and while it does have it's flaws we found that using something that was virtually painless with a few flaws was better than not using anything at all.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.