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.

▲

evan_a_a 3 days ago | parent [-]

I have bad news on that front.

https://tee.fail/

▲

fc417fc802 2 days ago | parent | next [-]

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

▲

rossjudson 2 days ago | parent | next [-]

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.

	▲	fc417fc802 2 days ago \| parent [-]
		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.)

▲

dist-epoch 2 days ago | parent | prev [-]

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.

	▲	fc417fc802 2 days ago \| parent [-]
		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.

▲

lxgr 3 days ago | parent | prev [-]

Yes, trusted computing is empirically hard, but I haven't heard solid arguments either way on whether it's actually infeasible.