intel / ehsm

An End-to-End Distributed and Scalable Cloud KMS (Key Management System) built on top of Intel SGX enclave-based HSM (Hardware Security Module), aka eHSM.

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 their cloud services.

Typically, the KMS (Key Management Service) is backed with dedicated HSM (Hardware Security Module). However, the existing hardware HSM solution is quite expensive and complex to extend on business demand. Although there are some commercial cloud HSM solutions to alleviate the problem of the scalability and availability, they still rely on the dedicated external hardware devices, and also currently there's no opensource product with low cost and scalable secure HSM solution deployed in cloud KMS use scenarios.

This project is named as eHSM-KMS, which provides a product-quality reference to help the customers setup a customized KMS (Key Management System) with the capabilities to create and manage cryptographic keys in their cloud environments.

It's based on Intel SGX (Software Guard eXtensions) technology that provides the near-equivalent hardware protection level of cryptographic functionalities including key generation, management inside the SGX enclave.

The Customers could deploy this total solution on their own private cloud or deploy it on a public cloud like Alibaba Cloud ECS SGX instances in which we have already verified.

---

Overview of the eHSM-KMS

This below diagram depicts the high-level architecture of the eHSM-KMS,

• eHSM-Core Enclave

  • The main functional component that provides cryptographic operations based on SGX SDK Crypto APIs (openssl/Intel ipp libaray).
  • The plaintext of keys are used/processed only inside this Enclave.

• The eHSM-KMS manager

  • A webservice hosted with the nodejs framework, which will send requests to eHSM-core enclave for cryptographic operations through the ffi native interfaces.
  • Provide public cryptographic APIs via RESTFUL interfaces to the users. key generation, key importing/export, encryption/decryption, sign/verify, etc.
  • Provide API access KEY and APP ID enrollment APIs.
  • Manage key properties, store/retrieve those info to/from DB.
    • Storing CMK Keyblobs, Key Versions and CMK rotation management.
    • KeyId mapping, Alias name, Origin, KeySpec, Key usage.

---

APPID and APIKey Enrollment

Since only the user with valid APPID and APIKey could request the public cryptographic restful APIs, eHSM-KMS provides a new Enroll APP which is used to retrieve the APPID and APIKey from the eHSM-core enclave via the remote secure channel (based on the SGX remote attestation).

The below diagram depicts the flow how to enroll a valid APPID and APIKey for the user,

For more details about each cryptographic APIs, please refer to the doc API_Reference.md.

---

Introduction to Keys used in eHSM-KMS

eHSM-KMS will provide different kinds of keys, but none of them will be exposed outside of the SGX enclave. The below diagram depicts the overview of the keys used in the eHSM-KMS,

• DK (DomainKey) is an AES key that is used to protect/wrap all the CMKs in a domain (region).
  • It must be securely distributed/provisioned cross all SGX-capable machines (or nodes) in a domain.
• CMK (Customer Master Key) could be symmetric or asymmetric keys.
  • Symmetric CMK mainly used to wrap the DataKey, also can be used to encrypted an arbitrary set of bytes data(<6KB).
  • Asymmetric CMK mainly used to sign/verify or asymmetric encrypt/decrypt data (not for the DataKey.)
• DataKey is a symmetric key with random size of bytes.
  • The plaintext of the DataKey is used to encrypt data locally, which should be cleared from memory once been used as soon as possible.
  • When a user wants to obtain the plaintext of DataKey again, it needs to call the Decrypt with the CMK to get the plaintext of DataKey.

Domain and Worker Nodes

The below diagram shows the definitions of the domain and worker nodes in the eHSM-KMS,

• All the SGX Nodes (SGX-capable platforms) in a Domain can equivalently & seamlessly provide KMS services for users.

• eHSM-core Enclave in each node should be provisioned with the capability of retrieving the cleartext of DomainKey. (DomainKey sharing across all the members in one domain)

• Each node may be offline/down. New node may be joined to or removed from a specific domain.

---

DomainKey Provisioning

eHSM-KMS provides a protocol based the SGX attestation to securely provision the DomainKey to each eHSM-core Enclave which is illustrated in the following diagram.

