Timeline for answer to Clarifying BitLocker Full Disk Encryption and the role of TPM by Ja1024
Current License: CC BY-SA 4.0
Post Revisions
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 30, 2024 at 16:20 | comment | added | Ja1024 |
@allexj: Yes, the sensitive area of the key created with tpm2_createprimary stays within the TPM and is never exposed to the outside world. The sealed data ("testpw") does get exposed when unsealing it with tpm2_unseal.
|
|
| Dec 30, 2024 at 15:37 | comment | added | allexj |
Just to clarify, when I run the command echo "testpw" | tpm2_create -g sha256 -u seal.pub -r seal.priv -i- -C prim.ctx, which part of the private key is never exposed? Is it the prim.ctx? I don’t think it’s the seal.priv, because from what I understand, it contains the encrypted form of "testpw", which would be revealed as plaintext when unsealed, exposing "testpw" to the OS. So, I assume when we say that "the sensitive portion of a key is never released outside of the TPM2 device," we are referring to the primary key (prim.ctx) used to encrypt the sealed object, right?
|
|
| Dec 30, 2024 at 15:19 | comment | added | Ja1024 | @allexj: The text talks about the (private) key inside the TPM which decrypts the VMK, not the VMK itself. The VMK is eventually decrypted and provided to the OS as plaintext, but the key used by the TPM for this purpose stays within the TPM and is never exposed. | |
| Dec 30, 2024 at 15:09 | comment | added | allexj | thanks you, really... what I don't get though is that I continue to read that "The sensitive portion of a key is never released outside of the TPM2 device"... but how is this possible? I think tpm MUST release the VMK to the OS in order to allow OS to decrypt the FVEK.... so what am I getting wrong? | |
| Dec 29, 2024 at 16:49 | comment | added | Ja1024 | @allexj: Correct. A TPM in conjunction with Secure Boot helps against malicious bootloaders and kernel rootkits (but not other malware). In principle, TPM 2.0 supports arbitrarily complex policies, so it could do a lot more to protect the VMK, e.g., require the user to prove ownership of a separate key (ideally stored on a smartcard or some other hardware token). But I don’t believe there are any plans for implementing this in BitLocker. | |
| Dec 29, 2024 at 15:30 | comment | added | allexj | thanks..... 2.1) so tpm improvement in protection is not for a thief who steals your laptop (since both cases with-tpm and without-tpm he can just bruteforce the user password) but it's a protection for a tampering for example of the kernel (so against rootkit, but please tell me if there are any other attacks that come into your mind)... | |
| Dec 29, 2024 at 15:25 | comment | added | Ja1024 | @allexj: 2.1) If the key is protected with both a TPM and a password, then, yes, an attacker with physical access only has to brute-force the password. 2.2) Correct, the VMK can only be decrypted after you’ve passed all checks of all key protectors. In your case, you have a TPM and a PIN, so the VMK isn’t available until both the Secure Boot verification was successful and you’ve entered the correct pin. | |
| Dec 29, 2024 at 15:01 | comment | added | allexj | 2.1) so this method forces attacker to be in THAT specific machine since the sealing "binds" with certain tpm unique characteristics and also with specific pcrs. but ok let's imagine the attacker has the victim machine, he now can bruteforce with a dictionary the password (not the 256 bit key but the human entered password at boot), right? so in this case what is the advantage compared to non-tpm? 2.2)also, when is the vmk loaded in ram? in my windows, I am not asked for disk password, it only prompts for user login pin, so I hope vmk is not loaded UNTIL I correctly enter pin, right? | |
| Dec 29, 2024 at 14:38 | comment | added | Ja1024 | @allexj: 1) Secure Boot in the context of BitLocker prevents the key(s) from being exposed to kernel-level rootkits. If the kernel has been manipulated, the TPM can detect that its signature no longer matches the known signature from Microsoft. Userspace programs are not covered by Secure Boot, so this only protects against particular malware. 2) Brute-forcing a 256-bit key is hopeless, so if the VMK is protected with a TPM, then an attacker cannot simply remove the disk from the system. They would either have to be physically present or attack the system after it has been unlocked. | |
| Dec 29, 2024 at 14:13 | comment | added | allexj | 1)TPM ensures the disk can only be decrypted on the same machine, preventing booting from a tampered system. If the machine is compromised (e.g., by password-logging malware), TPM detects changes in the PCR values (assuming malware "is in that pcrs") and prevents unsealing the VMK. Can you tell me any realistic attacks this mechanism prevents? 2)However, this security only applies if the attacker is attempting to compromise the machine from within. If the attacker removes the drive and analyzes it offline, in both the TPM and non-TPM cases, he would still need to brute-force the VMK, right? | |
| Dec 29, 2024 at 13:25 | history | answered | Ja1024 | CC BY-SA 4.0 |