TR and docs (#19)

* Add the CCF technical report (987e4c1)
* Update TR and documentation on crypto

README.md

@@ -51,16 +51,16 @@ to embed one of several language runtimes on top of its key-value store. Clients
 
 ## Learn more and get started
 
- * Get a more detailed breakdown of CCF by reading the CCF Technical Report
- * Explore the CCF open-source GitHub repo, which also contains application examples and sample scripts for provisioning and setting up confidential computing VMs using Azure
+ * Read the [CCF Technical Report](CCF-TECHNICAL-REPORT.pdf) for a more detailed description.
+ * Explore the CCF open-source GitHub repo, which also contains application examples and sample scripts for provisioning and setting up confidential computing VMs using Azure.
  * Learn more about [Azure Confidential Computing](https://azure.microsoft.com/solutions/confidential-compute/) offerings like Azure DC-series (which support Intel SGX TEE)
-   and [Open Enclave](https://github.com/Microsoft/openenclave) that CCF can run on
+   and [Open Enclave](https://github.com/Microsoft/openenclave) that CCF can run on.
 
 ## Getting Started on Azure Confidential Computing
 
 Under `getting_started/`:
  * `create_vm/` contains scripts to create an ACC VM (`make_vm.sh`).
-   This script expects a valid Azure subscription name to be set, eg: `export SUBSCRIPTION=sub_name`
+   This script expects a valid Azure subscription name to be set, eg: `export SUBSCRIPTION=sub_name`.
  * `setup_vm/` contains ansible playbooks that need to be run on the VM once created, for it to be able to build CCF.
    Running `./setup.sh` will apply those playbooks to the VM.
 

sphinx/source/cryptography.rst

@@ -9,45 +9,44 @@ Network
 
 A CCF network has a master secret, which is used to derive keys for multiple purposes:
 
- * A network identity, used in :term:`TLS`
- * A symmetric data key, used to encrypt entries in the ledgers
+ * A network identity public-key certificate, used for :term:`TLS` server authentication.
+ * Symmetric data-encryption keys, used to encrypt entries in the ledger.
 
 Node
 ````
 
-Each CCF node has a key pair. It is used to authenticate the node when it joins the
-network, as well as to sign entries committed by a node to the ledger during its
-time as leader.
+Each CCF node is identified by a fresh public-key certificate endorsed by a quote. 
+This certificate is used to authenticate the node when it joins the
+network, and to sign entries committed by the node to the ledger during its time as leader.
 
-Node keys are also used during recovery, to share recovered network secrets with nodes.
+Node keys are also used during recovery, to share recovered network secrets between nodes.
 
 User
 ````
 
-CCF users have key pairs, used to authenticate their :term:`TLS` connections to the service.
-These keys can also be used to sign user commands.
+Each CCF user is identified by a public-key certificate, used for :term:`TLS` client authentication when they connect to the service.
+These keys are also used to sign user commands.
 
 Member
 ``````
 
-CCF consortium members are identified by key pairs, which are used for authentication when
-connecting to the member frontend.
+Each CCF consortium member is similarly identified by a public-key certificate used for client authentication and command signing.
 
 Ephemeral Network Keys
 ``````````````````````
 
-Each node to node pair establishes a unique symmetric key, using authenticated Diffie Hellman key exchange,
-to authenticate ledger replication headers between the nodes. It is also use to encrypt forwarded
+Each node to node pair establishes a symmetric traffic key, using an authenticated Diffie Hellman key exchange.
+This key authenticates ledger replication headers exchanged between  nodes. It is also use to encrypt forwarded
 write transactions from the followers to the leader.
 
 Algorithms and Curves
 ---------------------
 
-All symmetric encryption in CCF is done with AES-GCM-256 from `Project Everest <https://project-everest.github.io/>`_.
+Authenticated encryption in CCF relies on AES256-GCM. Ledger authentication relies on Merkle trees using SHA2-256. These algorithms are provided by `project Everest <https://project-everest.github.io/>`_.
 
-Asymmetric crypto can be configured to use one of the following implementations:
+Public-key certificates, signatures, and ephemeral Diffie-Hellman key exchanges all rely on
+elliptic curves. They can be configured to use one of the following implementations:
 
- * curve25519/ed25519 from `Project Everest <https://project-everest.github.io/>`_.
- * secp384r1 from `mbedTLS <https://tls.mbed.org/>`_.
- * secp256k1 from `mbedTLS <https://tls.mbed.org/>`_.
+ * curve25519/ed25519 from `project Everest <https://project-everest.github.io/>`_.
+ * secp384r1 or secp256r1 from `mbedTLS <https://tls.mbed.org/>`_.
  * secp256k1 from `bitcoin core <https://github.com/bitcoin-core/secp256k1>`_.

sphinx/source/glossary.rst

@@ -16,7 +16,7 @@ Glossary
     `Trusted Execution Environment <https://en.wikipedia.org/wiki/Trusted_execution_environment>`_ is a secure area of a main processor. It guarantees code and data loaded inside to be protected with respect to confidentiality and integrity.
 
   TLS
-    `Transport Layer Security <https://en.wikipedia.org/wiki/Transport_Layer_Security>`_ is a cryptographic protocol designed to provide communications security over a computer network.
+    `Transport Layer Security <https://en.wikipedia.org/wiki/Transport_Layer_Security>`_ is an IETF cryptographic protocol standard designed to secure communications between a client and a server over a computer network.
 
   JSON-RPC
     `JSON-RPC <https://en.wikipedia.org/wiki/JSON-RPC>`_ is a remote procedure call protocol encoded in JSON.