The HIT Standards Committee's Privacy and Security Workgroup made several recommendations to simplify the NHIN Direct project's approach to secure data transport.
By default, NHIN Direct uses S/MIME and X.509 digital certificates to secure content end-to-end. S/MIME verifies the identity of sender and receiver, and encrypts and integrity-protects message content (the payload) but does not encrypt the email header fields (to/from, subject). The Direct specification contains ambiguous requirements regarding the use of TLS and full message wrapping to protect against data-leakage, creating confusion and complexity i.e.
“SHOULD” provide capability to use mutually authenticated Transport Layer Security (TLS) for all communications
Full message wrapping is “RECOMMENDED” and “OPTIONAL” – but warns that some receivers “may present such messages in ways that are confusing to end users“
The Privacy and Security Workgroup recommended specifying S/MIME as the standard for securing NHIN Direct content end-to-end, removing TLS and message wrapping as security options in the core specification. The residual risk of header fields can be mitigated through policy direction regarding suitable content for subject fields.
What does this mean? What's the difference between S/MIME and TLS? Is S/MIME better than TLS? Should one or both be used?
To understand the recommendations, you first need to understand how S/MIME and TLS work.
Dixie Baker created this overview of the two approaches.
S/MIME is a great way to encrypt and sign a payload of content to be sent from point A to point B. The channel of communication is not encrypted, the contents of the message are encrypted such that only the rightful receiver can decrypt them, validate that the expected sender transmitted the message, and the message was not modified along the way. The disadvantage of S/MIME is that you must keep certificates on file (or use public key infrastructure) for every organization you exchange data with. This does have the advantage that you can be sure only the right, trusted entities, with pre-existing authorization to receive data are part of the exchange.
TLS is a great way to encrypt a channel of communication. From Dixie's diagram, no existing certificates need to be kept on file and PKI is not required. A certificate is requested as the transaction begins and is used to send data via a symmetric encryption technique. It's simple and easy to implement. The downside is that there is no guarantee that the certificate is associated with the right authorized entity.
For Stage 1 of meaningful use, in which organizational entity to organizational entity exchange is all that is expected (not individual to individual), S/MIME and TLS are not much different. With S/MIME you keep a list of your organizational trading partner certificates on file and with TLS you hope that the URLs you are calling to request certificates are really the correct trading partners. TLS has a bit of an advantage in this configuration because the communication channel itself is secured and works fine with any protocol - SMTP, REST or SOAP. No header information is sent unencrypted as is the case with the S/MIME payload only encryption.
Where S/MIME wins over TLS is when more granularity than organization-to-organization is required. For example, if you wanted to secure content from Dr. Halamka to Dr. Baker, with assurance that the content went only to Dr. Baker, TLS cannot do that.
Thus, S/MIME alone provides a level of encryption which is good enough, ensures the organization receiving the data is the right one because you have certificates for all valid trading partners on file, and it prepares for a future when we may have individual to individual secure exchange, not just entity to entity exchange.
I welcome feedback from the industry on the recommendation that S/MIME be used as the standard for securing NHIN Direct content end to end. When I polled my operational people they voiced a distinct preference for just TLS which they felt was easier to implement and support, since there is no need for PKI and maintaining a local file of certificates for trading partners. I definitely understand how S/MIME has advantages for individual to individual secure transport, but I wonder if we will ever need such functionality. If the long term vision of a network of networks, based on secure organization to organization transmission using a national entity level directory, might TLS be good enough for the short term and long term?
While in theory S/MIME sounds easier, you underestimate the complexity of managing all the certificates for various receivers. This is a monumental task for experienced vendors and impossible for something like a small to medium doctor's EMR. Just try to imagine secure key exchange x 1000 combinations.
ReplyDeleteThis is the reason why you can't even get S/MIME support within large email providers. For example, none of the HHS OPDIVS support S/MIME and they control every account through a single email provider (MS Outlook). The commercial email vendors also choke on this and vendors like gmail use the TLS route rather than S/MIME.
Your use case of encrypted data from Dr. Halamka to Dr. Baker sounds fine, but is extremely difficult to operate without a trusted intermediary to manage and verify that Dr. Halamka and Dr. Baker's credentials are valid. Also, (with much added complexity and maintenace) TLS can definitely fulfill this use case. Mutual authentication TLS provides a secure channel end-to-end between two parties (who could be Dr. Halamka and Dr. Baker, or more likely their EMRs or trusted intermediaries).
The reason why your operational staff recommend TLS is because TLS is implementable and manageable, while S/SIME and the millions of certificates is extremely expensive to build out and maintain (although VeriSign and other CAs will love the added business). This is also why so few EMRs use PKI to authenticate users. Password or secure token is much more common.
I'm a developer working on an (as yet unannounced) HIT application, and I suggest using TLS exclusively.
ReplyDeleteMIME and S/MIME were meant for email. Remaining stuck in what I call an "email mentality" will hinder progress in HIT. Email is, and will probably always be, a mess. As much as I prefer Gmail to other email applications, I don't think even Google will ever tame the beast.
Using TLS for encryption gives software developers the ability to move beyond email, using simpler and more flexible protocols such as REST (or whatever protocols come down the road).
Since we're working towards having intelligent software on both the sending and receiving ends, using TLS to encrypt the connection, and letting the software parse for things such as XML tags or JSON strings (or, again, whatever future data exchange formats emerge) to figure out which individual the message should be routed to, is far more future-proof than using email-related technology.
Payload-based (S/MIME) privacy, authentication, integrity, and non-repudiation (P.A.I.N.) allow for the use of extant, proven, and well understood transport infrastructure (the vanilla SMTP backbone). Yes, TLS can be used underneath SMTP, but server configuration complexity increases and a corresponding delay in adoption occurs.
ReplyDeleteUsing TLS handshake certificates and keys for provider org-level P.A.I.N. enforcement requires that the provider org's server certificate be presented within the TLS handshake. This works fine in a deployment model where one server maps to one provider org. Outside that model (one server hosting many provider orgs), somewhat obtuse and relatively unsupported techniques like Server Name Indication (SNI) are required to present the correct certificate. This isn't a problem for big organizations, but it is a problem for the small provider who may want or need to outsource this complexity to what is called a full-service HISP in Direct. A portion of this debate from last May may be found here: http://wiki.directproject.org/message/view/Security+and+Trust+Workgroup/23578139
Direct is also targeted at secure communication with patients (through PHRs or the like). If the only P.A.I.N. enforcement we can provide short or long term is down to the level of the hosting PHR organization (which could represent thousands or millions of patients), I (personally) don't believe that will go far enough.
In most Direct deployment models, one does not need to maintain certificates of trading partners locally. DNS is proving to be a viable, proven, and scalable mechanism for obtaining certificates. On a related note, TLS as described in this blog entry will, I'm certain, necessitate the use of client and server certificates in the handshake. This implies the need to, for example, extract the client certificate from the TLS handshake and ensure that the owning organization is allowed to communicate with the server. Operational folks often view TLS as simple because they only deal with server certificates in an e-commerce setting, which isn't adequate in this context.
The Direct pilots and reference implementation are attempting to show how S/MIME can be hidden from users and admins in a wide variety of deployment models. Let those activities run their course and see what we learn.
Here's the explanation as to why we went S/MIME. We wanted to stick with TLS. We really did.
ReplyDeletehttp://blog.directproject.org/2010/12/smime-and-tls.html
John,
ReplyDeleteGreat commentary on the Direct Project (nee NHIN Direct). I think that you should get in touch with Arien Malac so he can give you a good and sound overview for why S/MIME was agreed on for the initial implementation backbone protocol for the Direct Project and why the two reference implementations take the complexities out of the certificate management issues that have plagued S/MIME up until now.
As for TLS vs S/MIME - I see confusion here as well in your post and the comments. TLS is used primarily to secure the channel for communication, while using S/MIME encrypts the content and therefore some claims can be tested about the sender as well as knowing it is the intended recipient (or someone that has access to their private certificate).
Cheers,
John Theisen
(Disclaimer - I'm a contributor to the .NET reference implementation as is Arien Malac)
It's also worth noting that there are already a variety of free and open source libraries/toolkits for implementing TLS, allowing a commodity web server with Apache (also free and open source) to communicate securely with other servers.
ReplyDeleteUsing S/MIME, on the other hand, can be prohibitively expensive, as Brian points out.
In addition to being a technologically sound alternative, TLS would help keep the Total Cost of Ownership of an HIT system from spiraling out of control.
OK, a quick, non-rhetorical question:
ReplyDeleteWhat do banks use to exchange financial information?
While TLS seems to be an easy way to encrypt email it's not always easy if you want to do it correctly.
ReplyDeleteSome questions you might ask yourself when deploying TLS
TLS only protects the channel and not the message. Once the message is stored or forwarded over a non-TLS channel, the message is no longer encrypted. For example if the recipient uses Gmail, the message will be stored unencrypted on Gmail's servers.
Because only the channel is secured (and not the message) how can you be sure that the message was not modified in transit?
What to do if the receiving party does not support TLS? Bounce? Send unencrypted?
Some companies use a fallback SMTP server hosted by another party in case of problems. How can you be sure that the other party always uses TLS and that you can trust them not looking at the message after temporarily storing the message?
In order to prevent DNS hijacking and “man in the middle” attacks, the certificate of the SMTP server(s) should be checked for all PKI rules. This may sound easy but for most SMTP servers it's hard to actually manage this. What to do if the domain of the certificate does not match the domain of the SMTP server? What to do if the certificate is not issued by a CA you trust? What to do if the certificate is expired?
Does the SMTP server check the certificates for revocation (CRL)? Does the SMTP periodically download CRLs to make sure the CRLs are up-to-date?
Some recipients might host their SMTP server by others. You should therefore trust all the hosting providers your recipients are using (like Gmail, hotmail etc.) because the encryption will be removed when they receive the message.
Some of these problems can be solved with TLS but it's no longer as easy as some might think. Now does that mean that S/MIME will solve all these problems? No but managing an S/MIME gateway is not as hard as some might think it is. Cost effective S/MIME gateways are available (disclaimer: I am the author of an open source S/MIME gateway) and most of them allows you to setup an S/MIME tunnel that allows you to S/MIME encrypt all email sent to a domain with just one certificate. Using an S/MIME tunnel is easy to setup and has the benefits of TLS but also solves some of shortcomings of TLS.
Martijn Brinkers
How about the extent to which you enable user control and the ability for members of your organization to use the strong authentication (even single sign-on), digital signature, encryption and non-repudiation functions in their daily activities?
ReplyDeleteLooking at this as solely a means of dealing with data in motion really means that you will go back to the drawing board.
We spend a lot of time working in government and enterprise putting in place PKI to support a wide range of critical business requirements. It has become pretty common and growing consistently and for good reasons.
Even the registration authority step alone has significant value. (Ask Paul Contino at Mount Sinai about his smart card program). When viewed at the enterprise level the case can be compelling.
TLS requires elements of a PKI anyway so the comments about not needing to deal with a PKI is really a straddle. In most cases the PKI is provided as a service anyway. I would be happy to have a cup of coffee if you want to discuss, its a walk from here in Brookline.
Ragheed,
ReplyDeleteI think you would get a fresh perspective on the problems being addressed and how the solution space was constrained by re-reading Dr. Halamka's blog entry, going to see what Dixie had to say (which was prefer (SHOULD) or require (MUST)) S/MIME over TLS, go see what the robust set of documentation has to say about the Direct Project at directproject.org and finally reading the post that Arien made about the >why< we ended up settling on S/MIME for now.
S/MIME with structured data attached is a stepping stone on the path towards interoperability. The facts are there is no standard by which true and comprehensive interoperability are taking place today. Each vendor and institution brings their own needs, proprietary data and walled gardens into the mix. Attempting to distill the problem down to "oh this is just X" or "how do financial institutions do this?" is an unfair basis to being an argument. Banks have a rich history of interchanging data, but even with that it takes a LOT of effort to make that work seamlessly in the background. I've got a number of friends that have worked in that environment and while the data is extremely sensitive, the number and types of transactions is several orders of magnitude less than what we have to deal with in Healthcare.
As for S/MIME or web based protocols email is not dead, and there is a place for it. There is also a very valid place for XD* based solutions.
Read the sources and then form your opinion. Do keep in mind that the "Direct Project" has been in review and discussed robustly for many months now and many topics were controversial. Also keep in mind how many times that you as a developer have looked at bit of dated code and declared it "crap". Every developer (or problem solver) attempts to solve the problem with the knowledge they have at hand at the moment and this may not be with all of the wisdom and awareness of the constraints that the original writer of the code had.
Lastly, the "Direct Project" itself is an open source initiative that encourages participation. If you would like to shape the direction of the specification in the future the place to do it is by participating at that level. Writing on a commentary block here won't change things from TLS to S/MIME or switch it completely out to SOAP or XMPP for that matter ;)
John
It looks like the Standards Committee is running ahead of the Policy Committee and Meaningful Use. For Stage One of MU, there are no requirements for individual authentication. The proposals for Stage Two also do not include any requirements for individual authentication. Everything is "organization-to-organization", which is, basically, communication from one EHR system to another EHR system. So, why is the Standards Committee and NHIN Direct focused on S/MIME and individual authentication (signing)?
ReplyDeleteIf Verizon has their way (http://www.healthcareitnews.com/news/verizon-assist-health-info-exchange), medical provider will have digital certificates in the near future. As I work mostly in the e-prescribing world, where standards are far more mature than the EMR and HIS arenas, and where e-prescribing of controlled drugs are about to become a reality (although digital certificates are not yet required), I believe we'll see the use of digital certificates in 2011, and likely some use of end-to-end transmission in 2012 or 2013. That said, I believe there are issues with S/MIME both in e-prescribing and NHIN data transfer, such as knowing which pharmacist is available to receive the prescription when it is sent, or if a particular provider is on vacation. I suspect the 3rd parties who will be required in these PKI transactions (gee, it seemed so easy to eliminate the 3rd parties...) will have solutions to these and other issues, but I believe requiring S/MIME early is premature. Let it be tested in the more limited e-prescribing usage before requiring such a complex and expensive system for more extensive use.
ReplyDeleteCOI DIsclosure: I am Chief Medical Officer of DrFirst, Inc.
Peter N. Kaufman, MD
A solution based on TLS would only work through total isolation (virtual) of all NHIN Direct e-mail network from any other. This would seem like a good thing, but would kill any advantage the NHIN Direct solution gains by using off-the-shelf technology and infrastructure (commercial or open-source). This total isolation could only be done through total trust in all who would ever communicate through this trusted network fabric. Any hole in the fabric would expose everything.
ReplyDeleteA secure network like this would require a central administration, and much legal trust. A secure network that supports asynchronous trust conversations end-to-end is far more robust and can scale both large and most importantly small.
http://healthcaresecprivacy.blogspot.com/2010/12/smime-vs-tls-two-great-solutions-for.html