Open

Introduction

PreVeil is an end-to-end encrypted email and file sharing service for businesses and individuals. PreVeil was designed and built from the ground up with the understanding that current information assurance architectures and paradigms are no longer sufficient. 

PreVeil’s philosophy centers around the three core principles:

• End-to-end encryption - the server never has access to private keys

• No central point of attack - no single person or machine that, if compromised, will leak data for a large number of users

• Ease of use – high quality user experience, integration with existing applications and systems, no passwords

PreVeil protects user information with end-to-end encryption, which ensures that no third party – not even PreVeil – can read any user-supplied information stored within the PreVeil system. Unlike most other service providers who say they use end-to-end encryption, PreVeil does not store the decryption keys in a centralized location such as a key server.

PreVeil was built with the assumption that centralized locations are attractive targets that can eventually be compromised by sufficiently motivated attackers. Whereas a successful attack on another provider’s key server can compromise their entire encryption system, PreVeil’s decentralized key management system is designed from the ground up to thwart this type of attack.

Open

Figure 1 – In the PreVeil system (shown above left) the servers only store encrypted content and the decryption keys are only on user devices. Other service providers (shown above right) may encrypt documents with user-specific keys, but these keys are stored on and accessible by the service provider - meaning that employees or hackers who obtain access to the server can potentially access all user information.

Administrators are often targeted by attackers because they have elevated privileges. 

To mitigate risks from compromised administrators or other insiders, PreVeil introduces Approval Groups™ - a powerful cryptographic method for distributing trust among a predetermined group of users. With Approval Groups compromising one administrator does not result in an entire organization being compromised.

PreVeil Security and Design

PreVeil was designed based on the idea that security is effective only if it’s easy to use. Since end-users have ingrained expectations and habits for both email and file-sharing, PreVeil has taken great care to replicate existing user experiences while minimizing the friction of adoption. Most of the security features described in this paper occur automatically and without requiring the user to take any special actions.

High Level Design and Enterprise Compatibility

PreVeil is a closed network built on a client-server model in which users download PreVeil software in order to securely collaborate with other PreVeil users. PreVeil has been built upon an end-to-end encryption platform which will enable the service to extend beyond email and file sharing into other collaboration methods.

Downloading PreVeil Software

When users join PreVeil, they first install PreVeil software onto their computer or mobile device and then create an account, which creates a public/private key pair that is associated with their identity and email address. Since PreVeil’s current design requires all cryptographic operations to be performed on user devices, PreVeil software must first be installed on each device with which a user is intending to use PreVeil (although PreVeil is currently prototyping a secure solution which does not first require software to be installed on the device).

Client-side Encryption and Decryption & Key Wrapping

Encryption and decryption operations are executed on users’ devices and never on the server. The encryption keys that are generated on user devices are themselves encrypted using a key wrapping architecture that allows for great scalability and granular access control. 

Dynamic Keys

Keys within the PreVeil system are version-controlled and are designed to be dynamic. This design, along with a “rekey” functionality, allows users and IT administrators to reset keys within the PreVeil system should a key be compromised. Rekeying allows the proper distribution of new keys so that an attacker with an old key will no longer be able to access new information. 

Authenticating Users and Devices

PreVeil clients communicate directly with the PreVeil server and authenticate with a series of keys which are only stored on user devices. Users must copy their private user key onto each device from which they wish to access their PreVeil account. Their key is securely copied over an authenticated, Diffie-Hellman encrypted tunnel, which prevents anyone from snooping on the transfer and extracting a key. 

Distributed Trust with Approval Groups

Approval Groups are a novel application of Shamir Secret Sharing that PreVeil implements to distribute trust among a group of people. Approval groups allow certain actions in the PreVeil system to require X of Y signatures from a specific group before an action is authorized to proceed. This powerful construct means that no single compromised administrator can cause any damage to the PreVeil system.

Designed for Enterprise

Unlike some other end-to-end encrypted email service providers, PreVeil has been built to support enterprise capabilities without weakening its security. Among many, several of the enterprise capabilities are:

• Distributed Account Recovery. Through Approval Groups, PreVeil is able to securely back up private keys without centralizing them or duplicating them. This means that user accounts can be recovered without introducing a vulnerability in the security system.

• Data Export. While PreVeil’s distributed keys and architecture make it impossible to obtain an organization’s data through one attack, organizations sometimes need to access all the emails and documents created by one, some, or all users. Through Approval Group technology, PreVeil enables the decryption and export of data only after a number of authorized users have granted their approval for the action.

• User Administration through Distributed Trust. PreVeil has an admin console that predetermined admins can use to manage PreVeil users at their organization, including adding users, promoting users, and deleting users. PreVeil’s Approval Group technology is used to ensure that privileged actions only take place after a number of trusted individuals approve the action.

• Logs and Audit Trail. All user actions within the PreVeil system are logged and encrypted.

Threat Model and Security Guarantees

Any security system should be accompanied by an attacker model as well as a discussion of what security guarantees the system provides and what guarantees it does not provide. 

PreVeil provides end-to-end encryption to protect the content of documents and email, a well-respected security notion. Additionally, PreVeil implements various traditional security mechanisms for safeguarding our clients and servers from attackers.

Server attacker model

For PreVeil’s cryptographic protocol, PreVeil targets a passive server-side attacker. This is an attacker that can eavesdrop on the data stored at the server (including the information in memory or on disk) but does not actively modify the execution of any part of the protocol or the data.  In particular, we assume that the attacker does not control the key distribution protocol, for example, during which clients look up the public keys of other clients. For an attacker to become active and perform such attacks, the attacker would need to radically compromise the PreVeil servers and gain control of them. To prevent such server-side attacks, PreVeil uses state-of-the-art systems security mechanisms for safeguarding the server (e.g., firewalls, access control, etc.).  

