4 ms·

> using a fTPM would solve the problem. All TPMs support encrypted sessions to prevent these kind of MITM attacks. You use TPM2_StartAuthSession and specify en

by als0 3y ago

> using a fTPM would solve the problem. All TPMs support encrypted sessions to prevent these kind of MITM attacks. You use TPM2_StartAuthSession and specify encryption with each session command. But Bitlocker doesn't use one, which is epic fail. Microsoft need to fix it. Edit: For comparison, systemd uses encrypted sessions when using LUKS disk encryption with the TPM https://github.com/systemd/systemd/commit/acbb504eaf1be51572b1c0d0d490ac478bc41c64 https://github.com/systemd/systemd/commit/acbb504eaf1be51572...

comex 3y ago
This isn’t even a proper MitM attack, just passive sniffing. But, I ask as someone unfamiliar with TPM, how do authenticated sessions work? How does the OS prove its identity to the TPM in a way an attacker couldn’t spoof in a real MitM attack? Any secrets or keys stored by the OS side would have to reside unencrypted on disk, since it doesn’t have an encryption key yet. Or even if the OS verifies the TPM’s identity somehow, even if this is done in a way that it can’t be worked around just by modifying some files on disk, what stops the attacker from running the same routine in an emulator? I don’t see how you get real security from this approach unless there’s some integration with Intel ME or SGX or other CPU-side ‘secure’ environments, but then you wouldn’t need the TPM to start with.
- Vogtinator 3y ago
  Agreed. I don't see a way this can be done without one side trusting the other implicitly. If the sniffer/MitM gets either the measured data (to replay) or the unsealed key (to use directly) it's game over. > I don’t see how you get real security from this approach unless there’s some integration with Intel ME or SGX or other CPU-side ‘secure’ environments, but then you wouldn’t need the TPM to start with. fTPMs are basically implemented within (or closely working together with) Intel ME reps. AMD PSP.
- mjg59 3y ago
  "Authentication" here is something of a misnomer - it's setting up an encrypted session without any proof of identity. In that form it's sufficient to block passive sniffing and require an active MITM instead. The TPM's side of things can be tied back to the EK and hence can be validated against the vendor-issued EK certificate, so in theory this can be implemented in a way that avoids that risk, but that still involves a mechanism for bootstrapping the trust in the EK signing authorities and if that's not in the signed component of the boot chain then you're going to have problems. I'm not sure what you're considering in the emulator case. Either the PCR values are going to be different or the TPM is going to be different, and in both cases that means you're not going to receive the decrypted secret.
- kobalsky 3y ago
  > even if this is done in a way that it can’t be worked around just by modifying some files on disk, what stops the attacker from running the same routine in an emulator? this is a question for an TPM expert. I'm a novice at this so take my reasoning with a grain of salt. A software only emulation shouldn't fool the TPM since part of the secure boot process ties the hash of some PCR banks to the firmware, bootloader and kernel booted, so if you were to modify them in a way that allows you see the key, then it TPM wouldn't be able to produce the correct decryption key. I'm not sure if windows uses those PCR banks to secure bitlocker, but on other OSes you can. I'm guessing that a hardware mitm would be possible with a discrete tpm, unless you use an aditional factor to boot as it usually recommended to prevent evil maid or cold boot attacks.
- voxic11 3y ago
  You are correct, see section 6.3 https://github.com/nccgroup/TPMGenie/blob/master/docs/NCC_Group_Jeremy_Boone_TPM_Genie_Whitepaper.pdf https://github.com/nccgroup/TPMGenie/blob/master/docs/NCC_Gr...
- 0xbadcafebee 3y ago
  MitM covers both passive and active. The traditional model for MitM was Telnet sessions, where a passive MitM would allow you to capture secrets and then initiate new sessions. With active mitm you can take over a session (or more!) but passive enables plenty of successful attacks, which is why you should use encryption, which MS didn't. lolz
- rstuart4133 3y ago
  > How does the OS prove its identity to the TPM in a way an attacker couldn’t spoof in a real MitM attack? Any secrets or keys stored by the OS side would have to reside unencrypted on disk, since it doesn’t have an encryption key yet. Your intuition is sound. The only way for the OS to prove it's identity is to have a secret only it knows, and prove to the TPM it knows it. TPM's do support that, but in this case the OS has nowhere that is robustly secure to store the secret. Windows could store a obfuscate secret on disk, but it doesn't bother. To be fair, there probably isn't much point - if someone is willing to go to this much work, then it's very likely they would be willing to invest the additional effort to break the obfuscation. This still gives you a level of protection you wouldn't have without the TPM. The disk can only be read when the TPM is present - so someone stealing disk, or walking away with a bit for bit copy of it won't get them very far. One place that's useful in cloud environments. If the cloud provided replaces a fail disk and doesn't wipe the old one - it's still useless unless someone unless they know what motherboard it was paid with. Still, I think that's an anti-feature for a laptop. It means if the motherboard fails you've lost the data on the disk even though it's perfectly fine, and indeed that is the case with bitlocker. If you protect the disk with a password you entered on boot up it is immune to this sort of attack, and you can move it between machines. Win, win. That's what I do. But, I don't use Windows to do it. > Or even if the OS verifies the TPM’s identity somehow That can be solved using attestation. Attestation is just a secret TPM knows, signed by the manufacturer. Windows could choose to deal only with TPM's from manufacturers it trusts, and presumably a emulated one wouldn't be one of them. Secure boot should prevent you from modifying Windows to accept any manufacturer, so it's secure. But I'd lay long odds Windows doesn't do this sort of verification.
