Skip to content
This repository was archived by the owner on Jul 25, 2024. It is now read-only.

use the local attestation protocol to secure transfer the domain key to instead of local sealing method #1

Merged
syan10 merged 10 commits into from
Sep 6, 2021
Merged

use the local attestation protocol to secure transfer the domain key to instead of local sealing method #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
7955476
add prefix of "ra_" to the file of the implementation for remote key …
syan10 Aug 30, 2021
4603cac
initial support for local attestation protocol
syan10 Aug 31, 2021
9b930ee
add msg exchange cmd support for retrieving domain key
syan10 Sep 1, 2021
f1860ad
use the local attestation protocol to exchange domainkey
syan10 Sep 1, 2021
c86d8d1
rename the services and restruct the folder layout
syan10 Sep 1, 2021
d9dda07
update the Readme and arch diagram
syan10 Sep 1, 2021
ef9f882
unify the interfaces name of ecall/ocall
syan10 Sep 2, 2021
5c51b95
add a unified makefile in the project root directory
syan10 Sep 2, 2021
3208354
unify the duplicate header files
syan10 Sep 2, 2021
b5efb83
update readme file
syan10 Sep 3, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 14 additions & 15 deletions .gitignore
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,20 +1,19 @@
deployserver/App/enclave_u.*
deployserver/Enclave/enclave_t.*
deployserver/App/*.o
deployserver/Enclave/*.o
deployserver/out/
dkeyserver/App/enclave_u.*
dkeyserver/Enclave/enclave_t.*
dkeyserver/App/*.o
dkeyserver/Enclave/*.o

deployproxy/App/enclave_u.*
deployproxy/Enclave/enclave_t.*
deployproxy/App/*.o
deployproxy/Enclave/*.o
deployproxy/out/
dkeycache/App/enclave_u.*
dkeycache/Enclave/enclave_t.*
dkeycache/App/*.o
dkeycache/Enclave/*.o

core/untrusted/enclave_hsm_u.*
core/trusted/enclave_hsm_t.*
core/untrusted/*.o
core/trusted/*.o
core/out/
core/App/enclave_hsm_u.*
core/Enclave/enclave_hsm_t.*
core/App/*.o
core/Enclave/*.o

bin/



Expand Down
61 changes: 61 additions & 0 deletions Makefile
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
#
# Copyright (C) 2011-2020 Intel Corporation. All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
#
# * Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# * Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in
# the documentation and/or other materials provided with the
# distribution.
# * Neither the name of Intel Corporation nor the names of its
# contributors may be used to endorse or promote products derived
# from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
#

include buildenv.mk

SUB_DIR := core dkeycache dkeyserver

.PHONY: all clean

all:
for dir in $(SUB_DIR); do \
$(MAKE) -C $$dir; \
done

ifeq ($(Build_Mode), HW_DEBUG)
@echo "The project has been built in hardware debug mode."
else ifeq ($(Build_Mode), HW_RELEAESE)
@echo "The project has been built in hardware release mode."
else ifeq ($(Build_Mode), HW_PRERELEAESE)
@echo "The project has been built in hardware pre-release mode."
else ifeq ($(Build_Mode), SIM_DEBUG)
@echo "The project has been built in simulation debug mode."
else ifeq ($(Build_Mode), SIM_RELEAESE)
@echo "The project has been built in simulation release mode."
else ifeq ($(Build_Mode), SIM_PRERELEAESE)
@echo "The project has been built in simulation pre-release mode."
endif

clean:
@rm -rf $(OUTDIR)
for dir in $(SUB_DIR); do \
$(MAKE) -C $$dir clean; \
done
263 changes: 131 additions & 132 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,132 +1,131 @@
# eHSM (SGX Enclave Based Hardware Security Module)

Cloud KMS (Key Management System) is a hardware-software combined system that provides customers
with capabilities to create and manage cryptographic keys and control their use for cloud services.

Typically, it is backed with HSM (Hardware Security Module). However,the existing hardware HSM solution
is very expensive and complex to manage. So, many CSPs will provide Cloud HSM solutions to alleviate the
problem of the scalability and availability issues, but they are still depend on the dedicated external
hardware devices, and currently there's no opensource with low cost and scalable secure HSM solution for
Cloud KSM scenario.

This project is called eHSM, which is provided as a reference code based on Intel Software Guard Extensions(SGX)
technology. It's designed to be protected from processes running at higher privilege levels, like OS kernel,
hypervisor, BIOS firmware.

And Compared with the traditional solution,eHSM is an open source solution with low cost, high scalability,
and high availability and could provide the equivalent protection level of cryptographic functionalities,
including key generation, management, use etc. in the SGX enclave.

It is intended to be deployed into Cloud Environment as an alternative solution for the Cloud KMS product.

## Overview of the KMS & HSM
the below diagram depicts the high level relationships between KMS and HSM,

![kms&hsm](./docs/diagrams/kms&hsm.png)

## Architecture of eHSM

The below diagram depicts the high level architecture of the eHSM,

![ehsm-arch](./docs/diagrams/ehsm-arch.png)

## Components and Services

### ehsm-deployserver
It will be deployed in an HSM-equipped platform or an SGX-capable platform, and runs as a TCP/IP socket server.

- Responsible for generating DK(domainkey) and protecting it in the HSM or enclave.

- Respond to the connection request from ehsm-deployproxy agent and deploy the DK to it via a remote secure channel
based on the SGX remote attestation.

- It may also provide some eHSM Configuration interfaces to the Customer Operator Panel to manage the domains.
(depending on the requirements, and not implemented yet.)


### ehsm-deployproxy
It will be deployed in the SGX worker node(1:1 map with ehsm-core in a Pod), and runs as a proxy agent service.

- Responsible for retrieving the DK from the ehsm-deployserver via remote secure channel and then distributing to
ehsm-core instance via local secure channel.


### ehsm-core
It will be deployed in the SGX worker node(1:1 map with ehsm-deployproxy in a Pod), and runs as a service to provide
main KMS functionality interfaces implementation to the Customer KMS Manager.

Currently, it now support the following cryptographic functionalities:
- CreateKey
- AES_128 (GCM)
- RSA_3072
- ImportKey
- Encrypt/ Decrypt
- AES_GCM128
- RSA_3072 (Padding: RSAES_OAEP_SHA_256)
- Sign/Verify
- RSA_3072 (Padding: RSA_PKCS1_SHA_256)
- GenerateDataKey
- GenerateDataKeyWithoutPlaintext
- ExportDataKey



## Build Instructions


```shell
Build ehsm-deployserver

# cd deployserver
# make
The binary of ehsm-deployserver will be generated in the out folder.

Build ehsm-deployproxy

# cd deployproxy
# make
The binary of ehsm-deployproxy will be generated in the out folder.

Build ehsm-core

# cd core
# make
The binary of ehsm-core will be generated in the out folder.
```

## Deployment
To simply demonstrate the eHSM system, the below steps try to deploy the above three components in a single SGX worker node.
But for the real product, the user need to deploy them into different platform according with the above desciptions.

- Setup the DCAP server
- following the wiki [intel-software-guard-extensions-data-center-attestation-primitives-quick-install-guide](https://software.intel.com/content/www/us/en/develop/articles/intel-software-guard-extensions-data-center-attestation-primitives-quick-install-guide.html)
- Start the service of ehsm-deployserver
```shell
# cd deployserver/out
# sudo ./ehsm-deployserver
it will create a socket server and wait the connection request from ehsm-deployproxy agent and deploy the DK to it via a remote secure channel based
on the SGX remote attestation. (The PCCS server is the above step)
```
***Note**** It's Recommend that the deployproxy and ehsm-core should be deployed into one Pod with 1:1 mapping
- Start the service of ehsm-deployproxy
```shell
# cd deployserver/out
# sudo ./ehsm-deployserver

It will try connect to the deployserver to retrieve the DK via the secure remote channel estabilished by the remote attestation. Then it will create another new
socket to wait the connection from ehsm-core service.
A local secure channel based the local sealing key will be setup which used to transfer the DK between deployproxy and ehsm-core.

```
- Start the service of ehsm-core
```shell
# cd core/out
# sudo ./ehsm-core

It will try connect to the deployproxy to retrieve the DK via the local secure remote channel, then keep it in the SGX enclave.

When the DK provisioning is done, each key materials generated/imported/exported from the ehsm-core service will be encrypted by the DK, only the cipher text will
be returned to the caller.
A local secure channel based the local sealing key will be setup which used to transfer the DK between deployproxy and ehsm-core.

```
# eHSM (SGX Enclave Based Hardware Security Module)

Cloud KMS (Key Management System) is a hardware-software combined system that provides customers
with capabilities to create and manage cryptographic keys and control their use for cloud services.

Typically, it is backed with HSM (Hardware Security Module). However,the existing hardware HSM solution
is very expensive and complex to manage. So, many CSPs will provide Cloud HSM solutions to alleviate the
problem of the scalability and availability issues, but they are still depend on the dedicated external
hardware devices, and currently there's no opensource with low cost and scalable secure HSM solution for
Cloud KSM scenario.

This project is called eHSM, which is provided as a reference code based on Intel Software Guard Extensions(SGX)
technology. It's designed to be protected from processes running at higher privilege levels, like OS kernel,
hypervisor, BIOS firmware.

And Compared with the traditional solution,eHSM is an open source solution with low cost, high scalability,
and high availability and could provide the equivalent protection level of cryptographic functionalities,
including key generation, management, use etc. in the SGX enclave.

It is intended to be deployed into Cloud Environment as an alternative solution for the Cloud KMS product.

## Overview of the KMS & HSM
the below diagram depicts the high level relationships between KMS and HSM,

![kms&hsm](./docs/diagrams/kms&hsm.png)

## Architecture of eHSM

The below diagram depicts the high level architecture of the eHSM,

![ehsm-arch](./docs/diagrams/ehsm-arch.png)

## Components and Services

### ehsm-dkeyserver
It will be deployed in an HSM-equipped platform or an SGX-capable platform, and runs as a TCP/IP socket server.

- Responsible for generating DK(domainkey) and protecting it in the HSM or enclave.

- Respond to the connection request from ehsm-dkeycache agent and deploy the DK to it via a remote secure channel
based on the SGX remote attestation.

- It may also provide some eHSM Configuration interfaces to the Customer Operator Panel to manage the domains.
(depending on the requirements, and not implemented yet.)


### ehsm-dkeycache
It will be deployed in the SGX worker node(1:1 map with ehsm-core in a Pod), and runs as a proxy agent service.

- Responsible for retrieving the DK from the ehsm-dkeyserver via remote secure channel and then distributing to
ehsm-core instance via local secure channel.


### ehsm-core
It will be deployed in the SGX worker node(1:1 map with ehsm-dkeycache in a Pod), and runs as a service to provide
main KMS functionality interfaces implementation to the Customer KMS Manager.

Currently, it now support the following cryptographic functionalities:
- CreateKey
- AES_128 (GCM)
- RSA_3072
- ImportKey
- Encrypt/ Decrypt
- AES_GCM128
- RSA_3072 (Padding: RSAES_OAEP_SHA_256)
- Sign/Verify
- RSA_3072 (Padding: RSA_PKCS1_SHA_256)
- GenerateDataKey
- GenerateDataKeyWithoutPlaintext
- ExportDataKey



## Build Instructions

```shell
# make

The binary will be generated in the bin folder.
bin/
├── ehsm-core
│   ├── ehsm-core
│   ├── libenclave-ehsm-core.signed.so
│   └── libenclave-ehsm-core.so
├── ehsm-dkeycache
│   ├── ehsm-dkeycache
│   ├── libenclave-ehsm-dkeycache.signed.so
│   └── libenclave-ehsm-dkeycache.so
└── ehsm-dkeyserver
├── ehsm-dkeyserver
├── libenclave-ehsm-dkeyserver.signed.so
└── libenclave-ehsm-dkeyserver.so

```

## Deployment
To simply demonstrate the eHSM system, the below steps try to deploy the above three components in a single SGX worker node.
But for the real product, the user need to deploy them into different platform according with the above desciptions.

- Setup the DCAP server
- following the wiki [intel-software-guard-extensions-data-center-attestation-primitives-quick-install-guide](https://software.intel.com/content/www/us/en/develop/articles/intel-software-guard-extensions-data-center-attestation-primitives-quick-install-guide.html)
- Start the service of ehsm-dkeyserver
```shell
# cd bin/ehsm-dkeyserver
# sudo ./ehsm-dkeyserver
it will create a socket server and wait the connection request from ehsm-dkeycache agent and deploy the DK to it via a remote secure channel based
on the SGX remote attestation. (The PCCS server is the above step)
```
***Note**** It's Recommend that the ehsm-dkeycache and ehsm-core should be deployed into one Pod with 1:1 mapping
- Start the service of ehsm-dkeycache
```shell
# cd bin/ehsm-dkeycache
# sudo ./ehsm-dkeycache

It will try connect to the deployserver to retrieve the DK via the secure remote channel estabilished by the remote attestation. Then it will create another new
socket to wait the connection from ehsm-core service.
A local secure channel based the local attestation protocol will be setup which used to transfer the DK between dkeycache and ehsm-core.

```
- Start the service of ehsm-core
```shell
# cd bin/ehsm-core
# sudo ./ehsm-core

It will try connect to the dkeycache to retrieve the DK via the local secure remote channel, then keep it in the SGX enclave.

When the DK provisioning is done, each key materials generated/imported/exported from the ehsm-core service will be encrypted by the DK, only the cipher text will
be returned to the caller.
A local secure channel based the local attestation will be setup which used to transfer the DK between dkeycache and ehsm-core.

```
Loading