Example: Consider the following example: Alice wants to share her private file in Dropbox with Bob, but not with Eve. She sets as an access control policy on Dropbox that only Bob can access her file. She relies on the security of the Dropbox software stack. However, Eve works for Dropbox and manages to steal a copy of Alice’s document. Eve can now read Alice’s document offline. With PreVeil, Eve only obtains an encrypted copy of the document content. Eve cannot decrypt this content even if Eve stole all information at the server: the decryption key is never sent to the server in PreVeil.  

PreVeil encrypts as much information about documents or emails as possible and exposes little information to the PreVeil server. In particular, PreVeil encrypts the contents and title of the documents or emails as well as email attachments. PreVeil also encrypts some metadata about the documents such as the title of a document/email and the initial snippet of an email. Like other end-to-end encrypted systems, some metadata is not encrypted in PreVeil because it is needed as part of the basic operation or performance of the system. This includes, but is not limited to, which users access or have access to what collections or documents (e.g., who sends an email to whom), who does what operation at what time, and the count and size of encrypted data in operations or documents. For example, the PreVeil server needs to know that Alice is sending an email to Bob, so that it puts the encrypted email in Bob’s inbox and in Alice’s sent box, but the server does not see the content, title, attachments, or snippet of the email.  

As part of allowing users to find other PreVeil members, PreVeil enables a user to tell if an email address is a member of PreVeil. This also means that an attacker can take advantage of this feature via a dictionary attack (that is, enumerate many possible emails) to identify who are all the members of PreVeil. To minimize this type of attack, administrator of PreVeil services can restrict who sees PreVeil membership via a Trusted Community feature (e.g., only users within a company).

User attacker model

A user could be malicious, or the user’s machine could get compromised (e.g., the user carelessly installs malware, an attacker steals a user’s laptop). Even if this is the case, PreVeil prevents this user from accessing the document content of another user, as long as the second user did not previously share (directly or indirectly) the document with the malicious user. The approval group is meant to help a victimized user recover their account and change their key. 

A user must choose a trustworthy approval group in order to protect his/her data. PreVeil also assumes that a user’s email account was not compromised at the time of setting up an account with PreVeil. 

Email or document search in PreVeil happens locally on the client-side, so there is no side channel leakage from a server-side search. 

Description of Key Infrastructure

Overview

In the PreVeil system, information is encrypted and decrypted only on a user’s client device, and the information stored on the cloud server is always encrypted. Each document or message – including its metadata such as file name and email subject - is encrypted with its own unique key.

Types of Keys in the PreVeil System

The PreVeil system generally uses asymmetric keys to manage identity and access and perform digital signatures and uses symmetric keys to encrypt information. 

• Symmetric keys are used to encrypt and decrypt information. Symmetric keys are much faster at performing encryption / decryption operations than asymmetric, but by themselves aren’t very scalable because as a system grows, it becomes increasingly difficult to distribute and update keys as more information and users are added.

• Asymmetric keys are used to manage identity and access to information. Asymmetric keys have a public component, which is shared to everyone in the PreVeil system, and a private component, which remains solely on user devices. Asymmetric cryptography was designed to be scalable, since each new user only needs to share a single public key in order to share their identity and have information be encrypted for them.

The following table lists the types of keys in the PreVeil system along with their function:

Identity & Authentication in the PreVeil System

Identity & Digital Signatures

Identity in PreVeil is defined by the association of three factors, which are stored together in the PreVeil server user database.

• a public key which is created by the user when they install PreVeil and create an account,

• an email address (ownership of which is verified) that is used as a PreVeil ID

• a first and last name, which are displayed in PreVeil along with the user’s email address

All PreVeil users have a public key. As described in Key Management and Key Wrapping, the user’s public key is used to encrypt other keys and documents uniquely for those users. As is further described in “Separating Signatures from Encryption,” each request made to the server is signed by the user’s private signing key to cryptographically prove that a user performed an action or guarantee the authenticity of a document or encrypted key.

User Account Setup & Verification

To join PreVeil, a new user first downloads PreVeil software onto their computer or mobile device and has access to the email address they plan on using as a PreVeil ID. The following describes the process to set up a new PreVeil account:

• PreVeil software is downloaded onto the user's computer or mobile device. In enterprise settings, PreVeil can be remotely installed using services such as Active Directory.

• The user enters their name and email address and submits this to the PreVeil server. In enterprise settings, this provisioning is performed by Administrators, and end users simply need to click a button.

• The server generates a secret code and sends it to the email address as a clickable link

• The user has a set amount of time to click the link, upon which

  • The PreVeil software on the user’s device creates a new user key

  • The PreVeil software on the user’s device creates a new device key

  • Both public keys are sent to the PreVeil server and are associated with the user

• The server adds the user to its identity database and configures storage space for the user’s email and files.

• At this point, existing PreVeil users can use the new user’s public key to send them information.

Note that the flow is slightly different for enterprise users – see here: Adding Users and Creating User Accounts.

Multiple Devices Without a Login/Password

Since PreVeil does not use a login or password system, using PreVeil on multiple devices is slightly different because users must copy their private key onto each device from which they would like to access PreVeil. Their private key is sent through a user-authenticated, Diffie-Hellman protected encrypted tunnel which prevents any third party from intercepting the key.

Open

Figure 2 – Users must add their account to each device from which they want to use PreVeil. The process is simple, quick, and is encrypted so that no third party – not even PreVeil – can see the key.

The key copying flow is as follows:

• The user verifies that they have access to a device with their existing PreVeil account

• The user downloads PreVeil onto their new device and selects “add existing user”

• On the new device, the user sees a series of 8 characters or a QR code

• The user enters these on the prompt — or scans the QR code — on their existing device. These characters act as an authentication mechanism to ensure that one device is securely connected to another through a Diffie-Hellman exchange.

• The private key is copied to the new device, upon which a new device key is generated and associated with the user account (see below for more on device keys).

