公有云上唯一一个FIPS-level4级别的HSM是如何实现的

作者：刘建国

介绍：IBM 云架构师 10年+IT从业经验， IBM 数字资产社区活跃成员，IBM在托管领域专家，目前专注于中国数字托管产业的发展。

————————————————

• Hyper Protect Crypto Services （HPCS）扫盲篇
• 什么是HPCS
• 什么是HSM
• 主秘钥（Master key）
• BYOK
• 安全性
• 冗余性
• BYOK VS KYOK

Hyper Protect Crypto Services （HPCS）扫盲篇
什么是HPCS

关于Hyper Protect Crypto Services（HPCS）,IBM 的官方文档的描述是这样的

IBM Cloud® Hyper Protect Crypto Services (Hyper Protect Crypto Services for short) is a dedicated key management service and hardware security module (HSM) based on IBM Cloud. With this service, you can take the ownership of the cloud HSM to fully manage your encryption keys and to perform cryptographic operations. Hyper Protect Crypto Services is also the only service in the cloud industry that is built on FIPS 140-2 Level 4-certified hardware.

Hyper Protect Crypto Services integrates with Key Protect application programming interface (API) to generate and manage keys. The Keep Your Own Key (KYOK) function is also enabled to provide access to cloud-based cryptographic HSMs. You can access the network addressable HSMs by making standard PKCS #11 API calls or Enterprise PKCS #11 over gRPC (GREP11) API calls to perform cryptographic operations.

我们先把这段话翻译成中文大概是这样的：
IBM Cloud®Hyper Protect Crypto Services(以下简称Hyper Protect Crypto Services)是一款基于IBM Cloud的专用密钥管理服务和硬件安全模块(HSM)。通过此服务，您可以获得云HSM的所有权，以完全管理您的加密密钥并执行加密操作。Hyper Protect Crypto Services也是云行业中唯一基于FIPS 140-2 Level 4认证硬件的服务。

Hyper Protect Crypto Services集成了Key Protect应用程序编程接口(API)来生成和管理密钥。还启用了KYOK (Keep Your Own Key)功能，以提供对基于云的加密HMS的访问。您可以通过标准PKCS #11 API调用或企业PKCS #11通过gRPC (GREP11) API调用来执行加密操作来访问网络可达的HSM服务。

看不懂是不是，没错一般人都看不懂，我第一次看也看不懂，因为仅仅两段话包换的名词和信息量巨大，任何一个点都能写成一篇又臭又长的文章。
那么这票博客的目的就是用最通俗的大白话把上面这段话说明白

通过文档描述我们能看到 HPCS主要包含两个主要的部分：

1. 秘钥管理服务(key management service), 简称KMS
2. 硬件安全模块(hardware security module), 简称HSM

如果你之前接触过其他厂家的相关服务，您可能听到KMS和HSM会觉得耳熟，没错，通常来说像AWS等这是2个服务是单独的，但是IBM把他们打包成了一个服务，这个服务就叫HPCS， 那么为什么IBM把他们打包成一个服务呢，因为企业级或者说金融级别的KMS是依赖于HSM。所以我们先来讨论什么是HSM。

什么是HSM

我的习惯是先上图：

这货就是硬件安全模块(hardware security module)HSM，说白了就是一块加密卡,这货牛的不得了，具体怎么牛，请参考这里。
我们通常用的都是软件生成的秘钥，比如用ssh-keygen生成登录秘钥对或者用openssl生成证书，加密卡干的就是这些事，当然这卡能办的事远远不止上面这些。
有人可能会问为什么要用硬件的加密卡，软件的不是也可以吗？
其实要回答这个问题就涉及到企业级的加密需求与合规需求了。
软件的解决方案的安全性和合规性是没法和加密卡比的，
这个加密卡IBM给的描述是

