Encrypted Data as a Service (EDaaS) Model#

USEncryption’s advancements in encrypted computation have paved the way for a new Encrypted Data as a Service (EDaaS) model, where Data Owners (D.O.) own data that could be valuable to Data Users (D.U.) but should not be shared unprotected for privacy or commercial reasons.

By keeping data encrypted at all times, even while it is processed, data owners can consider trusting third parties with their most confidential data, in encrypted format, to process and extract value from it without ever decrypting it. This is all powered by our USEncrypt® library, a robust Python library that handles operations for both data owners and data users.

Since data owners keep control over how the data gets used and how the results get decrypted, data can now be treated as a service and no longer has to be treated as an asset. As an asset and unprotected, there is a clear trade-off between utilizing confidential data and keeping it private: you can have either one or the other. But as a service and encrypted, we can achieve both: we can extract value from confidential data, while encrypted, with privacy and security, never compromising the unencrypted data.

Data Owners and Data Users#

The relationship between data owners and data users can be summarized as follows:

Encrypted Data as a Service (EDaaS) Model

USEncryption’s Encrypted Data as a Service (EDaaS) Model#

Data Owners (D.O.)#

  1. Getting Access to the Encryptor. The D.O. subscribes to USEncryption’s EDaaS and gets access to the Encryptor software in a container (either on the cloud or on-prem).

  2. Generating the Custom Circuits. The D.O. enters the private key to the Encryptor in their own safe environment (if preferred, this can even be offline or on-prem), which generates the custom encrypt/decrypt and primitive functions (circuits) used for computation with encrypted data.

  3. Safeguarding the Circuits. The D.O. keeps the encrypt/decrypt functions as confidential as the private key itself, not sharing these with any other entity (e.g., neither USEncryption nor D.U.).

  4. Encrypting and Storing the Data with the Controller. The D.O. encrypts data, uploads it to their own storage on the cloud, and makes it accessible to the Controller, which has no way to decrypt it.

  5. Storing the Primitive Functions with the Controller. The D.O. uploads primitive functions to the Controller storage on the cloud. These are not sensitive/confidential like the encrypt/decrypt circuits or the private key, since they can be used to operate on encrypted data but only produce encrypted results. There is no way to decrypt these without having the D.O.’s private key and encrypt/decrypt circuits.

Data Users (D.U.)#

  1. Subscribing to Encrypted Data. The D.U. subscribes to USEncryption’s EDaaS and D.O.’s encrypted data.

  2. Getting Access to the USEncrypt® Library. The D.U. logs in and gets access to the encrypted data and the USEncrypt® library pointing to all primitive circuits.

  3. Using the Encrypted Data. Using the USEncrypt® library, the D.U. can operate on encrypted data (i.e., run algorithms, train machine learning models, etc.). These operations can combine encrypted and non- encrypted values, always producing encrypted results.

  4. Requesting Decryption of Results. The D.U. can request decryption of results to the D.O. through the Controller. The D.O. then analyzes the request: if there is no danger of leaking data, the D.O. can decrypt results and provide decrypted values back to D.U. through the Controller.

  5. Analyzing the Results. At this point, the D.U. has gathered the desired insights (e.g. analytics, results, trained models, etc.), without ever seeing the raw, non-encrypted data. Once decrypted, these results or models can be used on plaintext data without any further need to access the encrypted data or the USEncrypt® library itself.