The ProtonDrive security model

This article documents ProtonDrive’s security model by showing how it uses end-to-end encryption to protect your sensitive data. While somewhat technical, this document is meant to be accessible to a general audience and attempts to explain how ProtonDrive works in plain language.

ProtonDrive is in the final stages of development before our beta launch later this year.

Overview

ProtonDrive is the newest addition to the Proton encrypted ecosystem. It offers secure online storage space for our users’ photos, documents, and other files with the same focus on privacy and security as the other Proton products.

ProtonDrive’s design is based on end-to-end encryption. This model prevents any attacker who gains access to one of our servers from:

• viewing the file structure in the users’ personal storage space 
• viewing or changing the contents of their files
• viewing or changing the file names
• adding new files and attributing them to the user

With this in mind, our goal is to ensure that the presence of encryption does not hinder the user in any way from seamlessly:

• uploading, downloading, and previewing files
• organizing their ProtonDrive content into folder hierarchies
• moving, renaming, and deleting files and folders 

Data model

All content in ProtonDrive lives inside a volume, an allotted amount of storage space, with each user having their own private volume. In the future, ProtonDrive will allow administrators to create a volume for their organization and to offer access to members of the organization. 

Each file and folder in ProtonDrive is described by two entities: 

1. a node — this keeps track of the entry’s metadata (for example, type, size, creation, and modification time) and its attributes  
2. a link — this identifies the entry’s position in the folder tree. The link indicates the entry’s location by referencing the parent entry and by storing the name of the entry. 

This model, similar to the Portable Operating System Interface (POSIX) file system model, facilitates communication and synchronization between ProtonDrive and the file systems on your device and will support the app on desktop and notebook in the future. In the case of files, the associated node also references the file content, which is split into multiple blocks, each with a maximum size of 4 MB.

Access

Accessing a volume is always done using a piece of information known as a share. A share can be seen as a kind of access card that provides a user with certain permissions and access to a specific part of the folder tree. A share, thus, has three functions:

• It references a link in the tree
• It limits the operations that can be performed on the content (ex: read-only, write-only, etc.) 
• It carries the cryptographic material required to start the decryption process of the content 

Each volume has a default share, corresponding to the root of its folder tree without any permission restriction.

Multiple users can be members of a share, and each membership can have its own permissions (admin, read, or write). This enables sharing content between Proton users or between members of an organization. A different method for sharing content with people without a Proton account is described in a later section.

Main encryption model

In this section, we describe the way content is encrypted in ProtonDrive. While there are many similarities with the ProtonCalendar encryption model, the difference lies in ProtonDrive’s hierarchical content structure, in which folder trees can have different depths. This means the decryption steps are repeated at each level of the tree.

All keys and passphrases are generated on the client’s side and only transmitted to the server in encrypted form. Similarly, file and folder names, as well as file contents, are only sent to the server in encrypted form, making it impossible even for Proton to decrypt any of these entities. 

Accessing shares

Proton users with multiple ProtonMail email addresses can have multiple email addresses associated with their ProtonDrive account. Each address has an associated key that allows the account owner to access a share when they become a member. 

When the share is created, the encryption system generates a 32-byte random share passphrase, along with an asymmetric key (the share key). The share key is locked using the share passphrase, which is encrypted and signed with the user’s address key. 

In the case of multiple share members, the share passphrase is encrypted with each member’s address key.

Payload encryption

The PGP encryption method allows using multiple asymmetric keys or passwords to encrypt a payload. PGP begins the encryption process by generating a new symmetric session key, which is a random passphrase of sufficient length. The session key is used to encrypt the payload, producing the data packet. 

The next step is to encrypt the session key, in turn, with each asymmetric key and each password provided by the user, resulting in multiple key packets. Each asymmetric key or password can decrypt its corresponding key packet and use the session key within to then decrypt the data packet. (See figure 5)

Allowing a new key (i.e., a new user) to decrypt the payload is a simple operation that doesn’t alter the data packet — only the session key needs to be encrypted again with the new key, producing a new key packet.

Files and folders are arranged in a tree structure. Therefore, there is a recurring pattern where a file or folder’s asymmetric key is locked with a passphrase, which in turn is encrypted with the asymmetric key of their parent folder. All passphrases are signed with the address key of the user, without which a malicious server could forge the contents of the tree.

Node encryption

For each node in the tree, whether a file or a folder, an asymmetric key and passphrase are also generated — the node key and passphrase. The node passphrase is encrypted with the parent folder’s node key (if the current node is not a volume root) or with a share key, if the current node represents a share root.

The file or folder name is also encrypted with the parent folder’s node key. As mentioned earlier, files are stored in blocks, where each block is at most 4 MB in size and is encrypted with the file’s node key. The blocks’ content hashes that mask the original content through encryption are linked in succession and the resulting string is signed with the address key of the uploader. This mechanism protects against a malicious or compromised server forging the contents of files.

The explanation so far covers the main points of the security model: encrypting and verifying stored content and sharing content between Proton users.

Sharing by URL

Our users may wish to share a file located in a ProtonDrive volume with someone who doesn’t have a Proton account. This can be done in a read-only manner through a mechanism that prevents Proton from accessing the shared content.  

The method we developed is based on the web client generating secure URLs, which allow access to the contents of specific files. The URLs are password-protected, and having both the URL and the password gives access to the shared content. While the Proton server will know the URL, it will never receive the password.

When creating a new shareable URL for a file, the web client will first confirm that a share directing to the file exists. The passphrase of this share must then be encrypted with the new password associated with the URL. This new password is either randomly generated by the ProtonDrive client, or is specified by the user. 

In the case of randomly generated passwords, the user can choose whether they want to include it at the end of the URL, equivalent to sharing the content publicly. This section of the URL isn’t shared with Proton servers, making the password and the content inaccessible to Proton. Alternatively, the user can choose to share the password separately.

In the case of user-defined passwords, this option isn’t available and the password must always be communicated separately.

As a final step, the client makes a request to the server to create a new shareable URL, providing the new encrypted key packet of the share passphrase. The server stores the encrypted key packet and returns to the client a unique random URL for accessing the shared content.

When the URL is accessed, the server will return the encrypted payload needed to access the shared content. Only by knowing the URL password can the payload be decrypted and the shared file be accessed.

This is a simplified description which captures the central principle of the design. The actual implementation includes mechanisms to prevent the repeated abusive access of the URLs. It also offers the ability to set an expiration time for the URLs or to limit the number of times the URLs can be accessed.

Conclusion

In this article we described the security model of ProtonDrive, which is designed to protect users’ data from malicious actors while offering the same ease of use as a non-end-to-end encrypted cloud storage service. As always, comments and suggestions are welcome, and security researchers can reach us at security@protonmail.com with comments or questions.

Best Regards,
The Proton Team

This post was authored by ProtonDrive technical lead Radu Popescu. 

Interested in building products like this? Join us.

You can get a free secure email account from ProtonMail here.

We also provide a free VPN service to protect your privacy.

ProtonMail and ProtonVPN are funded by community contributions. If you would like to support our development efforts, you can upgrade to a paid plan or donate. Thank you for your support.