Because you write your ransomware to encrypt to a hardcoded set of public keys that include an SGX attestation from those instances. This can be verified forensically and the unencrypted plaintext never leaves the victim organization.

> hardcoded set of public keys that include an SGX attestation from those instances.

You mean:

1. generate a public/private key in enclave

2. generate attestation from SGX enclave with public key hash.

3. seal the public/private key somewhere so it can be reused later, otherwise pc restart or app failures / no data.

4. publish source code that generates mrenclave somewhere that can be audited.

5. encrypt in place and assume remote trusts you when you say data was only exfiltrated encrypted or not at all.

Now, 5 is the problem i mentioned. Why would anyone trust that data was not exfiltrated unencrypted and copied a few times.

> and the unencrypted plaintext never leaves the victim organization.

You also mentioned this to be fair. Why would this be trusted?

6. Release data if no payment on bitcoin.

SGX enclaves do not have magic trusted access to network to get bitcoin payments data.

It can be man in the middled or fooled by omission by who controls machibe.

So key can be releases by feeding it bad data (payment was not done and time expired - release to the world).

There's also the problem that attestation might lead to the originating group if cpu is identifiable.

Malware encryptors can be left on the system for forensic investigation to discover. You’re correct that there’s no perfect guarantee the ransomware group didn’t also exfiltrate data using another method, but that would be kind of stupid; the idea of this would be to reduce a hard problem (trust a criminal to secure your data and eventually safely delete it) to a simpler problem (trust a criminal group not to do something economically irrational that also requires extra work and stealth at infection time.) You don’t need network access to verify a PoW blockchain transcript is correct, provided the cost of forging that blockchain segment is high enough (plus you can script payment redemption so it requires a signature from the enclave attesting that the information was destroyed.) I’m pretty sure a resourceful ransomware group can source a few motherboards and CPUs that can’t be traced back to them.

...and then Intel will simply have their HSM sign the cheat-code firmware for the EPIDs of those six chips.

Trust isn't all-or-nothing. When I ride a bus I'm trusting the driver with my life, but I wouldn't trust them to babysit my kids.

Mutability is deniability. I don't trust hardware companies with that. And I don't have to, either.

Stop hawking this SGX snakeoil. Except maybe to ransomware authors, who deserve what they'll get.

Intel could presumably help the ransomware authors bypass SGX protections but that’d be dumb. They might have some capability to trace attestations to a specific motherboard but I doubt any sophisticated ransomware group will be foiled by this.

I was implying that Intel would help the victims.

Attestations are quite certainly traceable to the EPID, which is a fuse array -- it's on the die, not the motherboard. In order to attest, the key that encrypts the victim's data would have to be SGX-generated. What kind of RNG do you think it uses? Maybe Dual_EC_DRDBG?

Help the victims how? If the CPUs have been captured, there's no need for altered firmware. If the CPUs have not been captured, then how is the altered firmware going to get installed?

I suppose it helps them in the former case, if they also had no backups. But the hackers are already in a very bad place if the CPUs get captured, so I don't think they care about SGX at that point. The hackers don't need to trust SGX. They only need the victims to trust it.