Author: Riccardo Focardi，Flaminia L. Luccio
Conference: CCS 2021
Paper Link: https://arxiv.org/abs/2109.13631
Note Link: https://jbox.sjtu.edu.cn/l/r1Xn25
Contributor: pdh
Overview
硬件安全模块（Hardware Security Modules, HSM）是一种可信的硬件，用来在复杂的系统中执行一些敏感的操作，主要是针对密钥的存储。通常人们在使用服务器时不会讲密钥直接存储在磁盘中，而是被保障在HSM的安全范围之中。HSM长期被用于保护SSL/TLS的加密密钥，以便实现安全的网路通信。近年来，HSM在其他领域有了更多的应用，例如金融、政府数据、主机游戏、区块链交易等。（介绍视频：https://www.youtube.com/watch?v=hOzkr66G1jw ）HSM具有防止数据被篡改的硬件特性，一般来说它会向外部提供一些API，方便使用者完成密钥的存储、封装、加解密等操作。最通用的API为PKCS#11，或者叫Cryptoki。
然而在过去二十年的研究中，发现其存在一些API级别的漏洞，例如$\textit{wrap-then-decrypt}$ attack，其存在漏洞的主要原因在于用来封装的密钥和被封装的密钥没有被区分开，同时还存在封装密钥多次使用的问题。后续有一些adhoc的工作来修补这一漏洞，在API中提供了wrap_with_trusted这一接口，但这个问题并没有受到广泛的关注。最新的PKCS#11的文档甚至还保留了之前不安全的wrap接口，而并未在文档中提到它的不安全性。还有一些其他的adhoc的工作，但是这些工作并不完整，没有对完整的API接口进行修改，只是设立了一个API的安全子集。随着近年来HSM在云上的使用越来越广泛，这些安全问题需要更加被注意。
本文提出第一次提出了针对HSM的配置（configuration，不太理解这个词，可能用standard更好理解？），通过对HSM的使用者的角色划分来防止那些有漏洞的API被攻击者利用导致密钥的泄露。本文将使用者划分成三种不同的类型：
- Normal Users：(𝑖)他们可以使用完整的API，以最大限度地提高兼容性；(𝑖𝑖)他们不能利用应用API级别的攻击来泄露敏感密钥，因为他们是最容易受到攻击的HSM用户。事实上，攻击者可能会利用生产应用程序中的漏洞来获得对HSM API的访问权限。
- Key Manager：这些用户利用标准的API来管理系统中的密钥。他们负责处理将用于包装其他敏感密钥的受信任密钥。这些钥匙的生命周期非常微妙。例如，它们不应该被包装在其他密钥下，也不应该被允许加密或解密数据。这样的用户通常处于更高的特权级别下，但是他们不能像NU一样开发普通的应用程序。
- Security Officer：安全官员是遵守PKCS#11标准的特殊用户，却无法访问完整的API。因此，SO主要执行管理任务，例如创建其他HSM用户和将密钥标记为受信任。具体来说，SO只能将由KM生成的密钥标记为trusted。同样的，他们不能像MU一样开发普通的应用程序。
直觉上来说，当讲trusted keys（由KM或者SO创建）与其他密钥区分开始，被封装的密钥就无法被攻击者获得。但是这个问题的难点在于要严格定义各种权限用户的能力，使得整个系统处于一个安全的状态。本文的角色分离基于一个重要假设，即一个用户生成的密钥可供其他HSM用户使用，但密钥管理操作(如属性更改)将仅允许密钥所有者使用。本文将展示这种形式的温和访问控制已在实际的云HSM解决方案中实现。
Contribution
(1) 本文第一次提出了通过对用户角色的划分来构建安全的PKCS#11。具体来说就是新增了两种特别的用户：Key Manager和Security Officer来创建trusted keys。
(2) 基于用户角色的划分，本文提出了第一个实际可用的HSM Configuration，它不需要对PKCS#11作任何的修改和限制，并且具有很好的兼容性。
(3) 本文展示了如何将这些规则直接应用于AWSCoudHSM，它提供了对用户和密钥的适当访问控制。
(4) 本文对PKCS#11的核心部分进行了形式化建模，并且用其区队提出的安全配置规则进行形式化的验证。本文使用了Tamarin这一形式化工具，用来验证敏感的密钥永远不会泄露给普通的用户。整个证明过程是全自动化的。