1

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.

11
  • If you reference in your question that you read something somewhere, it's beneficial to include that source. It may be that this is an untrustworthy source, or the source may include an explanation already. – MechMK1 Jun 2 '20 at 19:57
  • @MechMK1It is written everywhere, from Microsoft presentations to stackexchange answers. – J. Doe Jun 2 '20 at 20:04
  • I suggest to clarify what "key" you mean and where it is stored, and to read this brief explanation by Microsoft. – studio2012 Jun 2 '20 at 20:12
  • 1
    channel9.msdn.com/Events/TechEd/NorthAmerica/2014/… 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 2 '20 at 20:24
  • 1
    @J.Doe Yes, I already saw it in the comments. Thank you for linking it again. It was merely a suggestion on how to improve further questions of yours. – MechMK1 Jun 3 '20 at 13:05
1
+100

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.