Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Stuff Gets eXposed

sgx.fail

Post reply on HN
Print view View original

31–40 of 47 posts

Re: How Stuff Gets eXposed

#31

Post by hedora »

They mention volt2pwn, but kind of gloss over it. It is probably a variant of clkscrew for intel:

https://www.usenix.org/conference/usenixsecurity17/technical...

IMO, this is the most damning of the attacks. It uses voltage and CPU frequency overrides to flip a bit a the right time during an AES operation, leaking the AES key.

Although clkscrew was remotely exploitable (!!!) via malicious android apps, I don't see a path forward to mitigate these issues, especially when physical attacks are feasible.

IBM had a piece of AES key management hardware that would wipe keys if it changed temperature, saw voltage fluctuations, etc. It was also dipped in layers of epoxy surrounded by grounded wire mesh (with secret signals, etc for the layers) so it could kill itself if cut into (or before a low temperature bath would freeze the transistors), and also to act as a Faraday cage (to keep stuff in and out).

Good luck walking down this path with cell phones or power-slurping commodity cloud hardware! Even with all that, an attacker could likely irradiate it until the right bits flipped.

Re: How Stuff Gets eXposed

#32

Post by sebazzz »

ccrush wrote: post #20
userbinator wrote: post #13

Earlier quoted context omitted.

AMD has the PSP too.

The PSP is not the same as SGX. That's more like the management engine, and while I agree that both Intel and AMD are shipping that antiuser "feautue" and that AMD had its own implementation of a trusted execution environment like SGX, the current AMD chips do not ship with it. AMD is not perfect, but it's sad that people can choose one or the other and still prefer to hand Intel their money when Intel goes out of th…

> Intel and NVIDIA locked their GPU linking technology (SLI)

Are you sure about that? Ten years ago or so I had an ASUS motherboard for AMD processors that explicitly supported SLI.

Re: How Stuff Gets eXposed

#33

Post by comex »

tptacek wrote: post #28
asimops wrote: post #7

SGX, the technology which Signal Messenger built a lot of their secure? stuff upon. Like: Technology Preview for secure value recovery https://signal.org/blog/secure-value-recovery/ > Technology preview: Private contact discovery for Signal https://signal.org/blog/private-contact-discovery/ >

No. Virtually everything Signal has proposed to use SGX for, competing secure messengers simply store in plaintext databases already. Further, the fundamental security model of Signal is about what you don't send to Signal in the first place .

Yes. Signal should have taken your last sentence to heart and not implemented contact discovery. The feature actually compromises privacy even when used as intended, because anyone can see whether anyone else uses Signal (and, if you check regularly, when they started using it, which can be revealing). The fact that the feature requires sending your entire contact list to Signal's servers (using a broken encryption mechanism) is just another reason not to do it. To add insult on top of injury, Signal doesn't even notify the user it's uploading their contact list, instead using an actively misleading description when it asks for contacts permission ("See contact names and photos in your chats").

Re: How Stuff Gets eXposed

#34

Post by summm »

ccrush wrote: post #20
userbinator wrote: post #13

Earlier quoted context omitted.

AMD has the PSP too.

The PSP is not the same as SGX. That's more like the management engine, and while I agree that both Intel and AMD are shipping that antiuser "feautue" and that AMD had its own implementation of a trusted execution environment like SGX, the current AMD chips do not ship with it. AMD is not perfect, but it's sad that people can choose one or the other and still prefer to hand Intel their money when Intel goes out of th…

- Intel disables ECC Ram support for their consumer CPUs, AMD does not

Re: How Stuff Gets eXposed

#35

Post by lrvick »

tptacek wrote: post #28
asimops wrote: post #7

SGX, the technology which Signal Messenger built a lot of their secure? stuff upon. Like: Technology Preview for secure value recovery https://signal.org/blog/secure-value-recovery/ > Technology preview: Private contact discovery for Signal https://signal.org/blog/private-contact-discovery/ >

