I'm a part of a small company that is going to be implementing HIPAA compliance. We will be seeking legal counsel, etc so anything heard here will not be taken as legal advice, etc. I just want to bounce some ideas off of you guys.

The basic spirit of HIPAA from what I have read:

  • Ensure only authorized people can access PHI.
  • Ensure data in transport and at rest is encrypted.

I've done some googling (AWS whitepaper, hipaa hosting, etc) and was wondering what you guys thought of the following scheme:

  1. Rails front end application code (Heroku/AWS) that handles all the client requests, all phi sent over HTTPS.
  2. Data sent to a centralized encryption server to be encrypted.
  3. Encryption server sends encrypted data to the database server (AWS probably).

This would allow me to offload most of the server hardening onto the encryption server, as well as separate the keys from the data. Does anyone have any experience/insight in setting up a system such as this? Or even a system like this for HIPAA specifically? Is it even a good idea from a security standpoint? Also I've been hard pressed to find a company that simply hosts an "encryption server", are there any companies that specialize in something like that?

  • 1
    From a PCI-DSS perspective, various companies deal in providing "data vaults" which are essentially centralized encryption services for credit card/sensitive data. They are generally encryption + storage + tokenization all-in-one solutions but you might see if those companies have branched out into HIPAA services and whether anything is applicable. Commented Dec 15, 2011 at 20:40

1 Answer 1


The HIPAA requirements not nearly strong enough. In short it states that you must encrypt medical records at rest and you cannot use a broken primitive, which is obvious. Whoever audits your system probably like to see AES. This is trivial to support, and an Amazon RDS MySQL instance already supports this out of the box with the aes_encrypt() and aes_decrypt() functions.

Where HIPAA and PCI-DSS fall short is that they don't state what mode of operation should be used. In fact MySQL's aes_encrypt() uses ECB mode, which is horrific. Further more, there are problems with enforcing security when using encryption at this layer. aes_encrypt() is easy to break by configuring mysql to log all queries. The AES key must be embedded in your application so if it is compromised, the attacker could read the value out of a configuration file and access the records. This is two points of failure that can be avoided by encrypting the data within your application and then transmitting cipher text to the database. But HIPAA doesn't care about this problem. HIPAA's other requirements, such as requiring a CISSP to analyze your application is more important.

So no one needs to spoon feed you this masturbatory security feature. I urge you to implement a secure system, but HIPAA wasn't designed well enough to care.

  • So basically from a "compliance" standpoint I don't actually have to be all that secure.. however from a moral/technical point of view is the system as described above fairly secure?
    – Matt
    Commented Dec 16, 2011 at 1:24
  • @Matt the system as you describe it is just a storage device. So the attacker can request an encrypted object from the storage device, as if it was plain text. So that is totally masturbatory. I don't see how cryptography limits access at all in that scenario.
    – rook
    Commented Dec 16, 2011 at 2:05
  • Presumably there would be authentication and authorization controls so that only people authenticated through the application server could retrieve data from the encryption server. From what I have read key management is a real issue (like leaving your key in your car door after you lock it if not protected properly) so I'm trying to abstract key management into a separate service so that they keys aren't either hardcoded into my application code or stored in my database alongside the encrypted data.
    – Matt
    Commented Dec 16, 2011 at 3:57
  • @Matt yeah and so you are relying upon these authentication and authorization controls (that the attacker will have if your server is compromised), and not a symmetric cipher to keep your data safe. I'm not saying there is a solid answer here, i'm just saying that this doesn't stop the attacker from doing what he wants. Its not a "defense in depth" approach. You shouldn't trust your database.
    – rook
    Commented Dec 16, 2011 at 7:09
  • 1
    fair enough (thanks for all your answers by the way)... is there an industry best practice for keeping keys safe then?
    – Matt
    Commented Dec 16, 2011 at 17:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .