How to secure health data? Cryptography and security models | Hacker News Reader

How to secure health data? Cryptography and security models

blog.howareyou.com

40 pointsdawson22 comments

The part about passwords and password recovery is a bit troublesome in my opinion. If I am unconscious when I am brought to the hospital, the doctor should be able to access my records or release them to another doctor. Someone showing early signs of dementia might throw out their token and have no memory of ever having a password -- what do you do then? The threat is that an attacker might dump a database or steal a hard drive, not that a doctor might attack from the inside; doctors need to be able to access patient data under a variety of circumstances, including those where a patient is unable to give their consent or present a special token.

I think a better solution would be to give each doctor a smartcard, and to require some sort of threshold signature for certain operations (like sending patient data outside the hospital network) so that no single doctor has all the power. Attribute based encryption comes to mind here, since the ciphertext should only be stored once but should allow any doctor to decrypt; nurses might also need some amount of decryption capability (and would then need a smartcard of their own). Giving patients full control over their records sounds great on paper, but in practice people will forget their passwords and lose their tokens, and will probably not even realize the token is lost until they actually need medical care (and then it is too late).

We're implementing the Summary (Emergency) Care Record http://en.wikipedia.org/wiki/Summary_Care_Record

I think key splitting might be a better solution for the corner cases of unconscious or self-destructive patients. For example, split the key among 6 people associated with the patient such that any 4 of them are sufficient to decrypt. That way, even if 1/3 of the key-holders are not available, you can still get the info. This still gives you protection against database dumps and the insider threat, while not completely eliminated, is vastly reduced.

That is definitely an issue. I wonder if that could be biometric instead. Almost by definition if you are in a serious healthcare situation, biometric is an option. NYU Medical has palm scanners throughout and it is very easy for patients.

I was knocked unconscious in a bicycle accident a few years ago. For some reason at the time I was not carrying my wallet and not with anyone else. I ended up in the hospital with no identifying information at all, and actually woke up in the CAT scan machine having no idea what was going on. It was probably 3-4 hours after the accident before I was able to tell them who I was. I imagine in that scenario being able to grab a palm scan and look up my records, call emergency contacts, get my previous medical records, etc would have been very useful and wouldn't have required me to be conscious.

If I am unconscious when I am brought to the hospital...

The "break the glass" scenario / use case. It's basically a user facing backdoor. (Normal access goes thru the consent tree.)

It's 1 of 2 reasons why patient medical records cannot be encrypted, obfuscated, whatever. At this time.

EDIT:

The HowAreYou patient/user centric credentials does not permit the sharing (interchange) of medical records. For that, every patient must be uniquely identified and matched across heterogenous systems.

This is feasible in a single payer model, where there's a central naming authority issuing unique identifiers.

An analogy: A large organization with multiple systems, each with their own credential management. They install a master LDAP or ActiveDirectory, so that identifiers can matched across the organization.

In healthcare, that master unique identifier is sometimes called a master record number (MRN), patient identifier (PID), and some other jargon abusing acronyms.

EDIT 2:

Cambridge. UK NHS. Not the USA. They do have unique identifiers.

My bad. My only excuse is I shouldn't comment pre-caffinated.

I don't think this is a big problem. Just wanted to chime in with the opposing view.

We already have legal structures to account for people who are unable to provide informed consent (e.g., unconscious person, dementia sufferer etc): spouse, guardian etc can provide consent. This thing will piggyback on that same legal framework. Simply allow multiple RSA keys to decrypt the encryption key.

I think this sort of access control would be BRILLIANT.

I am quite concerned about random people accessing my health records. Obamacare's requirement of a standardized data storage format will only increase the temptation to datamine people's health records for fun and profit.

I'm confused by this paragraph, and I wonder whether this indicates a limitation on my part, the part of whoever wrote the marketing copy, or the part of the developers of this platform:

The problem of preventing an attacker associating a user’s encrypted ID to a decrypted ID is reducible to a security model called indistinguishability. We are using AES-CBC to perform this encryption, which means that our encryption scheme satisfies indistinguishability under a chosen plaintext attack, where the attacker is able to request encryptions, under the encryption key, of various plaintexts. We are confident that no such attacker exists, and that therefore our encryption is very secure.

First, it's my understanding that CTR is considered superior to CBC in all cases. Second, although it's true that resistance to CPT attack is a basic requirement for public-key crypto, AES is not public-key. It's likely they're talking about using RSA to secure the AES key, which seems normal. (As in, one could choose an existing solution.) But the last sentence seems bizarre. They're secure against a particular attack, and they doubt they'll ever see that particular attack, therefore they are "very secure"? WTF?

I guess I'm saying that this paragraph doesn't do much to convince me that the keys used to encrypt PID are securely stored, which I thought was the purpose of the paragraph. I don't assume that such keys are actually insecurely stored, and furthermore I'm not really sure that PID needs all this protection.

Hi Jesse,

So, let's talk about this point by point:

1. CTR mode and CBC mode both fulfil the same security definition: IND-CPA. IND part of the security definition refers to the fact that: there exists no polynomially bounded attacker that can with probability better than a half distingiush which of two plaintexts (that the attacker choses) have been encrypted under the scheme. The CPA part refers to the fact that this is a chosen plaintext attack, and the polynomially bounded attacker may submit plaintexts for encryption.

