This is an automated email from the ASF dual-hosted git repository.
mssun pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-teaclave.git
The following commit(s) were added to refs/heads/master by this push:
new e7d93b6 [dcap] Add README.md
e7d93b6 is described below
commit e7d93b6db0b489085bb3415749667b5186d6dce5
Author: Mingshen Sun <[email protected]>
AuthorDate: Tue Apr 28 14:37:12 2020 -0700
[dcap] Add README.md
---
config/README.md | 2 +-
dcap/README.md | 20 ++++++++++++++++++++
docs/mutual-attestation.md | 4 ++--
docs/my-first-function.md | 2 +-
docs/threat-model.md | 2 +-
5 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/config/README.md b/config/README.md
index 3d4e0db..76e4ae7 100644
--- a/config/README.md
+++ b/config/README.md
@@ -2,7 +2,7 @@
This Teaclave Config describes all sorts of configurations in the platform. All
configurations are defined in the TOML file format. Basically, there are two
types
-of configurations in Teaclave: build config and runtime config.
+of configurations in Teaclave: *build config* and *runtime config*.
## Build Config
diff --git a/dcap/README.md b/dcap/README.md
new file mode 100644
index 0000000..24aea41
--- /dev/null
+++ b/dcap/README.md
@@ -0,0 +1,20 @@
+# Data Center Attestation Service
+
+This directory includes a reference implementation of data center attestation
+service using
+[Intel SGX Data Center Attestation
Primitives](https://software.intel.com/en-us/blogs/2019/05/21/intel-sgx-datacenter-attestation-primitives)
(DCAP),
+which allows third-parties to create their own attestation infrastructure for
+the datacenter and cloud. Compared to Intel Attestation Service (IAS), DCAP
+Attestation Service is for environment where internet services is not
accessible
+and entities who are unwilling to outsource trust decisions to third-parties
+(like Intel's IAS).
+
+By default, Intel Attestation Service (IAS) will be used for attestation in
+Teaclave. To use DCAP instead of IAS, you have to first build Teaclave with
DCAP
+enabled (by appending `-DDCAP=ON` option to `cmake`) and deploy in
+infrastructure with DCAP supported.
+
+The Intel's [DCAP Installation
Guide](https://download.01.org/intel-sgx/sgx-dcap/1.3.1/linux/docs/Intel_SGX_DCAP_Linux_SW_Installation_Guide.pdf)
+contains instructions to install essential dependencies for developers. Also,
+you need to prepare environment in your infrastructure before deploying a
+DCAP-enabled application.
diff --git a/docs/mutual-attestation.md b/docs/mutual-attestation.md
index 2479638..796bbfd 100644
--- a/docs/mutual-attestation.md
+++ b/docs/mutual-attestation.md
@@ -2,7 +2,7 @@
The standard procedure to establish a secure and trusted communication channel
from a client to an enclave is through remote attestation. However, when the
-client itself is also an enclave and **mutual** trust between two enclaves is
+client itself is also an enclave and *mutual* trust between two enclaves is
required, we need additional design and implementation effort. The Teaclave
platform consists of multiple enclave services and most of the
enclave-to-enclave RPC communications need bidirectional authentication. This
@@ -32,7 +32,7 @@ that there will be several parties trusted by all
participants of Teaclave's
computation tasks (could platforms, data providers, and customers, etc). The
source code and binaries of Teaclave are audited by these trusted parties. Once
the auditors decided that Teaclave is secure, they sign and publish the
-identities of audited enclaves. The **public keys** of the auditors are
+identities of audited enclaves. The *public keys* of the auditors are
hard-coded in Teaclave enclave source via build time configuration, while the
enclave measures and their signatures are loaded from outside at runtime. Each
enclave will verify that the enclave measures are indeed signed by the auditors
diff --git a/docs/my-first-function.md b/docs/my-first-function.md
index 94ff01a..5bb4fe9 100644
--- a/docs/my-first-function.md
+++ b/docs/my-first-function.md
@@ -43,7 +43,7 @@ $ docker run --rm -v $(pwd):/teaclave -w /teaclave \
To build in simulation mode, you can add `-DSGX_SIM_MODE=ON` to `cmake`.
-### Launch Teaclave
+## Launch The Teaclave Services
Teaclave contains multiple services. To ease the deployment, you can use
[docker-compose](https://docs.docker.com/compose/) to manage all services in a
diff --git a/docs/threat-model.md b/docs/threat-model.md
index 4251da3..4714f1b 100644
--- a/docs/threat-model.md
+++ b/docs/threat-model.md
@@ -32,7 +32,7 @@ with everyone's privacy respected.
In the settings above, the root of trust converges to the enclave manufactures
(i.e., Intel) and its SGX-enabled CPU chips. Before the computation starts,
Teaclave is booted as a secure SGX enclave on one of these CPUs owned by the
-cloud service provider. After that, each party can **remotely** attest the
+cloud service provider. After that, each party can *remotely* attest the
authenticity of the hardware and the integrity of Teaclave platform through
attestation service (e.g., Intel Attestation Service). Private data are
securely
provisioned to the Teaclave enclave only if the attestation passes. After the
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
