Functional Encryption in ASCLEPIOS

In previous series, we have seen how ASCLEPIOS employs state of the art cryptographic schemes, such as ABE and SSE, to offer functionalities that rely on sensitive healthcare data, whilst preventing information leakage. In this post, we will examine how another cryptographic paradigm, namely Functional Encryption, is leveraged by the project’s framework.

What is Functional Encryption?

Let’s start with a definition. Functional Encryption is a cryptographic paradigm allowing fine-grained access control over data and revealing only partial information, going beyond the ‘all-or-nothing’ approach of traditional public key encryption systems. This is achieved by creating and issuing decryption keys of restricted capabilities. It can be thought of as a generalisation of the attribute-based encryption, but the idea here is quite revolutionary, as it foresees the ability to compute any function over encrypted data without ever revealing the underlying data.

But can it be used for any type of function? Actually, no! Even though from a theoretical perspective numerous functions can be supported, in the beginning only very basic functions were instantiated, e.g. Boolean formulas, due to numerous technical limitations. The recent development of schemes that can compute inner products, along with one proposed method for quadratic polynomials, have given new hope for implementing practical applications of functional encryption.

How does it work in ASCLEPIOS?

ASCLEPIOS uses both the symmetric and asymmetric key settings to perform statistical computations adaptable to the data and operations of healthcare providers. To add even more flexibility, we have also implemented multi-input functional encryption services that allow the computation of functions over encrypted data coming from different stakeholders, i.e. encrypted also with different keys. In services that use both the symmetric and asymmetric paradigm, either single- or multi-input, the following types of entities interact during the application of functional encryption computations:

Users, i.e. stakeholders that provide the data on which the functions are applied. Depending on the nature of the data, where they reside and who performs their encryption (and upload), the user may be a healthcare organisation, a physician, a patient or any other ASCLEPIOS user.

Analysts, i.e. ASCLEPIOS users who need to obtain a computation on the data provided by other users, but without accessing the actual data.

The above are the human actors in the application of the functional encryption services. In the background their interaction is enabled by:

A Trusted Authority, which runs inside a Trusted Execution Environment and is responsible for the generation and retrieval of the keys.

An Evaluator, i.e. a software responsible for calculating the function result using the ciphertext(s) and the functional encryption key.

An API Server, which is responsible for handling the requests through which encrypted data are uploaded and functional encryption services are invoked.

To give some indicative examples, the implemented services can be used to allow an analyst to know the average blood pressure of certain patients without having access to their medical records, but also to compute a linear regression formula that applies certain weights on a patient’s data (e.g. age, weight, blood pressure) to compute a predefined risk factor.

Conclusions and sneak peek to the future

We still have a long way to go until the ultimate vision of applied functional encryption is realised, but even simple statistical computations on sensitive health data performed through functional encryption can be the building blocks of truly innovative services, especially when combined with multi-party computations to achieve more advanced functionalities. Sounds interesting? This is something we are currently working on! So stay tuned for news on this but also to see how we will combine functional encryption with searchable encryption to enable queries such as “what is the average age of patients’ with condition X that share features Y,Z?”, facilitating the extraction of privacy-preserving insights across healthcare providers and practitioners.