
What's Intel SGX Good For? - vladivstok
https://www.lightbluetouchpaper.org/2020/05/07/three-paper-thursday-whats-intel-sgx-good-for/
======
pram
From 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

~~~
rkagerer
How long until we see an SGX-damaging malware in the wild that simply eats up
all the monotonic counters?

~~~
vladivstok
SGX is disabled by default on most systems so it would have to be a very
targeted malware

~~~
rkagerer
Truly disabled, or in the Software Controlled state?

~~~
aseipp
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.)

------
woah
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.

~~~
vladivstok
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).

~~~
woah
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.

~~~
vladivstok
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.

~~~
cyphar
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.

------
eqvinox
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?

~~~
jnwatson
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.

~~~
centimeter
> 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
Which, given that you believe that SGX hasn’t been compromised yet, is exactly
what you get!

~~~
centimeter
> given that you believe that SGX hasn’t been compromised yet

Who the hell would believe that?

------
forty
This usage of SGX by Signal was pretty cool [https://signal.org/blog/private-
contact-discovery/](https://signal.org/blog/private-contact-discovery/)

------
zozbot234
Perhaps I'm just missing the point here, but what's a "permissioned
blockchain" and how does it differ from a plain old database?

~~~
aledthemathguy
it'd decentralised, not controlled by single entity.

~~~
zozbot234
So, like git?

~~~
dunkelheit
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 ;)

------
woadwarrior01
On 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
We looked at it and found it to be very unstable and buggy.

Eventually we gave it up in place of native SGX programming.

------
goalieca
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?

~~~
fpoling
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.

------
RyJones
The 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
SGX 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.

------
DyslexicAtheist
TL;DR: same as ARM's Trustzone ... brilliant for hiding malware.

~~~
zimmerfrei
I 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
> (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!

------
paraselene_
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.

