云加密技术解析：Amazon Web Services
作者：Scott Arciszewski | 2024年2月14日 | 密码学
本文是云加密系列文章的一部分，全面解析Amazon Web Services（AWS）提供的云加密服务：包括适用场景、避坑指南以及关键使用注意事项。敬请关注本系列后续对其他云服务的深度解析。
在Trail of Bits，我们经常遇到利用云提供商加密服务实现安全目标的产品。但部分AWS加密工具和服务存在命名不透明或使用场景不明确的问题——尤其是AWS海量的服务目录虽然覆盖多种场景，却容易让经验有限的开发者无所适从。本指南结合Trail of Bits丰富的审计经验以及笔者在AWS担任开发者的实战经验，深入剖析这些服务的差异并解释关键技术考量，助您选择最适合的安全增强方案。
技术架构概述
云提供商的加密服务可划分为两个存在部分重叠的大类：加密服务和客户端加密软件。在AWS体系中，两者的界限基本清晰。
所谓"客户端"，是指服务运行在您的应用程序（客户端）中，而非相关服务内部。这并不代表服务必须在浏览器或用户设备上运行——即使客户端运行于EC2虚拟机，只要加密不发生在后端服务层面，就属于客户端范畴。
AWS加密服务的典型代表包括密钥管理服务（KMS）和云硬件安全模块（CloudHSM）。另一方面，AWS客户端加密软件（即工具）包括AWS加密SDK、AWS数据库加密SDK和S3加密客户端。
值得注意的跨界产品是清洁室加密计算（C3R）：这是一个深度集成到AWS清洁室服务的客户端工具。另一个是Secrets Manager，虽作为独立服务运行但仍属客户端范畴。（部分运用加密技术的强大功能如AWS Nitro将在后续博文中详细探讨。）
下面我们将深入分析部分AWS方案，包括其最佳应用场景和审计中常发现的技术隐患。
AWS加密服务
AWS CloudHSM
适用场景：行业或政府法规要求必须为特定用例直接使用HSM时 规避场景：若KMS可满足需求则优先选择KMS
CloudHSM本质是AWS在云环境中配置的HSM设备。如果架构没有直接使用HSM的法定要求，完全可以跳过CloudHSM。
AWS KMS
适用场景：使用亚马逊服务（包括非加密服务）或客户端库的任何场景 规避场景：加密/解密大型消息（应使用KMS密钥封装模式）
KMS可视为经过FIPS验证的HSM的可用性封装层。它提供数字签名、对称HMAC以及加密/解密功能，且密钥永不离开HSM。需要注意的是，KMS加密设计用于信封加密设置中的密钥封装，而非实际数据的直接加密/解密。
KMS一个重要但未被充分强调的功能是加密上下文（Encryption Context）。当在Encrypt调用中向KMS传递加密上下文时，该内容会被记录到CloudTrail中，且后续Decrypt调用必须提供完全相同的加密上下文才能解密数据。
关键技术细节：加密上下文不会作为加密数据的一部分存储在KMS中。如果直接使用KMS，您需要负责存储和管理这些附加数据。这两个问题均可通过使用AWS客户端软件解决（下文详述）。
近期KMS新增了外部密钥存储支持功能，KMS会调用您数据中心的HSM作为常规操作的一部分。此功能旨在满足某些国家的数据主权要求，仅应在法律强制要求时使用。通过该功能获得合规性的同时，您将牺牲耐用性、可用性和性能——通常得不偿失。
AWS客户端加密软件
AWS加密SDK
适用场景：在云应用中加密任意长度的密钥 规避场景：关系型或NoSQL数据库加密（应改用AWS数据库加密SDK）
AWS加密SDK是用于云运行应用的通用加密工具。其功能集可以简单到"封装KMS以加密文本块"（如果这就是全部需求），也可以灵活到支持分层密钥管理，在多密钥环设置中最大限度减少KMS网络调用。
关键优势：无论加密材料如何管理，AWS加密SDK都会将传递给KMS的加密上下文存储在加密消息头中，无需单独存储。
此外，如果使用包含ECDSA的算法套件，它会为每条消息生成临时密钥对，并将公钥存储在加密上下文中。这带来两个重要影响：
- 由于加密上下文被KMS记录在CloudTrail中，服务运营商无需解密即可跟踪消息在集群中的流转
- 由于每个ECDSA密钥对仅使用一次即丢弃私钥，可保证特定消息在创建后从未被篡改，即使使用多个密钥环也是如此
AWS加密SDK用户需要确保指定包装密钥而非使用KMS发现模式。发现模式仅为向后兼容而存在的反模式。
如果未使用分层密钥环，建议关注数据密钥缓存功能以减少KMS调用次数并降低云应用延迟。
AWS数据库加密SDK
适用场景：在数据库中存储敏感数据且希望永不向数据库暴露明文时 规避场景：非上述场景
截至本文撰写时，AWS数据库加密SDK仅支持Java版的DynamoDB。文档暗示未来将支持更多语言和数据库后端。
AWS数据库加密SDK（DB-ESDK）是DynamoDB加密客户端的后继产品。虽然保持向后兼容，但新消息格式带来显著改进，并能通过名为信标（Beacons） 的机制对加密字段执行查询而无需向数据库服务暴露明文。
技术核心：信标是HMAC函数的截断实例。给定相同密钥和明文时，HMAC具有确定性。如果将HMAC输出截断为几位，可将查找时间从全表扫描减少到少量可容忍的误报。
使用信标需格外谨慎：截断过短会导致大量资源浪费在误报排除上；截断不足则让访问加密数据库的攻击者可能推断信标之间的关系，进而推算出生成它们的明文值。（需注意关系泄露风险并非信标独有，任何允许加密数据库查询的技术都存在此风险。）
AWS基于PRF的生日边界提供信标规划指南，确保数据集中误报的健康分布。
免责声明：笔者在亚马逊任职期间设计了AWS数据库加密SDK使用的密码系统。
其他库和服务
AWS Secrets Manager
适用场景：需要管理和轮换服务密码（如访问关系型数据库）时 规避场景：存储网银密码等个人用途
AWS Secrets Manager可视为类似1Password的密码管理器，但专为云应用设计。与面向消费者的密码管理器不同，Secrets Manager的安全模型基于AWS凭证而非主密码或其他客户端管理的密钥。此外，您的密钥会进行版本控制以防止轮换期间的操作问题。
Secrets Manager可配置为定期自动轮换部分AWS密码。除数据库凭证外，还可用于API密钥和其他可能被提交到源代码的敏感值。
AWS清洁室加密计算（C3R）
适用场景：多个行业合作伙伴希望计算共有数据库条目数量而不泄露各自独家条目内容时 规避场景：非上述场景
C3R使用服务器辅助的隐私集合求交（Private Set Intersection）技术，允许多个参与者计算共有记录数量而不互相泄露无关记录。
典型案例：如果两个或多个医疗机构希望确认是否有共同患者（例如因提供的服务单独使用临床安全但联合使用存在风险），可使用C3R计算隐私集合交集而不侵犯单一机构服务的患者隐私。
C3R的主要局限在于应用场景较为狭窄。
总结
希望本篇概述能帮助厘清AWS加密服务的技术特性，助您为项目选择最佳方案。敬请关注本博客系列后续对其他云加密服务的深度解析！
如果您需要深入评估这些产品服务是否符合安全目标，欢迎联系我们的密码学团队。我们定期举办技术咨询会，安排约一小时的会议让您与密码学家交流答疑。
欢迎通过Twitter、LinkedIn、GitHub、Mastodon、Hacker News分享本文