今天，我们发布了Geo Key Manager，这项功能让客户在上传到Cloudflare时可以前所未有地控制私钥的存储位置。此功能基于以前的Cloudflare创新（称为Keyless SSL）和一种基于基于身份的加密和广播加密的新型加密访问控制机制。在这篇文章中，我们将解释这个在业界尚属首次的特性的技术细节，以及Cloudflare如何利用其现有的网络和技术来构建它。不同区号的钥匙Cloudflare在三年前推出了Keyless SSL，赢得了广泛的赞誉。使用无密钥SSL，客户可以充分利用Cloudflare网络的优势，同时将HTTPS私钥保存在自己的基础设施中。无密钥SSL一直受到客户的欢迎，在一些行业，如金融行业，有关于私钥访问控制的法规。在这些受监管的行业之外，采用无密钥SSL的速度较慢，部分原因是它要求客户在其基础设施内运行自定义软件（密钥服务器）。标准配置无密钥SSLKeyless SSL的一个令人鼓舞的用例是，客户可能不信任Cloudflare这样的第三方拥有他们的私钥。我们发现这实际上非常罕见；大多数客户确实信任Cloudflare和他们的私钥。但我们发现，有时客户希望找到一种方法来降低将钥匙放在世界各地某些物理位置的风险。这就是Geo-Key-Manager的有用之处：它允许客户将其私钥的暴露限制在某些位置。它类似于无密钥SSL，但是Cloudflare在您选择的位置托管密钥服务器，而不必在您的基础设施中运行密钥服务器。这降低了部署无密钥SSL的复杂性，并提供了人们关心的控制。地理密钥管理器"只工作"，不需要软件。无密钥SSL刷新器无密钥SSL是在Cloudflare开发的，目的是使HTTPS更加安全。通过HTTPS提供的内容是加密和认证的，因此窃听者或攻击者无法读取或修改它。HTTPS使用一种称为传输层安全性（TLS）的协议来保证数据的安全性。TLS有两个阶段：握手阶段和数据交换阶段。在握手阶段，交换密钥并建立共享秘密。作为此交换的一部分，服务器使用证书和私钥向客户端证明其身份。在数据交换阶段，来自握手的共享密钥用于加密和验证数据。TLS握手可以自然地分为两个部分：私钥操作其他的一切私钥操作对TLS握手至关重要：它允许服务器证明它拥有给定的证书。如果没有这个私钥操作，客户机就无法知道服务器是否是可信的。在无密钥SSL中，私钥操作与握手的其余部分分开。在无密钥SSL握手中，服务器不在本地执行私钥操作，而是对另一个控制私钥的服务器（称为密钥服务器）进行远程过程调用。无密钥SSL允许您在逻辑上分离关注点，这样web服务器的泄露不会导致私钥的泄露。这种额外的安全性是要付出代价的。从服务器到密钥服务器的远程过程调用会增加握手的延迟，从而减慢连接的建立。额外的延迟成本对应于从服务器到密钥服务器的往返时间，如果密钥服务器在世界的另一端，则可能是一秒钟。幸运的是，这种延迟成本只适用于第一次连接到服务器。一旦涉及到密钥交换，服务器就没有完成密钥交换。此外，如果您重新连接到站点，您也不必支付延迟成本，因为使用TLS会话恢复恢复恢复连接不需要私钥。仅为初始连接添加延迟。想深入了解这个话题，请阅读我在2014年写的这篇文章。使用无密钥SSL作为基本构建块，我们开始设计Geo-Key管理器。Geo Key Manager：设计架构Cloudflare拥有真正国际化的客户群，我们了解到，世界各地的客户对其私钥的放置有不同的监管和法定要求，以及不同的风险状况。世界上没有一刀切的解决方案。基于这一理念，我们开始设计一个非常灵活的系统来决定钥匙放在哪里。首先要解决的问题是访问控制。我们如何限制私钥发送到的位置的数量？Cloudflare有一个数据库，可以获取用户设置并将其安全、快速地分发到所有边缘位置。但是，该系统经过优化，可以在全球范围内同步整个数据库；修改它以有选择地将密钥分发到不同的位置，对于Cloudflare来说，这是一个太大的架构更改。相反，我们决定探索密码访问控制（CAC）系统的想法。在CAC系统中，数据被加密并分布在任何地方。只有当您有解密密钥时，才能访问一段数据。通过只将解密密钥发送到特定位置，我们可以有效地限制谁可以访问数据。例如，我们可以在客户的私钥上载后立即加密一次，然后使用现有的数据库复制系统将加密的密钥发送到每个位置。我们以前也尝试过CAC系统，最显著的是Red十月项目。使用Red十月，您可以加密一段数据，这样就需要多个人来解密它。这就是我们的Docker Secrets解决方案的原理。然而，Red十月系统不适合Geo Key Manager，原因如下：加密到的位置越多，加密的密钥就越大当添加新的位置时，不需要重新加密（我们经常这样做），就无法加密"除了给定位置以外的任何地方"的密钥每个数据中心的公钥都必须有一个安全的注册表对于Geo-Key-Manager，我们希望能够为用户提供细粒度的控制，并且能够随着Cloudflare不断增长的网络进行扩展。我们提出了以下要求：用户可以从一组预定义的区域中选择密钥所在的区域（如欧洲、美国、最高安全级别等）用户可以添加所选区域之外的特定数据中心位置（例如，所有美国地点加上多伦多）用户可以选择其所选区域内的选定数据中心位置而不发送密钥（例如，除伦敦以外的所有欧盟地区）无论配置有多复杂，解密密钥的速度都应该很快，而且存储起来也很容易构建一个满足这些需求的系统可以让客户自由地决定他们的密钥保存在哪里，以及在不断增长的网络中发挥作用所必需的可伸缩性。基于身份的加密允许我们满足这些要求的加密工具称为基于身份的加密。与传统的公钥加密不同，在基于身份的加密中，每一方都有一个公钥和一个私钥，在基于身份的加密中，您的身份就是您的公钥。这是一个非常强大的概念，因为它允许您对数据进行加密，而不必提前获得他们的公钥。公钥不是一个大的随机数，它可以是任何字符串，例如bob@example.com或者"比伯"。基于身份的加密对于电子邮件很有用，在电子邮件中，您可以想象使用个人的电子邮件地址作为公钥对消息进行加密。与使用PGP的复杂性相比，PGP需要在发送消息之前找到某人的公钥并对其进行验证。使用基于身份的加密，您甚至可以在某人拥有与其身份相关联的私钥（由中央密钥生成机构管理）之前对其数据进行加密。公钥密码（PGP等）基于身份的加密基于身份的加密是由沙米尔在80年代提出的，但直到2001年博纳和富兰克林的提议才完全实用。从那时起，各种有趣的方案被发现并投入使用。使高效的基于身份的加密成为可能的基础加密原语称为椭圆曲线对，这个主题值得发表自己的博客文章。我们的方案基于两个原语的组合：基于身份的广播加密（IBBE）基于身份的吊销（IBR）基于身份的广播加密（IBBE）就像一个allowlist。它允许您获取一段数据并将其加密到一组收件人。我们使用的具体结构来自Delerablee 2007年的一篇论文。关键的是，密文的大小并不取决于接收者的数量。这意味着我们可以有效地加密数据，而不管有多少接收者（或者在我们的例子中是pop），数据都不会变大。基于身份的撤销（IBR）就像一个阻止列表。它允许您加密一段数据，以便除排除预定义的一组收件人外，所有收件人都可以对其进行解密。我们使用的实现来自Attrapadung等人的论文的第4节。从2011年开始。同样，密文的大小并不取决于排除的身份的数量。这两个原语可以组合起来创建一个非常灵活的密码访问控制方案。为此，创建两组标识：每个区域一个标识，每个数据中心位置一个标识。一旦确定了这些集，每个服务器都将为其区域和位置提供基于身份的加密私钥。有了它，您可以根据以下集合配置对密钥的访问：要加密到的区域集要排除的区域内的位置集区域外要包括的位置集下面是如何加密客户密钥，以便给定的访问控制策略（regions，bloc