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.

4
  • I suggest to clarify what "key" you mean and where it is stored, and to read this brief explanation by Microsoft. Commented Jun 2, 2020 at 20:12
  • @EnosD'Andrea With key I mean the key stored into the TPM required to decrypt the drive.
    – J. Doe
    Commented Jun 2, 2020 at 20:18
  • 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
    Commented Jun 2, 2020 at 20:24
  • @J.Doe there is no reference to the USB startup key in your question. Commented Jun 2, 2020 at 20:47

2 Answers 2

3
+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.

2

I think it's because they decided to use the TPM to validate the PIN so that it could also enforce the maximum permitted number of invalid attempts. But to get optimal security they should have used the PIN also in the volume key derivation process. Maybe it seemed dirty, illogical or wrong to them to use the PIN value twice and that's why it wasn't done.

Elaboration: In itself it is a useful strengthening of security compared to PIN alone, because with PIN alone it is possible to carry out a brute-force attack just knowing the first sectors of the disk, so the end-user password has to be able to withstand such an attack (most aren't). By letting the TPM validate it, the attacker has a limited number of attempts - as long as the "TPM is secure" assumption is valid. If the attacker breaks open the TPM of course he could again get an unlimited number of attempts (by extracting whatever the TPM is using to validate). However, I agree the PIN should also have been used to derive the key apart from its role in unlocking the TPM. Ideally, the TPM would have contained a hash or similar of the PIN (something like H("VERIFIER" || PIN)) and used that to validate and maintain the counter. In case of success the TPM releases a key K that Bitlocker software would then combine with the PIN - something like VK := H("VOLUMEKEY" || PIN || K) which then encrypts the actual data (of course with suitable extra layers to handle multiple 'protectors' etc.). In this setup, even if the attacker breaks open the TPM he only gets H("VERIFIER" || PIN) and K which cannot be immediately used to derive VK. He can still attempt to brute-force the PIN using this value but it is no worse than if no TPM had been used at all because the disk must contain some information used to validate the PIN in that case.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .