I’ve been reviewing the outputs of the Security and Privacy (and Infrastructure) workgroup of the HIT Standards Committee for the past couple of weeks. Like many of you, I’m trying to decypher the ramifications for EHR users and implementors. I’ve been told that the basis for many of the standards recommendations on these sheets have been established on the basis of industry readiness. However, their recommendation for SHA-2 is a departure from this critieria.
The basis for that particular recommendation is due to Federal Agency requirements set forth by the National Institute of Standards and Testing. The policy established by NIST in March of 2006 results from research showing weaknesses in the SHA-1 algorithms. You can see the NIST policy statement here but I’ve also reproduced it below.
March 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms. Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010. After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols.
An intersting post from Xuelei Fan seems to indicate that the NIST guidance could be followed by an acceptable profile of TLS 1.0. I haven't done enough review of his assertions to determine if I agree with his recommendations or not, but they seem to reasonably thought out. Others have indicated that the deprecation of SHA-1 would eliminate TLS 1.0 for consideration as a protocol for securing communication channels, and would require support for TLS 1.2.
Implementation of security protocols is best left to experts, and unfortunately, the experts are a bit behind in supporting TLS 1.2 on many fronts. There are at least five key areas to consider:
1. Operating System Support
2. Programming Language Environment Support
3. Web Server Support
4. Browser Support
5. Communication Library Support
Operating System Support
Of the most common operating systems, only the Microsoft Windows OS provides cryptography support in the OS as far as I can tell. The most recent versions of Windows (Windows 7 and 2008 Server) support TLS 1.2 in SCHANNEL, the crypto library that ships with the OS. This accounts for less than 3% of the Windows OS deployment according to some sources (approximately 75% of Windows users are still on XP according to those same sources).
However, this support does not appear to be enabled by default, which creates some challenges. See http://forums.iis.net/t/1155254.aspx.
Programming Language Environment Support
Support for TLS 1.1 or 1.2 is not present in the most recent versions of Java or .Net, two of the most common platforms for application development. TLS 1.0 support is present in both the .Net and Java libraries.
Web and Application Servers
The only Web Server I’ve been able to find that supports TLS 1.2 natively is Microsoft’s IIS 7.5 or later, and only if deployed on a Windows OS supporting TLS 1.2. Application server support is essential if TLS 1.2 is to be used to deploy secure web services (using either REST or SOAP).
Communication Libraries
In the past, we’ve seen communication libraries as being a workaround that would enable application developers to use existing socket implementations and act as a gateway to secure communications. However, I’ve only found two libraries GNU TLS 2.8 and Yassl that support TLS 1.2. Even Open SSL doesn’t support TLS 1.2 yet.
Browser Support
What if you are using a thin client? Well, unless your thin client is using Opera 10, or Internet Explorer 8, you won’t see support for TLS 1.2. I have no clue whether the thin clients on smart phones support TLS 1.2, but given the dearth of support on the bigger platforms, I suspect smart phone support for TLS 1.2 is just simply not going to be there.
Commercial Support
Commercial support for TLS 1.2 is available for some web/application servers and programming languages, but presently this support only appears to be readily available from one vendor (that vendor by the way, also happens to hold the patents on some of the encryption used for SECRET and TOP SECRET classified information).
As a result of this review, I find myself extremely concerned about how the HIT Standards committee recommendation for SHA-2 would be implemented by the industry. Basically, users of HIT Software would need to upgrade to new operating systems or platforms, or purchase additional software or hardware to meet some of these requirements. I realize that our government partners already need to do so because of the NIST recommendation, but in some ways, this appears to be the tail wagging the dog.
No comments:
Post a Comment