• The centralized deployment node could be an HSM-equipped platform or an SGX-capable platform.
• eHSM-dkeyserver runs as a TCP/IP socket server, and it’s responsible for generating DK and protecting it in the HSM or enclave and provisioning it to each SGX members in this domain.
• eHSM-dkeycache runs as a proxy agent in each SGX Node (only need one instance for each node). And it’s responsible for retrieving the DK from the ehsm-dkeyserver via remote secure channel and then distributing to each ehsm-core instance via local secure channel.
• Whenever a new node is joined or refreshed into the domain, the ehsm-dkeycache service will try to connect the ehsm-dkeyserver to retrieve the DK and distribute it to each ehsm-core instances via the secure channel.
• The plaintext of DK will never be exposed outside of the enclaves.

---

Build Instructions

For more details please refer to build-instructions.

---

Deployment

For more details please refer to deployment-instructions.

ehsm's Issues

unify the input params of digest for sign operation

according to the cloud kms, the digest need to be hashed by the user, so the sign operation may not need to hash it again.

e.g, ecc/rsa/sm2

support CMK rotation

feature description:
Change the key regularly at specified time intervals, with the interval unit measured in days.

background
key rotation is implemented in most KMS systems, it use for

1. minimize the risks of key leaks and misuse.
2. meet regulatory and standard requirements, and prevent security incidents.
3. improve the reliability and flexibility of user data.

dkeyserver fail to start

I built ehsm following the doc https://github.com/intel/ehsm/blob/5c91d6dc367040606cfe55fab9c3f553deeb7243/docs/build-instructions.md#build-instructions, when I execute the build command 'cd docker && docker-compose up -d', I got this such error:

root@iZbp13dtuvfgav62kg8benZ:/ehsm-ksm/ehsm/docker# docker container ls -a | grep dkeyserver
2a5fb58f800e ehsm_dkeyserver:main "sh /home/start_dkey…" 48 minutes ago Exited (0) 37 minutes ago c_dkeyserver
root@iZbp13dtuvfgav62kg8benZ:/ehsm-ksm/ehsm/docker# docker logs 2a5fb58f800e
/home/ehsm/out/ehsm-dkeyserver/ehsm-dkeyserver -r root
[get_platform_quote_cert_data ../qe_logic.cpp:378] Error returned from the p_sgx_get_quote_config API. 0xe011
Initializing logs folder [path: /var/run/ehsm/logs].Logs folder: /var/run/ehsm/logs
2a5fb58f800e 01/16/23 08:37:02,829 INFO [App/main.cpp: line 311] - Service name: DomainKey Provisioning Service 0.3.2
2a5fb58f800e 01/16/23 08:37:02,829 INFO [App/main.cpp: line 312] - Service built: 2023.01.16 8:36
2a5fb58f800e 01/16/23 08:37:02,829 INFO [App/main.cpp: line 313] - Service git_sha: 02c8fc4
2a5fb58f800e 01/16/23 08:37:02,829 INFO [App/main.cpp: line 314] - Runtime folder: /var/run/ehsm/
2a5fb58f800e 01/16/23 08:37:02,829 INFO [App/main.cpp: line 339] - Target Server: NULL
2a5fb58f800e 01/16/23 08:37:03,285 ERROR [Enclave/enclave.cpp: line 720] - TLS server: unable to load certificate and private key on the server

2a5fb58f800e 01/16/23 08:37:03,286 ERROR [Enclave/enclave.cpp: line 770] - TLS server: OCALL: error closing client socket

2a5fb58f800e 01/16/23 08:37:03,286 ERROR [Enclave/enclave.cpp: line 776] - TLS server: OCALL: error closing server socket

/home/ehsm/out/ehsm-dkeyserver/ehsm-dkeyserver -r root
[get_platform_quote_cert_data ../qe_logic.cpp:378] Error returned from the p_sgx_get_quote_config API. 0xe011
Logs folder: /var/run/ehsm/logs
2a5fb58f800e 01/16/23 08:48:56,758 INFO [App/main.cpp: line 311] - Service name: DomainKey Provisioning Service 0.3.2
2a5fb58f800e 01/16/23 08:48:56,758 INFO [App/main.cpp: line 312] - Service built: 2023.01.16 8:36
2a5fb58f800e 01/16/23 08:48:56,758 INFO [App/main.cpp: line 313] - Service git_sha: 02c8fc4
2a5fb58f800e 01/16/23 08:48:56,758 INFO [App/main.cpp: line 314] - Runtime folder: /var/run/ehsm/
2a5fb58f800e 01/16/23 08:48:56,758 INFO [App/main.cpp: line 339] - Target Server: NULL
2a5fb58f800e 01/16/23 08:48:56,996 ERROR [Enclave/enclave.cpp: line 720] - TLS server: unable to load certificate and private key on the server

