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?
No comments:
Post a Comment