New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encryption for patient data #220

Closed
pengux opened this Issue Dec 5, 2015 · 25 comments

Comments

Projects
None yet
9 participants
@pengux

pengux commented Dec 5, 2015

Is there any encryption for the patient data? If there is, it should be documented

@hex007

This comment has been minimized.

hex007 commented Dec 5, 2015

@pengux If not then which standards would you recommend?

@pengux

This comment has been minimized.

pengux commented Dec 5, 2015

AES is best practice. Maybe using something like https://github.com/digitalbazaar/forge to do it? The data should not be decrypted until a valid login and access is provided.

@stefanpenner

This comment has been minimized.

stefanpenner commented Dec 5, 2015

Offline sync and encryption sounds tricky. This will likely require some thorough further investigation, choosing a cypher is the least of the choices needed to be made.

As this is a OSS we should see if someone specialized in this can spare some cycles to share approaches/audit etc.

@iagox86 maybe you or someone you know has thoughts on approaching this correctly.

@mattleff

This comment has been minimized.

mattleff commented Dec 6, 2015

@ircmaxell might have recommendations (per this).

@hex007

This comment has been minimized.

hex007 commented Dec 6, 2015

I think it is a bit early to implement encryption. Client side encryption seems easier than Server side.

@pengux As you said patient data should only be decrypted on successful login. Do you think decryption should be done based on user access level or user role level. As in, should a doctor have access to decrypted data of only his/her patients or of all the patients as a Doctor only. This makes sense if a nurse is making changes or updating data, as nurses are not restricted to patients but to the place of demand.

@pengux

This comment has been minimized.

pengux commented Dec 6, 2015

@hex007 Yes, the data should only be decrypted if the user has access to it. I'm not sure how your ACL and permissions are built but it should be easily done on the server side and sync down to the app. So the app only have the decrypted data that the current user is allowed to see. If the user logouts then the data should also be removed from the app.

@stefanpenner

This comment has been minimized.

stefanpenner commented Dec 6, 2015

If the user logouts then the data should also be removed from the app.

This then likely weakens the offline mode features of this application. Or weakens the security, because the user who is about to go offline for some time, will opt not to log out so they can keep access to the offline data.

Both sides have unfortunate side-affects. Keeping "data at rest" reasonably safe, without encouraging the user to do something unsafe (e.g. staying logged in to preserve data etc.) will have to be the focus.

An interesting an related article: http://tonyarcieri.com/whats-wrong-with-webcrypto lets see if tony has some cycles to give his thoughts. (i'll ping him).

Something that aims to mitigate some of the "JS is malleable" problems:

@pengux

This comment has been minimized.

pengux commented Dec 6, 2015

This then likely weakens the offline mode features of this application

Not necessarily as the app can be put to sleep mode (which also preferably encrypt the data) and require the user to authenticate again. The data is deleted only when the user actively logout.

I don't think the app will be HIPAA compliant without any encryption of data, and it may prevent uses in organisations which require compliance.

@stefanpenner

This comment has been minimized.

stefanpenner commented Dec 6, 2015

(which also preferably encrypt the data) and require the user to authenticate again.

the trick is doing this safely on the client

@hex007

This comment has been minimized.

hex007 commented Dec 6, 2015

This is my suggested workflow towards the encryption problem.

  1. A user logs into the system.
    1.1) The username password and a random hash token (encryption token) is generated.
    1.2) the server recieves this data.
    1.3) the server authenticates the user and generates an access token. This is used for all further communications.
    1.4) the user successfully authenticated message is sent to client with access token

  2. A user makes a data request
    2.1) the data request is received by the server
    2.2) the user is authenticated based on request token and user access to data is verified
    2.2) the response is encrypted with the token sent by the user while logging in (step 1.1)
    2.3) the user recieves the response
    2.4) response is stored locally for current and later use
    2.5) response is decrypted and accessible to user

  3. The user leaves the station by locking the system
    3.1) all user data is encrypted
    3.2) the user tokens are locked in a local crypto storage.
    3.3) the tokens are forgotten by the browser

  4. the user comes back to the station to resume work
    4.1) the user logs in again but since records show that user is already logged into the server local crypto storage is accessed using credentials to unlock access token and encryption token.
    4.2) all user data is decrypted using encryption token
    4.3) the data is synchronized to check for updates
    4.4) the data is available to the user
    4.5) all new requests are made with the access token

  5. the user logged out
    5.1) when the user logs out the data is errased unless offline mode is active.
    5.2) users access token is sent to server for deauthenication
    5.3) his encryption key is deleted unless offline mode is active
    5.4) the user successfully logged out

