"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."
Your motherboard UEFI blob and chip both have to support it. The vast majority of systems are limited by the fact their UEFI implementation does not enable (or allow you to enable) SGX at all, and at least on my Ice Lake laptop, SGX was disabled out of the box in UEFI (in a non-software controlled state.)
Or 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!
No 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
The 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.
I 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).
As 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.
The 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.
I think you're missing the point being made. GP isn't saying these schemes require a central server.
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.
So 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?
Part 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.
> 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.
That 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.
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.
The 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.
> 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.)
As 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.
There 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.
You could apply the same logic to cryptographic systems themselves; we have very few absolute proofs of security properties for the cryptography we use for TLS and the like, so they are “imperfect” and may be vulnerable and therefore are snake oil. However I doubt you’d feel indifferent about whether a website you are sending your credit card number to uses HTTPS and stores your payment information encrypted at rest.
I'd trust much more to software in general (and TLS-based crypto in particular) compared to hardware devices.
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.
You 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.
No, I have a very good understanding of how most of my users, i.e. "normal" people, operate. I would suggest you pick a random relative outside a STEM field and discuss what their security requirements for a blockchain wallet are.
I haven't "made up my set of Nerd rules." I have learned what the general expectations of my users are.
Yeah, 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.
It'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.
It'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.
Except 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.
The 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.
Git 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 ;)
Git 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)?
Hypothetical, 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?
SGX 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.
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).
> (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!
The 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...
For 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.
"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