This architecture provides robust protection against remote attackers because logins cannot realistically be attempted. Since encryption keys are orders of magnitude harder to guess than passwords and are not re-used by users between services, PreVeil users are protected against attacks that may leverage passwords stolen from other services.

Device Keys and Management

When a PreVeil account is first created or copied onto a device, an asymmetric key is generated to uniquely identify the device. The public key is uploaded to the PreVeil server, which keeps track of which device keys are associated with each user. Device keys are rotated automatically on a 24-hour basis, a feature which provides additional protection in the case of a compromised device and that will be used in the future to further facilitate account setup and use on multiple devices.

When the PreVeil application makes requests to the PreVeil backend server it takes the content of the request and provides two values to authenticate the user: it generates a signature of the content with the key associated with the user (the user key) and a signature of the content generated by the key associated with the device running PreVeil (the device key). This allows verification that (1) the user has access to the user's account via the user key, (2) the user has access to a valid PreVeil device, and (3) the request being sent is what was intended by the user based on the two signatures of the content being valid. If any of these three criteria are not met, the request is rejected.

It is important to note that the user key and device key are versioned, which is to say that new versions can be generated, and the most recent versions are required for the PreVeil backend server to respond to requests.

On the local devices, PreVeil keys are protected by administrator privileges. In the case of device compromise, the following actions can be taken:

1. Users and organization administrators have the ability to lock devices, at which point criteria (2) will break for the compromised device.

2. Once the compromised device has been locked, some PreVeil operations will cause the user key to update to a newer version, at which point criteria (1) will break for the compromised device, even if the device is subsequently unlocked.

From any active device, a user can remotely disable another device that is registered to their account and thereby block that device from accessing PreVeil information or performing actions in the system. Upon receiving such a request, the server checks to verify that the device making the request is still valid, after which the server then finds the corresponding device’s public key and temporarily revokes it. Subsequent requests or actions from that device will be ignored from the server. A user can then unlock the device from any active device by sending the server an unlock command.

Should an attacker obtain a user’s device and remotely lock out a user’s devices, a user that has set up an Approval Group will be able to recover their account by performing an account recovery onto a new or existing device (see process description: Recovering a user key.) After an account has been recovered, a user’s account will automatically be rekeyed, therefore locking the attacker out and preventing the attacker from accessing new material (although they will still be able to access any material they have already downloaded).

Web PreVeil

Web PreVeil is the name for the PreVeil application that runs solely in a web browser (in addition to the typical installations that involve background processes installed in Windows and Mac OS or mobile apps).  In Web PreVeil all cryptographic functions as well as the Drive and Email services are implemented in code running in the user’s browser.  

The user initiates a session by visiting http://web.preveil.com, which initiates a process of transferring a temporary copy of the user’s private key to the browser session.  This temporary copy exists for the duration of the browser session only (i.e. the specific tab accessing Web PreVeil); it’s not stored locally or in a browser cookie.  If the user formally logs out of Web PreVeil or closes the browser window/tab running the session, the temporary key copy is lost.  Furthermore, the key will be invalid after 24 hours.

The temporary copy of the user’s private key is securely transferred to the browser session using the same mechanism to add new devices (described above), based on the Diffie-Hellman key exchange protocol.  Most of the time, the user has previously installed PreVeil on a mobile device and has transferred their private key.  In these cases, the mobile device’s camera scans a QR code presented in the browser session, which contains the common value necessary for the Diffie-Hellman protocol.

Since each device accessing the PreVeil services must authenticate via a valid device key, the Web PreVeil session creates a special kind of device key.  It’s special in that it’s temporary — valid for the current browser session only — and it does not automatically rotate to a new version every 24 hours.

Because Web PreVeil exists only in a browser session, features that require the installation of software on a local machine are not available.  There’s no local PreVeil directory in the file system, so files are not automatically synchronized with the server.  Files can be uploaded, downloaded, and viewed in the browser.  In addition, email messages are composed, reviewed, and managed through the browser session only; there’s no integration with other mail clients like Outlook, Mac Mail, and Gmail.  And the Admin Console is not currently supported in Web PreVeil.

Authenticated Server Connections

PreVeil clients communicate to the server over encrypted transport layers, including HTTPS and encrypted WebSockets. Each request made to the server is signed using the user key and the device key. The server only responds if both keys are active (not revoked) and correspond to the latest key versions listed on the server. Therefore, an attacker will not be able to extract information or perform actions in PreVeil by only using old keys or one of the two key types.

Key Management and Key Wrapping

Overview

For file storage and sharing, PreVeil uses a “wrapped key” architecture in which the keys required to decrypt information themselves are encrypted using encryption keys that only the appropriate users can access. For emails, the recipient’s public user key is directly used to encrypt the keys protecting email subject, content, and attachment. For files, there is an additional layer of keys used to differentiate file permissions. 

To ensure that PreVeil servers are never able to access decryption keys:

• All user information is only ever encrypted and decrypted on user devices

• The cryptographic action in which Folder Permission Keys are “wrapped” for the appropriate other users takes place on user devices, not the server

• The PreVeil server only stores symmetric or private keys that are encrypted - the PreVeil server never has access to any unencrypted keys, which can then directly be used to access user information

Key wrapping allows for scalable distribution of encryption keys. Below is a simplification of the data stored on the PreVeil server, which we’ll use to describe how key wrapping works. While PreVeil can implement multiple tiered access controls, at a high level, there are three categories of encryption: document-level encryption, granular folder permissions, and user access controls – discussed in depth below.

Open

Figure 3 – Key wrapping allows for granular file protection and access control without generating a high number of encryption keys. Access is controlled by distributing access to a key which allows another key to be accessed which then allows document access. Access to keys is controlled on a per-user level in which user public keys are used to encrypt copies of the same access key per user with the appropriate permission. Note that the PreVeil server only contains encrypted information – even though keys are stored on the server, they are stored encrypted so that an attacker or employee is unable to access the key.

