What's Intel SGX Good For?
lightbluetouchpaper.org
lightbluetouchpaper.org
"Intel has recently added support for monotonic counters [5] as an optional SGX feature that an enclave developer may use for rollback attack pro- tection, when available. However, the security and per- formance properties of this mechanism are not precisely documented. We performed a detailed analysis of SGX counters and report our findings in Appendix B. To summarize, we found out that counter updates take 80-250 ms and reads 60-140 ms. The non-volatile mem- ory used to implement the counter wears out after ap- proximately one million writes, making the counter func- tionality unusable after a couple of days of continuous use. Thus, SGX counters are unsuitable for systems where state updates are frequent and continuous."
permanently breaks lol
The gist of them is that instead of using hard computational work to secure a chain against sybil attacks, they use timeouts enforced by Intel. To get more mining power in proof of work, one has to buy a lot of hashing chips, and feed a lot of power into them. To get more mining power in these "proof of Intel" schemes, one must buy more SGX chips from Intel. The supposed benefit here is that the SGX chips consume much less power than the hashing chips.
That's all well and good, except- both of the schemes in the linked papers have the same security properties as if Intel simply set up a centralized timestamping server. Intel's timestamping server would also perform a lot faster than any of these blockchains.
As for the two schemes, you are correct about the first paper that it depends on the timeouts enforced by SGX. However, the second paper makes no such assumptions and doesn't even assume that the enclave is secure; all it relies on is the attestation service (which is remote).
What I find ridiculous is that they have roughly the same security properties as a timestamping server set up by Intel. Creating a blockchain that depends entirely on one trusted party seems pointless.
The point they're making is that PoET assumes that Intel SGX actually provides the properties that Intel claims (namely that they will never produce attestation certificates for code not run in SGX). Thus there is a single party which you are trusting to provide these properties and not attack your system. If you're okay with trusting a single party then the system is equivalent (in terms of security) to having that single trusted party run a server which emits timestamps.
RRR suffers from basically the same problem -- you're trusting Intel to not produce endless fraudulent identities and thus always be chosen as the oldest miner.
> Unfortunately, this proposal suffers from a critical security economics issue: node maintainers here have a strong incentive to break into their own SGX chips. If an adversary managed to compromise their SGX, they could win the leader election at every round by setting the timeout to 0. The more valuable the network, the stronger the incentive to compromise your own platform.
I wouldn't call controlling my own SGX "compromising my own platform". It is my own platform after all, why should I not control it as I please?
For example, it might be fine as a way to guarantee the integrity of things like Folding@Home where disruption provides no gain other than the satisfaction of successful vandalism, but not for securing a popular cryptocurrency.
Out of curiosity, I would've hoped that the consensus in the cryptography community is that "secure enclaves" are pretty much snake oil to begin with... is this not the case?
(I mean... for a secure enclave to actually work, you need "perfect" physical security, "perfect" software implementation inside, and "perfect" design of the cryptographic systems around it... that sounds rather infeasible. I always assumed cryptographers would agree and that it's mostly engineers and lawyers trying to "ship the impossible" to do things like DRM.)
Computer people have absolutely got to get out of this mindset where impossible means "according to my made up set of Nerd rules", vs the rules that are in place in the world surrounding them.
I haven't "made up my set of Nerd rules." I have learned what the general expectations of my users are.
The TLS vs SGX is a particularly bad comparison. SGX's internal design was not even published, let alone reviewed; and it already had multiple bad exploits. The TLS design and code has been reviewed by a multiple cryptographers, and the algorithm itself (not implementation) is unbroken.
Peer-to-peer computation is hard to implement because of the quite hairy social aspect of requiring a trust root that is out of direct control of the owner of the equipment.
I trust what people do on their machines to the extent they can cryptographically prove it to me. Anything else is, for me, an unacceptable compromise.
Who the hell would believe that?
Furthermore, the actual implementation isn't likely to use a narrow proof that the running javascript hasn't been tampered with, but rather a blunt proof over the entire software environment. The outcome would basically be putting decades of personal computing freedom back in the box. Imagine needing to run Windows on your bona fide desktop and not being able to virtualize it or even use a headless box via RDP.
A small sandbox isn't a full threat in the manner I laid out, just the same owner-is-hostile dynamic.
If attestation keys were only rooted in the processor itself (ie not signed by Intel/AMD) and users could load their own, the worthwhile properties of hardened hardware would be preserved without making the owner an enemy.
Moreover, the line between permisisonless and permissioned blockchains isn't necessarily about who's allowed to join but rather which identity they use. For RRR, the only reason we limit ourselves to permissioned is because we require long lived identities to prevent sybil attacks; otherwise it's as "open" as any public blockchain.
Eventually we gave it up in place of native SGX programming.
Hyperledger Project is a project of the Linux Foundation, not a foundation in and of itself.
Source: Am Linux Foundation employee working on Hyperledger
The best thing that you can say about this is that it is good for some corporate mockchain use cases as long as the existing attacks against it aren't used and worse ones aren't developed.
ARM TrustZone is predicated on the Secure World being potentially able to monitor and modify the entire Non-Secure World, because it has control over the MMU (see TZASC, TZMA, TZPC). The reverse is clearly impossible.
SGX instead is defined as a "secure" sandbox, it has basically no privilege even over the process it runs in.
Having said that, researches demonstrated examples of SGX-based malware, which is ultimately rooted in the fact that SGX state is not fully observable (i.e. you can load encrypted code, though you need a lot scaffolding). However, such malware uses a lot of tricks whose side effects can be detected (notwithstanding the fundamental microarchs attacks).
precisely for this reason ... that it raises the cost of an attacker by also raising the cost for security researchers and making introspection impossible, ... it is snake-oil. It's a perfect hiding spot not despite but because of this!