PreVeil encrypts all user data End to End which means that the information is encrypted and decrypted only in a user’s client device. The information stored on the cloud server is always encrypted; the server never can see plaintext data. In the PreVeil system, each document or message is encrypted with its own unique key, using the XSalsa20 stream cipher. Even file names and email subjects are encrypted. The decryption keys are never visible to the server, unlike other systems where the server has access to decryption keys in order to manipulate or display user data. PreVeil’s cloud servers are designed to protect user information even when they’re under attack because they can never see unencrypted data nor access decryption keys.
Taller IT Walls Aren't Working
Much of the state of the art in information security has been focused on building better and taller walls around enterprise IT systems. The security of the IT fortress becomes even more critical as more data moves to the cloud and as cloud service providers aggregate data from many organizations in one place. The problem is that these walls are limited in their effectiveness, and daily news stories of breaches only underscores their fragility. If a cloud service operates on plaintext user data, it’s vulnerable to attack.
Perhaps the problem should be reformulated: how can user data be protected even when the cloud is breached? The PreVeil system is designed to do just that.
With PreVeil, you're protected, even if the cloud is breached.
Here's how it works:
Advanced Key Management
The PreVeil key management system is designed to allow users to communicate and share encrypted data across multiple devices while hiding the complexities of keys from users. Each user is assigned a public/private key pair using Curve25519-based cryptography. The user’s public key is stored on the server and is accessible to other users, and the private key is stored only on the user’s device.
When a document or message is created, it is encrypted using a unique symmetric key.
This document key is then wrapped (encrypted) with the public key of each user that has access to the document. So if Alice and Bob both have access to document D, the key that encrypts D is encrypted itself using Alice’s public key and again using Bob’s public key. These two encrypted keys can now be safely stored on the server along with the encrypted document. When Alice needs to access the document, the system retrieves the encrypted document as well as the encrypted key (i.e. the document key that was encrypted with Alice’s public key). The PreVeil software on Alice’s device then uses her private key to unwrap (decrypt) the document key. And now the document key is used to decrypt the document itself. The creator of the document also digitally signs the document key so anyone else accessing the document can be assured they’re dealing with an authentic document (as opposed to an attacker who may be trying to claim they’re the author of the document).
All of this key management and distribution is completely transparent to the user and happens automatically.
Distributed Trust & Approval Groups
The PreVeil system avoids centralized points that can become targets for attackers. For example, most systems have the concept of a “super-user” or “administrator” who can access all information in the system. PreVeil doesn’t have such a concept, but administrators can still access encrypted corporate information when necessary. Trust is is not centralized, it’s distributed amongst a set of administrators or users. We call this concept Approval Groups, which can be set up to require x out of y people to agree before a privileged activity can occur. Approval groups are enforced cryptographically, not by using business logic on the server. Therefore an attacker cannot force approvals by taking over the server. In the PreVeil system, Approval Group authorization results in the generation of a Recovery Key – a key that only exists if the right approvers give their approval. Consider an example where an Approval Group is used to recover a user’s private key when all their devices have been lost or stolen. When the Approval Group is created:
- The user’s private is encrypted with the Recovery Key
- The resulting wrapped key is stored on the server.
Now let’s assume the user has lost all of her devices and needs to recover her private key:
- The user initiates the key recovery process on her device, which requires that she communicate with Approval Group members to authorize recovery.
- Once the required number of Approvers agree, the Recovery Key is generated on the user’s device.
- The wrapped private key is now sent by the server to the user’s device
- The Recovery Key is used to unwrap (decrypt) the user’s private key.
It’s important to note that no single approver can authorize the privileged activity; a critical set of approvers (defined when the approval group is established) must do so. Recovery Keys can also be used to provide access to a shared folder in a file system (revealing the folder’s key) or to authorize certain transactions or features (such as deleting a user’s account) by using the Recovery Key to create a digital signature that enables the transaction. To show how Recovery Keys are created and used, consider a simple example where 2 out 4 approvers must agree in order for some privileged activity to occur. Recovery Keys are reconstructed by solving a polynomial equation (based on the Shamir Secret Sharing algorithm, created by Adi Shamir). When only two approvers are required, the polynomial equation is a simple one, representing a line, such as y = a1x + s. Here s is the shared secret to be recovered, the Recovery Key. Each possible approver is represented by an (x,y) coordinate, where x is the approver’s user ID, and y is their part of the shared secret. As long as at least two users approve – i.e. give up their part of the shared secret, the original equation for the line can be calculated, and s (the Recovery Key) can be determined. If more approvers are required, a higher-order polynomial is used, e.g. y = a2x2 + a1x + s for 3 approvers.
Ease of Use
The PreVeil system is designed from the ground up to be easy to use, with a focus on a clean, simple user interface that hides complexity. It’s designed to integrate with existing applications and ways users like to work. For example, shared documents can be manipulated through the system’s native file manager – the Finder in Macintosh and File Explorer in Windows. PreVeil can also integrate with existing mail clients, like Mail on Macintosh and Microsoft Outlook on Windows. Consider Outlook as an example. Outlook was designed to connect to a Microsoft Exchange server as well as Internet email accounts using the IMAP and SMTP protocols. When a user installs PreVeil on a Windows computer, she is given the option of installing PreVeil in Outlook. When she does, PreVeil installs a special email account (with the same email address that the user already has) that’s used for secure communication. The account is set up to use IMAP/SMTP. PreVeil installs IMAP and SMTP proxies that are locally hosted on the user’s machine. All Outlook mail traffic to and from the PreVeil account goes to these PreVeil local proxies, which decrypt/encrypt messages and store them on the PreVeil server.
No Additional Passwords
Password proliferation is a big problem for two reasons – ease of use and security. Users hate having lots of passwords because of the difficulty in remembering and managing them. They often choose easy-to-guess passwords or store their password lists in an insecure place. From a security standpoint, password proliferation means less protection, not more. Passwords are also a major security risk for cloud service providers because password storage locations become prime targets that are inevitably breached; hundreds of millions of LinkedIn and Yahoo passwords have been stolen by hackers who breached their “secure” servers. In the PreVeil system, users are not required to create or remember any password. Instead, the system relies on strong cryptographic keys for user access. These keys are the private keys described above and are automatically created, managed and stored on the client device and available only to the user. PreVeil has no access to them. A user’s private key functions as a password except, unlike conventional passwords, it is equivalent to a number with dozens of digits. When users create a PreVeil account on additional devices, care is taken to transfer this private key to the new device using the secure Diffie-Hellman key transfer algorithm. Finally, any email or document encryption key stored on PreVeil servers is always encrypted (wrapped) under the user’s public key instead of a guessable password. Neither a hacker nor PreVeil can access it. With current computing power, it will take decades of computation to guess a key.