Privacy-Preserving Data Sharing with Homomorphic Encryption

A mature privacy posture can only be achieved through privacy management, privacy control, and data-centric capabilities. Cutting across various disciplines, privacy is much more than a security-only discipline.

The secure sharing of data across different clouds has become increasingly important in the information age. With more companies and organizations relying on cloud computing for secure online storage, the issue of how to share data in a private and secure manner must be addressed. Homomorphic encryption is an increasingly popular solution to this problem, as it allows encrypted data to be manipulated without having to decrypt it. In this article, we will explore homomorphic encryption technology and its potential applications for securely sharing data across clouds.

Homomorphic Encryption: A Brief Summary

Encryption schemes form a central body of activity in cryptography. For many researchers, it remains their primary activity despite the addition of other topics to the subject of cryptography. Generally, encryption schemes involve sending information from one party (sender) to another (receiver) over an insecure channel. It is assumed that the sender wishes to preserve the confidentiality of the information. That is, an adversary may not be able to figure out the information being sent.

The information that is to be sent is called plaintext. The message that is sent over the insecure channel is said to be ciphertext (or encrypted text). Clearly, the plaintext and ciphertext will differ, otherwise, the adversary may simply intercept the insecure channel and receive the information.

An encryption scheme may be described as an algorithm that takes as input plaintext and an encryption key and converts the plaintext into ciphertext. The reverse process by which ciphertext is converted back into plaintext using an input decryption key is called the decryption algorithm or scheme.

There are therefore three algorithms, an encryption algorithm, a decryption algorithm, and a key-generating algorithm (for generating a pair of encryption and decryption keys). All three algorithms are publicly known and available. Generally, the keys used by the algorithms are kept secret.

So, the process of sending information from the sender to the receiver may now be described as follows. The sender uses an encryption scheme (with an encryption key) to create ciphertext and transmits the ciphertext over the insecure channel. The receiver receives the ciphertext and using a decryption scheme (with an input decryption key) obtains the plaintext.

The question then becomes, how does the receiver acquire or obtain the proper decryption key?

For example, the sender may first send the decryption key to the receiver to be used but since the channel is insecure, care must be exercised. The transmission of keys securely is a research area in itself.

Enter Homomorphic Encryption

It is not hard to see that the above method of sending information from a sender to a receiver may be considerably simplified if we never have to decrypt the ciphertext. Upon receiving a ciphertext, the receiver simply processes the ciphertext as if it were plaintext! Ciphertext need never be decrypted.

This is the promise of homomorphic encryption schemes. Information that is to be transmitted is encrypted using a particular encryption scheme called homomorphic encryption. The receiver receives the encrypted information, does not decrypt the information (and hence does not need a decryption key), and simply computes with it.

As an example, user Alice may send her homomorphically encrypted dataset to user Bob who, upon receipt, processes the dataset using his application. Since Alice’s information is never decrypted, the adversary (and Bob) remains oblivious to Alice’s data.

While the idea of homomorphic encryption is seductive, the history of this technology is filled with disappointments. The basic ideas of homomorphic encryption have been known for decades (since the 1970s). Its three primary disadvantages have also been known for decades.

1. Performance: To date, the performance (computing time and size of encrypted text) is impractical. Despite decades of effort to improve performance, no substantial improvements have been reported. Recently, a particular subset of homomorphic functions (called partial homomorphic encryption) has been discovered that can yield somewhat better performance but even this level of performance is considered impractical by the community in general.
2. To process the received information, the receiver must use a special mathematics function library that supports homomorphic functions. Thus, the receiver must alter and change his code base to use this new library. Furthermore, the rewriting of algorithms is not an easy task since fully homomorphic encryption requires programming at a different level of abstraction (boolean circuits) compared to regular programming (no if/else conditions, no loops, etc.).
3. While homomorphic encryption may be used to protect data, it cannot be used to protect code. If a receiver wishes to send an algorithm to the receiver and the receiver needs to execute the algorithm on his/her computer, the receiver must decrypt the received algorithm, since a CPU cannot execute encrypted text.

Use of Homomorphic Encryption at SafeLiShare?

SafeLiShare does not use homomorphic encryption because of its performance issues and because SafeLiShare is concerned with emphasizing code security and protection of code IP, along with data protection and data security. All the emphasis on data security and access should not preclude concerns with the algorithm/code that processes the data. Many enterprises spend vast amounts of resources on algorithm development and code generation. Recent advances in machine learning models and AI systems emphasize the importance of algorithm design, development, and code and application development. It must be remembered that a workload consists of data and code assets.

In multi-party collaborative computing use cases, the concern of the analytics/code provider is to protect the Intellectual Property (IP) of its code asset (algorithm privacy) whereas the data provider is concerned with data security (data privacy).

In SafeLiShare’s system, both the data and code assets are uniformly treated with respect to policy specification and enforcement. Policies may be specified to protect code and data assets.

By establishing secure links between code and data assets, SafeLiShare can ensure that only a predetermined code asset can be allowed to process a given data asset, and vice versa. Both data and code assets are encrypted when stored in clean rooms. As needed and based on authorizations, code, and data assets may be combined to define a workload. When encrypted data and code assets comprising a workload are brought into a confidential computing secure enclave for execution, the encrypted assets are first decrypted using a key protected by the confidential computing hardware.

Secure Dynamic Compute and Data Assets Transparently

With SafeLiShare, organizations can start securing and collaborating data and code assets as a drop-in security service, keeping their sensitive data protected and applying on-demand dynamic computations like the entire federated data analytics workflow with policy-enforced access control. To schedule a demo, visit https://safelishare.com/demo.