先來看獨立的密鑰安全技術

1 自建或單租戶 CloudHSM

優點：密鑰永不出硬件，無法導出，只能對外提供公鑰。
交易時，外部應用把消息哈希傳進去簽名，再把簽好名的結果拿出來用。
這種方式安全性拉滿，但成本高、容量有限，適合交易所熱錢包和高凈值用戶托管錢包。
AWS CloudHSM是FIPS 140-2 3 級驗證的硬件，是在您自己VPC下的專屬單租戶。
AWS 單租戶cloudHSM(在aws 上自建cloudHSM集群)很貴 每小時1-3美金。筆者自建一個集群且只有一個可用區,開了有兩三天，帳單干到了100多美金，差不多人民幣1000多塊。。嚇得測試結束趕緊關掉了

2 AWS KMS

其實KMS也是使用的HSM硬件（FIPS 140-3級別） 但是是多租戶的。

當然KMS支持自定義密鑰存儲，您可以與您的單租戶CloudHSM結合使用：

3 TEE環境

芯片級別的安全技術，像AWS的 AWS Nitro Enclave、Intel SGX、ARM TrustZone。

AWS Nitro Enclaves 是亞馬遜云科技提供的 TEE 解決方案，可同時兼容 Intel，AMD x86 處理器以及 Graviton arm 架構處理器，并支持 EC2 實例和 Amazon EKS（Kubernetes）計算服務。

Amazon Nitro Enclaves，旨在提供安全且高度隔離的計算環境，用于處理敏感數據和執行安全計算任務。它使用的 Amazon Nitro System 技術，可以通過硬件隔離技術將計算實例內的部分資源保護在一個受信任的硬件隔離區域中。Nitro Enclaves 采用 Nitro Hypervisor 技術，在 EC2 實例內部，允許您創建一個 CPU 和內存隔離的計算環境。它沒有持久存儲、交互式訪問或外部網絡，僅支持與其父實例通過 vsock 的方式進行安全通信。用戶無法通過 SSH 進入 enclave，并且父主機實例的進程、應用程序或用戶無法訪問 enclave 內的數據和應用程序。

4. Wallet.data本地加密存儲

錢包生成密鑰對后，用AES算法把私鑰加密，存到數據庫或文件里，要用的時候再解密。
這種方式簡單便宜，但安全系數最低，容易被攻擊，適合低價值交易、測試錢包等。

有些人喜歡把上述單獨列出就作為解決方案來講解了 其實不然，實際生產中面對不同情況各種方案是要組合起來來使用的。同時我們不能脫離需求，而中心化交易所最常見的錢包需求就是生成錢包和保管私鑰，我們以此為標的，來列舉可能的方案：

目標🎯：生成ECDSA secp256k1公私鑰。（aws 區塊鏈領域加密算法僅支持secp256k1）

No.1

