No, Gmail is not HIPAA-compliant
Google has made a big deal out of selling Google Apps as a way for health-care providers to securely store patients’ medical records. As of this writing Google will sign Business Associate Agreements for their Google Apps for Business customers — about five dollars per month.
This is great. While I can’t vouch for Google’s security practices firsthand, I assume that they keep their networks pretty well tied down. I’m not sure how appropriate Google Apps are for the purposes of health-care providers, and of course having a web-app provider that can be trusted is just one part of any system of private information storage. Anyone counting on a signed BAA to call themselves compliant is kidding themselves. As put so well at the Tame Your Practice blog, practicioners’ standards and practices have to be compliant — apps themselves are not.
What ought be much clearer is that Google offers no form of secure email for communication between health-care providers and clients, or between anyone and anyone else, for that matter. Even if you pay Google and they sign your BAA, messages sent by Gmail are not encrypted en route between Google’s servers and someone else’s. They try, but they simply don’t control the whole message from end to end. Google Apps may secure your documents in a manner compatible with HIPAA-compliant practices, but Google will not secure your email messages. The only ways to meet the HIPAA requirements would be to get your clients to sign a Consent for Nonsecure Communications waiver or to use a third-party service or software to encrypt your email messages.
The Consent for Nonsecure Communications might cover your posterior legally, but it does NOT protect anyone’s privacy.
The bad news is a good thing
Frankly, it’s good that Gmail is terribly insecure. Gmail is just email. While Google has cooked up their own way of accessing email, they have not replaced or reinvented the global email network. While my hopes that Google+ might someday be something other than another walled garden didn’t pan out, Google has never pretended that they own email. They are competing in a field for which there is global infrastructure and apparently doing a very good job of it.
The bad thing is bigger than Google
So if it is good that one entity hasn’t achieved electronic-message hegemony, that still leaves us with the problem: email is fundamentally insecure. As has been pointed out for decades, it is much like putting all your communications on postcards without envelopes. It doesn’t matter how many armed guards you have carrying that postcard to the mailbox, anyone and everyone can read it while it is en route.1
What’s necessary is to encrypt the message before it gets sent in a way in which it can’t be read by anyone except the designated recipient. The problem with that? It’s slightly inconvenient.
Uh oh
Yeah, that’s right. And there is no way around it. It shouldn’t be surprising, either. If you want to give someone else access to your car, house, mailbox, or storage unit you usually have to give them a funny-shaped piece of metal with unique grooves and ridges that permits the rotation of a mechanism that unlocks whatever it is that you locked up. These items are known colloquially as keys.
To send messages that only the intended recipient can read, you also need keys. Instead of bits of metal, these keys are made of… well, bits. Just like the old-fashioned kind of key, cryptographic keys are funny-looking:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: SKS 1.1.5
Comment: Hostname: pgp.mit.edu
mQINBFGutp8BEADDCBH0pwZS8XLYTWRvOPTJ47nLrwTHF2F2VBJ/PeZGK8EUiCPCzBdlPs8M
C10m1bKRmNewfxlB8D36GSx2RASeFGsWm7BeBIOFqDKxLY78m1x4hvZKldk6qd511Np62mHN
eicdHh0t/oUzieiV3izeBG8PDkSq3PvWmQbYcbCiUOOzo984bKyo4wZnTLMZTgx6179NaSpY
Brm243AArhMTbWmeXTKQwQb+0z9+bup+SEnoWdHsAwOymsP9hWssR9PuPT93StBoZE4xr7/f
That’s not the entire key;2 it actually goes on for quite a ways like that. But you shouldn’t actually ever have to look at it more than once or twice, and maybe not at all.
It gets a little bit more complicated. Explaining the ins and outs of encryption is beyond the scope of this post (and ultimately beyond my ability) but here is the cool part: the key that locks the message is not the one that unlocks it. Thanks to some very clever math developed back in the ’70s, you get to have a «master» key that unlocks all the rooms in your own cryptographic house, and give other people a key they can use for sending you a message, but which they can’t actually open any doors with. The analogy is already stretching thin, but you can think of it as handing out keys to a mail slot in your door; you need the house key to get in to read the letters.
Wait, did you say the ’70s?
Yeah. The common implementation, PGP, was released in 1991 by Phil Zimmermann. But the math he based it on was already decades-old. Don’t worry, so is the math that goes into the construction of airplanes, bridges, and automobiles.
PGP (or GnuPG, or any other implementation of the OpenPGP standard) isn’t the only way to do this kind of encryption, called public-key or asymmetric encryption, or even the only way to do it in email. In fact, this technology is in use almost everywhere on the Internet. It’s in use whenever you see the little green lock in your browser’s URL bar, and it secures the connection between your mail client (if you don’t use web-based email) and your mail server. It’s used in bank transactions and some instant/text message protocols.
So why won’t that work with email? Because those technologies don’t know who you are. They just know who they are talking to. Your browser doesn’t care whether it’s you or someone who stole your laptop; it just makes sure that no one else can listen in. When email makes hops from one server to another, only those two servers are having the encrypted conversation. The recipient and the next server along the way have a completely different encrypted conversation. Even if the transmission of the message is encrypted at every stage of the process, each and every server that takes part in the delivery has to decrypt the message in order to send it on to the next one.
However, using personal encryption a message can be packed up so that it can only be read by the person it is intended for. Then you send that message by email, and it gets sent from server to server but what each server along the way is looking at is a message that is already encrypted. It might seem like a belt-and-suspenders solution to do both, but so far few people use end-to-end encryption. Encrypting the communication between servers is at least better than nothing.
Wasn’t this about doctors?
It’s a bigger problem than just communication between medical professionals and patients, but it’s a good example of the kind of situation in which privacy is expected, but where people also want the convenience of email. To those who say that people with nothing to hide don’t need encryption haven’t thought through the basic idea of privacy. There are good reasons why doctors and patients, attorneys and clients, clergy and laity, parents and children, husbands and wives, employers and employees, and any number of other combinations of people who converse do so in private.
In the United States we have a set of laws collectively known as HIPAA which include a set of standards for privacy and security. Healthcare providers are rightly concerned about providing their clients with the convenience that consumers have come to expect when doing business, but have a higher responsibility for maintaining privacy than, say, an online bookstore does.
The need for privacy in communication with healthcare professionals is just one use-case, but it’s the use-case where there are currently a lot of professionals who are strongly motivated to find a solution.
Unfortunately, the «sign the waiver that says you don’t care if our communication is insecure» solution really isn’t a solution. What’s needed are general solutions that can be used for all cases.
Sadly, we’re back to encryption being slightly inconvenient and sort of hard for people to really understand. Implementations are a little clumsy, but one of the biggest hurdles shouldn’t be a hurdle. I don’t really understand public-key encryption. I’m up on most of the general concepts but most of the maths are way out of my league. First-year calculus was more than twenty-five years ago, and that was the last time I studied maths.
I also don’t know much more than the basics about how the laptop I’m using works, but that doesn’t stop me from typing.
But if encryption is going to become commonplace in email (and I think that it must) those of us who are comfortable using it are going to have to be generous with our time to help those who find it overwhelming. There’s a lot of information out there about how public key cryptography works, but very little of it is geared toward those who are just starting. Perhaps that’s a project worthy of future column-inches in Monochromatic Outlook but for the moment, I’ll throw out a few options:
PGP/OpenPGP/GnuPG
This is the strongest option, but it has a few drawbacks. There aren’t a lot of mail clients with built-in support for PGP. There are a number of add-ons and plug-ins available, but getting up and running with PGP generally means jumping through some hoops. Also, while this is strong encryption, there is no central authority for validating keys. Users are expected to confirm the keys directly with the people they communicate with. Again, this makes for better security, but requires more attention. GnuPG is the best place for most folks to start.
S/MIME
Cryptographically S/MIME is similar to PGP.3 The difference is that S/MIME email encryption uses central certificate authorities, like web browsers do. This means that when you receive an S/MIME encrypted message, you have some indication that it was sent by who it claims it was sent by. The problem with that is that you have to trust the certificate authorities. It also means that you have to buy the certificates from the authorities, though there are a number of places to get free certificates for personal use. It’s a set of valid trade-offs. Although I prefer PGP, I do also use S/MIME. S/MIME has much wider email client support.
Third-party solutions
These may be the most convenient, but are my least favorite. My doctor uses Virtru which seems to work well, but it means opening up a browser window in order to read or sent email to him. Also, I have to simply trust that this third-party is really on the level. Presumably they have signed the nice BAA, but ultimately I think it’s a bad idea to count on a third-party for privacy.4
That said, Virtru does seem to have some kind of integration with Google Apps for Work.
Special note about Gmail
The title of the post mentions Gmail, so I ought to wrap up with this. End-to-end encryption is very difficult with web-based applications. That’s unfortunate but it is true. There are browser plugins like Mailvelope (reviewed on LifeHacker) if you use Firefox or Chrome, but that doesn’t help MSIE users. And you have to trust the browser itself. Sure, they’re open-source, but who compiles their own binaries. Still better than nothing.
Other than by using a browser plugin, your only Gmail option is to use a third-party service, manually encrypt each message, or use a standalone mail application.5
Things are looking up for encryption. Between all the Snowden hype making encryption sexy (or at least adorkable) and the push for secure email by healthcare providers (and their customers, even if the customers don’t really know that’s what they are demanding) we may finally be seeing the beginning of the adoption of secure email standards and practices.
What stands in the way? Web-based email. That isn’t going away, but wherever there are problems, if there is enough desire to overcome them, solutions eventually present themselves. It’s just up to us to see those solutions and use them.
- An imperfect metaphor perhaps. Presumably the Post Office has custody over the postcard the whole time, but letter-carriers often have bins full of mail in plain sight in public. If your postcard is at the top of that bin, any passer-by might see it. With email your message may be handed from server to server, and the packets making up the message could conceivably travel all around the world through servers owned by (and this list is not exhaustive) big corporations who hope they can get away with that kind of data-mining, spammers, agencies of the United States government, agents of foreign governments, organized crime, private investigators, and amateur hackers. ↩
- The whole thing can be found at the MIT public keyserver ↩
- Ok, technically, I think S/MIME refers only to the way in which the encrypted message is encoded in an email. However, in practice it refers to a broader set of key-management practices and… other stuff. ↩
- There is an old saying: three can keep a secret if two are dead. ↩
- In case it wasn’t clear, you can use almost any standalone email application with Gmail, and do your encryption through the client. That’s how I do it. When I refer to Gmail here, I have meant using web-based Gmail. ↩