diff --git a/src/404.md b/src/404.md index 61b0af3..6810806 100644 --- a/src/404.md +++ b/src/404.md @@ -1,3 +1,4 @@ # Document not found (404) -This URL is invalid, sorry. Try the search instead! +This URL is invalid, sorry. Try the search instead!\ +Feel free to contact us at diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 54efa84..b83ec79 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -6,15 +6,15 @@ # User Guide -- [Installation](./todo.md) +- [Installation]() - [Become a Node]() - [Buy DTE Token]() # Reference Guide -- [Provider Nodes]() +- [Node Operators](./operators/README.md) - [detee-daemon]() -- [Brain Nodes]() +- [Brain](./brain/README.md) - [brain-node]() - [Users]() - [detee-cli]() @@ -23,11 +23,17 @@ # Security +- [Security Overview](./security/README.md) + - [Intel SGX](./security/intel_sgx.md) + - [RATLS](./security/ratls.md) + - [Sealing](./security/sealing.md) + - [Hacker Challenge](./hacker_challenge/README.md) - [Prerequisites](./hacker_challenge/prerequisites.md) - [Quick Start](./hacker_challenge/quick_start.md) - [Hacking](./hacker_challenge/hacking.md) - [Network](./hacker_challenge/network.md) + - [Architecture](./hacker_challenge/architecture.md) - [Issues](./hacker_challenge/known_issues.md) --- diff --git a/src/brain/README.md b/src/brain/README.md new file mode 100644 index 0000000..f221123 --- /dev/null +++ b/src/brain/README.md @@ -0,0 +1 @@ +# DeTEE Brain Network \ No newline at end of file diff --git a/src/hacker_challenge/architecture.md b/src/hacker_challenge/architecture.md new file mode 100644 index 0000000..8d05a77 --- /dev/null +++ b/src/hacker_challenge/architecture.md @@ -0,0 +1,7 @@ +# Hacker Challenge Architecture + +Hacker Challenge is a decentralized network of nodes, though the decentralized +algorithms are simplified as you will see from the code, since every node in +the cluster is inherently trusted. + +The nodes validate each other through [RATLS](../security/ratls.md) \ No newline at end of file diff --git a/src/img/database_key_sealing.jpg b/src/img/database_key_sealing.jpg new file mode 100644 index 0000000..ff21ba6 Binary files /dev/null and b/src/img/database_key_sealing.jpg differ diff --git a/src/img/mratls_hratls.jpg b/src/img/mratls_hratls.jpg new file mode 100644 index 0000000..2d59202 Binary files /dev/null and b/src/img/mratls_hratls.jpg differ diff --git a/src/operators/README.md b/src/operators/README.md new file mode 100644 index 0000000..7943ac1 --- /dev/null +++ b/src/operators/README.md @@ -0,0 +1 @@ +# DeTEE Server Provider Operators \ No newline at end of file diff --git a/src/security/README.md b/src/security/README.md new file mode 100644 index 0000000..4985456 --- /dev/null +++ b/src/security/README.md @@ -0,0 +1,13 @@ +# DeTEE Security Overview + +In order to provide the most secure and reliable Virtual Machines and Containers, +DeTEE is relying on a few key technologies and techniques: + +- **Intel SGX** (Software Guard Extensions); +- **AMD SEV** (Secure Encrypted Virtualization); +- **Intel SGX DCAP** (Data Center Attestation Primitives); +- [**mRATLS**](./ratls.md#mRATLS) (Mutual Remote Attestation Transport Layer Security); +- [**hRATLS**](./ratls.md#hRATLS) (Hybrid Remote Attestation Transport Layer Security); +- [**Sealing**](./sealing.md) (Technique of saving sensitive information to the untrusted disk). + +
diff --git a/src/security/intel_sgx.md b/src/security/intel_sgx.md new file mode 100644 index 0000000..72c9d0a --- /dev/null +++ b/src/security/intel_sgx.md @@ -0,0 +1,4 @@ +# Intel SGX + +Refer to [this link](https://www.intel.com/content/www/us/en/security-center/technical-details/sgx-attestation-technical-details.html) +to see the list of current vulnerabilities and mitigations for Intel SGX. \ No newline at end of file diff --git a/src/security/ratls.md b/src/security/ratls.md new file mode 100644 index 0000000..f264f89 --- /dev/null +++ b/src/security/ratls.md @@ -0,0 +1,35 @@ +# DeTEE RATLS + +DeTEE uses a custom implementation of Remote Attestation Transport Layer Security +(RATLS) to secure the communication between the different components of the DeTEE +network. The library for RATLS is implemented in Rust, check out the [repository](https://gitea.detee.cloud/general/detee-sgx) + +So the RATLS is a special mode of TLS that uses the Remote Attestation (RA) certificates +during the handshake. The RA certificates are generated during the remote attestation +using the Intel SGX SDK and contain the MRENCLAVE, MRSIGNER, PRODID, SVN of the peer. + +Two modes exist for the RATLS. + +![RATLS Modes](../img/mratls_hratls.jpg) + +## mRATLS + +During Mutual Remote Attestation TLS (mRATLS) handshake, the peers exchange their RA +certificates and verify them. Each peer has a whitelist of the MRENCLAVE, MRSIGNER +PRODID, SVN of the other peer. If the RA certificate is not in the whitelist, the +peer will reject the connection. + +This is the mode that Hacker Challenge nodes and Brain nodes are using to only allow +the trusted peers to connect. In the case of the Hacker Challenge, the whitelist +contains only the mrenclave measurement of the currently running code to ensure +that only identical copies of the code can connect. + +## hRATLS + +This mode is used when one of the peers is not running inside the enclave. Thus the +name Hybrid Remote Attestation TLS (hRATLS). The implementation for this mode is +already completed by the DeTEE but was not publicized yet since we are actively +testing the implementation. + +
+ diff --git a/src/security/sealing.md b/src/security/sealing.md new file mode 100644 index 0000000..a42a5be --- /dev/null +++ b/src/security/sealing.md @@ -0,0 +1,48 @@ +# SGX Sealing + +Sealing is a technique of saving sensitive information to the untrusted disk. The +data is encrypted and can only be decrypted by the same enclave that sealed it. +The enclave is any software that operates in a trusted execution environment (TEE). + +When sealing data on the disk with SGX, the enclave is encrypting it with its own +unique key that the processor creates by combining the enclave's measurement and +the processor's own root key. The key is unique to the enclave and the processor, so +the data can only be decrypted by the same enclave running on the same processor. + +Check the following code example that demonstrates how to seal and unseal data +using the enclave. + +```toml +[dependencies] +detee-sgx = { git = "https://gitea.detee.cloud/general/detee-sgx", features = ["sealing"] } +``` + +```rust +// Sealing +detee_sgx::SealingConfig::new()?.seal_data(vec![1, 2, 3, 4])?; +std::fs::write(path, sealed).map_err(Into::into) +// Un-sealing +let sealed = std::fs::read(path)?; +let serialized = detee_sgx::SealingConfig::new()?.un_seal_data(sealed)?; +``` + +This example relies on the `utils_lib`, that is present inside the docker image +that we provision, `detee/occlum:0.30.1-ubuntu20.04`. This library uses the `/dev/sgx` +device in runtime through IOCTL to interact with Occlum runtime to ask the processor +to generate the sealing key for the enclave. + +## Use-cases for sealing + +Sealing is useful when you want to save sensitive data to the disk so that it +persists between software restarts, but you don't want anybody except for your +software to be able to read it or tamper with it. For example, you can use sealing +to save the wallet key to the disk, or the database encryption key. + +The only limitation is the performance of sealing big files. Since the sealing +process is simplified in the `detee-sgx` it works best for small files so we +recommend when sealing a lot of data to use the native tools, present for your +database or software and instead sealing only the encryption key. + +![Database key sealing](../img/database_key_sealing.jpg) + +