2a5fb58f800e 01/16/23 08:48:56,996 ERROR [Enclave/enclave.cpp: line 770] - TLS server: OCALL: error closing client socket

2a5fb58f800e 01/16/23 08:48:56,996 ERROR [Enclave/enclave.cpp: line 776] - TLS server: OCALL: error closing server socket

The error said "unable to load certificate and private key on the server", but where is the certificate and private key ?

Upgrade to Openssl 3

Depend on Intel sgx ssl.

https://www.openssl.org/docs/man3.0/man7/migration_guide.html

support client sdk for popular programming language(go, rust, python, java, scala, etc)

Bug: RSA key can't work

• reading API docs: https://github.com/intel/ehsm/blob/main/docs/API_Reference.md#createkey
• reason flag --padding_mode doesn't correctly work.

Example:

# 1.
cd ehsm && ./run_with_single.sh

cd test/cli

# 2.  here return success
python3 createkey.py --url  https://127.0.0.1:9002 --keyspec EH_RSA_4096  --origin EH_INTERNAL_KEY --padding_mode EH_PAD_RSA_PKCS1

# 3.
python3 asymmetric_encrypt.py  --url https://127.0.0.1:9002 --keyid  0c96e815-6969-47f1-ac9b-03ba0c5fa888  --data MTIzNA==

Feature Request: Support WebKMS standard

Hi, I just got aware of this (excellent) project.

IMHO, trying to offer WebKMS (REST API) support could be a big "boost" to this project, since Web standards end up being "the final standards" (Think of TLS, OAuth, OpenID, ...).

My two cents!

Support SGX SSL as the default enclave SSL

Is there some bytes limit in Encrypt or AsymmetricEncrypt?

Hello

I'm trying to create some encrypting application using ehsm.

But I faced some error when I request Encrypt or AsymmetricEncrypt with more than some bytes of data.

For Encypt, the whole server exit with some malloc error.
And for AsymmetricEncrypt, it just fail with server exception.

Is there some limit with the bytes of data?

Thanks

verify_quote_with_file_and_policyId fails test

Running test_kms_with_cli.py, the last test test_GenerateQuote_and_VerifyQuote() fails.
with error VerifyQuote failed, error message: Server exception
The failure happens in verify_quote_with_file_and_policyId() where requests.post() returns false

resp = requests.post(url=base_url + "VerifyQuote", data=json.dumps(params), headers=utils.headers, verify=utils.use_secure_cert)
if(utils.check_result(resp, 'VerifyQuote') == False):
return
Please not that all other tests in file test_kms_with_cli.py pass successfully.
Machine is ICX server production running ubuntu20.04.
ehsm runs inside docker container
pccs runs inside docker container on same machine as ehsm.
couchdb run inside docker container on same machine as ehsm

move the HMAC verification into core enclave

currently, the request params' hmac verification process is did in web service layer, which may lead to the apikey exposure, need to move it into core enclave to enhance the security.

How to use EHSM to encrypt a secret data? Is there any relevant document？

If I need to enable secret data encryption like KMS，

Bug: memory leak

memory leak happened in import_struct_from_json() function.

ehsm/core/App/ffi_operation.cpp

Lines 92 to 106 in a415147

	ehsm_keymetadata_t *out_data = (ehsm_keymetadata_t *)malloc(sizeof(ehsm_keymetadata_t));
	if (out_data == NULL)
	return;
	out_data->keyspec = (ehsm_keyspec_t)payloadJson.readData_uint32("keyspec");
	out_data->digest_mode = (ehsm_digest_mode_t)payloadJson.readData_uint32("digest_mode");
	out_data->padding_mode = (ehsm_padding_mode_t)payloadJson.readData_uint32("padding_mode");
	out_data->origin = (ehsm_keyorigin_t)payloadJson.readData_uint32("origin");
	out_data->purpose = (ehsm_keypurpose_t)payloadJson.readData_uint32("purpose");
	*out = (T *)malloc(sizeof(ehsm_keymetadata_t));
	if (*out == NULL)
	{
	explicit_bzero(out_data, sizeof(ehsm_keymetadata_t));
	return;
	}

at lines 103 to 105, out_data is allocated but not free.

ehsm_ksm_service application running on single mode stop during the generateQuote operation

