# Certificates

<figure><img src="https://992309858-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F16SLHNsoOkGFPdpaQYzQ%2Fuploads%2F09gujY6KhPUvZ8cpcqSY%2Fcert_verify.png?alt=media&#x26;token=2b29a702-37a8-4e9f-8dd7-27f9643b95e5" alt=""><figcaption></figcaption></figure>

To ensure that all secrets are securely stored and the entire application is protected from the cloud provider and a potential adversary, all enclaves must be certified. To solve the problems in the previous subsection, the solution relies on the KMS as a trust anchor, a cloud customer doing proper configuration, and the message integrity for data-in-transit provided by TLS. By design, the KMS always verifies the remote attestation reports of all it's clients to grant access to secrets only to authorized SECS. This is useful for verifying the entire architecture.

* First, the cloud customer must create a wildcard certificate, such as through a DNS-01 challenge from Let's Encrypt. DNS-01 challenges cannot be done by an acme client alone and therefore cannot be integrated into an enclave, so the cloud customer must generate the wildcard certificate first. The important thing here is to create and store the private key on the cloud customer's local machine, and to provision it later using Secret Key Provisioning (Figure above Step 1).
* In addition, the cloud customer must make sure that it's own system is not infected, otherwise the secret key can be leaked. The wildcard certificate must be issued by a recognized CA, as the client must also verify it. All connections to the KMS are made via RA-TLS, where the KMS verifies the attributes and the certificate chain. Within the KMS the wildcard certificate should be associated with the MRENCLAVE and MRSIGNER of the Activator and Queue Proxy, so that only they are able to retrieve it (steps 2 and 5). In addition, certificates of a SECS should be associated with a domain within the KMS and have the domain covered by their measurement, for example by storing it in Gramine's manifest as an environment variable. This way a SECS can only be used for a specific domain and it allows to distinguish between SECS with the same code.
* The next step (step 3) is to create a user associated with a MRENCLAVE, MRSIGNER and a domain within the KMS.&#x20;
* The KMS should then in turn be a CA, create the private key and associated certificate for the provided domain (Step 4).&#x20;
* When the SCSC is deployed, the Queue Proxy (step 5) receives it's wildcard certificate and the SCSC receives the certificate signed by the Vault (step 6).&#x20;
* Now, when a client sends a request to either the Activator or the Queue Proxy, the wildcard certificate is verified first. If it is issued by a recognized CA, it forwards the request (Step 7).&#x20;
* In the case of the Activator, the Activator must verify the Queue Proxy to see if it has the same certificate as itself. If so, it can trustfully forward the request to the Queue Proxy (step 8).
* Now the next step is a bit different when the Queue Proxy contacts the SCSC. Each Queue Proxy must know the root certificate of the vault. This can be done by including it in the enclave with Gramine's trusted file feature so that it is covered by the measurement. So first it will verify that the SCSC's certificate is indeed issued by the Vault. Then it checks the host header in the HTTP request to see if it matches the domain referenced in the certificate. If it does, it forwards the request to the SCSC. This ensures that if the message is routed to an incorrect Queue Proxy, but the proxy is benign, the message is not routed to an incorrect SECS.&#x20;

By sending the request only over TLS to trusted enclaves, the integrity of the request's HTTP host header is guaranteed. The assumption also relies on the fact that only benign Activators and Queuing Proxies should be in possession of the wildcard certificate, which is guaranteed by the KMS. As a result, the KMS is the central trust anchor for the entire request path. It is easy for a cloud customer to misconfigure this, which can lead to huge security risks, e.g. by associating a wrong MRENCLAVE with the wildcard certificate.

## KMS Verification

One problem remains, and that is that the client needs to verify the KMS and be sure that the wildcard certificate used was actually provided by that KMS. One attack vector would be for a malicious domain provider to be able to get wildcard certificates issued for any of their customers. This would allow the customer to connect to a malicious Activator and Queue Proxy. The cloud customer itself, since it generated the key pair referenced in the certificate, is able to detect this type of attack by simply verifying the certificate with the correct public key. For a client of the cloud customer, this becomes a bit more difficult because the client does not know which public key is non-malicious. This could be solved by the client having the correct public key of the wildcard certificate hard-coded into it's frontend. In addition, the frontend should run in an enclave to measure the public key and prevent tampering with it. The TLS private key and certificate of the frontend, if it is not a desktop application, should be generated inside the frontend using an HTTP-01 challenge and stored in the KMS. Since the frontend now needs to be verified by the client in order to trust it, an attestation verification service (AVS) can be used, which is described in [remote-attestation-verification](../remote-attestation-verification "mention").&#x20;

Due to the fact that the public key of the wildcard certificate is hard-coded into the frontend, by verifying the frontend, it acts as a trust-anchor to verify the Activator, the Queue Proxy, and the SECS. In addition, if the frontend also has the public key of the KMS hard-coded into it, then verifying the frontend is sufficient to act as a trust-anchor that verifies the entire architecture, assuming that the verifier has the correct measurements of the frontend. Since the frontend communicates only with benign Queue Proxies and Activators, which is confirmed by the KMS, it trusts the Queue proxy and Activator to verify the next component in the request path. This is a valid assumption, since only Queue proxies and Activators with the correct code should be able to obtain the wildcard certificate. If the frontend is open source and published on a platform such as Github, the client can deploy the frontend itself to get the correct measurement. To perform the above attack, Github must work with the domain provider to include its public key in the source code. Therefore, it is imperative that Github is not the domain provider, as is the case with Github Pages, otherwise Github can do this on its own. Client certification of the KMS is only required if the client communicates directly with the KMS.

Knative offers the option to enable auto-tls, which will automatically generate a LetsEncrypt signed TLS certificate for each newly created Knative Service and stores it in Kubernetes secrets. Although with auto-tls each service has its own key pair for TLS, this key pair is stored in the untrusted etcd, making all key pairs used in auto-tls untrusted. This results in the auto-tls feature not being usable.

The main advantage of this architecture is that the user application does not require any modifications. The best solution would be for Knative to allow TLS passthrough, but since this is not supported, a workaround is needed.
