Cryptography Overview

The following page will show diagrams indicating how the various cryptographic keys are used in the solution.

Cryptographic material

The solution handles many keys for various purposes. All keys can be rotated (replaced with newer keys) according to client defined key rotation policies.

• Server TLS key and certificate: This asymmetric key pair is used in the TLS protocol to encrypt all traffic with the server.
• Gateway HTTPS TLS key and certificate: This asymmetric key pair is used in the TLS protocol to encrypt all HTTPS traffic with the gateway.
• Gateway FTPS TLS key and certificate: This asymmetric key pair is used in the TLS protocol to encrypt all FTPS traffic with the gateway.
• Gateway SSH key pair: This asymmetric key pair is used in the SSH protocol to encrypt all SFTP traffic with the gateway.
• Internal CA: The instance has its own internal CA key pair. All certificates created in this instance are signed using the CA key.
• Server Key Pair: The server has its own keypair and requires all files uploaded to have its public key as one of the "recipient". This allows the server to decrypt the file contents and run extensions that can do post-processing on it.
• User Key Pair: Every account in the solution has its own keypair it uses to sign uploaded files and decrypt keys when downloading files.
• Community Key Pair: All communities (and share) has its own key pair. When a file is uploaded to a community, the public key of the community is used as the recipient.
• File encryption key: Each file is encrypted using a randomly generated symmetric key. This key is encrypted under the public keys of the recipients and kept in the PKCS7 envelope header of the encrypted file.

Key storage

Symmetric file encryption keys

Each file is encrypted using a randomly generated symmetric key (as described above). This symmetric key is stored encrypted under the public keys of the recipients (communities or users) in the PKCS7 envelope header of each individual file. It is not stored separately in the database.

Asymmetric keys (user and community key pairs)

• The public keys (certificates) are stored in the Certificate database table.
• The corresponding private keys are stored in the PrivateKeys database table.
• Keys in these tables are stored obfuscated but not encrypted at the application layer.
• If the database uses encryption such as Transparent Data Encryption (TDE), the key material will benefit from this additional layer of protection at rest.
• If a key needs to be revoked (e.g. due to a suspected compromise), see How to revoke an asymmetric key.

TLS and SSH cryptographic material

• The cryptographic material used for TLS protocols (HTTPS, FTPS) and SSH keys (SFTP server) is stored obfuscated in the CryptographicMaterial database table.
• The same considerations about TDE apply.

Uploading a file using HTTPS end-to-end transfer

To have end-to-end encrypted transfers, in addition to the usual transport security (TLS), the client (web browser) generates a key pair to retrieve keys directly from the server. It then generates itself the symmetric file encryption key and encrypts it under the recipient and server public keys before sending it to the gateway. The gateway does not have the corresponding private keys, so it cannot decrypt the file encryption key, it puts it directly in the PKCS7 envelope header in encrypted form and assembles the rest of the PKCS7 envelope.

Downloading a file using HTTPS end-to-end transfer

Uploading a file using HTTPS (without end-to-end) or FTPS

Downloading a file using HTTPS (without end-to-end) or FTPS

Uploading a file using SFTP

Downloading a file using SFTP