While I'm running test/test_kms_with_cli.py, it just stopped during the generateQuote operation.
Is it some code update bug?

On server side, it stops here.

wbs79-System-Product-Name 1940973 2023-08-18T18:19:27.700 INFO [function.js: line 427] - {"body":{"appid":"35a99bfc-7908-49ea-8292-cb2f6c854e7d","payload":{"mr_enclave":"26bd5697bc4ce98829c734767ca05dc5fea531aad98836c3959c516791c36c1f","mr_signer":"c30446b4be9baf0f69728423ea613ef81a63e72acf7439fa0549001fd5482835"},"timestamp":"1692350367697","sign":"pMCn/1L28VwI6SJoQZF3B9dkrTq1JpNKPglHwUovP/Y="},"query":{"Action":"UploadQuotePolicy"},"ip":"143.248.249.162"}
wbs79-System-Product-Name 1940973 2023-08-18T18:19:27.708 INFO [function.js: line 427] - {"body":{"appid":"35a99bfc-7908-49ea-8292-cb2f6c854e7d","payload":{"policyId":"c77cf40b-2431-4b3f-8c8a-9ae284775f8f"},"timestamp":"1692350367705","sign":"K+/UYPIAhomZ4eczJEdzgeLi8o2sDWYGRA3kuNWFtiw="},"query":{"Action":"GetQuotePolicy"},"ip":"143.248.249.162"}
wbs79-System-Product-Name 1940973 2023-08-18T18:19:27.716 INFO [function.js: line 427] - {"body":{"appid":"35a99bfc-7908-49ea-8292-cb2f6c854e7d","payload":{"challenge":"Y2hhbGxlbmdlMTIzNDU2"},"timestamp":"1692350367713","sign":"tIvVmlEWd3wa3mDqc8iIAUtP3BaTmGkwg0knj/3zL4U="},"query":{"Action":"GenerateQuote"},"ip":"143.248.249.162"}
wbs79-System-Product-Name 08/18/23 09:19:27,718 DEBUG [App/ffi_operation.cpp: line 1357] - challenge: 
 Y2hhbGxlbmdlMTIzNDU2 

^C^C^C^C^Z
[1]+  Stopped                 sudo ./run_with_single.sh

On client side, it stops here.

====================test_GenerateQuote_and_VerifyQuote start===========================
Succeed.
uploadQuotePolicy req:
OrderedDict([('appid', '35a99bfc-7908-49ea-8292-cb2f6c854e7d'), ('payload', OrderedDict([('mr_enclave', '26bd5697bc4ce98829c734767ca05dc5fea531aad98836c3959c516791c36c1f'), ('mr_signer', 'c30446b4be9baf0f69728423ea613ef81a63e72acf7439fa0549001fd5482835')])), ('timestamp', '1692350367697'), ('sign', 'pMCn/1L28VwI6SJoQZF3B9dkrTq1JpNKPglHwUovP/Y=')])

UploadQuotePolicy successfully 

uploadQuotePolicy resp:
{"code":200,"message":"Upload quote policy success.","result":{"policyId":"c77cf40b-2431-4b3f-8c8a-9ae284775f8f"}}

getQuotePolicy req:
OrderedDict([('appid', '35a99bfc-7908-49ea-8292-cb2f6c854e7d'), ('payload', OrderedDict([('policyId', 'c77cf40b-2431-4b3f-8c8a-9ae284775f8f')])), ('timestamp', '1692350367705'), ('sign', 'K+/UYPIAhomZ4eczJEdzgeLi8o2sDWYGRA3kuNWFtiw=')])

GetQuotePolicy successfully 

getQuotePolicy resp:
{"code":200,"message":"Query quote policy success.","result":{"policyId":"c77cf40b-2431-4b3f-8c8a-9ae284775f8f","mr_enclave":"26bd5697bc4ce98829c734767ca05dc5fea531aad98836c3959c516791c36c1f","mr_signer":"c30446b4be9baf0f69728423ea613ef81a63e72acf7439fa0549001fd5482835","createTime":1692350367702}}

check getQuotePolicy result with mr_enclave: True
check getQuotePolicy result with mr_signer: True

generate_quote req:
OrderedDict([('appid', '35a99bfc-7908-49ea-8292-cb2f6c854e7d'), ('payload', OrderedDict([('challenge', 'Y2hhbGxlbmdlMTIzNDU2')])), ('timestamp', '1692350367713'), ('sign', 'tIvVmlEWd3wa3mDqc8iIAUtP3BaTmGkwg0knj/3zL4U=')])

