7 ms·
What's Intel SGX Good For?
- eqvinox 6y agoSo the security of a blockchain now depends on the security of the SGX enclave? What could possibly go wrong... > 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?
- StavrosK 6y agoIt's not "your own platform", that's what the article gets wrong. The entire purpose of SGX is that it's my platform (that I can control/be assured that you can't), running on your hardware.
- zozbot234 6y agoIt's not my platform either, it's Intel's platform and I'm simply trusting them as to what code is running on SGX. Might as well trust Amazon or any other cloud provider.
- anonymousDan 6y agoExcept then you trust Amazon and Intel, not just Amazon (presuming you run on x86). The nice thing about SGX is that you don't need to trust the whole cloud provider software stack.
- devit 6y agoYeah, you can only use SGX-like systems when the reward from breaking them is limited since they can all be broken given sufficient resources (or even just insider knowledge). 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.
- vladivstok 6y agoThe assumption behind PoET is precisely that you don't control a part of your machine (the SGX enclave). I agree that that's an unreasonable assumption which is why we developed RRR.
- eqvinox 6y ago> I agree that that's an unreasonable assumption which is why we developed RRR. 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.)
- vladivstok 6y agoAs the article states at the end, no one should assume that enclaves give you perfect security. They are most useful when used as a defense in depth mechanism: a way to increase the cost for a successful attack.
- als0 6y agoThere is no such thing as perfect security - it is always a risk assessment exercise. Secure enclaves in general are not snake oil. Secure elements and TPMs, for example, are evaluated by independent testing bodies to high levels of security certification. These are examples of secure enclaves. Secure enclaves in this context, SGX, are an on-CPU mechanism that have weaker isolation properties than other enclaves. However, SGX has a different set of advantages, and may be acceptable to use based on the value of the asset being protected.
- aseipp 6y agoYou have a very limited understanding of what "works" and what is "impossible", it seems. Actual security engineering occurs in hostile environments all the time, in extremely non-perfect environments, with non-perfect tools, and many of its principles (and practices) noticeably make security better for users, operators, and engineers. Similarly, DRM is not only NOT "impossible", it's very possible, very real, and actively used against people today. I suspect if you truly think DRM is "impossible" you have a vastly more limited understanding of security than you think you do. 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.
- jnwatson 6y agoPart of it is community agreement. In order to mutually trust what we do on each others' machines, we give up some rights, including the ability to lie about what you executed on your own machine. It is the implicit agreement in Folding @home and many community computation projects, only this is better enforced. 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.
- deleted 6y ago[deleted]
- centimeter 6y ago> In order to mutually trust what we do on each others' machines, we give up some rights 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.
- Spivak 6y agoWhich, given that you believe that SGX hasn’t been compromised yet, is exactly what you get!
- centimeter 6y ago> given that you believe that SGX hasn’t been compromised yet Who the hell would believe that?
- mindslight 6y agoThat may sound like a worthwhile goal, but it's actually ripe for abuse by exacerbating existing power imbalances. For example, right now we just laugh at websites that insisting on imposing nonsensical requirements on end users (client side form validation, insistence on using a particular browser, disable copy/paste, anti-adblock, etc). Imagine they have the power to do this and succeed. 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.
- DyslexicAtheist 6y agoTL;DR: same as ARM's Trustzone ... brilliant for hiding malware.
- zenlot 6y ago"SGX differs from its competitors such as TrustZone in its focus on reducing the volume of trusted code in its “secure world”."
- eqvinox 6y agoThe fact that it's designed to allow a smaller volume of trusted code doesn't really prevent you from putting the "normal" amount of malware in there...
- zimmerfrei 6y agoI disagree. 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).
- DyslexicAtheist 6y ago> (i.e. you can load encrypted code, though you need a lot scaffolding) 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!
- deleted 6y ago[deleted]
- pram 6y agoFrom a paper in that article: "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
- eqvinox 6y agoNo problem, isn't it obvious?: instead of paying for electricity to mine blockchains, you now pay for new hardware! Protect the environment by filling Intel's pockets :D
- rkagerer 6y agoHow long until we see an SGX-damaging malware in the wild that simply eats up all the monotonic counters?
- yrro 6y agoOr ransomware that does so if the ransom is not paid. This can also be done with UEFI variable writes, since the flash where they are stored is... often not of the highest quality!
- throwaway2048 6y agoI don't think many people care about their SGX functionality.
- vladivstok 6y agoSGX is disabled by default on most systems so it would have to be a very targeted malware
- goalieca 6y agoHypothetical, but would intel be better off trying to allocate one of its 70 cores as a dedicated crypto processor with dedicated memory rather than fall down the trap of trying to safely share resources?
- fpoling 6y agoSGX is about making arbitrary general purpose computations encrypted and inaccessible from the rest of the system. Thus it cannot use a crypto chip with fixed set of secure operations.
- zozbot234 6y agoPerhaps I'm just missing the point here, but what's a "permissioned blockchain" and how does it differ from a plain old database?
- aledthemathguy 6y agoit'd decentralised, not controlled by single entity.
- zozbot234 6y agoSo, like git?
- dunkelheit 6y agoGit almost qualifies, but it has no automatic conflict resolution mechanism. Imagine how you would program a bank using git as a database. You would put each account balance in its own file and install a hook that checks that no money is created out of thin air. Commits are transactions. Everything kind of works, but how would you prevent double spends in such a system? Double spends are like divergent branches so presumably someone will need to step in and perform a merge. But this someone then becomes a point of centralization, thereby disqualifying git as a blockchain ;)
- anonymousDan 6y agoGit solves a different problem. Look up state machine replication, and then think about the case where some portion of the participants (max 1/3) are malicious. In git how do you deal where there is no central 'trusted repo' to push to, and a malicious participant sends a commit to some subset of participants but not to others (i.e. equivocates)?
- vladivstok 6y agoThe main difference is spreading out the control of the database to multiple actors. No single entity is allowed to make unilateral changes to the state of the database. 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.
- forty 6y agoThis usage of SGX by Signal was pretty cool https://signal.org/blog/private-contact-discovery/ https://signal.org/blog/private-contact-discovery/
- woadwarrior01 6y agoOn a related note, here's a project[1] that runs JS workers in Intel SGX enclaves using the Duktape JS interpreter. [1]: https://github.com/evervault/node-secureworker https://github.com/evervault/node-secureworker
- tarun_anand 6y agoWe looked at it and found it to be very unstable and buggy. Eventually we gave it up in place of native SGX programming.
- paraselene_ 6y agoFor now, playback for UHD blu-ray and protected 4K content, including netflix. Tried to play some UHD discs on my living room HTPC, which requires either Intel SGX, or a Pascal-based NVidia GPU.
- RyJones 6y agoThe Linux Foundation is a foundation. Hyperledger Project is a project of the Linux Foundation, not a foundation in and of itself. Source: Am Linux Foundation employee working on Hyperledger
- yarrel 6y agoSGX is trusted third party hardware. 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.
- woah 6y agoThe two blockchain papers are so ridiculous on their face that I find it amazing that the authors were able to work on them at all (Intel funding may have helped in that regard). 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.
- vladivstok 6y agoI feel like you've misunderstood the papers, and what the motivation behind them is. The argument isn't that Intel chips are more efficient, it is that these schemes simply don't require continuous computations. 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).
- woah 6y agoAs I understand it, the benefit of PoET is that it doesn't require the massive waste of electricity that PoW does. 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.
- vladivstok 6y agoThe timestamps for PoET don't require centralized servers; the timers are local to the platform. RRR goes one step further and doesn't even trust local timers.
- deleted 6y ago[deleted]