I suspect that they do not actually contain the encryption key. It is more convenient if the disk encryption key is stored on the disk, but separately encrypted. You actually want to store the key multiple times, one for each unlock method. If the disk can be unlocked with a password, then you store the key encrypted using the password (or encrypted using the output of a key derivation function run on the typed password). If it can be unlocked with a smartcard, then you store a copy that is encrypted using a key stored in the card. When Bitlocker uses the TPM, it no doubt asks the TPM to encrypt the key and then stores that on the disk. To decrypt the disk it can ask the TPM to decrypt the stored key, which will only succeed if the TPM is in the same state that it was in when the key was encrypted.
The reason it's done this way is to allow multiple methods of accessing the disk, to allow the encryption password to be changed without having to rewrite every single sector of the disk, etc, etc. You can even “erase” the disk in one swift operation by simply erasing all copies of the key.
That is also required for any kind of key rotation to work, you're getting new key for a key, because alternative of using key directly would mean re-encrypting the whole drive when it changes and of course only having single one instead of multiple
don't worry, ms pushes users to just put data on onedrive, they will start losing data far before machines actually die. We already had plenty of stories of that mess.
I believe you can also get it from your online Microsoft account if that's what you logged in with once. I ran into this a while ago and had to do it that way. I didn't even know I'd set up Bitlocker.
Your suspicion is correct. I have an AMD AM5 motherboard, and everytime I update it's BIOS it warns me that the fTPM will be reset, and I know it does so because afterwards Bitlocker prompts me to introduce the recovery key since it can't unlock the drive anymore.
What do you mean exactly? Both AMD/Intel have signed firmware, and both support hardware attestation, where they sign what they see with an AMD/Intel key and you can later check that signature. This is the basis of confidential VMs, where not even the machine physical owner can tamper with the VM in an undetectable way.
> While the data itself is encrypted, notice how the values written by the first and third operation are the same.
The fact that Intel and AMD both went with ECB leaves me with mild disbelief. I realize wrangling IVs in that scenario is difficult but that's hardly an excuse to release a product that they knew full well was fundamentally broken. The insecurity of ECB for this sort of task has been common knowledge for at least 2 decades.
Google "intel sgx memory encryption engine". Intel's designers were fully aware of replay attacks, and early versions of SGX supported a hardware-based memory encryption engine with Merkle tree support.
Remember that everything in security (and computation) is a tradeoff. The MEE turned out to be a performance bottleneck, and support got dropped.
There are legitimate choices to be made here between threat models, and the resulting implications on the designs.
There's not much new under the sun when it comes to security/cryptography/whatever (tm), and I recommend approaching the choices designers make with an open mind.
I agree with the sentiment but I'm struggling to see how this qualifies as a legitimate tradeoff to make. I thought the entire point of this feature was to provide assurances to customers that cloud providers weren't snooping on their VMs. In which case physically interdicting RAM in this manner is probably the first approach a realistic adversary would attempt.
I can see where it prevents inadvertent data leaks but the feature was billed as protecting against motivated adversaries. (Or at least so I thought.)
Fair point, my ECB remark was misguided. But I think the broader point stands? I did acknowledge the difficulty of dealing with IVs here.
It's the same issue that XTS faces but that operates under the fairly modest assumption that an adversary won't have long term continuous block level access to the running system. Whereas in this case interdicting the bus is one of the primary attack vectors so failing to defend against that seems inexcusable.
> Active physical interposer adversaries are a very real part of legitimate threat models. You need an integrated root-of-trust in your CPU in order to solve these.
It's been almost 10 years since Microsoft, based on their Xbox experience, started saying "stop using discrete TPMs over the bus, they are impossible to secure, we need the TPM embedded in the CPU itself"
The TPM itself can actually be discrete, as long as you have a root-of-trust inside the CPU with a unique secret. Derive a secret from the unique secret and the hash of the initial bootcode the CPU is running like HMAC(UDS, hash(program)) and derive a public/private key pair from that. Now you can just do normal Diffie-Hellman to negotiate encryption keys with the TPM and you're safe from any future interposers.
This matters because for some functionality you really want tamper-resistant persistent storage, for example "delete the disk encryption keys if I enter the wrong password 10 times". Fairly easy to do on a TPM that can be made on a process node that supports flash vs a general CPU where that just isn't an option.
What kind of keys are they? In that same regard, Apple holds the keys to sign software for secure enclaves on iDevices and Macs, does that make them backdoored, since they can control execution on the firmware that protects everyone's authentication data and secrets?
Yes, Apple products are backdoored - not just through esoteric keys, but also because they're uploading your pictures to the mothership "to check they're not hild porn."
reply