Monday, 17 August 2020

Schrems II additional safeguards: confidential computing

The highest EU court (CJEU) in the Schrems II ruling said that standard contractual clauses (SCCs) can, in principle, be used to legitimise transfers of personal data outside the EU/EEA, provided "additonal safeguards" are implemented where appropriate (or "supplementary measures", as the European Data Protection Board or EDPB has called them).

I previously blogged about providing additional safeguards through encryption. And indeed Amazon, regarding its AWS cloud service and Privacy Shield's invalidation, emphasised its "technical and physical controls designed to prevent unauthorized access or disclosure of customer and partner content", and "advanced encryption and key management service".

I also noted that data could be encrypted in storage and in transmission ("at rest" and "in transit"), but there were difficulties with operating on encrypted data, although work was proceeding on areas such as homorphic encryption.

I just wanted to expand on that to point out that, in fact, it is a reality today that secure operations on data are possible in practice - without the third party cloud provider or other service provider being able to "spy" on the computing operations or access intelligible data that they could then give to third country intelligence or security agencies.

The main development here is "confidential computing", as it's become known as. This involves protecting data in use, within a "trusted execution environment" (TEE) which safeguards the data from outside viewing or interference. TEEs, or enclaves as they're also termed, can be implemented via hardware, e.g. Intel's SGX (Software Guard Extension) which seeks to protect areas of memory running the relevant application code on the relevant data, or via software. Edited: to clarify, yes, this isn't really working on encrypted data, it's working on unencrypted or decrypted data, but only when (effectively) it's within a secure hardware "box" that the cloud or other service provider can't peek into. This means they can't see what the data in the box is, or what operations are being conducted on that data, so they can't spy on the data or processing or tell any authorities what it is.

What's exciting is that the Confidential Computing Consortium, spearheaded by the Linux Foundation, was formed just last year, in Oct 2019, with members including Alibaba Cloud, Arm, Google, Huawei, Intel, Microsoft and Red Hat and also Baidu, Bytedance, Fortanix, Oasis Labs, Oracle, Swisscom, Tencent and VMWare. By the end of June 2020, it had been joined by companies such as Accenture, AMD, Facebook, NVIDIA, and R3 (see Members list and FAQ, CCC overview and White Paper).

Open source projects under the CCC's umbrella include an SGX SDK for Linux, an Open Enclave SDK to build TEE apps that can run across multiple TEE architectures (Microsoft) and Enarx, a platform for TEEs to create and run “private, fungible, serverless” applications (Red Hat). 

In addition, Microsoft already offers confidential computing on Azure, i.e. in the cloud using SGX, while Google offers (although not under CCC) Asylo, an open source framework for confidential computing. AliCloud uses Fortanix, also mentioning SGX. As we're talking cloud, what about Amazon's AWS, you may ask? Well, interestingly AWS is absent from the CCC membership list, but it too, in Dec 2019, had launched "Nitro enclaves" for customers to create "isolated compute environments" to process "highly sensitive data", initially in preview phase.

UPDATE: after I posted this blog, I found further articles on confidential computing so I want to add the links here: about IBM's offering of confidential computing in its public cloud and its launch of fully homomorphic encryption toolkits, and about the use of its confidential computing services (another article), again in the public cloud, by the likes of Bank of America, Daimler and (for healthcare data) Apple.

Use of technologies like confidential computing should stymy or at least deter third party vendors' and/or third country authorities' attempted monitoring or surveillance of data in use - regardless of where the servers conducting the processing are geographically located, i.e. there's no need for data localization in order to protect personal data (or other sensitive data) properly! Couple the use of confidential computing with strong encryption of data at rest and strong encryption of data in transit, and Roberta's your auntie.

What's the catch? This is all relatively new still, so there might well be teething issues. And no doubt confidential computing will be more expensive than "normal" computing, but costs should come down in future as is common with new technologies. I wonder if the CCC will go for a certification for confidential computing under the GDPR's Arts.42-43 in future? Or even Art.46(2)(e) or (f), codes or certifications enabling transfers? (as I've argued before, there shouldn't be a need for "binding and enforceable commitments of the controller or processor in the third country to apply the appropriate safeguards" if they can't even access the data in question. But Art.46 says what it says...).

(Another area worth considering is secure multiparty computation or MPC, but I didn't want to hold up this blog post while awaiting more info on that. There seems to be an industry consortium there too, the Multi-party Computation Alliance.)