There are many use cases where users expect that their data are end-to-end encrypted and no third party or attacker will be able to read the data except at the user's device. In some cases this is easy to accomplish and give confidence to the user about the end-to-end encryption. Generally, this is because there is a separate app at both ends of the communication and that can be examined with the proper tools.
However, there are two cases where the user wants to be sure that his data are not readable at the server, but cannot rely on a separately installed app.
The first one is data that are accessed via a web browser:
-
LastPass or other PW manager - These generally run as a JavaScript browser extension, and the user has no way to be sure that the JavaScript isn’t decrypting the content on the server, or that the JavaScript is not sending the cleartext to the server.
-
Data covered by HIPPA or other legal confidentiality requirements - It would be best to keep this data encrypted until it reaches the client device. While you could theoretically secure the data by encrypting it inside a database, this still causes potential operational problems as well as presenting a high value target since getting the encryption key for the DB would reveal the entire contents.
-
Browser-based apps - Google Docs or iCloud.com apps. User confidentiality would be greatly enhanced if browser-based apps could store their data in a standardized, secure fashion. The functionality of many apps is such that the user's data is processed entirely on the client side, and the server has no need to actually see the contents.
Other use cases where end-to-end encryption would be useful but is not commonly implemented are:
- IoT - standardized way to store data in cloud for privacy. Think fitness trackers, security cameras, etc. The server has no need to process the user data, just act as a key-value store.
This is a proposal for a standard that provides transparent privacy protection while allowing for sharing and ease of implementation. The guiding principle is:
Decryption of data must happen only at the client, never at the server. It should not even be possible to decrypt the data at the server.
JSON:
{
Name
Metadata [at the developer's discretion]
[optional: decrypted data for public sharing]
Encryption method
[optional: certificate fingerprint]
[optional: block encryption key for public sharing]
[optional: array of encrypted block keys for individual sharing]
Encryption salt
Encrypted data (PEM format)
}
Encryption would be something like DHE-RSA-AES256-GCM-SHA384 or AES256-GCM-SHA384
IoT devices can upload content using a certificate to encrypt
- security cameras
- health trackers
- GPS trackers
Apps can upload and download with PBKDF2- or Argon2-based symmetric key mixed with salt
Public sharing can be enabled by putting key into data block
REST storage and retrieval
New URL scheme: pscd:// (privacy secured cloud data) [NEED BETTER NAME]
PSCD is contained in a sandbox within the browser
Browser MUST render PSCD in a dedicated process per data source (easy in today’s browsers)
Inside the sandbox:
- Prior to any PSCD call, the sandbox acts like a standard browser window
- Process can GET resources from anywhere
- Process can POST (allows logins, etc.)
- Process can make XML-HTTP requests
- Once any PSCD call happens, sandbox becomes isolated and data MUST be transferred via PSCD channels only, not via any other channels. (This is similar to a "drop privilege" kind of call for OS daemons.)
Browser provides strong guarantees that PSCD will stay inside the sandbox unless explicitly approved or initiated by the user
- copy/paste
- drag/drop
- mobile - share icon tap by user
- call from code inside with per-instance user approval
The browser MUST display a strong, non-forgeable visual cue to users that the window or tab is displaying PSCD content
Browser transparently decrypts PSCD on download, encrypts PSCD on upload for JavaScript running inside the sandbox
Browser can treat PSCD content as an embedded iframe. Outer page can pass in info, but calls from inside to outside must be explicitly approved by user
- Resources MUST be passed in at sandbox creation time to prevent data leaks via URL or DNS lookups
- Outside can make calls into the sandbox, but the result MUST always return null
This allows for advertising-supported sites, mash-ups, etc.
Each server that anticipates uploads of certificate-encrypted data SHOULD implement a certificate retrieval mechanism on the same domain, with the certificates identified by the same identifier as user accounts. This should be done so as to make it easy to set up IoT devices.
Example: a newly installed security camera that records to cloud storage needs to be linked to an account. The camera uploads to cloudstorage.pretendco.com. The user has an account based on her email address someuser@example.com, so the camera downloads a certificate from https://certificates.cloudstorage.pretendco.com/someuser%40example.com, installs it, and uses it to encrypt uploaded blocks.
Example: a user wants to share a login username and password to another user in a password manager. The password manager domain used for the actual sync of password data is passwordserver.supersecretpwmanager.com, and user accounts are identified by a GUID. The password manager will need to look up the proper GUID, then connect to https://certificates.passwordserver.supersecretpwmanager.com/abcdefgh-1234-5678-ijkl-123456abcdef, retrieve the certificate, and use it to encrypt a key to the data block.
A way to point to a cert from somewhere else