jfim 3y ago
I wonder if that oversight is intentional and what would be the reason for it.
- Dalewyn 3y ago
  I would hazard a guess that it's probably because BitLocker predates TPM by at least two years, and Microsoft wants to avoid bricking old BitLocker secured data because most users just aren't going to be on top of this stuff.
logical_person 3y ago
authenticated sessions are practically useless on anything but a fully integrated device, because there is no guarantee of the SRK's identity - MITM is still possible.

by als0 3y ago

comex 3y ago

This isn’t even a proper MitM attack, just passive sniffing. But, I ask as someone unfamiliar with TPM, how do authenticated sessions work? How does the OS prove its identity to the TPM in a way an attacker couldn’t spoof in a real MitM attack? Any secrets or keys stored by the OS side would have to reside unencrypted on disk, since it doesn’t have an encryption key yet. Or even if the OS verifies the TPM’s identity somehow, even if this is done in a way that it can’t be worked around just by modifying some files on disk, what stops the attacker from running the same routine in an emulator? I don’t see how you get real security from this approach unless there’s some integration with Intel ME or SGX or other CPU-side ‘secure’ environments, but then you wouldn’t need the TPM to start with.

Vogtinator 3y ago
Agreed. I don't see a way this can be done without one side trusting the other implicitly. If the sniffer/MitM gets either the measured data (to replay) or the unsealed key (to use directly) it's game over. > I don’t see how you get real security from this approach unless there’s some integration with Intel ME or SGX or other CPU-side ‘secure’ environments, but then you wouldn’t need the TPM to start with. fTPMs are basically implemented within (or closely working together with) Intel ME reps. AMD PSP.
mjg59 3y ago
"Authentication" here is something of a misnomer - it's setting up an encrypted session without any proof of identity. In that form it's sufficient to block passive sniffing and require an active MITM instead. The TPM's side of things can be tied back to the EK and hence can be validated against the vendor-issued EK certificate, so in theory this can be implemented in a way that avoids that risk, but that still involves a mechanism for bootstrapping the trust in the EK signing authorities and if that's not in the signed component of the boot chain then you're going to have problems. I'm not sure what you're considering in the emulator case. Either the PCR values are going to be different or the TPM is going to be different, and in both cases that means you're not going to receive the decrypted secret.
kobalsky 3y ago
> even if this is done in a way that it can’t be worked around just by modifying some files on disk, what stops the attacker from running the same routine in an emulator? this is a question for an TPM expert. I'm a novice at this so take my reasoning with a grain of salt. A software only emulation shouldn't fool the TPM since part of the secure boot process ties the hash of some PCR banks to the firmware, bootloader and kernel booted, so if you were to modify them in a way that allows you see the key, then it TPM wouldn't be able to produce the correct decryption key. I'm not sure if windows uses those PCR banks to secure bitlocker, but on other OSes you can. I'm guessing that a hardware mitm would be possible with a discrete tpm, unless you use an aditional factor to boot as it usually recommended to prevent evil maid or cold boot attacks.
voxic11 3y ago
You are correct, see section 6.3 https://github.com/nccgroup/TPMGenie/blob/master/docs/NCC_Group_Jeremy_Boone_TPM_Genie_Whitepaper.pdf https://github.com/nccgroup/TPMGenie/blob/master/docs/NCC_Gr...
0xbadcafebee 3y ago
MitM covers both passive and active. The traditional model for MitM was Telnet sessions, where a passive MitM would allow you to capture secrets and then initiate new sessions. With active mitm you can take over a session (or more!) but passive enables plenty of successful attacks, which is why you should use encryption, which MS didn't. lolz
rstuart4133 3y ago
> How does the OS prove its identity to the TPM in a way an attacker couldn’t spoof in a real MitM attack? Any secrets or keys stored by the OS side would have to reside unencrypted on disk, since it doesn’t have an encryption key yet. Your intuition is sound. The only way for the OS to prove it's identity is to have a secret only it knows, and prove to the TPM it knows it. TPM's do support that, but in this case the OS has nowhere that is robustly secure to store the secret. Windows could store a obfuscate secret on disk, but it doesn't bother. To be fair, there probably isn't much point - if someone is willing to go to this much work, then it's very likely they would be willing to invest the additional effort to break the obfuscation. This still gives you a level of protection you wouldn't have without the TPM. The disk can only be read when the TPM is present - so someone stealing disk, or walking away with a bit for bit copy of it won't get them very far. One place that's useful in cloud environments. If the cloud provided replaces a fail disk and doesn't wipe the old one - it's still useless unless someone unless they know what motherboard it was paid with. Still, I think that's an anti-feature for a laptop. It means if the motherboard fails you've lost the data on the disk even though it's perfectly fine, and indeed that is the case with bitlocker. If you protect the disk with a password you entered on boot up it is immune to this sort of attack, and you can move it between machines. Win, win. That's what I do. But, I don't use Windows to do it. > Or even if the OS verifies the TPM’s identity somehow That can be solved using attestation. Attestation is just a secret TPM knows, signed by the manufacturer. Windows could choose to deal only with TPM's from manufacturers it trusts, and presumably a emulated one wouldn't be one of them. Secure boot should prevent you from modifying Windows to accept any manufacturer, so it's secure. But I'd lay long odds Windows doesn't do this sort of verification.

jfim 3y ago

I wonder if that oversight is intentional and what would be the reason for it.

Dalewyn 3y ago
I would hazard a guess that it's probably because BitLocker predates TPM by at least two years, and Microsoft wants to avoid bricking old BitLocker secured data because most users just aren't going to be on top of this stuff.

logical_person 3y ago

authenticated sessions are practically useless on anything but a fully integrated device, because there is no guarantee of the SRK's identity - MITM is still possible.