End-to-End Encryption Whitepaper

When sharing sensitive information via the cloud, strong security measures should be employed to ensure data integrity and data privacy. This whitepaper provides a detailed technical description of the encryption system CALIPIO implemented to protect customer data. The majority of the cloud service providers do not offer this level of protection to it’s customers. CALIPIO is willing to go the extra mile by protecting customer data with end-to-end encryption while keeping user-friendliness.

This post is intended for security engineers and those that are well versed in encryption technologies. If you are looking for a more high level description continue reading Better safe than sorry – CALIPIO’s approach to End-to-End Encryption

Layers of encryption

CALIPIO takes security seriously, therefore CALIPIO uses two layers of encryption to protect customer data. This chapter discusses the different layers and illustrates the major benefits of using end-to-end encryption. The following figure shows the two encryption layers and possible points of attack.

Transport layer encryption

Transport layer security (TLS) provides communication security over a computer network. TLS can be used to secure client-to-server or server-to-server communication. TLS provides reliable communication by using message authentication codes (MAC) to prevent undetected loss or modification of data.

The transport layer encryption protects the communication channel and ensures that data cannot be intercepted or manipulated. While data is perfectly secure during transmission, it is available in plain text as soon as it leaves the secure communication channel. At the server level, data processing and storage is performed outside the transport layer security. Thus, without additional measures, anybody with access to the server or storage is able to read or manipulate sensitive customer data. In most instances hackers are not to blame for gaining unauthorized access to the server infrastructure. More likely is a scenario in which an employee with access to the server infrastructure or cloud providers themselves could gain access to customers’ data. It is therefore essential that customers trust that the operator is committed to safeguarding their data.

CALIPIO is only using secure TLS protocol versions 1.2 and 1.3. The outdated TLS protocol versions 1.0 and 1.1 are therefore disabled.

End-to-End Encryption layer

When handling customer data, it is important to ensure data protection and privacy. CALIPIO fulfills these high requirements as the system is not able to access the unencrypted customer data by design. All data is encrypted at the client-side, before transmitting it to the CALIPIO cloud. CALIPIO servers are processing encrypted customer data only. The servers are not able to decrypt this data because the keys are not known by the CALIPIO cloud. The stored customer data is still end-to-end encrypted and cannot be decrypted.

Additionally, client-to-server and server-to-storage communication is protected by transport layer encryption. A possible attacker is not able to access or modify customer data because they are ​encrypted by ChaCha20​ stream cipher and tamper protected by Poly1305​.

CALIPIO provides ​perfect forward secrecy​ (PFS) by using a different 256-bit encryption key for each recording. This means that even if an attacker knows the encryption key of a single recording, it is not possible to decrypt other recordings with the same key. End-to-end encryption makes it impossible for the cloud provider to collect sensitive customer information and share it with third parties. Even in the event that customer data has to be handed over to the authorities, it cannot be accessed in plain text. Not even CALIPIO is able to decrypt customer data. CALIPIO will use state-of-the-art encryption algorithms to provide the best possible data protection for its customers.

Cryptographic library

CALIPIO uses the cryptographic library libsodium for cryptographic operations. Transport layer encryption is implemented by the web browser being used and is not part of this whitepaper. ​libsodium ​is an ​open-source​, portable and cross-platform compatible fork of the cryptographic library NaCl. For more information and the source code, see the following links.

libsodium documentation: https://libsodium.gitbook.io/doc/
libsodium github: https://github.com/jedisct1/libsodium

Stream encryption

A CALIPIO recording can consist of multiple streams. For example a screen, audio, or webcam stream. Each of these data streams is encrypted and tamper protected by using the ​ChaCha20-Poly1305 ​algorithm. The data is encrypted using the ​ChaCha20 ​stream cipher and authenticated by ​Poly1305 ​message authentication code. This encryption algorithm is part of TLS 1.3.

