伪造某人的公钥的可能性

信息安全 验证 公钥基础设施 中间人
2021-08-27 22:25:58

我知道公钥密码学是如何工作的;(非常)简化:

  1. Alice 获取 Bob 的公钥并使用该密钥发送加密消息并将其发送给 Bob。

  2. Bob 并且只有 Bob 可以解密消息,因为他是唯一拥有并发私钥的人。


场景(也简化):

我以某种方式感染了 Alice 的设备,并用我自己的公钥替换了 Bob 的“存储”公钥。在她用我的公钥加密她的消息并发送后,我截获了消息,现在可以用我的私钥解密它。然后我可以充当中间人。

编辑:我们假设我们只能以某种方式更改公钥,而不能以明文形式读取消息。


我的问题是:

  • Alice 如何知道 Bob 的公钥?
  • 是否有可能欺骗某人(或设备本身),以便他们认为他们正在向 Bob 发送消息,但实际上是用其他人的公钥加密消息?
  • 这个问题是如何规避的?
2个回答

Alice 如何知道 Bob 的公钥?

Alice 有几种方法可以验证 Bob 的公钥,每种方法都有自己的优缺点。

直接和亲自

这可能是最安全的方法。爱丽丝和鲍勃亲自见面,交换并可能签署彼此的公钥。这将使任何人几乎不可能篡改这个过程。

缺点应该很明显:这种方法对于不定期见面的人来说是不可行的。世界各地的人们需要投入大量资金才能见面,只是为了交换钥匙。

通过 Bob 的服务器

Bob 有一个 Web 服务器,由适当的 TLS 保护,并在那里提供他的公钥作为下载。虽然这比亲自会见 Bob 方便得多,但也存在妥协的风险。

如果 Eve 能够访问 Bob 的服务器并生成她自己的密钥对,她就可以用她自己的公钥替换 Bob 的公钥。一旦人们试图向 Bob 发送消息并且他将无法解密它们,这一点就会变得很明显,但此时可能已经为时已晚。

通过密钥服务器

Bob 没有自己托管密钥,而是将他的密钥上传到密钥服务器并链接到它。这与之前的方法非常相似,但将风险从 Bob 转移到了控制密钥服务器的人身上。

此外,攻击者可以以 Bob 的名义创建一个假公钥(“Evil Bob”),并另外为 Bob 的朋友创建假公钥,从而围绕“Evil Bob”创建一个假信任网络。

通过“直接消息”

一种天真的方法是在 Twitter、WhatsApp 或类似平台上向 Bob 发送消息,询问他的公钥。这里的问题是你无法真正验证这是否真的是他。攻击者可能已经访问了他的帐户并为“Evil Bob”分发了假公钥。

VoIP 系统可能会更好,但并不像人们想象的那么完美。

是否有可能欺骗某人,以便他们使用假公钥?

是的,如上所述。Bob 不直接和亲自给您密钥的任何情况都可能受到损害。

但是有保护措施。人们可以签署 Bob 的密钥,从而为 Bob 担保。这些联系越紧密地交织在一起,伪造钥匙就越困难。尽管如此,这是可能的。

Alice 如何保护自己免受 Eve 在她的设备上修改 Bob 的公钥?

假设是 Eve 能够利用 Alice 的设备来修改 Bob 的私钥。

这种情况很困难,但并非不可能。每把钥匙都有一个指纹,实际上是两个指纹:“长”和“短”,用来识别钥匙。如果 Alice 要记住长指纹,那么 Eve 就不可能创建一个冲突并插入一个她控制的密钥,并且这足以让 Alice 将其误认为是合法密钥。

如果她只记住“短”指纹,那么它在技术上是可行的,尽管像 Alice 和 Bob 这样的普通人可能会先锁定高价值密钥。

在这种情况下,信任网络也会有所帮助,因为即使生成了虚假的信任网络,Alice 也不会信任这些密钥中的任何一个,因为她需要自己的私钥来签名(并且 Alice 已经保护了她的私钥)具有 Eve 不知道的强随机密码的密钥)。

如果 Alice 将她的通讯人的公钥保存在数据库、电子表格、文本文档中;那么你的方案可行是可行的。

然而,大多数人(希望包括 Alice)只会信任已被认证为真实的公钥。目前有两种主流方法可以做到这一点:

中央权威机构认证

公钥由专门为此任务设置的组织认证 - 这些称为证书颁发机构(CA)。

当 Bob 要求他们证明他的公钥时,CA 将检查他的凭据。然后 Bob 可以将他的认证公钥(通常称为证书)发送给 Alice 和他的许多其他朋友/同事。

如果 Alice 只信任已由受信任的 CA 认证的公钥,那么您的方案现在将失败。你不能潜入你的公钥,因为它没有经过认证,因此 Alice 不会信任它。

您可以使用您的公钥接近 CA,但他们只会证明它属于您,而不是 Bob(或 Alice,或其他任何人)。

这种方法被商业 CA 使用,它们签署用于断言 Internet 上资源的身份的证书(例如本网站)。组织也可以运营自己的 CA。

由朋友和/或同事认证

上述方法的一个替代方案是让爱丽丝与已经与鲍勃对应的朋友/同事确认他的公钥是否真实。他们将通过与他人确认或与 Bob 本人确认(可能是面对面的会议)来了解这一点。这样,信任就像蜘蛛网一样传播,导致这个概念被称为信任网

后一种方法由 Pretty Good Privacy 和 Gnu Privacy Guard 使用。


不过,CA 并不是问题的全部和全部。在您的场景中,您已经破坏了 Alice 的设备,这意味着您可以将她的设备配置为信任由另一个 CA(即您的 CA)认证的公钥。您现在可以证明您的公钥伪装成 Bob 的,而 Alice 会在不知不觉中信任它。

但是,当我们与您的问题略有不同并认为“鲍勃”不是一个人,而是在一个非常大的网络(如 Internet)上的一个新资源时,CA 就会出现。在这种情况下,由于管理所有公钥问题的规模,信任网络模型将无法正常工作。

换句话说,CA 在包含单个一对一关系的场景中不会有太大好处,例如您的问题中的 Alice 和 Bob,因为它只是改变了 Alice 隐含地从Do I trust Bob's进行的测试公钥?是否相信我的设备尚未配置为信任其他 CA?

但是,在一对多的关系中,例如 Internet,CA 将取消在使用前以某种方式检查每个公钥的要求,并用检查您的设备的配置来代替它(我们都毫无疑问地这样做! )。

当然,在现实世界中,如果你成功破解了 Alice 的设备,那么你是否更改 Bob 的公钥在大局中并不重要。