(This was originally posted to the Cambridge security blog here.)
Software Guard eXtensions (SGX) represents Intel’s latest foray into trusted computing. Initially intended as a means to secure cloud computation, it has since been employed for DRM and secure key storage in production systems. SGX differs from its competitors such as TrustZone in its focus on reducing the volume of trusted code in its “secure world”. These secure worlds are called enclaves in SGX parlance and are protected from untrusted code by a combination of a memory encryption engine and a set of new CPU instructions to enforce separation.
SGX has been available on almost every Intel processor since the sixth generation of Intel Core (Skylake). It has had a bit of a rocky journey since. Upon its release, there were concerns expressed about SGX being used as a medium for malware dissemination. A proof of concept demonstrating the effectiveness of this was also published. Then there were concerns about the mandatory agreements required to publish enclave code in production. In order to use Intel’s attestation service, a key enabler for any remote application built on SGX, developers have to obtain a commercial license from Intel. This lock-in raised a fair bit of consternation and to date hasn’t been fully addressed by Intel. Then came the vulnerabilities. SGX was found to be vulnerable to cache timing attacks, speculative execution vulnerabilities and to Load Value Injection attacks. This has further eroded the credibility of the platform.
That said, there have been a fair few projects that have utilized SGX either to harden existing solutions or to come up with hitherto unseen applications. In this post, we’ll look at three such proposals to see how they utilize SGX despite its concerning attributes. Where applicable, we will also talk about how the discovered vulnerabilities have affected their viability.
1. Proof of Elapsed Time by Intel Corporation, 2016 (and under active development)
Intel’s Sawtooth was one of the first projects in Hyperledger, a Linux Foundation umbrella project dedicated to open source permissioned blockchain projects. One of the main appeals of permissioned blockchains versus permissionless blockchains (such as Bitcoin) is their promise of better energy efficiency. Since permissioned networks consist of a closed set of known collaborators, it is possible to use more efficient consensus mechanisms than Proof of Work. Initial permissioned projects resorted to using standard consensus algorithms such as PBFT and Raft, however, these turned out to be unsuitable for larger networks due to scalability restrictions.
To overcome these restrictions, Intel designed Proof of Elapsed Time (PoET) and released it as the default consensus algorithm for Sawtooth. PoET is a leader-based consensus algorithm that relies on SGX for its security guarantees. The algorithm is fairly simple, at each block time every node performs the following steps:
1. Each node requests a timeout from its SGX enclave using a trusted function.
2. Node sleeps until the timeout returns.
3. Upon return, a trusted function then verifies that the timeout has actually expired.
4. Node broadcasts its verified timeout value to the network. The node with the lowest timeout is selected as the leader.
The goal of PoET was to create a leader election algorithm akin to Proof of Work but instead of computational work, the “voting power” of an entity here is proportional to the number of SGX chips that that entity controls. In principle, this leads to massive runtime efficiency gains since no intensive work is performed as part of the leader election. 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.
This isn’t just a theoretical concern since a whole host of vulnerabilities have been demonstrated for SGX in the last couple of years. In order to mitigate this to some degree, Sawtooth now includes z-test to check if a particular node is winning elections too frequently. Of course, this doesn’t negate the adversary’s advantage completely and it has been shown that even with a handful of compromised nodes the adversary can compromise a network, z-test notwithstanding. Because of this, I would consider PoET to only be useful in crash fault tolerant settings where there are no motivated adversaries; this also seems to be the general consensus among developers judging by forum posts on Sawtooth.
2. Don’t Mine Wait In Line: Fair and Efficient Blockchain Consensus with Robust Round Robin by Mansoor Ahmed-Rengers and Kari Kostiainen, 2019
This paper follows directly from the preceding discussion and aims to create an SGX-based consensus algorithm that doesn’t suffer from the same security economics issues. For reasons that will be obvious soon, we call this algorithm Robust Round Robin (RRR). We start off by asserting that having the trusted computing device in the adversary’s possession implies that we cannot rely on the enclaves not being compromised. Thus, we do not rely on the enclaves for runtime security guarantees, rather we only use them as a gating mechanism for identities used for consensus (i.e., sybil attack prevention).
The only SGX primitive we rely on is the remote attestation performed with the Intel Attestation Service (IAS). This service uses a quoting mechanism that relies on a hardware key to prove to the IAS that it is an SGX platform. Now, if an adversary uses a non-SGX system to attempt this, the attempt will fail since they will not have access to the requisite key. On the other hand, if the adversary does have possession of an SGX system, they do not gain anything by compromising their system since there is 1-to-1 relation between keys and identities granted.
Once a node is assigned an identity, it broadcasts its identity to all the enrolled nodes on the network. Upon receipt of this identity, this identity joining event is added to the blockchain and the node is then said to be enrolled. All nodes maintain the list of enrolled identities ordered by their “mining age”. The mining age is the number of blocks that have elapsed since an identity last mined a block. The ten or so nodes with the highest mining ages are considered to be candidate miners. All the candidate miners then send a candidate message to a logarithmic set of randomly sampled voting nodes. The voters pick the oldest candidate as the miner who then broadcasts the next block. Thus, in the absence of offline nodes we follow a deterministic round robin leader selection which ensure fairness of rewards.
This protocol does not suffer the same vulnerabilities as PoET but it is susceptible to a compromise of the centralized IAS. If Intel is malicious or if the IAS servers are compromised then the gating mechanism cannot be trusted. An alternative version of the gating mechanism that relies on an initial bootstrapping phase via Proof of Work is therefore also presented in the paper. This alternative version, however, suffers from some of the same problems that Proof of Stake systems suffer from (eventual monopolies and lack of easy entry for new participants).
3. EnclaveDB: A Secure Database Using SGX by Christian Piebe, Kapil Vaswani and Manuel Costa
In this paper, the authors present a different use case for SGX: securing databases. They propose EnclaveDB, a database engine that uses SGX enclaves to thwart malicious database administrators. They envision EnclaveDB being useful in cloud computing settings where users may not trust the host with sensitive data.
The authors consider a threat model where the adversary controls all code running on the server except for the enclave. This includes disk and network I/O. They do not allow physical attacks and assume that SGX’s memory protection guarantees hold. Their goal is to provide an in-memory database that guarantees confidentiality, integrity and freshness with a small performance impact. They achieve this goal by splitting the database system into client-side and server-side components. The client side is responsible for storing a database encryption key as well as a key management service that establishes trusted connections to the server side enclave.
On the server side, EnclaveDB has two components: the untrusted SQL server and a trusted Enclave. The SQL server can perform queries on public, non-sensitive data. It is also responsible for receiving requests on behalf of the enclave and invoking stored procedures within the enclave. The enclave contains a Hekaton in-memory database along with a set of compiled queries. These queries are compiled on the client side and then loaded on to the enclave thus reducing the attack surface by not requiring a general query processor to be loaded into the enclave. Unfortunately this also entails that any changes in the database schema would require redeploying the enclave code. The actual transaction processing follows a fairly simple two-phase commit protocol between Hekaton and the host.
One of the issues with the system design is the use of SGX’s monotonic counters in the transaction processing protocol to prevent rollback attacks. These have been shown to support only a limitted number of writes before permanently burning out. This calls into question the validity of their solution since database maintainers would presumably expect long run-times from their servers. The authors suggest a partial mitigation for this but this does not fully address the concern. More seriously, it appears to me that EnclaveDB is vulnerable to the aforementioned cache timing attacks revealed on SGX. It also appears that there isn’t much that can be done about this by way of implementation mitigations either without upstream fixes to SGX. Proposals such as Varys have, however, provided promising avenues for these fixes.
Conclusion
Intel SGX has its issues: vulnerabilities and archaic lock-in policies by Intel being the foremost ones. That said, it is the most accessible, widely deployed trusted computing framework for desktop and server-side developers. This wide availability is a key contributor to the large amounts of research being done on SGX. Moreover, as RRR demonstrates, it is possible to use SGX to gain integrity assurances despite the discovered vulnerabilites. Lastly, I expect SGX to see more widespread adoption as a relatively low cost defense-in-depth mechanism. Yes, there are vulnerabilities but using SGX nevertheless represents an additional hurdle for any potential adversary. If security economics has taught us anything, it is that introducing that hurdle can only be a good thing.
