Skip to content

SaaS

To enjoy the KMS using the SaaS offering on the Cosmian public platform, contact us to get a preview access.

Contact us to get access

Compared to the on-premise self-installation, this service is configured using:

  • A database running inside an SGX enclave. Cosmian can’t therefore access its content.
  • The SSL certificates of the HTTP server are generated by the enclave. Cosmian can’t therefore access them, so that the communications between you and the server are completly secure.

The KMS supports a payload (file to encrypt/decrypt) size up to 10GB. Sending a larger payload will result in a 413 HTTP error.

Trustworthiness

The KMS enables you to check its trustworthiness. To do so, three routes are useful, using GET method:

  • /quote?nonce=<nonce> returning the quote of the KMS running inside the enclave. It takes a nonce as parameter which is an arbitrary and non predictable string. The returning quote is base64 encoded.
  • /certificates returning the SSL certificate and the enclave public key of the HTTPS server
  • /manifest returning the manifest of the enclave. You can therefore analyse the hashes of the trusted files and the execution context such as env variables or enclave parameters

With these three routes, you can proceed a remote attestation on Microsoft Azure Service. Note that the report data of the quote is generated has follow:

report_data = Sha256( certificate + nounce )

Let’s explain why:

  • The ssl certificate is encrypted using the mr_enclave key. Therefore if the server is updated, the certificates will be also updated and the quote will vary. Moreover this parameter is public, so you are plenty aware when the certificate changes.
  • The nonce is added to make the quote unique each time the user want a proof a trust. It uses an arbitrary and non predictable string. The kms server can’t therefore send a previous verify version of the quote.

Once obtained the remote attestation, you can proceed several checks:

  • assert the KMS server runs inside an SGX enclave known by Intel
  • assert the quote inside the remote attestation is the same as the quote returned by the enclave
  • assert the mr_enclave and mr_signer are the same between the Remote Attestation and the quote
  • assert the mr_enclave and mr_signer are the expected ones. See below.
  • assert the Remote Attestation is not outdated (time is between iat and exp)
  • assert the quote’s report data is both the same in the remote attestation and in the quote

mr_signer

This value enables you to verify that the KMS is running inside an enclave which belongs to Cosmian. Indeed this value is a sha256 hash of the public key used to sign the enclave.

This value can be compute by the CLI and compared against the values obtained from the quote and the remote attestation.

If the value is altered, it could mean that you are not using the Cosmian KMS in the Cosmian infrastructures. You shouldn’t proceed and you should report that incident to us.

mr_enclave

This value enables you to verify that the KMS code and libraries inside the enclave are the same as the code you can read on Cosmian Github.

You can get the open-sourced KMS docker, read the mr_enclave from it and compare it against the values obtained from the quote and the remote attestation.

sudo docker run \
    -v public_data:/root/public_data \
    -it enclave-kms --emulation

The mr_enclave can be read from the output of the docker itself.

Measurement:
    c8e0ac76ee1b9416e53890677cbbce8a5f1d8bf2f1c7ab208c1e0efa56e8cea2

Attributes:
    mr_enclave: c8e0ac76ee1b9416e53890677cbbce8a5f1d8bf2f1c7ab208c1e0efa56e8cea2

If the value is altered, it could mean that you are not using the KMS from Cosmian but a modified one. You shouldn’t proceed and you should report that incident to us.

The database

The database is read by the KMS server from the enclave and the database filesystem are encrypted for the host. The key to decrypt the database are unknown by the KMS until the user sent it for each query, by adding the header: KmsDatabaseSecret following by the user secret token.

The key was firstly provided to the user by the KMS when the user registers a new group. A group has two properties:

  • The users belonging to the same group share the same key to decrypt the database. That is to say, the KMS splits the database into independant databases.
  • These same users can share KMS objects between each other.

You can create a new group and getting the key by querying the KMS using POST method to the endpoint /register.

Cosmian can’t get the database keys at any point because of the three following properties:

  • the link between the KMS and the user is SSL-encrypted,
  • the memory of the KMS is located inside the enclave,
  • the ssl key material is located inside the enclave,

© Copyright 2018-2022 Cosmian. All rights reserved