No. Virtually everything Signal has proposed to use SGX for, competing secure messengers simply store in plaintext databases already. Further, the fundamental security model of Signal is about what you don't send to Signal in the first place .

But SGX is almost no better than plain text, especially when centralized.

At least solutions like Matrix give you the choice where your metadata is stored, and have never had a requirement for PII like phone numbers to worry about in the first place.

Re: How Stuff Gets eXposed

#36

Post by saagarjha »

comex wrote: post #33
tptacek wrote: post #28

Earlier quoted context omitted.

No. Virtually everything Signal has proposed to use SGX for, competing secure messengers simply store in plaintext databases already. Further, the fundamental security model of Signal is about what you don't send to Signal in the first place .

Yes. Signal should have taken your last sentence to heart and not implemented contact discovery. The feature actually compromises privacy even when used as intended, because anyone can see whether anyone else uses Signal (and, if you check regularly, when they started using it, which can be revealing). The fact that the feature requires sending your entire contact list to Signal's servers (using a broken encryption m…

It's such a silly hill to die on, too. SGX keeps breaking, their push for it remains annoying, and it's not even that great of a feature. Why are they so ardent about it?

Re: How Stuff Gets eXposed

#37

Post by saagarjha »

stefan_ wrote: post #10
gjsman-1000 wrote: post #2

It's no secret that every time Intel tries to add a Trusted Execution Environment like TrustZone, they somehow manage to screw up. For better or worse, "successful" TEE implementations on other platforms are why we don't have Google Pay or (for many services) 4K streaming on PC. (If everybody was falling apart like SGX, companies may have had to lighten up.) PowerDVD is a bit irrelevant though. PowerDVD no longer sup…

These attacks on SGX are some of the most advanced attacks on any TEE ever. The crappy ARM smartphone vendor TEEs regularly fall apart from mere C bounds issues.

You're making an apple-to-oranges comparison between TEEs and SGX. The attacks on SGX here are on the processor/model of SGX itself. Buffer overflows are bugs in the applets that run inside the TEE. SGX applications can and do have similar bugs. Here's a random paper I found, there are many more: https://arxiv.org/pdf/2110.06657.pdf

Re: How Stuff Gets eXposed

#38

Post by saagarjha »

fomine3 wrote: post #26
stefan_ wrote: post #10

Earlier quoted context omitted.

These attacks on SGX are some of the most advanced attacks on any TEE ever. The crappy ARM smartphone vendor TEEs regularly fall apart from mere C bounds issues.

TEE isn't implemented by smartphone vendors but implemented by SoC vendors, isn't it? You mean MediaTek is crappy?

Yes but also see my sibling comment.

Re: How Stuff Gets eXposed

#39

Post by hayley-patton »

Quoth one of the pages of the Secret Network https://scrt.network/about/about-secret-network/>:

> Every validator on Secret Network runs their code inside a TEE so no one—not even the nodes operating on the network—can access the information being decrypted and processed.

How could one possibly verify that a secure enclave is being used?

Re: How Stuff Gets eXposed

#40

Post by throw_a_grenade »

hayley-patton wrote: post #39

Quoth one of the pages of the Secret Network https://scrt.network/about/about-secret-network/ >: > Every validator on Secret Network runs their code inside a TEE so no one—not even the nodes operating on the network—can access the information being decrypted and processed. How could one possibly verify that a secure enclave is being used?

You do attestation. CPU has it's own private key [1] and signs a message saying what was the initial state of the enclave. Enclave can plug "user data" into this message, which almost always is a signature over a public key for TLS private key which was generated inside the enclave. Enclave presents it to the other side of encrypted connection (i.e. you). You verify the CPU's signature so the encrypted channel established between you and owner of said private key necessarily happened between you and enclave. QED.

Obviously this assumes attacker can't extract TLS private key from the enclave. Nominally this is a central promise of SGX, but if you have some attack which allows you to read enclave's memory anyway, all of this falls apart. TFA discussess several attacks to this effect.

[1] SGX' threat model says CPU silicon is too complicated to extract this key even if you have physical access.

Post reply on HN