@jkleinsc

This comment has been minimized.

Member

jkleinsc commented Dec 6, 2015

One thing to keep in mind here: this project is targeting hospitals in the developing world and as such we don't need to worry about HIPAA compliance.
That isn't to say security shouldn't be considered, but we are operating under different constraints. If there are performant ways to provide encryption and those ways make sense for the project I think they are worth discussing.

@tarcieri

This comment has been minimized.

tarcieri commented Dec 6, 2015

I would suggest starting with access control requirements and a threat model. What data is worth protecting? Who are you protecting it from? Who should have access? How are you going to use cryptography to enforce that access?

One of the biggest problems with client-side JS encryption is often it doesn't actually mitigate any threats (and may add additional attack surface)

@iagox86

This comment has been minimized.

iagox86 commented Dec 6, 2015

Hey, Stef roped me into this, and I wanted to give my 2 cents. I don't know enough about this project or have enough cycles to help much, but I figured I'd say something!

@tarcieri made the exact point I was going to, but I'll try to expand on it.

The most important thing to do, before even thinking about what type of encryption to use is thinking about the goals and threat model that you're trying to defend against. I realized while writing this that I could break it down into the three core tenets of security: confidentiality, integrity, and availability.

Confidentiality: If an attacker compromises the server, should the data be compromised? What if they compromise the user? Or an adminstative user? Typically one or the other will lead to data compromise, unless a very complex system is in place with key escrow. Based on the threats that you think you'll face, consider which of those are possible.

Continuing confidentiality: what if the adversary can sniff the connection? What if they can man in the middle the connection? In-transit data is presumably protected by SSL, but is an adversary breaking SSL (or man in the middling somebody) a concern? What if they can guess a user's password - can this be tied at all to two-factor authentication (like a Yubikey - they can store encryption keys securely).

If somebody steals a hard drive, are the keys and data both stored there? What if somebody puts a keylogger on the user's machine?

Integrity: Can an attacker change the data in a meaningful way? Can they change the encryption keys? This is a bit implementation-level, but the Cryptographic Doom Principle applies - encryption isn't enough without signing.

Availability: let's say the only user (or users) with access to a record get hit by a bus. Is the data going to be locked out forever? And, if not, how is it recovered? And can that recovery be abused? Are there backups? Are backups tied to keys? Are keys backed up? How's that handled? Losing medical records sucks, but not as much as having them stolen. Probably. It's gotta be considered.

And the final bit: look for some other professional project that's done the same thing, and learn from them. It's almost impossible to get encryption right, even if it's what you do for a living. I regularly give talks on crypto attacks, with the goal of dissuading programmers from designing crypto themselves. :)

@hex007

This comment has been minimized.

hex007 commented Dec 6, 2015

In case of Death or incapabilities of a user to unlock data, an admin should always be able to unlock it. The problem in that case might change from data protection to keeping track of all users and the time of modification of data. Thus keeping the users accountable for misuse.

@tarcieri

This comment has been minimized.

tarcieri commented Dec 6, 2015

@hex007 to do that (allow an administrator to unlock any record) with client-side encryption you'll need a key escrow system, which is a very tricky thing to get right.

If that's the case, you're probably better off with server-side access control.

@iagox86

This comment has been minimized.

iagox86 commented Dec 6, 2015

@hex007

This comment has been minimized.

hex007 commented Dec 7, 2015

Can you elaborate on key escrow and how is works?

