Arien Malec responded with a good discussion of some issues that were uncovered during some prototyping. I am not convinced that this was fully investigated, but it still is a good read and a well done description of SSL, TLS server authentication and TLS mutual authentication.
My answer is: Security is hard, Trust is hard…
All the posts I have read today are all not looking at the total picture. I recommend one look at the Security and Trust workgroup output (Yes, I am a very active member). I think that the Threat Models are most important here:
Threat Models (WG Consensus Achieved)With TLS, you MUST create a walled garden. Any hole in the wall causes the whole thing to fail. If TLS was used there would be a private e-mail network just for trusted organizations, all organizations would need to be trusted.
Direct Project Security Overview (WG Consensus Achieved)
Certificate Pilot Recommendations Discussion (WG Consensus Achieved)
TLS is not as care-free – PKI free - as Dixie tries to say it is. The comments about not being able to know if you are connecting to the right place is exactly evidence that PKI is need here. What is not needed with TLS is an out-of-band mechanism to distribute certificates, since TLS includes certificate discovery/distribution inline. But one must have a trust relationship.
It is this distribution of certificates that is the hard part of S/MIME. I send signed email messages to people that I want to be enabled to send me encrypted content. This mechanism of certificate distribution, sending a prior signed message, is the one that is used in practice today. I have tried to argue that any use of NHIN Direct messaging very likely was preceded by conversations that were not patient specific but were related to building a relationship. Between organizations this conversation was about what services one might offer another. These conversations likely included discussions about legal restrictions. These conversations could have easily have transmitted the certificate and setup a trust relationship.
also see: Healthcare Provider Discoverability and building Trust
TLS is great for point-to-point communications, or for communications with trusted-intermediaries. But it fails for end-to-end asynchronous message communications, and is NOT the right approach for e-mail.
Wrapping:
There is a little bit of discussion about 'wrapping'. The wrapping that is being discussed is S/MIME wrapping… that is to take an email message and put it inside another email message… Think Russian dolls… The theory is that if you keep wrapping enough times it must be secure. This can hide the ‘subject:’ line, but doesn’t hide the ‘to:’ or ‘from:’.
Yes one can have a highly intelligent email router that puts false ‘from:’ on the outside email, and somehow uses a trusted-intermediary-endpoint-address (‘to:’). Clearly lots of discovery problems here, or configuration and databases. But if you are going to configure this kind of a system, then we should just use a more capable system.
Scope of NHIN Direct
People keep forgetting that NHIN Direct is a transport for VERY SMALL providers with VERY LITTLE technology. These people only need to communicate with a few ‘others’. We need the NHIN Direct solution to help low-tech people. We needed it to work with little beyond off-the-shelf software, or exactly commercial (or open-source) off-the-shelf. The NHIN Direct transport should NOT be looked to as a solution for more intricate workflows.
As part of this NHIN Direct has also recommended that email addresses could be departmental or organizational. That is one address that represents a whole department or whole organization. Thus there isn’t a huge number of addresses, one for each organization. I don’t think this is a great solution, as it basically brings us back to organization-to-organization rather than end-to-end; but it does put the policy decision in the hands of those that should make the policy decision.
So, I suggest they keep the scope clear for NHIN Direct… Allow simple e-mail with slightly complicated security… and get working on robust health information exchanges. Use NHIN Direct as a stepping stone, and stop thinking it is a long term solution.
See: Directed Exchange vs Publish/Discover Exchange and NHIN-Direct Privacy and Security Simplifying Assumptions
I agree with keeping it simple. And I see no problem with having two confidentiality solutions for two very different use cases.
ReplyDeleteDirect is only two steps up the technology ladder from FAX. That is, it is FAX plus a structured data payload and an electronic sealed (secure) S/MIME envelope. It need be no more complex than that.
The more complex requirements of EHRs include record locator services, data discovery, data abstraction and aggregation, and -- quite importantly -- the data-source not knowing all of the data-consumers, i.e., only knowing the repository where the first copy resides. The "walled garden" of TLS fits that case well.
The confidentiality solutions are well-defined and, although requiring some up-front investment and ongoing operational costs, are do-able with known technology and standards.
The harder problem -- where we SHOULD be spending our energies -- is establishing and maintaining trust for patients. How can we provide meaningful assurance to patients that their privacy is protected according to their expressed preferences? The answers need to seamlessly scale from small offices to large institutional and governmental scope.