The two and half problems of Edge Cloud Security: Secure Key Distribution, Enclaves, and a tamper resistant Fleet

Cloud is moving to Edge, and that's not news. It will happen, for better latencies and to meet the data spatial density needs of AI. To accelerate this transtion Cloud Service Providers (CSPs) and System Integrators (SIs) must find a fast path to solving security problems such as below:

1. Secure Key Distribution: CSPs must share data encryption keys with an edge device that's outside their physical trust boundary.
2. Secure Enclaves: All plain-text data processing and key usage on the edge devices must run in-memory, inside a secure enclave that provides protection from unauthorized users.
3. A tamper-resistant Fleet: Maps each and every device in edge cloud infrastructure to CSPs and enterprise tenants for a low level, under-fleet, capability. In a multi-tenant deployment this may be a shared infrastructure. Data key protection is half the problem here, the other half is onboarding and provisioning.

These three are not seprate problems but are linked. They must be solved together for this to work as expected. This article is based on public domain information including Hyperscaler (CSP) documentation, Open Source projects, and vendors offering products in this space - good and stable public domain references hopefully. No reference, no mention. The goal is to bubble up such a conversation and pain-points from individual teams to the ecosystem at large.

The problem of Secure Key Distribution

CSPs store data in encrypted state. When data is generated, or processed it is in plain text, then it is encrypted as it is stored. The encryption key is often a Data Key (using AWS analogy) which must itself be in plain text while it is being used. and then be deleted once it has been used and it's purpose is over; at the same time what key was used to encrypt must also be stored (encrypted) along with the encrypted storage data. CSP know how to extract the plain-text data key from encrypted data key later if needed. This is based on their key management service that may use a Hardware Security Module (HSM) or a vault. A lot of good documentation on youtube and AWS/Azure portals (references available on request).

This problem is solvable using existing technologies, but the main interest of enterprise customers and Managed Service Providers (MSPs) would be reduced CAPEX and OPEX. How to make this an open system where enterprise customers can chose different parts of the solution from different providers (not free or open source, but open choice).

Can the ecosystem come together to build it in less than 1 year instead of say 3 years?

The problem of secure enclaves

When a plain-text data key is made available for data encryption/decryption, the CSPs expect all processing to be done in memory. AWS has Nitro Enclaves which referred to be a Hypervisor based technology. Similarly Azure refers to Trusted Execution Environment (with pointers to ARM TrustZone and Intel SGX based technologies) where data remains inaccessible to unauthorized or malicious users.

The challenge for Edge Cloud is that it is expected to be a heterogenous environment. All major CPU vendors provide varying capabilities to meet this need (references available on request).

Can the Operating System abstract away the underlying hardware differences in a unified format to offer a seamless API for system integrators and CSPs supporting a heterogenous edge?

The problem of Fleet Management

CSPs do their own fleet management. Similarly System Integrators and Managed Service Providers for Edge do their own. The challenge is to provide this as an open solution, at minimal personnel overhead so that enterprises do not need to allocate additional cost on this count for their Cloud to Edge digital transformation. More relevant to our conversation is, how can such a Fleet Management extend CSP's trust into remote edge devices.

The problem of Fleet Management in this article can be reduced to defining a lower layer (call it Under-Fleet) that provides well defined APIs and that can be bundled in major OS distributions. There are Open Source technologies that can help align and accelerate (references available on request). But the question remains, who or which ecoystem can be the catalyst to bring together a minimum functional system that will be largely reusable by CSPs, SIs and MSPs.

Epilogue

Do these problems make sense to you? Did I misprioritize, leaving out other higher, more critical considerations for you? Or did my analysis of the problem miss its mark? Drop a comment, it may help the ecosystem looking at where to start and who knows we may have a solution together.