

How to secure health data? Cryptography and security models - dawson
http://blog.howareyou.com/post/60928192861/how-are-you-cryptography

======
betterunix
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).

~~~
specialist
_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.

------
jessaustin
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.

~~~
samphippen
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.

------
clueless123
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.

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

~~~
specialist
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.

~~~
macnix
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.

------
DanBC
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!

~~~
specialist
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](http://gawande.com/better)

~~~
DanBC
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...](http://www.theguardian.com/society/2013/jul/25/mid-
staffordshire-nurses-struck-off))

> _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._

------
bioneuralnet
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.

~~~
bioneuralnet
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.

------
andrewcooke
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?

~~~
samphippen
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

~~~
andrewcooke
great - sounds good, thanks for replying.

