Cisco Registered Envelope Service (CRES), big security flaw?

Question

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.

Answer 1

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.

Answer 2

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.