EnclaveDB: A Secure Database using SGX

Summary: EnclaveDB is a database engine that guarantees confidentiality, integrity, and freshness for data and queries even when all other actors including the database administrator is a malicious actor. The novel way this can happen is through a small trusted computing base which includes in memory storage and precompiled procedures. I think the real beauty in this technology was the fact that they were able to do it with minimal synchronization of threads - which honestly I would find a challenge to do.

 

What I liked:

  1. The attacker model for this paper is amazing, the study authors managed a way to maintain the integrity of the database even when the database admin is malicious

  2. The paper explains really well why current methods for property preserving encryption end up failing or not holding up as well as this solution

  3. The system maintains the programming model similar to conventional relational databases so they are not reinventing the wheel.

  4. I found it interesting the system allows for remote attestations - which seems very similar to the literature I've read on distributed ledgers and block chain systems

  5. The protocol requires minimal synchronization between threads - which explains why the system is able to maintain freshness of data

 

What I didn't like:

  1. Even though the security leaps offered by this system are huge, I think that 40% more overhead might be too much to supplant traditional database systems.

  2. The system requires specific hardware (SGX) which means that systems need to replace their current hardware in order to use this system

  3. I'm not sure how practical it is to assume that we can host huge amounts of memory in DRAM just because the prices of it are falling

  4. The system uses the Intel Attestation verification service to check if a given quote has been signed by a valid attestation key --> From what I understand if this system fails it could end up compromising the entire system. So it could possibly have a single point of failure

  5. I'm not really 100% sure how the remote challenger can establish trust in an enclave without a lot of really intensive ZKPs

 

 

 

Points for Discussion:

  1. How different are these secure enclaves from the one's used by Apple?

  2. How could someone spoof an enclave in an untrusted database

  3. Instead of creating a specific area in an untrusted database, why not work on finding a secure data base to work on?

  4. How is the Merkle Tree used in EnclaveDB different than the one used in BlockChains

  5. What percentage overhead for a secure database system like this is acceptable for wide scale adoption in the enterprise community?

 

New Ideas:

  1. Explore new ways to audit results from this database

  2. Building of the distributed attestation might be really interesting because each distributed system could verify in a different way whether the enclave really is an enclave. It could also distribute the computation of a ZKP

  3. From a hardware POV is there a way to designate secure memory only for a specific function?

  4. How can distributed methods of memory tables be used in systems like Block Chains

  5. Analyze the adoption of systems like these and their user groups