The SecureValueRecovery2 (SVR2) project aims to store client-side secrets server-side protected by a human-remembered (and thus, low-entropy) pin. It does so by limiting the number of attempts to recover such a secret to a very small guess count, to disallow brute-force attacks that would otherwise trivially recover such a secret. To limit the number of recovery attempts, SVR2 keeps persistent state on the guess count, along with the secret itself, in a multi-replica, strong-consensus, shared storage mechanism based on in-memory Raft.
The SVR3 project expands on this approach by implementing secret-sharing across multiple hardware-protected backends (SGX, Nitro, SEV-SNP), requiring breaking of all underlying hardware security models to extract the necessary secrets.
SVR2/3 is designed, first and foremost, to not leak the secret material, and, secondarily, to provide the material back to clients. Given this, if there is a choice between "lose the secret material forever" and "store the secret material but potentially leak it", we'll choose the former. This means that, in some cases, we've chosen to allow the system to lose liveness (the ability to serve back anything) in order to maintain the security properties of the system. We'll happily discard every secret in the system rather than expose one of the secrets to a leak.
SVR2 is a successor to the SecureValueRecovery project that Signal already uses for the above stated purpose. We've built a second version of this system to handle a few specific issues:
- Update to SGX DCAP capabilities
- Provide better operational handling of crashes/failures via self-healing
- Simplify to a single-replica-group model since SGX CPUs now have an EPC size of hundreds of gigabytes
As part of SGX DCAP updates, this project also attempts to be as safe as possible while running on SGX TME memory, compared to the differing security guarantees of the SGX MEE memory utilized in the original version.
SVR3 builds upon the implemented SVR2 data model, exposing a different client request/response protocol that exposes a Ristretto-based oblivious pseudo- random function (OPRF) rather than a direct store/retrieve database.
In order to build and test everything in this repository, you should be able to
just run make at the top-level. You must have a valid docker installed
locally to do this. Running this at the top-level will:
- Create a docker image in which to build things
- Build
enclave/enclave.test(a debug enclave for simulation/testing) andenclave/enclave.signed(a production enclave) - Build and test the host-side process in
host/
If you'd like to incrementally build and change things, you can do so by
running make dockersh. This will build the aforementioned docker image,
then drop you inside of it in a bash shell. You can then run any of
make all # Make everything
make enclave # Make all of the enclave stuf
make host # Make all of the host stuff
(cd enclave && make $SOMETARGET) # Make just a specific target in enclave
(cd host && make $SOMETARGET) # Make just a specific target in host
Code is divided into a few main directories at the top-level
docker- Contains the spec for the docker image used to build everything else.shared- Contains all code/configs that must be shared between the host and enclave. This includes any protos that the host and enclave use to communicate, and the definitions of ocalls/ecalls (the*.edlfiles).enclave- Contains all code and build rules for building the in-enclave binary. This is a C++ codebase.host- Contains all code and build rules for building the host-side binary, which starts up an enclave, then communicates with it. This is a Go codebase.docs- Contains additional documentation above and beyond the host/enclaveREADME.mddocs on specific topics.trustedimage- Builds a trustable VM disk image based on the current enclave code, for use in AMD SEV-SNP and other environments where the trusted unit is a VM rather than a binary.
Copyright 2023-2024 Signal Messenger, LLC
Licensed under the AGPLv3