Bug: createkey causes eHSM-KMS-Service to abort.

If the --purpose flag is passed, creating the key will cause eHSM-KMS-Service to abort.
Example:

# first 
./run_with_single.sh

# second
python3 createkey.py --url  https://127.0.0.1:9002 --keyspec EH_AES_GCM_256  --origin EH_INTERNAL_KEY  --purpose EH_PURPOSE_ENCRYPT_DECRYPT

Bugs found in ehsm

Hello~

Heap OOB

enclave_decrypt defined in EDL set cmk_size as cmk's size, but attacker can feed cmk_size smaller then sizeof(ehsm_keyblob_t), and TBridge only malloc cmk_size for it.

public sgx_status_t enclave_decrypt([in, size=cmk_size] ehsm_keyblob_t* cmk, size_t cmk_size,
                            [in, size=aad_size] ehsm_data_t *aad, size_t aad_size,
                            [in, size=ciphertext_size] ehsm_data_t *ciphertext, size_t ciphertext_size,
                            [in, out, size=plaintext_size] ehsm_data_t *plaintext, size_t plaintext_size);

Then in function enclave_decrypt, cmk->keybloblen will out-of-bound access invalid memory, e.g. cmk->keybloblen is at offset 0x30, but cmk_size is fed with 0x20.

sgx_status_t enclave_decrypt(ehsm_keyblob_t *cmk, size_t cmk_size,
                             ehsm_data_t *aad, size_t aad_size,
                             ehsm_data_t *ciphertext, size_t ciphertext_size,
                             ehsm_data_t *plaintext, size_t plaintext_size)
{
    sgx_status_t ret = SGX_ERROR_UNEXPECTED;

    if (cmk == NULL ||
        cmk_size != APPEND_SIZE_TO_KEYBLOB_T(cmk->keybloblen) ||
        cmk->keybloblen == 0 ||
        cmk->metadata.origin != EH_INTERNAL_KEY)
        return SGX_ERROR_INVALID_PARAMETER;
    ...
}

support cmk rotation

cmk will need to be upgraded or maybe expired, so need to consider to support its rotation in future.

[eHSM-KMS] How is the remote attestation realized?

Hello,
　We are developing a system using eHSM-KMS.
　In the process, we are currently having trouble understanding how the remote attestation works.

　I have added logs to the eHSM-KMS source code to investigate remote attestation,
　From the eHSM-KMS source code, I could only understand that SSL communication is performed between DkeyServer and DkeyCache using OpenSSH.

　We also tried starting eHSM-KMS with the PCCS server stopped,
　In the SGX library function (tee_get_certificate_with_evidence),
　I could only find that an error (SGX_OL_NETWORK_ERROR:0xe019) occurs in the SGX library function (tee_get_certificate_with_evidence).

　What kind of communication is going on between the PCCS server, DkeyServer and DkeyCache?
　What I would like to know is as follows.
　　When does eHSM-KMS communicate with the PCCS server?
　　What is passed when communicating with PCCServer and what is obtained as a result?

　Regards,
　H_Sakakibara

Bug: padding is returned as part of plaintext in the SM4_CBC decryption

Description

Padding of data is also returned as part of data in SM4_CBC decryption, which causes the inconsistence between plaintext and result of decryption.

Reproduction

The following script is a minimal reproduction. Save it to bug.py in the ehsm/test folder and run.

from cli import createkey, enroll, decrypt, encrypt, enroll
import base64
import _utils_

# !!! CHANGE ME IF NEEDED
BASE_URL = 'https://127.0.0.1:9002/ehsm?Action='

appid, apikey = '', ''
appid, apikey = enroll.enroll(BASE_URL)
_utils_.init_appid_apikey(appid, apikey)

keyid = createkey.createkey(BASE_URL, "EH_SM4_CBC", "EH_INTERNAL_KEY", "EH_KEYUSAGE_ENCRYPT_DECRYPT")
text = "symmetricKey"

aad = str(base64.b64encode("test".encode("utf-8")),'utf-8')
data = str(base64.b64encode(text.encode("utf-8")),'utf-8')

# encrypt
ciphertext = encrypt.encrypt(BASE_URL, keyid, data, aad)

