先来看独立的密钥安全技术
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,纯本地存储或自建存储。
方案选择
现在我们回归实际业务，从
- 操作难易程度
- 业务方向
- 成本控制
三个角度考虑最优方案。
首先，很明显，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曲线，这也是一个趋势，所以这种方式可以突破这种限制，实现多链支持。