Comment by dist-epoch
3 days ago
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.
I have bad news on that front.
https://tee.fail/
> 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.
1 reply →
I don't think that's the issue. It seems it's the same memory address location, so an address/location based IV would have the same problem.
You need a sequence number to solve this, but they have no place where to store it.
1 reply →
Yes, trusted computing is empirically hard, but I haven't heard solid arguments either way on whether it's actually infeasible.