Linux 基金会、BastionZero 和 Docker 提出了一个新的开放项目 OpenPubKey，该项目开发了用于对任意对象进行数字签名的同名加密协议。 该技术是 BastionZero 和 Docker 的联合项目开发的，目的是简化 Docker 容器镜像的数字签名，以防止其被替换并确认声明的创建者的构建。 该项目将在Linux基金会的支持下在中立平台上开发，这将消除对个别商业公司的依赖，并简化与第三方参与的协作。 OpenPubKey 的参考实现是用 Go 编写的，并在 Apache 2.0 许可证下分发。
OpenPubKey的功能不限于容器镜像，该技术可用于确认任何资源的来源，防止依赖替换，并提高数据集分发渠道的安全性。 例如，该技术适用于验证程序集、单个消息和提交。 签名创建者只需要在支持 OpenID 的服务中拥有一个帐户，消费者就有机会验证附加签名并确认其与声明的 OpenID 标识符的连接。
就其目的而言，OpenPubKey 类似于 Google 创建并之前转移到 Linux 基金会的 Sigstore 系统，但不同之处在于，它摆脱了负责维护公共日志以确认真实性的集中式服务器组件，从而显着简化了实施、使用和维护。变更（透明日志），并确保证书颁发机构（Certificate Authority）的运行。
OpenPubKey 使用 OpenID 身份验证技术并将创建的签名链接到现有的 OpenID Connect 提供商，而不是部署您自己的证书颁发机构。 换句话说，OpenPubkey 允许您使用 OpenID Connect 提供商 (IdP) 而不是证书颁发机构将加密密钥绑定到特定用户。 该技术与现有的 OpenID 提供商完全兼容，例如 GitHub、Azure/Microsoft、Okta、OneLogin、Keycloak 和 Google，并且不需要他们方面进行更改（使用提供商提供的标准 ID Token，这允许您仅通过客户端 OpenID Connect 上的更改来实现 OpenPubKey）。
OpenID 提供商颁发的令牌会转换为证书，以加密方式将 OpenID Connect 中的标识符绑定到公钥。 然后，用户使用生成的密钥对任何数据进行签名，随后可以根据 OpenID Connect 中的标识符验证这些签名。 OpenPubKey 使用具有有限生命周期的临时密钥 - 这些密钥在 OpenID 登录期间生成，并在与 OpenID 提供商的会话结束时删除。
使用 OpenPubKey 创建签名的示例算法：
- 使用 OpenID 提供商（Google、GitHub、Microsoft 等）登录。
- 向 OpenID 提供商请求 ID 令牌。
- 返回由提供商密钥签名的令牌，并包含一个“随机数”字段，其中包含请求期间传输的任意数据（传输公钥的 SHA3 哈希值）。
- 在用户端使用接收到的令牌作为证书，包括密钥数据。
- 将令牌附加到签名，类似于证书。
验证包括检查附加的令牌是否由 OpenID 提供商签名，并使用公钥验证资源上数字签名的有效性。这将验证资源是否使用证书中的标识符进行签名，并且 OpenID 提供商的签名也确认了这一点。例如，签名者可能会收到一个由 Google OpenID 提供商签名的令牌，表明其已验证为 bob@gmail.com，并使用公钥 0x54A5...FF。然后，当接收者收到使用相同密钥签名的消息时，可以使用提供商签名的令牌来验证 bob@gmail.com 的密钥是否为 0x54A5...FF，以及该消息是否确实由 bob@gmail.com 签名。
架构的简化是通过某些妥协来实现的（例如，依赖外部 OpenID 提供商以及缺乏具有分层哈希的更改日志），这些妥协在某些情况下是可以接受的，但在其他情况下则不然。 为了减少对 OpenID 提供商的依赖，其人员的妥协或行为可能会损害系统的声誉（例如，被黑客攻击的提供商可以向第三方发布虚构的密钥），建议使用额外的但非强制性的 MFA 联合签名者（多重身份验证联合签名者）用于多重身份验证的链接（令牌不仅必须由主提供商签名，还必须由确认用户的独立身份验证服务签名）。
OpenPubKey 的弱点之一还在于存在无关信息，这些信息可用于长期跟踪活动，并且无论重命名如何（重新使用标识令牌而不是新证书）。 在验证过程中直接绑定到 OpenID Connect 密钥消除了服务器部分，但显着使客户端的实现变得复杂，并且在客户端上进行攻击（攻击面）时留下了更多的回旋余地，例如，由于以下事实：密钥轮换由客户端承担。 缺少更改日志不允许客户端跟踪可能的密钥泄漏。
来源： opennet.ru