** A 方式一：TEE環境+自定義HSM密鑰存儲(自定義單租戶aws cloudhsm）**，【即 在 Nitro Enclaves 環境中運行 CloudHSM 的客戶端應用】。

舉例：在 Amazon Nitro Enclaves 中運行 Amazon CloudHSM 應用。

在某些需要使用 CloudHSM 的合規場景下，如果只是單單在 EC2 示例中運行- CloudHSM 應用，在主機被攻陷的情況下，有可能造成 CloudHSM 中密鑰被竊取，或者加解密，身份驗證、授權等被利用。針對這種情況，我們可以通過將 CloudHSM 應用運行在 Nitro Enclaves 隔離環境中，來進一步增強數據的安全性和完整性。
說白了就是在 Nitro Enclaves 環境中運行 CloudHSM 的客戶端應用。 私鑰的生成，簽名 等操作都是在HSM里執行的。
AWS提供的CloudHSM SDK只是CloudHSM集群管理的API， 并不是針對hsm中key操作（生成，簽名等操作）的API,
因為CloudHSM是硬件層面的安全硬件模塊，有自己的接口方案，所以它不支持“想當然式的API直接”調用，而是必須使用一套基于密碼學的接口方案和客戶端，例如：PKCS #11, OpenSSL Dynamic Engine,JCE provider。 具體可以參考AWS CloudHSM 使用指南

B 方式二：TEE+KMS:即 在 Nitro Enclaves 環境中運行【自定義程序】調用 AWS KMS。使用kms來幫助我們直接管理密鑰的生成，簽名等操作。這些都可以直接通過kms的api調用實現， 而無需像方式一那樣處理硬件模塊接口。

注意，這里KMS的密鑰存儲理論上可以分為默認存儲和自定義存儲(自定義單租戶cloudHSM集群)，但是我們的業務是生成錢包，是基于 非對稱 橢圓加密曲線secp256k1的，但aws kms的自定義密鑰存儲不能和非對稱加密一起使用，所以這里只能使用KMS的默認hsm存儲，即直接使用KMS服務。

No.2

如上文提到的場景，( C ) 即單單在 EC2 實例中運行CloudHSM 應用。
或者 ( D ) 使用自定義程序在EC2 實例中進行KMS調用。

No.3

(E) 使用KMS+S3存儲
或者 (F) KMS+本地存儲

4 不安全

不使用KMS,純本地存儲或自建存儲。

方案選擇

現在我們回歸實際業務，從

1. 操作難易程度
2. 業務方向
3. 成本控制

三個角度考慮最優方案。

首先，很明顯，KMS的操作難易程度要遠遠小于自定義CloudHSM，且能提供幾乎相當的安全性，并且可以與aws 其他服務 高度集成，所有 KMS 密鑰使用請求都會記錄在 CloudTrail 中，方便審計。
所以在必須用HSM存儲密鑰的角度上來講，選擇直接集成KMS的優勢明顯。
其次，業務角度，交易所錢包一般分為用戶錢包和歸集錢包，其中歸集錢包又分為熱歸集錢包和冷歸集錢包。
用戶錢包顧名思義，就是每個用戶充值的時候都會分配對應網絡的一個錢包地址，一般來講這個是固定的。所以用戶錢包的生成量會非常的大。而歸集錢包地址數則相對來說小了很多，只要交易所根據自身業務量維持在一個合理范圍值即可。

這里就不得不考慮密鑰存儲的成本問題。

其次，自定義CloudHSM存儲密鑰的成本實在是太高了，單個密鑰單個小時就要1-3美刀，根本不適合用來做用戶錢包,哪怕是歸集冷錢包地址累積下來也是一筆不小的開銷。（同時歸集冷錢包的另一種普適方案是使用智能合約多簽錢包或MPC錢包。）
所以無論從哪個角度看,使用自定義cloudHSM都不是一個好的選擇，除非你自有安全硬件，機房和工程師，當然土大款人傻錢多也可以任性梭哈aws 自定義cloudHSM。
而如果歸集錢包使用kms，成本則會下降很多，也保證了相當的安全性。所以針對歸集錢包，使用TEE環境部署簽名機代碼，簽名機調用aws kms服務會是一個很好的選擇。

歸集錢包： AWS Nitro Enclaves + AWS KMS(hsm)

對于用戶錢包，由于aws單個區域內的單個用戶的kms 密鑰容量
的限制10萬個，而對于有大體量用戶需求的場景（如：交易所），單個用戶密鑰存儲的限制顯然不符合需求， 而增加可用區和賬戶數的方式顯然會帶來系統實現上更高的復雜性、繁瑣度和不穩定性。

所以，我們不如轉變下思路，將用戶錢包密鑰生成后使用AES加密后再落地，將AES的密鑰存儲在KMS，這樣就解決了用戶體量持續擴展的問題，而用戶密鑰的存儲 理所當然的選擇為S3。當然這里的密鑰生成部分依然要放在Nitro Enclaves里做，只要是生產環境的密鑰生成就要放在TEE環境里，可以將安全提升至內存級別。

用戶錢包：AWS Nitro Enclaves + AES + AWS KMS(hsm) + S3 

這種方式還有個好處就是可以突破aws的密鑰算法限制。 不管CloudHSM還是KMS的加密算法支持在blockchain領域都是只有 ECDSA secp256k1 曲線的，而一些新興的鏈如 Solana Ton等是在使用EDDSA ed25519曲線，這也是一個趨勢，所以這種方式可以突破這種限制，實現多鏈支持。