# test Decrypt(ciphertext)
plaintext = decrypt.decrypt(BASE_URL, keyid, ciphertext, aad)

try:
    assert plaintext == text
    print("\033[32m", "PASS", "\033[0m", sep='')
except AssertionError:
    print("\033[31m", "FAIL", "\033[0m", sep='')
    print("decrypted:")
    print(plaintext.encode())
    print("origin:")
    print(text.encode())

The result should be:

<output of the cli>
FAIL
decrypted:
b'symmetricKey\x04\x04\x04\x04'
origin:
b'symmetricKey'

Note

Note that the padding only occurs when len(text) % 8 != 0.

Service 'ehsm_base' failed to build with error: returned a non-zero code: 100

Hi, I pull the ehsm and run docker-compose build, but always truck into the step of build ehsm_base image.Could you help me have a look?

PKCS#11

Interesting project in security: new way of seeing key protection.
As you may know the standard interface towards historical HSM is PKCS#11.
That's the way we use to use remote HSMs to store Certification Authorities secrets and, more generally, private keys.
Any software that has to deal with such keys has a PKCS#11 interface (often through openssl).

How could we use ehsm that - old - way? Via a specific openssl plugin?
Thank you a lot,
db

Bug: Internal server exception when listing secrets with empty description

Description

The list_secrets API crashed with Server internal error, please contact the administrator. and code 500 when one of the description of the secrets is an empty string.

The full response:

{'code': 500, 'message': 'Server internal error, please contact the administrator.', 'result': {}}

The server log:

8a6738f1f1a 2811841 2023-10-17T07:00:54.630 ERROR [errors: line 399] - TypeError [ERR_INVALID_ARG_TYPE]: The first argument must be of type string or an instance of Buffer, ArrayBuffer, or Array or an Array-like Object. Received undefined
    at new NodeError (node:internal/errors:399:5)
    at new from (node:buffer:330:9)
    at base64_decode (/workspaces/ehsm/ehsm_kms_service/function.js:34:39)
    at listSecrets (/workspaces/ehsm/ehsm_kms_service/secret_manager_apis.js:539:41)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  code: 'ERR_INVALID_ARG_TYPE'

Reproduction

Create a file inside ehsm/test with following python code:

from cli import enroll, createSecret, listSecrets
import _utils_


BASE_URL = 'https://172.18.0.2:9002/ehsm?Action='

appid, apikey = enroll.enroll(BASE_URL)
_utils_.init_appid_apikey(appid, apikey)

secret_data = "mysecret"
secret = createSecret.createSecret(BASE_URL, "secret1", secretData=secret_data)

# encrypt
listSecrets.listSecrets(BASE_URL)

Root Cause

According to the stack trace of ehsm server, this error is triggered by a function call to base64_decode in listSecrets function. (ehsm_kms_service/secret_manager_apis.js#L539

ehsm/ehsm_kms_service/secret_manager_apis.js

Line 539 in 926fd30

secret['description'] = base64_decode(doc['description'])

The base64_decode function crash when input string is empty.

Possible Solution

Add custom handling to empty string for base64_decode function.

Trouble with setting environment of quick start

I'm trying to install ehsm and quick start with the below document.

https://github.com/intel/ehsm/blob/main/docs/build-instructions.md

However, I faced some troubles with setting PCCS server IP and host ip.

Am I correct that we should change the pccs url in /etc/sgx_default_qcnl.conf with https://1.2.3.4:8081/sgx/certification/v3/ and host ip and pccs url in docker/.env?

For me, it doesn't work. May I get some help?

ehsm_base

Support SM9 (cryptography standard)

Background

SM9 is a Chinese national cryptography standard for Identity Based Cryptography issued by the Chinese State Cryptographic Authority in March 2016(from wikipedia). it is also standardized in ISO 18033-5 .

Use cases

1. communication between distributed IoT Devices, such as V2x (ie. vehicle to vehicle )
2. communication between IoT Devices and Cloud Services, such as EV Charging Points and Cloud Services
3. ...

Anti-DoS attack

Reject Restful APIs from the blacklisted callers

the dkeycache service CPU usage is alawys 100%

when I deployed ehsm based on https://github.com/intel/ehsm/tree/main/docker , the dkeycache CPU usage is always 100%.

docker-compose logs:

support restful request with attestation token

attach the attestation token into the request params to assure the kms is actually run in the enclave.

Support Intel Trust Authority Attestation

@yang8621