CTR mode does not satisfy a stronger security definition than CBC mode, but is parallelizable for encryption and decryption. Whilst this may sound like it makes CTR mode preferable, it also means that each block of ciphertext is independent. With CBC mode, errors propogate throughout the ciphertext meaning that it is harder for an attacker which does have access to a encryption oracle to modify the message through modification of the ciphertext. They would have to be able to modify every block of the ciphertext in CBC mode, whilst having to only modify one in CTR Mode.

2. To clarify: all PID is encrypted under the strong AES encryption I have outlined above. In practical terms there is only one security definition that is stronger than the one we are using, which IND-CCA in which the attacker also has access to a decryption oracle. The attacker in this case is arbitrarily restricted to be unable to decrypt certain plaintexts. This does not make a large deal of sense in a real world attack, if the attacker does have access to a decryption oracle, it is likely they will be able to decrypt any ciphertext and blow the encryption wide open.

Regarding the necessity of encrypting PID, for various compliance reasons it is necessary for us to ensure that if someone pulls our servers out of the rack they can't get access to our users' data. This scheme satisfies our compliance requirements and, we believe, keeps our permission control model cryptographically enforced.

Thanks -- Sam Phippen

How are you? Engineer.

The issue is Accountability.

It is more important to know "who/when/why" are people looking at your records that stoping people from accessing them all together.

All successful and failed transactions against any resource gets logged. We haven't exposed it in the API yet, but it's coming.

I'm guessing that you're updating records. So you're resolving what's "truth" during the inbound operation. (For readers: data may be received out of order, so implementers must resolve the single source of truth in near real-time.)

Our systems used to do that.

My redesign eliminated updates, did only inserts, and resolved the "truth" during the query. Greatly simplified everything.

No more "historical" table, where deltas are logged. Determining what was known when (determining liability) queries were simply date bounded. No need to "rerun the data" when a mapping or business rule changed. Etc.

No updates, no real deletes either (only virtual ones). Data about transactions is stored separately from the clinical data, in an optimised store for log data.

Exactly.

About 5 years ago, I was looking to add tamper evident logging to our systems.

At the time, the state of the art was a rolling hashcode chain. Add a SHA field to each log event, which includes the delta, so that you can tell if someone altered any of the log entries.

There's now algorithms which factor for untrusted / insecure loggers. I haven't digested those papers yet.

But it's just a bandaid. Because I can still root to the OS, database. Tamper evident logging must be done at the lowest levels. (If anyone knows of such a project, please share a link.)

I'd be interested to see a list of threat models you have.

1) Gossiping employee?

2) Bribable employee?

3) Careless doctor?

4) Malicious doctor?

Britain's serial killer with highest murder rate was Dr Shipman, so malicious doctor while rare is a serious risk.

This looks interesting and I'll be following along!

Having served the roles of patient and healthcare IT geek, I believe (but cannot prove):

Biggest threat (to patients) is mistakes. Chop off the wrong arm. Misdiagnosis. Adverse effects from drug interaction, allergy, whatever.

Second biggest threat is poor policy, procedure compliance. Awul Gawande's book Better is a good primer. http://gawande.com/better

Yes, I guess some protection against people faking data to cover mistakes is more important than protecting against people faking data when they've deliberately killed someone, because deliberate killings are rare.

Fudging the data is important; we've seen some clinicians are faking data to show their departments are meeting national guidelines even though they're not.

(http://www.theguardian.com/society/2013/jul/25/mid-staffords...)

> Between July 2000 and July 2010 she inaccurately recorded patient discharge times from A&E, and ordered other colleagues to follow her example, the panel found.

While this looks interesting, it brings to mind a question I've been struggling with. (Disclaimer: I work in health software) While taking reasonable precautions to ensure the security and privacy of health info is an obvious decision, I am at a loss to understand Western culture's frantic chase after "perfect privacy through technology." Technological safegaurds will become increasingly complex/expensive while their returns diminish. Is there a point at which we'll be satisfied, or will we continue chasing for smaller and smaller gains with little regard for the cost/complexity?

I'm not sure where we presently fall on that curve, but I would love for our culture to take a step back and consider it.

And from a more abstract perspective, the least secure points in an otherwise secure system are the endpoints, where data is no longer encrypted. In this case that's Doctors, related healthcare staff, and the patients themselves. Increasing security in the middle will have little or no impact on those human endpoints, or their behavior. While that doesn't make technological improvements meaningless, they should always be framed and considered in that context.

The whole thing seems to be about "covering our aes".

According to Murphy's law, in one way or another, sensitive information will leak. When this happens you'll need to show that you did your best to avoid it. Lawyers can be more expensive than programmers therefore it is probably better to save on lawyers than on programmers.

no mention of k-anon or l-diversity in the aggregates. was that just to keep things simple, or do you really not enforce that?

Hi Andrew,

to cut a long story short, we've done some work to decrease the resolution of the encrypted data in the aggregates. For example: we store age to nearest year instead of date of birth, location is severely reduced in resolution from address to state and so on. By this way we're confident these attacks aren't directly applicable, whilst the aggregates are still useful.

Your own doctor always has access to the full resolution data via access to your data key. These attacks are something we're concerned about too and we're looking to bring in third parties to ensure that our system is secure.

Thanks -- Sam Phippen

How are you? Engineer

great - sounds good, thanks for replying.

Reply on news.ycombinator.com