Beginning earlier in October, word began to spread regarding a new vulnerability caused by weak encryption passwords handed out by Infineon TPM (Trusted Platform Module) chips, the embedded technology responsible for creating the keys for encryption by tools like Microsoft BitLocker. Given the source of the problem and the number of industry participants involved, our opinion is that communication and remediation plans are being handled and presented extremely well by Infineon, the various hardware vendors, and Microsoft.
How severe is the impact?
Even though there are known exploits to this vulnerability, they are currently very computationally expensive to execute, taking an estimate of 140.8 CPU-years to break a single key. At the current point in time, it means TPM-generated RSA keys can’t be broken at large scale, but targeted attacks are possible. So, although there exists a practical attack against TPM-generated RSA keys, it doesn’t allow large-scale exploitation of affected systems. Therefore, the effective impact of this vulnerability is fairly low.
Note: The source describes the impact on Chrome and Chromebook devices; other TPM-based devices will behave in a similar manner.
How does it work?
There are basically two layers to this vulnerability:
1. Affected TPM versions generate insecure encryption/decryption keys, and need to be patched with firmware updates.
2. Even if the TPM firmware is updated, insecure keys that were generated by affected TPMs before they were patched need to be cleared and regenerated.
On the surface, that sounds horrible, and can result in a ton of remediation work. Fortunately, there are mitigating factors that mean that the vast majority of our clients’ systems are unaffected by this vulnerability.
What are the mitigating factors?
1. Virtual Machines are not directly affected. VMWare hosts do not virtualize or expose any hardware TPM functionality to the guest, so the guest OSes of any version always generate keys in software, using secure algorithms different from those used by an affected TPM. Guests simply report “TPM not found”.
2. Further, it doesn’t look like ANY of our reporting servers are TPM-aware.
3. The vast majority of the endpoints leveraged by our clients are still running Windows 7. Windows 7 does not leverage TPM functionality for ANY operating system service other than BitLocker. Even though we should probably eventually flash the TPM firmware anyway, there is no threat that any keys used by an endpoint were issued from an affected TPM (except if BitLocker is in use).
What work is left?
We recommend flashing firmware and re-encrypting devices that were encrypted with BitLocker (or any other TPM-leveraging encryption scheme), particularly for those clients in regulated industries, like banks, credit unions, health care, financial services, and similar. All have the option of proactively addressing this vulnerability, or choosing to be reactive and addressing should the vulnerability be picked up on a subsequent audit. To schedule Innovative to remmediate, contact us today.
For more information from Microsoft on the issue, this KB article is pretty comprehensive: https://support.microsoft.com/en-us/help/4046783
For those that just love reading relevant stuff from the Security Guidance article, you will want to read all of these:
AD Certificate Services: https://support.microsoft.com/en-us/help/4047409
AD Directory Services: https://support.microsoft.com/en-us/help/4046462
Virtual Smart Card: https://support.microsoft.com/en-us/help/4046784
Windows Hello for Business and Azure Active Directory: https://support.microsoft.com/en-us/help/4046168
Server 2016 Domain-Joined Device with Public Keys: https://docs.microsoft.com/en-us/windows-server/security/kerberos/domain-joined-device-public-key-authentication