Swinging the Compliance Hammer at Obsolete Crypto

13 Nov 2018

Abstract

Many applications still utilize older cryptographic technologies, even though security professionals warned that these are obsolete and unsafe to use. Some implementations can easily be upgraded to current encryption and contain a graceful fall-back for situations where it’s required, such as when a remote party only supports legacy technologies (e.g., TLS downgraded connections). Other situations are more difficult and require dual-implementation paths for the upgrades over time (e.g., password hashes moving from MD5 to SHA-512). Unfortunately, even with decades of dire warnings about hacks and attacks, companies often won’t invest in upgrades due to other priorities. How does an infosec professional force the issue? We are suggesting the use of regulatory and compliance mandates to drive the improvement.

In this whitepaper, we show how TLS v1.0, MD5, SHA-1, and others violate federal regulations and various industry compliance rules. Legislation like the Health Insurance Portability and Accountability Act (HIPAA) does not explicitly state “MD5 is bad”, instead they tend to reference other guidelines, rules, laws, or standards that require you to follow the trail of breadcrumbs to figure out if you’re actually in compliance. We connect the dots and explicitly show that legacy cryptographic technologies do not meet the requirements. Armed with this information, it is far easier to build a case that management must accept and address.

This article was co-written by Josh Barons and Jay Ball.

Summarization

Though we go into intricate detail below, this tl;dr decision table documents what standards and requirement frameworks allow which types of cryptography.

  SSL TLS v1.0 TLS v1.1 TLS v1.2 TLS v1.3 MD5 SHA-1 SHA-224
SHA-512/224
SHA3-224
HIPAA forbidden end user: optional
app-to-app: forbidden		 pre-mid-2019: optional
after: same as TLS 1.0		 required pre-2024: optional
after: required		 no no pre-2031: maybe
after: no
HITRUST
   v9.1		 forbidden forbidden allowed allowed allowed no no no advice
PCI-DSS
   v3.1		 forbidden forbidden required strongly
encouraged		 no advice no no no advice
GDPR forbidden forbidden forbidden required recommended no no allowed
Germany nein nein nein required recommended nein nein nein

HIPAA

Most compliance requirements reference other standards or documents in a mathematically transitive manner. Sometimes the references are not as clear cut as we’d like them to be. For example, HIPAA says “follow the guidance by NIST” but that NIST document says “Government systems must do xyz.” Does this mean that your HIPAA system needs to only follow NIST if you send medical information to the feds or some other government agency? No; it simply means that a HIPAA system must follow the same guidelines as if it were a government system.

According to this document published in 2013 by U.S. Department of Health & Human Services:

Valid encryption processes for data in motion are those which comply, as appropriate, with NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; 800-77, Guide to IPsec VPNs; or 800-113, Guide to SSL VPNs, or others which are Federal Information Processing Standards (FIPS) 140-2 validated.

In NIST 800-52 rev1, page vi states:

While SSL 3.0 is the most secure of the SSL protocol versions, it is not approved for use in the protection of Federal information because it relies in part on the use of cryptographic algorithms that are not Approved. TLS versions 1.1 and 1.2 are approved for the protection of Federal information, when properly configured. TLS version 1.0 is approved only when it is required for interoperability with non-government systems and is configured according to these guidelines.

From the above, HIPAA systems must support TLS v1.1 or v1.2. SSL is forbidden and TLS v1.0 is allowed with specific configurations and in very limited circumstances.

Other organizations, such as LuxSci, have different interpretations on what is absolutely required, but they encourage TLS v1.2. Primarily, the interpretations revolve around non-governmental interoperability and lowering the security requirements. We feel this is not correct as a higher-level regulation like HIPAA applies to everyone. Thus, if your HIPAA system is talking to any other HIPAA system you must follow NIST completely.

As such, server-to-server applications dealing with Protected Health Information (PHI) must transmit data following NIST standards. Server-to-application transmissions, like from your company’s infrastructure to a mobile health app must also follow these rules. Server-to-browser, however, is a different story. If the remote machine is a doctor’s office, the doctor’s machine should be HIPAA compliant anyway and thus connections must follow NIST. However, an end user patient does not necessarily have a HIPAA-compliant computer as their personal device. As such, this is where the “non-governmental interoperability” clause comes in and the necessity to support some outdated and legacy technologies.

Some of these TLS requirements will change when the final version of NIST 800-52 rev2 is published in mid-2019. TLS v1.3 will become required and TLS v1.1 will move down to the “non-governmental interoperability” list (see page iv of draft 2). Ergo, HIPAA systems must use TLS v1.2 or newer but may allow TLS v1.0 and v1.1 for end user browsers as discussed on page 8 of the draft of NIST 800-52 rev2.

