corrected errors and update of How it works page

mithril-security · Aug 1, 2024 · e87a6ee · e87a6ee
1 parent 742853e
commit e87a6ee
Show file tree

Hide file tree

Showing 5 changed files with 6 additions and 11 deletions.
diff --git a/docs/assets/secure-tooling-dark.png b/docs/assets/secure-tooling-dark.png
diff --git a/docs/assets/secure-tooling-light.png b/docs/assets/secure-tooling-light.png
diff --git a/docs/docs/concepts/attestation.md b/docs/docs/concepts/attestation.md
@@ -14,7 +14,7 @@ The process of receieving and verifying these proofs is called **attestation**,
 
     The goal of this process is to check that the code running is indeed the code of the application we are expecting and has not been tampered with. It isn't to audit the application code itself. You can think of this a bit like a checksum when you download a software!
 
-## How do we implemet attestation in BlindLlama?
+## How do we implement attestation in BlindLlama?
 
 With BlindLlama, we measure our enclave code using a virtual TPM (vTPM). We are able to measure the whole software stack of our enclave, from the UEFI to our custom OS, which can then be verified (or **attested**).We also measure and attest additional custom data such as the enclave's application code and TLS certificate.
 
@@ -29,7 +29,7 @@ With BlindLlama, we measure our enclave code using a virtual TPM (vTPM). We are
 
 ### Server side: Measuring the software stack
 
-Let's firstly takea  look at how the server provides cryptographic proof of its codebase.
+Let's firstly take a  look at how the server provides cryptographic proof of its codebase.
 
 When the TPM-enabled machine used for server deployment is booted, various default measurements are taken, such as hashes of firmware, boot loaders, and critical system files. These hashes are stored in the TPM's PCRs (Platform Configuration Registers), a set of registers, or locations in memory, within the TPM itself.
 
@@ -63,7 +63,7 @@ The BlindLlama server includes this TPM's quote in a cryptographic proof file, w
 
 When an end user queries our BlindLlama API, before a secure connection can be established with the server, the client will receive and verify the server's **cryptographic proof file**, which contains **the TPM's quote** signed by the private AK. 
 
-The client also receives a [cert chain](https://www.ibm.com/docs/en/ztpf/1.1.0.15?topic=ca-certificate-chain-verification), a chain of certificates, which is used to verify the TPM quote’s signature.
+The client also receives a [cert chain](https://www.ibm.com/docs/en/ztpf/2024?topic=ca-certificate-chain-verification), a chain of certificates, which is used to verify the TPM quote’s signature.
 
 Verification is done in done in three steps:
 

diff --git a/docs/docs/getting-started/how-we-protect-your-data.md b/docs/docs/getting-started/how-we-protect-your-data.md
@@ -17,15 +17,12 @@ At the end of this process, users will know that when using our Python SDK, **th
 
 ## Server side
 
-[TODO: UPDATE THIS IMAGE]
-
 ![toolchain-light](../../assets/secure-tooling-light.png#only-light)
 ![toolchain-dark](../../assets/secure-tooling-dark.png#only-dark)
 
 ### 1. Deploying the API in an enclave
 
-[TEXT TODO]
-
+<!-- [TEXT TODO] -->
 We provide more details about **enclaves** in our [concepts guide](../concepts/enclaves.md).
 
 ### 2. Proving privacy controls are applied
@@ -39,8 +36,6 @@ Not only do we attest the code loaded in our backend.
 You can learn more about attestation and attested TLS in our [concepts guide](../concepts/attestation.md).
 
 
-
-
 ### 3. Auditing the whole stack
 
 The security and privacy properties we provide are derived from code integrity, i.e. having cryptographic proof that the server we connect to is running the expected BlindLlama open-source code.
@@ -67,7 +62,7 @@ This is done by verifying the proof file provided by the server. This file is de
 
 ### 2. Attested TLS
 
-The server also provides the client with its TLS certificate. This is unique to the server and is used by the client to verify they are talking to the genuine BlindLLama server. If the verification is succesful, the TLS certificate is used to communicate with the hardened AI server using TLS. 
+The server also provides the client with its TLS certificate. This is unique to the server and is used by the client to verify they are talking to the genuine BlindLLama server. If the verification is successful, the TLS certificate is used to communicate with the hardened AI server using TLS. 
 
 > The TLS certificate is signed by a private key that lives inside and never leaves the hardened environment. 
 

diff --git a/mkdocs.yml b/mkdocs.yml
@@ -105,7 +105,7 @@ nav:
 
 # - 🚀 Getting Started:
 #   - Architecture: 'docs/getting-started/design.md'
-#   - How it works: 'docs/getting-started/how-we-protect-your-data.md'
+- 🚀 How it works: 'docs/getting-started/how-we-protect-your-data.md'
   #  - Quick tour: 'docs/getting-started/quick-tour.ipynb'
 
 - 💡 Concepts: