Proper implementation of HIPAA within iOS app with several factors

Question

We are developing an iOS app that allows users to store/modify Protected Health Information (PHI) and the app needs to allow users to do so without an internet connection for large parts of the process. We will need to encrypt the data but are having a difficult time coming up with a solution on how to properly do so as we don't want to store the key in the code and the data would still need to be able to be accessed without a connection to a server.

Our working idea is to encrypt the data using the user's password (which would not be stored on the device) but we run into an issue where other users may need to modify/access that data on that device via their own login. (In the event one iPad breaks)

The ideas we've tried to work through but don't seem secure are:
- Storing a static key in code
- Storing a dynamic key given by the server in a local sql database
- Storing the dynamic key given by the server in the iOS keychain

We were considering having both users login upon data retrieval and encrypting it with both passwords but we run into user-related issues where the data could be locked if one user isn't on duty or not nearby.

Question: How can we properly protect PHI on iOS so that it can still be accessed by those who are allowed to access it, potentially offline, and doesn't restrict the data to being viewable by only one person - preferably without storing logins (as we don't want user credentials stored)

Follow-up: If this isn't something feasible, what would be the best course of action to take to meet most of the needs above?

Edit:Clarification
Authentication takes place originally when pulling down/submitting data and we need to encrypt the data that's pulled down while keeping it accessible to previously authenticated users without storing the key.

Answer 1

Disclaimer: My company makes a HIPAA-compliant iPod application. I'm responsible for the compliance...

The iPhone actually meets many HIPAA requirements out of the box. Once a passcode is set on the device, the contents are encrypted -- which takes care of many HIPAA requirements, notably encryption at rest.

For downloading the data, you must use a TLS or otherwise encrypted connection to make sure data is encrypted in transit.

You have to configure your application to download and push a security policy to a web site in a .mobileconfig file that forces the users to set a passcode on the device to use the application. If the passcode is set, then the device is encrypted. So, the .mobileconfig will enforce this.

You also should leverage use of the keychain to store any type of token or credential provided by the user. To make it simpler, you can have your app require a 4-digit passcode to unlock those credentials from the keychain --rather than have them retype a password on the phone.

If the app does not have a network connection to the server constantly, you can create a sync button. This will sync relevant data to the local filesystem. When changes are made, it saves it locally, until the app is told to sync again, in which case it reconciles changes with the master web app database.

Finally, this is not an exhaustive description of iOS HIPAA compliance, I encourage you to consult with a lawyer to draw up your security policies and other documentation, which is required to have under HIPAA.

Answer 2

I know this is a rather old question, but I came across it as part of another search and figured I'd throw out one more idea here in case others are facing similar challenges.

You may want to look at envelope encryption.

One example strategy you could use is as follows:

Assumptions:

You have PHI, you have user A and user B, and each user has a different password. You want both users to have full access to the PHI after entering their respective passwords. A user login is composed of a username and a password.

Strategy:

You encrypt the PHI with a secret key (let's call it K). You ship a data table down to the device, containing for each user: a hash of the username (e.g. md5), and a version of K encrypted by the user's password (let's call that encrypted key eK).

So, in order to gain access to the PHI, user A enters his username and password, and the following occurs, in order:

• a hash is calculated from the username
• that hash is used to find the relevant entry in the table
• the encrypted key eK is decrypted using the password the user has entered, resulting in a usable key K
• the PHI is decrypted using K and loaded into memory
• (the user can modify the data as neeeded)
• the PHI is re-encrypted using K and stored to the device

Now, user A could log out, and user B could log in with her username and password, which results in a decrypted version of the same K, then usable to decrypt and re-encrypt the PHI as needed.

Considerations

By hashing the username, we avoid disclosing any actual usernames in the data table.

With this strategy, you are able to store the encryption key itself, but in a fashion such that a user without the appropriate username / password would not be able to access the key, and would not be able to decrypt the PHI.

Answer 3

While I am soon going to begin a career dealing with HIPAA, and have therefore been brushing up, I thus far only have experience with PCI compliance. That being said my understanding of what I've looked into so far seems to indicate that both the ePHI itself and metadata of that ePHI (creation date/time, filename, last mod date --- ref. http://www.hipaasecurenow.com/index.php/dropbox-is-not-hipaa-compliant/) must be encrypted.

Storing a key where you store the data you want to protect seems like a risky move. Like keeping a key to your car in the sun visor.

Furthermore, part of HIPAA compliance is physical security. What physical control over that mobile user's phone do you have? For my two cents the best way forward is to forget about the offline capabilities and focus on an app that might always require an internet connection, but is secure.

Answer 4

I think your question is "How to perform offline authentication and authorization on an untrusted device?".

The short answer to this question is: you cannot.

The long answer is: some guys tried to work around this problem, for blue-rays players and video game consoles. To solve the problem they try to make the untrusted device a trusted one, by preventing the users to take a permanent control of their device. New blue-rays will need updated players to be played and players with vulnerabilities are black-listed by the blue-ray consortium. Consoles use temper-proof cryptographic components to protect their secrets (in combination with other mechanisms). For detailed information on these two examples, you can start with wikipedia looking for the sections about DRM management. However, video-games and blue-rays are not protected health information. They can tolerate their protection mechanisms to break from time to time, they planned for it and can recover. Moreover, you don't have any control on the devices and cannot implement a security mechanism similar to them.

What I would recommend you to do is first to forget to authenticate for many users to simplify you needs. You just authenticate the iOS app user and then transfer the responsibility of the PHI to him. He can then share his data, but any problem resulting will be of his fault entirely. The user will have to take the steps to remain compliant with HIPAA (your app might be able to help him). Secondly, forget about offline authentication. Authenticate him online, before retrieving the data and the rights associated. However you will not be able to strongly enforce those rights as you have no control of the device. Then again, your application can try to enforce them and you can make it illegal to alter or reverse-engineer the application. Thirdly, storing encrypted data with the key to decrypt them is pointless. It will just increase development and maintenance costs without increasing the value of your application. If HIPAA mandates encryption, let iOS manage it: use its APIs and let it encrypt it with the user password or security tokens or whatever.

There might be other solutions better suited to your needs.