A unique 256-bit key is used for each stream. The next chapter describes the generation of unique stream keys based on a single recording key. Stream data can be chunked into multiple parts. The chunk size depends on the type of stream and is controlled by the application. By using different keys for each stream we can use the same starting nonce for all streams. The nonce will be incremented after each encrypted stream chunk.

The initial 192-bit nonce is randomly generated at the client-side. The stream key, the nonce and the stream data are used as input parameters for ChaCha20-Poly1305​ encryption. The nonce is not confidential and will be stored in the CALIPIO cloud. It will be associated with the recording and can be retrieved by the client.

Recording and stream key generation

A unique 256-bit key is randomly generated to encrypt the recording at the client-side. The recording key is used to generate a 256-bit key for each stream of the recording. These keys will be called stream keys. The stream keys are generated with the ​blake2b ​hash algorithm. The recording key, the stream ID and the stream context are used as input parameters for the hash function.

BLAKE2B-256(key=recording key, message={}, salt=stream id, personal=stream context )

The type of stream is used as a stream context when generating the stream key. For example “AUDIO___” or “MEDIA___”. The stream ID, as well as the stream context, are not confidential. The stream ID and the stream context will be calculated by the CALIPIO software based on the recordings’ metadata. Therefore, it is not necessary to transfer them to the CALIPIO cloud.

Recording key encryption

It is more convenient to transmit a human-readable password than a 256-bit recording key. Therefore, a user-chosen or randomly generated password is used to encrypt the recording key. The encrypted recording key will be stored in the CALIPIO cloud. Without knowing the password it is impossible to decrypt the recording key.

The password is used as input for the ​Argon2id13​ key derivation function [3]. A 256-bit secret key will be generated based on the password. Argon2id13 is configured to perform two iterations and consume 128 Mib of RAM. The salt configuration parameters (like the used algorithm), iterations and memory limit can easily be changed in the future. These parameters are not confidential and will be stored in the CALIPIO cloud.

The derived key is used to encrypt the recording key with authenticated encryption using ​ChaCha20-Poly1305​. A wrong password can be detected when decrypting the recording key because of the message authentication code (MAC) applied to the encrypted recording key.

Big picture of CALIPIO’s end-to-end encryption

When putting together key generation, key encryption and stream encryption, the whole process of end-to-end encryption becomes visible. As shown in the figure below, key generation and encryption take place on the client side. The encrypted stream data, password encrypted recording key as well as non-confidential parameters, salt and nonce are stored in the CALIPIO cloud. The transfer from the web browser to the CALIPIO cloud is protected by transport layer security.

Recording links

Sharing end-to-end encrypted CALIPIO recordings is as user-friendly as sharing non-encrypted content. CALIPIO recordings can be shared by just sending a link. This chapter explains how CALIPIO achieves this high level of user-friendliness by maintaining CALIPIO’s high level of security.

https://recorder.calipio.com/play/HRA1nLVw#Ga42PBx7
https://recorder.calipio.com/play/<recording-id>#<password>

A CALIPIO link contains a recording ID (highlighted in red) and a password (highlighted in green). Each recording is identified by its recording ID. The web browser can download the encrypted recording data from the CALIPIO cloud by providing the recording ID. The recording key is necessary for decrypting the recording in the web browser. As described in the chapter “Recording key encryption” the recording key is encrypted by a password. The password contained in the link is used to decrypt the recording key.

To maintain zero knowledge of encryption keys it is absolutely critical that the password is never transmitted to the CALIPIO cloud. A web browser does not transmit the fragment component of a URL to the server. The fragment component of the link is preceded by the # character. The password is the fragment component of the CALIPIO link. Therefore, the password is never transmitted to the CALIPIO cloud but the CALIPIO javascript application (executed in the web browser) is able to process the password. 

The recording ID and password can be transmitted separately if required. If the password part is missing in the CALIPIO link, the user will be prompted to enter the password in the web browser.