2

I have read here that if you choose TPM + PIN protection the PIN does not become part of the key, it is simply used by the TPM as an additional security measure. It doesn't make sense to me, it would have been much safer and much easier to implement by encrypting the key stored in the TPM with the hash of the PIN. Since the TPM is only a physical solution, attacks have been made against it and the fact that it is protected by a PIN or not is irrelevant. While with the implementation I said before, which is apparently the most logical (correct me if I'm wrong), there is a protection based on mathematics plus TPM help for keyloggers and rootkits. So why was this choice made?

Are there alternatives to bitlocker that use the method described by me? I have seen that LUKS and veracrypt still have very limited support for the chip, therefore still far from using the PIN at the same time.

J. Doe
  • 65
  • 1
  • 10
  • I suggest to clarify what "key" you mean and where it is stored, and to read [this brief explanation by Microsoft](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-countermeasures#pre-boot-authentication). – Enos D'Andrea Jun 02 '20 at 20:12
  • @EnosD'Andrea With key I mean the key stored into the TPM required to decrypt the drive. – J. Doe Jun 02 '20 at 20:18
  • 1
    https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/WIN-B314#fbid= here is said that with PIN it is performed a simple check opposed to USB key where a part of the master key is in the USB, so it is impossible to decrypt the drive without the USB, even if you break the TPM. – J. Doe Jun 02 '20 at 20:24
  • @J.Doe there is no reference to the USB startup key in your question. – Enos D'Andrea Jun 02 '20 at 20:47

1 Answers1

2

There's no known reason other than Microsoft just not deeming it necessary. A common theme in cryptographic design is to keep the system as simple as possible, to avoid problems later on.

If they'd have added a scheme to combine the PIN and the TPM key, they'd need to come up with a way to combine those keys. That likely means something like hashing the two values together, or using a HMAC. If that scheme was later discovered to use a primitive (e.g. hash algorithm) that was insecure, that's a problem. They'd likely have included a way to indicate which algorithm was used, for future-proofing, but that's more code, which means more attack surface, which means more validation and testing and potential issues in the future.

It's also more complex for situations where the disk is unlocked by something other than a PIN, such as a smart card. There needs to be additional consideration as to whether the same scheme can be used there, or whether there needs to be even more code and a different cryptographic approach for that scenario.

In this case it's absolutely reasonable to argue that the additional cryptographic functionality and code is worth it. Hinging the security of your FDE solution solely on the security of the TPM does not seem like a particularly good move in the face of modern attacks on TPMs and Intel CSME (which implements the fTPM). However, when BitLocker was initially conceived, these attacks were purely theorised, so it's also easy to see how Microsoft made the choice that they did.

I definitely agree with your concerns, and I have argued before that the next version of BitLocker should utilise the PIN itself as part of the header key derivation, in order to at least partially mitigate the threat of TPM attacks.

Polynomial
  • 132,208
  • 43
  • 298
  • 379