Cloud Attestables on Morello Boards (CAMB)
Lead Research Organisation:
University of Cambridge
Department Name: Computer Science and Technology
Abstract
The overall aim of the project (called CAMB) is to enhance the Morello board with security run-time execution environments which we call attestables. This enhancement would motivate cloud providers to add Morello boards to their hardware infrastructure and use them to instantiate attestables, attest, and rent them as attestable services to cloud clients upon requests. CAMB's aim is to expand overall support of the Morello board and develop software components on top of the existing CHERI software stack.
CAMB's innovation is the attestables that are in essence sandboxes underpinned by capabilities supported by hardware and guarantee three security properties:
1. Its data is not observable by unauthorised parties.
2. It will follow the rules it is started with faithfully,
3. It can attest by the cloud provider to the first two points.
The limitation of the security guarantees offered by current cloud providers have mo- tivated our proposal. We believe that the attestable will progress the state-of-the-art in cloud security. The possibility to instantiate attestables on the Morello board will create a demand and rise the level of security guarantees. A cloud provider will be able to offer clients execution environments to run applications that are exfiltration sensitive. On the other hand, the deployment of Morello boards in cloud provider's infrastructure will give clients a level of assurance that current technology is far from offering.
We take a cue from the usage of Hardware Security Modules (HSMs). HSMs are pieces of hardware that leading cloud providers deploy and rent to clients as security boxed for storing cryptographic keys and performing cryptographic operations without the risk of unauthorised access. However, HSMs are concerned primarily with data at rest, in contrast, an attestable offers security in-memory, that is, with no persistence. To request the rent of an attestable, a cloud client (say, Alice) will execute the following procedure with the cloud provider:
1. Alice sends the application and specification usage, e.g, 3 hours (a service contract) to the provider.
2. The provider accepts the contract, creates the attestable, populates it with the application, attests it and responds with a signed contract.
3. The provider instantiates the attestable, grants access to Alice, and wipes the mem- ory used by the attestable after usage.
4. Alice uses the attestable. In collaborative applications (eg, fair exchange) she shares it with other clients.
5. The provider wipes the attestable memory.
CAMB's innovation is the attestables that are in essence sandboxes underpinned by capabilities supported by hardware and guarantee three security properties:
1. Its data is not observable by unauthorised parties.
2. It will follow the rules it is started with faithfully,
3. It can attest by the cloud provider to the first two points.
The limitation of the security guarantees offered by current cloud providers have mo- tivated our proposal. We believe that the attestable will progress the state-of-the-art in cloud security. The possibility to instantiate attestables on the Morello board will create a demand and rise the level of security guarantees. A cloud provider will be able to offer clients execution environments to run applications that are exfiltration sensitive. On the other hand, the deployment of Morello boards in cloud provider's infrastructure will give clients a level of assurance that current technology is far from offering.
We take a cue from the usage of Hardware Security Modules (HSMs). HSMs are pieces of hardware that leading cloud providers deploy and rent to clients as security boxed for storing cryptographic keys and performing cryptographic operations without the risk of unauthorised access. However, HSMs are concerned primarily with data at rest, in contrast, an attestable offers security in-memory, that is, with no persistence. To request the rent of an attestable, a cloud client (say, Alice) will execute the following procedure with the cloud provider:
1. Alice sends the application and specification usage, e.g, 3 hours (a service contract) to the provider.
2. The provider accepts the contract, creates the attestable, populates it with the application, attests it and responds with a signed contract.
3. The provider instantiates the attestable, grants access to Alice, and wipes the mem- ory used by the attestable after usage.
4. Alice uses the attestable. In collaborative applications (eg, fair exchange) she shares it with other clients.
5. The provider wipes the attestable memory.