FIPS 140定义了加密模块的安全需求。它是由美国国家标准与技术协会(NIST)发布的，被广泛用于衡量hms的安全性。IBM CEX6S通过NIST(证书编号3410(链接位于ibm.com之外)的FIPS 140-2 Level 4认证，这是商用加密设备可获得的最高级别认证。

没错，这货是你能在市面上各个云厂家里唯一实现了FIPS 140-2 Level 4认证的，也是最高等级的认证。
搞安全的应该知道各种认证能把人搞死，所以我们就不具体展开讲了，如果想了解具体的可以自行谷歌下这个认证，但是有一点可以提一下，这个FIPS 140-2 Level 4 之所以牛逼，在于它是360度物理保护的，如果检查到入侵，存储的秘钥会被自动清除，以防止秘钥有泄露的风险。

听到这里是不是有点慌，这货是不是太过安全了，检测到入侵直接把秘钥给我删了，那我的秘钥如果没有备份岂不是凉凉了。这里就要引出一个新的概念 master key， 这货其实删除的是master key。
那我们下面不得不讲一下什么叫master key了。

主秘钥（Master key）

学安全的都知道，安全的东西拼的是逻辑紧密，有些东西用起来很简单，但是背后的原理，如果深究就会很头痛，里面的逻辑是一环扣一环，为了大家的快速理解本人将用最大的大白话说明这里面的逻辑。

首先我们知道秘钥是加密数据的，这个加密数据的秘钥，IBM那边的叫法是数据加密秘钥data encryption key（DEK），但是这个秘钥怎么保存成了叫人头痛的问题，如果以明文保存，一旦被窃取，就凉凉了，所以安全起见通常会把这个秘钥也加密，这个被加密的DEK的秘钥，叫root key，也叫客户根秘钥customer root key（CRK），那么问题又来了，这个CRK怎么存又是个问题了，所以还要给他加个密，这个秘钥就叫master key（主秘钥），这个master ky 就是最后的总秘钥，所以他们的关系应该是这样的

从上面这张图可以看出master key 是这个加密链条的根，也是最重要的客户隐私资产，有点像分层确定性加密钱包里的seed，所以他的重要性是不言而喻的，关于这个master key，我后面会单独写一篇文章讲他的加密与管理逻辑，为什么要单独把它拿出来讲呢？一个是它太重要了，

那么问题来了master key要怎么存呢？
这里面又要引入一个新的概念 KYOK

BYOK

KYOK 就是keep your own key的缩写，翻译成中文叫保持客户自己的秘钥，
与之对应的是BYOK （bring your own key），这俩货有啥区别我们等会展开讲，
万事不离其宗，我们先讲原理。

首先回到刚才那个master key 的问题。我们把master key要怎么存的问题细化下引入了如下子问题

1 master key 是怎么来的

2 master key 保存在哪里

3 master key 的安全防护是怎么做的

我们先看第一个问题 master key是怎么来的？
1 master key 是HSM在硬件内部通过多个key合成来的，这些合成master key的子key ，我们叫它秘钥分量。
秘钥分量被上传到HSM后，HSM通过多个秘钥分量合成一个master key，这个master key 会被烧录到HSM的硬件里，master key被写入到硬件里后，就不能被读取了，就是说这个master key 不能离开HSM的硬件，这个是由技术来保证的, 所以这个master key 也是不能够被备份的，所以用户初始化的时候要求至少有2个HSM 加密单元，两个加密单元同时初始化并烧录master key，大概流程如下图。

如上图 通常来说秘钥分量是由多个人同时持有不同的秘钥分量，合成master key的时候通过多人同时操作来完成秘钥分量的上传，master key 收到秘钥分量后合成master key，HSM不并保存秘钥分量，秘钥分量只有客户才拥有，所以这就是KYOK，用户持有自己的key。

安全性

master key 生成与保存问题解决了，安全性通过以下几点来保证
1 HSM 基于FIPS 140-2 Level 4 安全标准，从物理层面保证master key 的安全性，如果检查到有泄露风险行为的发生，HSM会主动删除master key 以防止用户关键资产泄露，客户需要拿秘钥分量重新合成master key。
2 秘钥分量的形式，通过不同人持有不同的秘钥分量，通过权限隔离，防止了坚守自盗的风险。
3 角色隔离，我们这里提到的HSM初始化的流程其实省略了很多逻辑步骤，真正的初始化流程其实还有管理员角色与秘钥分量持有人角色和CA 角色，实际的操作还需要有签名管理员签名才可以下发，由于篇幅的原因我们这里不展开了。
4 master key 被烧录进HSM的硬件里，是只写的，IBM和机房运维人员以及任何人都没法读取的，这个是通过技术手段保证的，而不像其他云厂商是通过流程与合规手动保证的。

冗余性

1 HSM 实例支持多个加密单元，而且可以夸大区，这里就提高了冗余性
2 加密分量是可以备份的
3 即使HSM 的所有大区都遭受灾害，所有HSM都被毁坏，客户依然可以使用手中的加密分量在IBM任何一个可用区快速初始化一个新的HSM和相应的master key。

BYOK VS KYOK

上面这张图是从youtube 的IBM HPCS 介绍视频中截图下来的，里面列了BYOK与KYOK的对比信息与异同。
我们先挑重点讲

master key，没办法这个是根本，我们上来还是要先讲这个
KYOK ： IBM的HPCS的master key是通过用户持有秘钥分量来持有的，IBM本身不能访问master key
BYOK： 其他云厂家的master key 是通过HSM自动生成的，客户并不持有master key，而且这个master key 是通过合规与流程保证云厂家不会访问的，说白了就是AWS帮你生成一个master key，然后告诉你我不会访问这个key，请你放心，其实这个是不符合安全里的概念-零信任。
看到了吧这个就是最主要的区别。
所以这一点引出了上图中的如下不同

technical assurance – IBM can not access the keys (IBM 从技术角度不能访问你的key，因为IBM访问不了master key)

Client has exclusive control of HSM master key (这个没什么好讲的，上面很大篇幅都在讲这个，客户端独占HSM主密钥)

FIPS 140-2 level 4

Client manage master with smart card (客户通过智能卡的方式管理主秘钥，这个就不展开讲了，后面有机会写给大家)

client can perform key ceremony (这个就是master key的初始化了，这个要客户自己执行，因为master key 的生命周期是客户自己控制的，不像其他云厂商提供一个自己生成的master key，)

怎么样，原理懂了，这些鸟语是不是就看明白了。：）

基本原理都讲清楚了，期待我们的下一篇文章使用HPCS吧：）
————————————————
文章仅代表作者观点。
原文链接：https://blog.csdn.net/ciscojianguo/article/details/120627896