Document-level protection

Each document is encrypted with a unique key, so that an attacker who compromises one document cannot then obtain access to other documents. These symmetric keys are generated on the user devices that first upload the documents. These document keys themselves are then encrypted and stored on the server. 

Granular Folder Permissions

All files under the same folder share the same access control and permissions list, so all documents being shared to the same folder use the same permission key to encrypt the document encryption keys. In the picture above, the green lock represents a permission key that allows an arbitrary number of unique document encryption keys (such as the blue and black keys) to be encrypted without requiring subsequent modifications to the key infrastructure.

Each folder has 6 asymmetric permission keys which enable users to perform actions if they have access to the corresponding private key. For example, the keys that encrypt documents in a certain folder are encrypted under that folder’s Read Permission Key (the blue Document 1 encryption key itself is encrypted with the green Folder Read Permission Key in the above figure). Similarly, other permissions are authorized or verified by the server by looking to see if the request has been signed with the appropriate permission key (e.g. a user can only write something to a shared folder if the request has been signed with the Write Permission Key).

User Access Control

Folder permissions are granted by giving a user access to the private key component of the corresponding Folder Permission key – by encrypting the folder permission private key for each user with the user’s public key. This ‘wrapping’ is performed on the device of the user granting permissions to others and happens automatically when a user shares a folder.

In the above example, if Alice is sharing Document 1 and Document 2, the only action Alice needs to perform is to encrypt the appropriate private Folder Permission key (the green colored key) using the recipient’s public key (in this case the teal colored lock). Since each user has their own copy of the private key, the PreVeil system can granularly track access and creates an audit log based on each user.

Customizable and Scalable

The key wrapping architecture described can be used to extend to further levels of wrapped keys. Although not graphically depicted, the notion of Groups in PreVeil is simply another set of “Granular Folder Permissions” whose keys wrap other permission keys. Since keys themselves take up negligible amounts of disk space, wrapping keys for multiple users is feasible even at scale.

Key Wrapping Example – Reading Shared Information

Below is an example to describe the cryptographic components and their interactions. In this scenario, Alice is trying to access Document 1, which has been shared with her. All of this key management and distribution is completely transparent to the user and happens automatically.

Open

Figure 4 – The PreVeil software on Alice’s device sees that Document 1 has been added to the server and so it downloads the encrypted Document 1, the Document 1 decryption key which has been encrypted under the Folder Read Key, and the Folder Read Key which has been encrypted under her own user key.

Open

Figure 5 – After downloading all the files, the PreVeil software on Alice’s device first uses Alice’s orange private key (which is only kept on her devices) to decrypt the green Folder Read Key (left picture). The Folder Read Key is then used to decrypt the blue Document 1 decryption key (middle picture). The Document 1 decryption key is then used to decrypt Document 1 (right picture). This entire process happens automatically in the PreVeil software.

Key Wrapping Example – Writing Shared Information & Sharing with a New User

When a user, Alice, uploads and shares a new document, the process is reversed:

1. The PreVeil software identifies a newly added file and on Alice’s device, generates a unique file key which encrypts this file (this is a simplification - as described later, a series of unique block encryption keys, not a single file encryption key, are generated).

2. The document is encrypted with the file key

3. The encrypted document is sent to the PreVeil server

4. The file key is then encrypted using the public key of the appropriate “Read Folder Permission Key”

5. Any user who has access to the Read Folder Permission Key is then able to decrypt the file key and then subsequently decrypt the document

6. To share the document with a new user, Alice would wrap the private Read Folder Permission Key using the recipient’s public key

Note that in this flow, neither the document nor the document key are encrypted directly with Alice’s recipients’ user keys. PreVeil’s key wrapping architecture separates the need to map a document directly to a user. As long as a user is granted the correct permission, they will be able to access the correct documents. 

Approval Groups

Decentralize Trust and Remove Single Points of Failure

An Approval Group is a set of users who together authorize an operation.  Traditional systems allow each admin to have very broad privileges to reset user passwords, access user data, etc. PreVeil tries to avoid such central points of attack.  Approval Groups cryptographically distribute trust amongst a set of people, making the system much more secure than systems that centralize trust in a set of admins. 

Implementation

Approval Groups can be constructed to allow any x out of y approvers to authorize an operation.  They can also be cascaded together to enable more complex combinations, for example: any 3 of 10 users of group A (IT administrators) plus 1 out of 2 users of group B (executives). 

Approval Groups for User Recovery

Approval Groups recover secret keys by using the Shamir Secret Sharing algorithm.  To set up an Approval Group (an operation that’s executed on the client), a secret key is broken into fragments or shards, with each shard assigned to an approver.  The shard is encrypted with authenticated encryption using the approver's public key and the user’s private signing key (thereby ensuring that the approver can verify that the correct user is the one who actually sent the wrapped shard to the server). These encrypted shards are stored on the PreVeil servers.

Open

Figure 6 – A conceptual illustration of a user’s private key being “sharded” so that each shard is encrypted in a manner that only one approval group member can access. When recovering a key, the shards are securely copied and reconstituted. Note that Shamir Secret Sharing ensures that the ‘shard’ is not a part of a key, just a piece of information that allows the key to be reconstituted.

When a user needs to recover the secret key, each of the required approvers (x out of y) retrieves their encrypted shard from the server, decrypts it using the approver’s private User key, and sends the decrypted shard securely to the user that’s recovering the key.  Using the Shamir Secret Sharing algorithm, the shards can be mathematically combined to recover the original secret key.  Note that the secure transmission of the shards is implemented via the Diffie Hellman Key Exchange protocol.  After a key is recovered, it must be re-keyed to prevent a repeat of the key recovery without the approvers’ consent.

Approval Group Enterprise Uses

Enterprise use of Approval Groups extends beyond account recovery. A description of these uses can be found here:  Approval Group Functions.

