Architecture - Attackers, Threats and Solutions

The first step in understanding how to secure data and applications in a zero-trust environment is to look at potential attackers and their threat model. We assume the application code is safe and that we do not need to protect against the software developer.

Attacker	Access	Threats
Passive 3rd party	insider	may get a copy of the disks content
Man in the middle	external network	may intercept the data in transit
Infrastructure admin.	physical access + network	may externally look at memory, disk contents and network traffic may change hardware or spoof server names, redirect traffic
System admin.	OS level access	may access and change memory, disks content and network traffic. may modify the code or run malicious code
Application admin.	authorization stack	may escalate privileges to access the data

Protection against all attackers

Client-side encryption is the only ubiquitous solution that protects against all attackers because data is encrypted by the data owner under its own key before it reaches any of these attackers. Enabling client-side encryption without loss of functionality usually requires a modification to the application and the use of a few Cosmian products: Cosmian Covercrypt, Cosmian KMS and possibly Cosmian VM and Cosmian Findex.

See the last use case on this page for details.

Protection against a reduced list of attackers

When the threat model is limited to a reduced list of attackers, other solutions may be used. The following table summarizes the solutions that Cosmian provides to protect against each attacker.

Attacker	Solution Name	Cosmian Products
Passive 3rd party	Encryption at rest	Cosmian Covercrypt: post-quantum encryption with access policies Protects against the “Harvest now, decrypt later” risk + limits key leakage
Man in the middle	Encryption in transit	TLS
Infrastructure admin.	Memory Encryption	Cosmian Enclave or Cosmian VM: verifiable encrypted memory at runtime
System admin.	Sealed Encrypted Memory	Cosmian Enclave: verifiable enclaved encrypted memory at runtime that is immutable from the outside (the underlying OS)
Application admin.	Covercrypt encryption	Client-side encryption with Cosmian Covercrypt: access policies in user decryption keys prevent the user from decrypting data not authorized by its key

Use case: move to the cloud

When moving an application for its own users to the cloud, the main threat is the cloud provider itself. It is assumed that the system administrators and the application administrators are trusted.

In that particular case the use of TLS connections to applications running in Cosmian VMs with a simple at-rest encryption scheme is sufficient to protect the data and the application from the cloud provider. The Cosmian VM integrity is remotely verifiable by the user, preventing the infrastructure administrator from tampering with the VM hardware or software.

Use case: protect code at client’s premises (or client’s cloud)

When the application code is to be deployed at a client premises (or cloud), and needs to remain secret (such as an AI model), the main threat is the client’s system administrator.

Cosmian Enclave is the solution that lets the code provider encrypt its code under its own key, deliver it encrypted to the client’s system administrator. The encrypted code is then loaded in an enclave with encrypted memory, and before securely provisioning the code encryption key to the enclave, the code provider can then verify that the code is correctly deployed inside the enclave. Check this section for more details.

Use case: a 3rd party SaaS platform running in the cloud

From a user’s perspective this is the use case where its data is exposed to all potential attackers: client side encryption will be the answer to protecting its data.

Enabling client-side encryption

From the SaaS provider perspective, this means making a client-side encryption API available to its users. If the application offers a web interface, the web application will need to be modified to encrypt the data before sending it to the servers. Encryption will require the ability to connect to a KMS from the web application. Performing encryption client-side will require

• either Cosmian javascript (or Dart, or Java, etc.) encryption libraries running client-side with calls to the Cosmian KMS server to fetch keys
• or direct encryption/decryption calls to the Cosmian KMS which can perform encryption on the fly in a scalable manner.

An example: Google Workspace

Google Workspace is a good example of a SaaS application that offers client-side encryption out of the box. Google made an API available that allows connecting compatible Key Management Systems such as Cosmian KMS to encrypting data in the browser.

Thanks to Cosmian VM, the user does not even have to install its KMS on premise. The KMS can be deployed in a Cosmian VM on GCP, which will protect it from Google and its browser can connect to it over a TLS connection.

Likewise, other services, such as document summarization using a language model, can be deployed in a Cosmian VM and made available to the user through a web interface. The user’s data will be encrypted by the TLS connection to the AI service and will only be available to service in encrypted memory which is protected from Google.

Cosmian VM and Cosmian KMS will soon be offered as IaaS services on the Google marketplace and other hyperscalers marketplaces.

SaaS platform: distributing keys between clients

When using client-side encryption in a SaaS platform setting, some users may need to be able to decrypt data from another user that was encrypted with a key that they do not have. This is the case, for example, when a user shares a document with another user. The document is encrypted with the key of the user that created it.

The Cosmian KMS offers a key sharing mechanism that allows users to share keys with other users. The key sharing mechanism is based on a standard Public Key Infrastructure (PKI) available in the KMS which offers the ability to wrap a decryption key under the public key of another user. The receiving user can then unwrap the key using its own private key.

The users can safely use the Cosmian KMS PKI deployed in the cloud because the KMS does not have access to the private keys of the users.

Say Client 1 wants to provide Client 2 with a decryption key sk_a to decrypt data previously encrypted with Covercrypt with Client 1’s public key pk_1.

This decryption key is sensitive and should be wrapped under Client 2’s public key to be transferred from Client 1’s KMS to Client 2’s KMS. Since their KMS cannot communicate, the clients are using the Public Key Infrastructure (PKI) built in Cosmian KMS to exchange keys.

The typical flow for the distribution of a decryption key is illustrated in the following diagram.

Say Client 1 wants to provide Client 2 with a decryption key sk_a to decrypt data previously encrypted under Client 1’s key.

1. Client 2 (the recipient) generates a key pair sk_2/pk_2 and publishes its public key pk_2 wrapped in a certificate to the SaaS PKI.
2. Client 1 recovers Client 2’s certificate containing pk_2.
3. Client 1 wraps (i.e., encrypts) the decryption key sk_a under the public key pk_2 and publishes the wrapped key in the SaaS PKI.
4. Client 2 recovers the wrapped key sk_a from the SaaS PKI and unwraps it (i.e. decrypts it) using its private key sk_2.