云加密技术解析：亚马逊云服务

Scott Arciszewski 2024年2月14日 密码学

本文是云加密系列文章的一部分，全面介绍了亚马逊云服务（AWS）提供的云加密服务：何时使用、何时避免使用以及重要的使用注意事项。请持续关注本系列后续对其他云服务的深度解析。

在Trail of Bits，我们经常遇到利用云提供商加密服务来实现安全目标的产品和服务。然而，部分云提供商的加密工具和服务名称晦涩或使用场景不明确。AWS尤其如此，其海量服务针对多种用例定制，但对经验有限的开发者可能造成选择困难。本指南基于Trail of Bits丰富的审计经验以及笔者在AWS担任开发者的亲身经历，深入剖析这些服务的差异，解释重要注意事项，帮助您选择正确的解决方案以提升项目安全性。

引言

云计算提供商提供的加密技术可分为两个有部分重叠的大类：加密服务和客户端加密软件。就AWS而言，两者的界限基本清晰。

所谓"客户端"，是指服务在您的应用程序（客户端）中运行，而非在相关服务中运行。这并不意味着服务必须在Web浏览器或用户设备上运行。即使客户端运行在EC2的虚拟机上，加密也不在后端服务层面进行，因此仍属于客户端。

AWS加密服务的示例包括密钥管理服务（KMS）和云硬件安全模块（CloudHSM）。另一方面，AWS的客户端加密软件（即工具）包括AWS加密SDK、AWS数据库加密SDK和S3加密客户端。

AWS有一款产品模糊了两类服务的界限：清洁室加密计算（C3R）——这是一款与AWS清洁室服务紧密集成的客户端工具。另一款是Secrets Manager，它在客户端运行但本身是一项独立服务。（一些使用加密技术的强大功能，如AWS Nitro，将在后续博文中详细探讨。）

下面让我们探索一些AWS产品，包括它们最适用的场景以及我们在审计中经常发现的潜在问题。

AWS加密服务

AWS CloudHSM

适用场景：当行业或政府法规要求您为特定用例直接使用HSM时。否则应优先选择KMS。 避免场景：如果KMS可以满足需求。

CloudHSM本质上是在云环境中提供的AWS托管HSM。如果您的架构没有法律要求直接使用HSM，可以完全跳过CloudHSM。

AWS KMS

适用场景：任何使用亚马逊服务（甚至非加密服务）或客户端库的情况。 避免场景：加密或解密大型消息（应改用KMS进行密钥包装）。

AWS KMS可视为经过FIPS验证的HSM的可用性封装。它提供数字签名、对称HMAC以及加密/解密功能，且密钥永远不会离开HSM。然而，KMS加密旨在用于信封加密设置中的密钥包装，而非实际数据的加密或解密。

KMS一个重要但未被充分强调的功能是加密上下文（Encryption Context）。当您在加密调用期间向KMS传递加密上下文时，它会在CloudTrail中记录该上下文，且仅当后续解密调用提供完全相同的加密上下文时，加密数据才有效。

需要注意的是，加密上下文不会作为加密数据的一部分存储在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发现（Discovery）。发现是一种仅用于向后兼容的反模式。

如果您不使用分层密钥环，您可能还需要查看数据密钥缓存，以减少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密码。

除了数据库凭证，AWS Secrets Manager还可用于API密钥和其他可能被提交到源代码的敏感值。

AWS清洁室加密计算（C3R）

适用场景：如果您和几个行业合作伙伴想要找出有多少数据库条目是共有的，而不向彼此透露独家数据库条目的内容。 避免场景：如果您不进行上述操作。

C3R使用服务器辅助的私有集交集（Private Set Intersection），允许多个参与者找出他们有多少共同记录，而不向彼此透露不相关的记录。

例如：如果两个或多个医疗服务提供者想要确定他们是否有共同患者（例如，因为他们提供的服务在临床上不能安全地一起进行，但单独进行通常是安全的），他们可以使用C3R计算私有集的交集，而不侵犯仅由一个提供者服务的患者的隐私。

C3R的主要缺点是它的用例相当狭窄。

总结

我们希望这个简要概述能澄清AWS的一些加密产品，并帮助您为项目选择最佳方案。请持续关注本博客系列的后续文章，我们将涵盖其他云加密服务！

同时，如果您想更深入地了解这些产品和服务，以评估它们是否适合您的安全目标，请随时联系我们的密码学团队。我们定期举行办公时间，安排约一小时让您有机会与我们的密码学家会面并提出任何问题。

如果您喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News