PreVeil Keys in Depth, Key Versioning & Rekeying

PreVeil Key Details and Metadata

All asymmetric keys in the PreVeil system actually consist of three components:

1. Key Version - used to track the version of the key so that the PreVeil server only authenticates and accepts requests from the latest version of the key

2. Signing Key – used to cryptographically sign requests and actions, resulting in cryptographic proof that certain users or groups performed actions

3. Decryption Key – used to perform encryption/decryption operations for specific users or groups

Separating Signatures from Encryption

Previously, asymmetric keys had been discussed as a key pair – a public key component and a private key component. While this is correct, the cryptographic libraries and implementation used by PreVeil actually use two key pairs – one public/private key pair for encryption and decryption, and another public/private key pair for signing.

The separation of these functions provides greater mitigation against any attacks in which a component of a key is compromised – if an attacker is able to obtain a decryption key, they still will not be able to masquerade as a user and sign as them, and vice versa.

Separating the encryption function from the signature function also allows the enterprise Data Export & E-Discovery feature to decrypt information without compromising the identities of users – in this process, only the encryption/decryption keys are copied to perform the decryption, but the signing keys are not copied and thus a user’s identity cannot be compromised.

Key Versioning & Old Key Access

Keys in the PreVeil system are intended to be dynamic to mitigate the scope and effect of attackers who are able to access old versions of keys. As such, PreVeil’s internal protocols allow each asymmetric key to be versioned so that only the latest key version is acknowledged by the server and authorized to perform actions.

To ensure access to material encrypted using older keys, when a key version is increased (see Rekeying below), old keys are encrypted using the new encryption key. This allows a user with access to the latest key to access all other previous keys.

Rekeying Guarantee

Rekeying is an integral part of the PreVeil security architecture because it provides a method to ensure that any malicious user with access to an older key is not able to access any new material. 

Rekeying is a multi-step process that originates on a user’s device (to guarantee that the server does not access the newly generated key). Some iterations of rekeying require Approval Group™ authorization, such as Recovering a user key.

Rekey Types and Triggers

Below is a list of events that trigger rekeying events across the three different classes of keys explained in the overview section of Identity & Authentication in the PreVeil System

Identity & Digital Signatures

Identity in PreVeil is defined by the association of three factors, which are stored together in the PreVeil server user database.

• a public key which is created by the user when they install PreVeil and create an account,

• an email address (ownership of which is verified) that is used as a PreVeil ID

• a first and last name, which are displayed in PreVeil along with the user’s email address

All PreVeil users have a public key. As described in Key Management and Key Wrapping, the user’s public key is used to encrypt other keys and documents uniquely for those users. As is further described in “Separating Signatures from Encryption” each request made to the server is signed by the user’s private signing key to cryptographically prove that a user performed an action or guarantee the authenticity of a document or encrypted key. User Account Setup & Verification

To join PreVeil, a new user first downloads PreVeil software onto their computer or mobile device and have access to the email address they plan on using as a PreVeil ID. The following describes the process to set up a new PreVeil account:

• PreVeil software is downloaded onto the user's computer or mobile device. In enterprise settings, PreVeil can be remotely installed using services such as Active Directory.

• The user enters their name and email address and submits this to the PreVeil server. In enterprise settings, this provisioning is performed by Administrators and end users simply need to click a button.

• The server generates a secret code and sends it to the email address as a clickable link

• The user has a set amount of time to click the link, upon which o The PreVeil software on the user’s device creates a new user key o The PreVeil software on the user’s device creates a new device key o Both public keys are sent to the PreVeil server and are associated with the user

• The server adds the user to its identity database and configures storage space for the user’s email and files.

• At this point, existing PreVeil users can use the new user’s public key to send them information.

Note that the flow is slightly different for enterprise users – see here: Adding Users and Creating User Accounts.

Multiple Devices Without a Login/Password

Since PreVeil does not use a login or password system, using PreVeil on multiple devices is slightly different because users must copy their private key onto each device from which they would like to access PreVeil. Their private key is sent through a user-authenticated, DiffieHellman protected encrypted tunnel which prevents any third party from intercepting the key.

Open

Figure 2 – Users must add their account to each device from which they want to use PreVeil. The process is simple, quick, and is encrypted so that no third party – not even PreVeil – can see the key.

The key copying flow is as follows:

• The user verifies that they have access to a device with their existing PreVeil account

• The user downloads PreVeil onto their new device and selects “add existing user”

• On the new device, the user sees a series of 8 characters or a QR code

• The user enters these on the prompt — or scans the QR code — on their existing device. These characters act as an authentication mechanism to ensure that one device is securely connected to another through a Diffie-Hellman exchange.

• The private key is copied to the new device, upon which a new device key is generated and associated with the user account (see below for more on device keys).

This architecture provides robust protection against remote attackers because logins cannot realistically be attempted. Since encryption keys are orders of magnitude harder to guess than passwords and are not re-used by users between services, PreVeil users are protected against attacks that may leverage passwords stolen from other services.

Device Keys and Management

When a PreVeil account is first created or copied onto a device, an asymmetric key is generated to uniquely identify the device. The public key is uploaded to the PreVeil server, which keeps track of which device keys are associated with each user. Device keys are rotated automatically on a 24-hour basis, a feature which provides additional protection in the case of a compromised device and that will be used in the future to further facilitate account setup and use on multiple devices.

When the PreVeil application makes requests to the PreVeil backend server it takes the content of the request and provides two values to authenticate the user: it generates a signature of the content with the key associated with the user (the user key) and a signature of the content generated by the key associated with the device running PreVeil (the device key). This allows verification that (1) the user has access to the user's account via the user key, (2) the user has access to a valid PreVeil device, and (3) the request being sent is what was intended by the user based on the two signatures of the content being valid. If any of these three criteria are not met, the request is rejected.