What do you think about the workflow that i have suggested? I did not specifically mention server side encryption as i didnt know how to handle that. Decryption of data and then encryption of request specific data will be taxing on the server if there are many users. How many, depends on the server config. Considering that places looking for using the software might not have a state of the art config this looks bleak.

@stefanpenner

This comment has been minimized.

stefanpenner commented Dec 7, 2015

It seems like the higher order bit, is actually fleshing out the requirements (eg. the 3 tenets @iagox86 mentioned) . Specific solutions can be applied when the business cases have been specified, and holistic solution thought up. I would be concerned by any patch work attempt at securing the system.

@iagox86

This comment has been minimized.

iagox86 commented Dec 7, 2015

Encryption isn't really that slow or intensive.. IMO, performance
considerations should wait until it can be benchmarked.

In terms of escrow and such, I'll have to get back to you.. Typing from my
phone. :-)

But basically, it either require an extra server that handles the keys.

Ron
On 6 Dec 2015 6:45 p.m., "Stefan Penner" notifications@github.com wrote:

It seems like the higher order bit, is actually fleshing out the
requirements. Specific solutions can be applied when the business cases
have been specified, and holistic solution thought up. I would be concerned
by any patch work attempt at securing the system.


Reply to this email directly or view it on GitHub
#220 (comment)
.

@ircmaxell

This comment has been minimized.

ircmaxell commented Dec 7, 2015

My stance is that you shouldn't be doing crypto in the browser (or more accurately, you shouldn't be relying on it): JavaScript Cryptography Considered Harmful.

Instead, what I'd recommend is decrypting server side once you pass ACL for that user. As far as protecting against server breaches, having a separate crypto server can help, but it still depends on the attack vector.

Once you decrypt, enforce TLS to the client. My $0.02 at least.

@iagox86

This comment has been minimized.

iagox86 commented Dec 7, 2015

IMO, TLS should be required, not even up for discussion (of course, that's
not my decision to make, but launching anything with sensitive data that
doesn't require TLS is crazy).

The thing is, if the server stores the encryption keys and enforces ACLs,
then what, exactly, does the encryption accomplish (besides a checkbox on
HIPAA if that was an issue)?

On Mon, Dec 7, 2015 at 8:10 AM, Anthony Ferrara notifications@github.com
wrote:

My stance is that you shouldn't be doing crypto in the browser (or more
accurately, you shouldn't be relying on it): JavaScript Cryptography
Considered Harmful
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
.

Instead, what I'd recommend is decrypting server side once you pass ACL
for that user. As far as protecting against server breaches, having a
separate crypto server can help, but it still depends on the attack vector.

Once you decrypt, enforce TLS to the client. My $0.02 at least.


Reply to this email directly or view it on GitHub
#220 (comment)
.

@jkleinsc

This comment has been minimized.

Member

jkleinsc commented Dec 7, 2015

I agree that we should be using TLS server side and with Let’s Encrypt now providing free certs, there really isn't any excuse. HospitalRun server already supports SSL/TLS, but its not configured by default.

I appreciate all of the discussion here and I believe at the current time the best approach forward is server based ACL, in particular because we can accomplish this in CouchDB. This also means that offline usage/storage of data will be limited to the data that the user has access to.

@tarcieri

This comment has been minimized.

tarcieri commented Dec 7, 2015

Data-at-rest encryption for the contents of your database can be nice, especially PII/PHI. This means if someone compromises a database backup, they haven't immediately breached confidential health information.

Best practice is of course to encrypt the complete contents every time you make a database backup, but encrypting database fields, even if it's just the PII/PHI, also protects the data if the database is compromised (but not the app)

@jkleinsc

This comment has been minimized.

Member

jkleinsc commented Jan 14, 2016

There has been an ongoing conversation on the server side of this project here:
HospitalRun/hospitalrun-server#5. We are going to start partitioning the data so that users only have access to the data accompanying their role. The one frontend feature that we do need to implement is to partition out private patient data into its own data model so that we can limit which users can see that data.

@tangollama

This comment has been minimized.

Member

tangollama commented Apr 22, 2016

Closing in favor of the discussion in the server repo in the aforementioned issue.

@tangollama tangollama closed this Apr 22, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment