tag:blogger.com,1999:blog-4384692836709903146.post5366886528640633153..comments2024-03-27T09:55:23.143-07:00Comments on Dispatch from the Digital Health Frontier: Simple, Direct, Scalable, and Secure Transport - S/MIME verses TLSJohn Halamkahttp://www.blogger.com/profile/04550236129132159307noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-4384692836709903146.post-31646469358358500972010-12-23T21:12:10.247-08:002010-12-23T21:12:10.247-08:00A solution based on TLS would only work through to...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. <br /><br />A 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.<br /><br />http://healthcaresecprivacy.blogspot.com/2010/12/smime-vs-tls-two-great-solutions-for.htmlJohn Moehrkehttps://www.blogger.com/profile/04526719420117446030noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-31182993584661324702010-12-23T21:03:54.562-08:002010-12-23T21:03:54.562-08:00If Verizon has their way (http://www.healthcareitn...If 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.<br /><br />COI DIsclosure: I am Chief Medical Officer of DrFirst, Inc.<br />Peter N. Kaufman, MDPeterhttps://www.blogger.com/profile/11744836379515259811noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-76556734826299613182010-12-23T13:49:56.036-08:002010-12-23T13:49:56.036-08:00It looks like the Standards Committee is running a...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)?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-90405061468162670382010-12-23T13:44:56.648-08:002010-12-23T13:44:56.648-08:00Ragheed,
I think you would get a fresh perspectiv...Ragheed,<br /><br />I 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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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 ;)<br /><br />JohnAnonymoushttps://www.blogger.com/profile/01805029619319986824noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-23754192233852819442010-12-23T05:10:35.713-08:002010-12-23T05:10:35.713-08:00How about the extent to which you enable user cont...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? <br /><br />Looking at this as solely a means of dealing with data in motion really means that you will go back to the drawing board. <br /><br />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. <br /><br />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. <br /><br />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.Anonymoushttps://www.blogger.com/profile/01774758098197773280noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-12375456455519232502010-12-23T01:13:24.426-08:002010-12-23T01:13:24.426-08:00While TLS seems to be an easy way to encrypt email...While TLS seems to be an easy way to encrypt email it's not always easy if you want to do it correctly. <br /><br />Some questions you might ask yourself when deploying TLS<br /><br />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.<br />Because only the channel is secured (and not the message) how can you be sure that the message was not modified in transit?<br />What to do if the receiving party does not support TLS? Bounce? Send unencrypted?<br />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?<br />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?<br />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? <br />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.<br /><br />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. <br /><br />Martijn BrinkersMartijn Brinkershttp://www.djigzo.comnoreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-89606208022437253362010-12-22T21:19:46.419-08:002010-12-22T21:19:46.419-08:00OK, a quick, non-rhetorical question:
What do ban...OK, a quick, non-rhetorical question:<br /><br />What do banks use to exchange financial information?Ragheedhttps://www.blogger.com/profile/14094714966299726648noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-20899099745708392942010-12-22T15:15:28.446-08:002010-12-22T15:15:28.446-08:00It's also worth noting that there are already ...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.<br /><br />Using S/MIME, on the other hand, can be prohibitively expensive, as Brian points out.<br /><br />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.Ragheedhttps://www.blogger.com/profile/14094714966299726648noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-9671694194915082452010-12-22T15:11:42.133-08:002010-12-22T15:11:42.133-08:00John,
Great commentary on the Direct Project (nee...John,<br /><br />Great 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.<br /><br />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).<br /><br />Cheers,<br />John Theisen<br /><br />(Disclaimer - I'm a contributor to the .NET reference implementation as is Arien Malac)Anonymoushttps://www.blogger.com/profile/01805029619319986824noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-58381567218062092012010-12-22T15:01:20.300-08:002010-12-22T15:01:20.300-08:00Here's the explanation as to why we went S/MIM...Here's the explanation as to why we went S/MIME. We wanted to stick with TLS. We really did.<br /><br />http://blog.directproject.org/2010/12/smime-and-tls.htmlAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-46591890290217204452010-12-22T13:43:31.031-08:002010-12-22T13:43:31.031-08:00Payload-based (S/MIME) privacy, authentication, in...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.<br /><br />Using 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<br /><br />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.<br /><br />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.<br /><br />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.Unknownhttps://www.blogger.com/profile/06888858343833487183noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-18852269400861191312010-12-22T13:23:43.460-08:002010-12-22T13:23:43.460-08:00I'm a developer working on an (as yet unannoun...I'm a developer working on an (as yet unannounced) HIT application, and I suggest using TLS exclusively.<br /><br />MIME 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.<br /><br />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).<br /><br />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.Ragheedhttps://www.blogger.com/profile/14094714966299726648noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-12470533173328021232010-12-22T12:16:44.357-08:002010-12-22T12:16:44.357-08:00While in theory S/MIME sounds easier, you underest...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.<br /><br />This 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.<br /><br />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).<br /><br />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.Brian Alexander Leehttps://www.blogger.com/profile/04154356447489829768noreply@blogger.com