It is important to note that the user key and device key are versioned, which is to say that new versions can be generated, and the most recent versions are required for the PreVeil backend server to respond to requests.

On the local devices, PreVeil keys are protected by administrator privileges. In the case of device compromise the following actions can be taken:

3. Users and organization administrators have the ability to lock devices, at which point criteria (2) will break for the compromised device.

4. Once the compromised device has been locked, some PreVeil operations will cause the user key to update to a newer version, at which point criteria (1) will break for the compromised device, even if the device is subsequently unlocked.

From any active device, a user can remotely disable another device that is registered to their account and thereby block that device from accessing PreVeil information or performing actions in the system. Upon receiving such a request, the server checks to verify that the device making the request is still valid, after which the server then finds the corresponding device’s public key and temporarily revokes it. Subsequent requests or actions from that device will be ignored from the server. A user can then unlock the device from any active device by sending the server an unlock command.

Should an attacker obtain a user’s device and remotely lock out a user’s devices, a user that has set up an Approval Group will be able to recover their account by performing an account recovery onto a new or existing device (see process description: Recovering a user key.) After an account has been recovered, a user’s account will automatically be rekeyed, therefore locking the attacker out and preventing the attacker from accessing new material (although they will still be able to access any material they have already downloaded).

Web PreVeil

Web PreVeil is the name for the PreVeil application that runs solely in a web browser (in addition to the typical installations that involve background processes installed in Windows and Mac OS or mobile apps).  In Web PreVeil, all cryptographic functions as well as the Drive and Email services are implemented in code running in the user’s browser.  

The user initiates a session by visiting http://web.preveil.com which initiates a process of transferring a temporary copy of the user’s private key to the browser session.  This temporary copy exists for the duration of the browser session only (i.e. the specific tab accessing Web PreVeil); it’s not stored locally or in a browser cookie.  If the user formally logs out of Web PreVeil or closes the browser window/tab running the session, the temporary key copy is lost.  Furthermore, the key will be invalid after 24 hours.

The temporary copy of the user’s private key is securely transferred to the browser session using the same mechanism to add new devices (described above), based on the Diffie-Hellman key exchange protocol.  Most of the time, the user has previously installed PreVeil to a mobile device and has transferred their private key.  In these cases, the mobile device’s camera scans a QR code presented in the browser session, which contains the common value necessary for the Diffie-Hellman protocol.  

Since each device accessing the PreVeil services must authenticate via a valid device key, the Web PreVeil session creates a special kind of device key.  It’s special in that it’s temporary — valid for the current browser session only — and it does not automatically rotate to a new version every 24 hours.

Because Web PreVeil exists only in a browser session, features that require the installation of software on a local machine are not available.  There’s no local PreVeil directory in the file system, so files are not automatically synchronized with the server.  Files can be uploaded, downloaded, and viewed in the browser.  In addition, email messages are composed, reviewed, and managed through the browser session only; there’s no integration with other mail clients like Outlook, Mac Mail, and Gmail.  And the Admin Console is not currently supported in Web PreVeil.

Authenticated Server Connections

PreVeil clients communicate to the server over encrypted transport layers, including HTTPS and encrypted WebSockets. Each request made to the server is signed using the user key and the device key. The server only responds if both keys are active (not revoked) and correspond to the latest key versions listed on the server. Therefore, an attacker will not be able to extract information or perform actions in PreVeil by only using old keys or one of the two key types.

Key Management and Key Wrapping.

User / User Access Control Keys

• When an Approval Group is changed, a user key is rekeyed to prevent the old Approval Group from later colluding to get the user’s key.

• After recovering an account using an Approval Group, a user key is rekeyed to prevent the Approval Group from later colluding to get the user’s key (in production 2Q 2019).

Folder Permission Keys

• When someone unshares or changes user permissions on a shared folder, the user performing the action creates a new version of all Folder Permission Keys and reencrypts these for accordingly for the remaining users. This ensures that those who have been unshared are not able to access the Folder Permission Keys and so cannot access document any new encryption keys. 

Encrypted information

• Updating keys does not require data to be re-encrypted. Doing so would require a user’s entire email and document base to be downloaded onto one device and re-encrypted using new unique information keys (for each email and document). By rewrapping the keys themselves under new Folder Permission Keys, as described above, PreVeil still minimizes the amount of information attackers can obtain with old access keys.

Rekeying Details

The following are changes that take place when a user rekeys. For the sake of clarity, the example below describes what happens when a user “Alice” rekeys.

User Device

• A new user key is created, and the public key is uploaded to the PreVeil server.

• The old user key is encrypted with the new key - so Alice uses her new private key to access her old private key to decrypt old messages. The encrypted old user key is stored on the server to ensure that it as well as access to old data can be accessed from any of Alice’s devices.

• Alice’s home Drive folder and existing folder permission keys are re-encrypted under her new user key (in production 2Q 2019).

• Alice’s new user private key is re-sharded and distributed to her Approval Group.

Server Directory

• The public component of Alice’s user key replaces the public component of her old key.

Emails

• Moving forward, new emails sent to Alice will be encrypted using Alice’s new user key.

• Alice’s old emails will remain encrypted using Alice’s old key.

Alice’s Approval Group

• Each member of Alice’s Approval Group receives a shard of Alice’s new private key, with each shard uniquely encrypted for a single approval group member.

Cryptographic Algorithms & FIPS 140-2

PreVeil supports use cases that require NIST FIPS 140-2 certified encryption algorithms. PreVeil uses the OpenSSL FIPS Object Model v2.0 library for crypto algorithms and they are FIPS 140-2 certified under NIST certificate #1747: https://csrc.nist.gov/projects/cryptographic-modulevalidation-program/Certificate/1747. 

FIPS-approved AES symmetric encryption algorithm is used for block cipher, and the asymmetric key generation and signing also uses an ECDSA FIPS approved algorithm. All PreVeil users will use the same encryption algorithms. The encryption parameters used for this are listed below:

• Symmetric keys are generated using AES-256 in GCM mode

• Asymmetric keys are generated using elliptic curve P-256

The base FIPS-approved encryption is further enhanced by signing protected objects with additional set of key pairs generated by NaCl/Libsodium EC25519. This provides additional assurance above the FIPS baseline requirement by also including proof of cryptographic trust from a community-approved project.

The asymmetric keys are integrated in a manner such that both P-256 and EC-25519 keys are required for a user to decrypt information. This architecture allows PreVeil to be used by those requiring FIPS 140-2 algorithms.

PreVeil’s cryptographic module has been validated by NIST as compliant with the FIPS 140-2 Level 1 standard.  The certification can be found here: Cryptographic Module Validation Program | CSRC | CSRC

Data Infrastructure — Email and Files

Architecture for Storage and Processing

Open

Server Architecture

Storage.  Both file and email data are stored on the server in a key-value storage system using Amazon’s S-3 service.  Alternatively, data can be stored on-premise on a server owned by a customer or a 3^rd party storage provider that provides an S-3 style key-value interface.

Processing of client requests, storage of metadata and keys are handled by a set of Collection Servers deployed on Amazon’s EC-2 service.  Collections are described in more detail below, but for now consider a Collection to be the home of a user’s email mailbox or a directory of files.  Each Collection resides on a single Collection Server, but a Collection Server can support many Collections.  Each Collection Server is also associated with a Postgres database that contains the keys associated with the Collections residing on that server.  Private keys are always encrypted on the client before being stored on a server; the server can never access private keys directly.   Each Collection Server also contains public User keys for all users in the PreVeil system.

Client requests and events are posted to a Kafka event log that’s used to reconstruct state should a Collection Server fail.  Collections are replicated on two servers, so if a server suddenly crashes, other servers can take over with minimal Kafka replay.  When a server fails, its responsibilities are distributed across the remaining servers.  Additional servers may be added at any time, and the total load will be redistributed across the available server infrastructure.  

PreVeil Confidential

PreVeil Data Structure and Nomenclature - Files, Directories, and Collections

Open

Files partitioned into blocks then encrypted with unique Keys

Files are stored as a set of blocks, each encrypted under a unique Block Key, which is a symmetric key.  Each block has a unique Block ID that identifies it for storage and retrieval in S3 storage.  Blocks are updated in “append” mode on S-3, which means that any block changes are added to storage.  This allows retrieval of older versions of files.  Each Collection has a data retention policy that specifies the length of time or number of versions to be retained.  Blocks that are no longer required are flagged for deletion via a garbage collection process that occurs periodically.

Files are organized into directories, and the file name metadata in a directory is encrypted under a symmetric Directory Key.  Directories can contain sub-directories.

Open

Sharing Rules

A Collection is a special kind of directory in that it can be shared with other users.  A Collection can contain files as well as sub-directories.  All of the contents of a Collection have the same sharing permissions.  In other words, if the sharing permissions for a directory include “Edit & Share” for user A & B and “read-only” for user C, then all directories and files in the Collection will be editable and sharable for users A&B and read-only for user C.  

Collections may not contain other collections as a user interface design rule; users often get confused when sharing permissions differ across files or sub-directories.  There is one exception to this rule: each user has a “root” level directory in which all other directories and Collections are kept.  This root directory is called the Default Collection.  

Logs & Audit Trail

Collections have logs associated with them to track activity (i.e. user x changed file y).  Log entries are encrypted on the server with an asymmetric Log Key and stored with the Collection. 

The server creates a log entry for each operation and encrypts the log using the public Log Key. 

The private Log Key is encrypted under the User Key so that users can see their own log entries. In organizations (described below), Log Keys are also encrypted under an Admin Key so authorized admins can also view logs.  More on administrative access below.  Log entries are hash-chained and signed to ensure that an attacker cannot modify logs.  

Advanced Permissions

Various permissions can be granted to users who have access to a Collection, including the following:

• Read access — the ability to read files and directories

• Write access — the ability to create and update files and directories

• View access — view the Access Control List, i.e. see the list of users who have access to the Collection and what their privileges are

• Share — the ability to share a collection with others.

• Log — the ability to view logs

These permissions are combined together to create sharing options:

• Read only = Read

• Edit & Share = Read, Write, View, Share, Log

• Edit = Read, Write, View, Log

• Blind Drop = Write

Open

A Collection Read Key is an asymmetric key that’s used to provide security for read operations on files and directories.  Block keys and Directory Keys are encrypted under Collection Read Keys.  Also, the metadata for file and directory names in the root directory (the Default

Collection) are encrypted under the Collection Read Key.  Each user who has read access to a Collection will have the corresponding Collection Read Key encrypted under their User Key stored on the server.

A Collection Write Key is an asymmetric key that’s used to provide security for write operations. Whenever a client creates, uploads, updates, or deletes file blocks to the server, the request is signed by the client with the Collection Write Key.  The signature is checked by the server before the data is stored.  Users who have write access to a collection have the corresponding Collection Write Key encrypted under their User keys stored on the server.

The server also enforces signed requests for the following operations:

• Sharing collections with other users — requires a request to be signed by a Collection Sharing Key (the server also ensures that the sharer possesses the privileges being shared).

• Viewing other members of a shared collection — requires a request to be signed by an ACL Viewer Key (access control list).

• Re-keying a collection — requires a request to be signed by a Collection Owner Key.

File Operations

Create a file

When a client creates a file to be stored on the server, it divides the file into blocks, creates keys for each block, and encrypts the blocks using the block keys.  All files are contained in a Collection, which could be the root (i.e. “default Collection” that’s private to the user) or another collection that’s shared with others.  The block keys are encrypted under the relevant Collection Read Key.  The client creates a request for the server to create the file and attaches to the request the encrypted block keys, filename and other metadata encrypted under the appropriate Directory Key, and a list of block IDs to upload.  The request is signed with the Collection Write Key and sent to the server.  The server validates the signature of the request before processing.  Client and server then communicate to upload the encrypted blocks to the server.