As for allowed ciphers, our friends at LuxSci did an awesome job of consolidating this list. If we consider NIST 800-52 rev1 plus 2017 NIST action advisory, the allowed list is:

CDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:AES256-SHA:AES128-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:DHE-DSS-AES256-SHA256:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:DHE-DSS-AES128-SHA:DH-DSS-AES256-GCM-SHA384:DH-DSS-AES128-GCM-SHA256:DH-DSS-AES256-SHA256:DH-DSS-AES128-SHA256:DH-DSS-AES256-SHA:DH-DSS-AES128-SHA:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-ECDSA-AES256-SHA384:ECDH-ECDSA-AES128-SHA256:ECDH-ECDSA-AES256-SHA:ECDH-ECDSA-AES128-SHA

Notice that the list of ciphers does not contain 3DES and RC4 – thus connections are effectively not allowed from Window XP systems (which should have been upgraded long ago).

But, when the final versions of NIST 800-52 rev2 is published in mid-2019, the allowed cipher list shrinks once more and will probably become:

TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:TLS13-AES-128-CCM-8-SHA256:TLS13-AES-128-CCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES256-CCM8:DHE-RSA-AES128-CCM8:DHE-RSA-AES256-CCM:DHE-RSA-AES128-CCM:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA

Most would consider the above discussion on TLS and ciphers to be the realm of browsers, web servers, REST endpoints, and all things HTTP. However, the Internet operates using many other protocols and all must be compliant as above. This includes email which encompasses SMTP, IMAP, POP, and more. But the Internet is full of many other types of services and protocols – all must meet the requirements discussed here.

If an email with PHI must be transmitted, then the SMTP machine sending the message must not permit connections to mail servers which do not allow for secured connections using TLS v1.2 (as above).. A company which allows users to retrieve email to their desktops must lockdown their IMAP servers. However, as SMTP allows for “store and forwarding”, the originator has no control if downstream connections are encrypted at all. Thus, it is best not to send PHI data via email, unless the PHI is further protected in a manner consistent with HIPAA requirements

Yet, many popular email solutions, like Google’s Gsuite, allow some unfortunate cipher choices, such as DES-CBC3-SHA which is not allowed by NIST 800-52 rev1, but happens to be supported by Windows XP (again with the XP, which happens to be common in the medical industry).

The HIPAA requirements above also make reference to Federal Information Processing Standards (FIPS) 140-2 approved standards, which includes a list of Security Requirements for Cryptographic modules. MD5 is not listed as an approved technology in the document and thus cannot be used in a HIPAA-compliant system.

SHA-1 is mentioned in FIPS 140-2 as approved and the algorithm is defined by FIPS 180-4. But, in Appendix A of FIPS 180-4, it says to reference NIST 800-107 for updates on the effective security of SHA-1. Section 4.2 of NIST 800-107 states “The latest cryptanalytic results for SHA-1 indicate that it may have a collision resistance strength that is considerably less than its expected strength of 80 bits.” On page 7, NIST 800-107 rev1 says “The security strengths of the approved hash functions for different applications can be found in SP 800-57 part 1.

On page 54 of NIST 800-57 part 1 rev4, SHA-1 is shown as less than 80 bits of effective security and is highlighted in orange which indicates it is “no longer approved for applying cryptographic protection”. Moving forward to page 55, Table 4 says that using algorithms of less than 112 bits is disallowed, thus SHA-1 is not allowed.

However, there is a small exception for processing legacy ciphertext data, like SHA-1, in certain situations. It is allowed to validate something already hashed via SHA-1; but, when the hash is being computed, it must be updated to a more secure algorithm. As an example, if the system uses some form of SHA-1 password hashing, the password can be validated but then must be updated to an approved algorithm.

To prepare for the 2031 deprecation of SHA-224, SHA-512/224, and SHA3-224, it is wise to simply avoid those algorithms completely. As the hashes may protect data with a shelf life of say, seven years, then you must cease using these hashes before 2024. It would be an easier effort to simply move to something stronger now. The implementation difference between SHA-224 and SHA-256 is trivial and computational difference is negligible. However, the migration efforts would be great, ergo abstinence is the best choice for these three algorithms.

HITRUST

Health Information Trust Alliance or HITRUST established a Common Security Framework (CSF) which contains section v9.1 Control 09.s regarding Information Exchange Policies and Procedures. This details many relevant processing mechanisms and technologies used. In particular, it says:

Valid encryption processes include:
1. Transport Layer Security (TLS) 1.1 or later