Read a file

Since a file is always contained in a collection, the client first retrieves the appropriate Collection Read Key.  The client uses its private User Key to decrypt the Collection Read Key, which is then used to decrypt file metadata, directory keys, and block keys.  The client sends a request to the server (S-3 storage) to retrieve the appropriate blocks (as specified by block IDs). As each block is retrieved, it’s decrypted by the client using the corresponding block key.  The decrypted blocks are then assembled into a file in the user’s file system.  

Delete a file

To delete a file from a Collection, the client packages a request to the server to delete the set of blocks (specified by block ID) associated with the file.  It then signs the request with the Collection Write Key.  The server checks the signature, and if valid, marks the specified blocks for later deletion.  Physical deletion occurs during periodic garbage collection and is dependent on a data retention policy specified for the Collection.

Share a Collection

In PreVeil, sharing occurs at a directory (Collection) level; individual files aren’t shared.  To share a Collection with other users, the sharing client retrieves from the server the public User Key for each shared user.  It then encrypts the appropriate permission keys under each user’s public User Key and creates a request for the server.  For example, if the recipient is to have “Edit and Share” access, the sharing user encrypts the following keys under the recipient’s User

Key in the creation of the server request: Collection Read, Collection Write, Collection Share, ACL Viewer, Log.   The request is then signed with the Collection Sharing Key (to prove to the server that the sharer has permission) and sends the request to the server.  The server checks the signature and, if valid, adds the relevant keys to the Postgres database associated with the target Collection Server.

Un-share (and re-key) a Collection

To un-share or change any other sharing permission, the Collection is essentially re-shared with an updated set of keys.  The client making the request generates a new set of collection keys (read, write, view ACL, etc.) and encrypts the appropriate ones under the User Key of each recipient.  It then sends the request to the server to update all of the new keys with the new list of shared users and their permissions.  As described above, the asymmetric key data structure includes a list of key versions with prior versions encrypted under the key of the latest version (so version 0 is wrapped under version 1, which is wrapped under version 2, etc.).  This means that someone who no longer has access to a collection will be unable to decrypt the latest set of keys; nor will it be able to retrieve the list of prior versions and access them.  It also means that files need not be re-encrypted when Collections are re-keyed, which would be extremely expensive from a computation and data transport perspective.

Email

Overview

Email uses the same storage mechanisms that files do.  Email content (including attachments) is organized into blocks, encrypted with block keys, and stored in Amazon S-3 (or alternatives as previously noted).  Each attachment is just like a file — organized into its own set of blocks each encrypted under a unique block key.

Open

A user’s mailbox is organized as a special kind of Collection (it’s called a Mail Collection), without all the usual collection read, write, and share keys.  Instead, the User private key is used to decrypt items in this Collection, and the User public key encrypts the files that comprise email messages.  This special collection’s subdirectories contain the user’s mailboxes — Inbox, Deleted Items, Sent Items, Drafts, plus user-defined mailboxes.  Each mailbox subdirectory contains the files that comprise individual email messages and attachments.  The Outbox is contained on a client only.   

The Postgres database on the collection server contains metadata for the mailboxes, such as block IDs of the messages, encrypted block keys, and other message data.

Just as file collections have logs associated with them, the special User Collection also contains log entries that track email and other activities performed by the user.  The mechanism works the same as with files: log entries are generated by the server, encrypted under the collection’s Log Key, and hash-chained to prove authenticity.

Sending a message

To send a message, the client first packages the message and its attachments into blocks, creates block keys for each, and encrypts the blocks.  It also prepares the message “snippet,” which is contains the first few lines of the message that are to be displayed in the user’s message list.  The client retrieves public User Keys for each recipient of the message and then encrypts all of the block keys under each recipient’s key.  The client creates a server request to send the email, including in the request a list of recipients, block IDs referencing the blocks that contain message and attachment data, encrypted block keys for all the recipients, the encrypted message snippet, and other metadata.  The request is then signed with the User Key and sent to the server.  The server copies the encrypted blocks to S-3 storage and updates recipients’ User Collections with relevant message data, including encrypted block keys.  

Note that some recipients’ User Collections may reside on different servers than the sender’s. In that case, the sender’s server will relay the message data to each of the recipients’ servers for processing.

Receiving a message

Client devices regularly poll the server to see if any new messages are available.  If a new message is waiting, the server sends the client a list of block IDs, encrypted block keys, and message metadata.  The client retrieves the message blocks from S-3 storage.  It uses its User private key to decrypt the block keys and then uses the block keys to decrypt the message blocks and assemble them into an email message and file attachments.  Before presenting the message to the user, the client checks the signature of the message (and attachments) to verify the sender’s authenticity.

Deleting a message

Deleting a message simply involves moving the message to the user’s Deleted Items mailbox.  Messages deleted from this mailbox are flagged as “expunged” and deleted during a garbage collection phase per a predetermined mail retention policy.

Enterprise Features

Overview & Organizations

The primary distinguishing feature providing for enterprise versus individual use of the PreVeil system is the notion of an Organization.  Organizations have administrators to manage user accounts and, with certain restrictions, access user data. Enterprise users belong to an Organization, which can contain members from any email domain. Thus, Organizations can contain employees, subcontractors, partners, etc., who may not share a common email address domain.

An Organization is identified by a unique ID.  Its data is stored in the Postgres database on a specific server, just as users and Collections are managed by specific servers.  

Open

Administrators

Organizations have Administrators, who are users with certain privileges.  All the Administrators for an Organization together form an Admin Group.  Members of an Admin Group have access to an asymmetric Admin Group Key, which is encrypted under each member’s User key.