Which specifically excludes the older SSL and TLS v1.0 algorithms. It also says “See NIST SP800-52 Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementation”, which is the same technical definition as HIPAA.

There is no explicit advice on hashes, except for:

When using electronic communication applications or systems for information exchange, the following items shall be addressed:
…
5. the required use of cryptographic techniques to protect the confidentiality, integrity and authenticity of covered information;

As weak hashes can be reversed, the authenticity and integrity of the data protected with MD5 or SHA-1 is suspect. Thus, neither algorithm is permitted.

PCI-DSS

The Payment Card Industry Data Security Standards Council stipulated in PCI-DSS v3.1 that SSL and TLS v1.0 were to no longer be supported by 30 June 2016 but later pushed this date to 30 June 2018. Systems must use TLS v1.1, but TLS v1.2 or newer is highly recommended. Support for TLS v1.1 became required in June 2018. There is further text noting that any TLS v1.1 implementation must remove many types of ciphers, such as weak ones like DES. This requirement can be met by following the same cipher requirements shown in the latest revision of NIST 800-52.

Note that there is a very narrow exception carved out to use weak encryption for some Point of Sale (POS) terminals on closed networks, but this loophole does not apply to any browser-based or most PC-based technologies.

Starting in February 2018, weak ciphers or unapproved algorithms, like MD5 and SHA-1, were no longer allowed.

GDPR / EU / Germany

The European Union’s General Data Protection Regulation (GDPR) directive generally doesn’t state “use this version of TLS”, but it does require strong cryptography in chapter 2, article 5:

Principles relating to processing of personal data
(1) Personal data shall be: …
f) processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’).

As technologies such as MD5, SHA1, TLS v1.0 and TLS v1.1 are known to be broken and cannot ensure confidentiality or integrity, they cannot be used. Additionally, the German Bundesamt für Sicherheit in der Informationstechnik (BSI) (Federal Office for Information Security) says only TLS v1.2 or newer should be used according to BSI TR 02102-2 (English version) in section 3.2. Since EU GDPR requires encryption via up-to-date technology, this infers that only TLS 1.2 or newer is acceptable. BSI TR 02102-2 goes deeper in allowed ciphers, but these are similar to NIST and not discussed in this whitepaper.

Another document, BSI TR 02102-1 (English version) states, “die folgenden Hashfunktionen als kryptographisch stark” (auf english: “the following hash functions are considered to be cryptographically strong”) SHA-256, SHA-512/256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512” on page 39 (auf english: 37). Page 40 (38) explicitly says SHA-1 “definitiv nicht mehr eingesetzt werden” (should “no longer be used”).

The BSI documents dictates that SHA-224 (and the similar strength SHA-512/224 and SHA3-224) are legacy. These algorithms will not be considered secure in 2023 and there are no advantages of using them over SHA-256, SHA-512/256, or SHA3-256. This is similar logic to NIST’s hesitation on these algorithms, but with a more paranoid expiration date.

Under GDPR regulations, if your company suffers a breach, you must prove that there was strong protection in place to protect the data or suffer greater penalties. Trying to convince an EU Data Protection Authority officer that TLS v1.0 is adequate after 15 years of dire warnings from security experts simply will not work.

Generally, meeting the well defined and more secure technical requirements of the German BSI should be sufficient to cover your organization for GDPR with respect to hashes, ciphers, and transmission algorithms.

Conclusions

Knowing when something is insecure and should be fixed can be easy; the ability to translate the vulnerability into a compliance violation can be difficult. The analyses shown in this whitepaper were created to help equip the infosec community with leverage to assist in getting issues corrected promptly. Sometimes management does not understand the underlying technical aspects, but if an argument is paired with how something is not compliant with existing government requirements, then issues are more likely to be addressed.

The authors have worked at and with different companies over the years and dealt with each of the regulations discussed. We hope that you can use our experiences to assist your team and company on your journey to become more secure.

Random Research Notes

The following links were referenced in the construction of this whitepaper:

Masthead Credit: Dennis van Zuijlekom from his photo stream // License: Creative Commons Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0) // Edits by Jay Ball under same license.

About The Authors

This blog post was co-written by Josh Barons and Jay Ball and co-published on Jay’s blogs at veggiespam.com; it will be mirrored to Josh’s blog in the future. Both Josh and Jay are #infosec professionals who protect companies, networks, and applications from both technical and regulatory aspects at a hip startup in SoHo. Both participate in local infosec organizations such as OWASP, 2600, HackNYC, and more. You can DM Josh on Linked-In, DM Jay on Linked-In or Twitter @veggiespam, or reach either via appropriate email.

Original post by veggiespam - check out veggiespam