PKI 的不同方法

信息安全 证书 公钥基础设施 身份
2021-08-30 08:05:28

公钥基础设施又一次失败之后,我在想整个事情到底有多糟糕。不可否认地将身份与公钥相关联的业务,以及我们为实现它所做的所有工作,开始感觉就像在山上溜冰一样。原谅我,我只是在这里大声思考。

我开始思考ToR 隐藏服务协议及其解决此问题的方法。隐藏的服务名称”(像任何其他 URL 一样在地址栏中输入)实际上是从公钥派生的 - 所以你最终会访问类似的网站kpvz7ki2v5agwt35.onion- 但你不需要证书或 PKI、公钥和仅域就足以证明它们属于一起(直到您能够产生冲突,但这是另一回事)。现在很明显这有一个问题——DNS 的全部意义在于提供人类可读的 IP 地址映射。

这引出了我最后的、可能有缺陷的建议;为什么我们不使用从公钥生成的 IP 地址?(相反的方法起初听起来更方便,但由于明显的加密原因不能工作)。

我们有一个巨大的 IPv6 地址空间。一个 1024 位的 RSA 密钥对被认为最多有大约 80 位的熵。那么为什么不拆分一个 80 位段,并将公共 RSA 密钥映射到该段中的 IP 地址呢?

我的头顶上有一些缺点;

  • 因此,攻击者可以生成一个密钥对,并立即知道该密钥对将在哪个服务器上使用,如果这样的服务器存在的话。也许 80 位空间可以扩展为使用 4096 位 RSA 密钥,据信最大熵约为 256 位,使得这样的搜索不可行(不幸的是,我们需要 IPv7+ 和 512 位左右的地址才能适应)。这种攻击也没有听起来那么糟糕,因为它没有目标。这种攻击可以通过在 key->IP 过程中加入盐来缓解,服务器在连接时将其发送给客户端。这种盐使每个服务器的 key->IP 进程都是唯一的。
  • 攻击者可能会使用已知的盐对密钥空间进行暴力破解,直到它们与选定的 IP 匹配。这是有针对性的攻击,所以有点吓人。但是,使用慢速(1-3 秒)算法进行从公钥到 IP 的映射可以缓解这种情况。使用盐还意味着这种蛮力只适用于单个 IP,并且必须针对每个目标 IP 重复。

为了试图阻止mods关闭它,我会尽力把它变成一个问题;这个想法在某些方面完全有缺陷吗?过去有没有尝试过?我只是在闲逛吗?

3个回答

将公钥映射到 IP 地址很容易(只需对其进行散列并保留前 80 位),并且您已经列出了使其具有某种鲁棒性的方法(即使转换变慢)。它的缺点是它根本不能解决问题:它只是移动它。

问题在于将加密保护的访问(即服务器公钥)绑定到人类用户理解的身份概念。人类用户掌握域名您不会让他们验证散列生成的 IPv6 地址...

当然,有一个已部署的系统将名称映射到 IP 地址等技术数据;这是DNS您可以将其扩展为将域名映射到公钥验证令牌(即将公钥的哈希值放在 DNS 中的某个位置),甚至是公钥本身。如果您使用 DNS 传输对安全敏感的名称-密钥绑定,那么 DNS 将成为一个有价值的目标,因此您必须为 DNS 本身添加安全性。此时,您就有了DNSSEC,它用于替换 HTTPS 网站的 X.509 PKI 的当前提议。尚不清楚 DNSSEC 是否会比现有 CA 更好;那是转换演员,但概念认证业务仍将潜伏在这里。

人类想要人类可读的名称,而公钥是不可读的。所有基于证书的解决方案(无论是 X.509 还是 DNSSEC 或其他)都试图将公钥绑定到任意选择的名称。另一种不同的方法是使公钥可读奇怪的是,有一些加密协议:基于 ID 的加密他们使用一些相当曲折的数学工具(椭圆曲线上的配对)。它们并没有改变核心概念(实际上,在某些时候,必须有人在诸如“谷歌”之类的社会身份和计算机世界之间建立联系)但它们改变了动态. 在基于 ID 的 SSL 系统中,每台服务器都拥有非常短暂的私钥,并且中央机构每天都会向每台服务器颁发一个与其名称相匹配的新私钥。最终效果就像 X.509 PKI 一样,撤销本身就可以很好地发挥作用,因此损害遏制将是有效的。

另一个转折是取代身份的概念。由于人类无法读取公钥,因此接受它:他们不会读取它们。相反,使用知道如何读取密钥专门实体来追踪主动攻击。这就是Convergence中“公证人”的全部意义所在公证人会跟踪哪个网站使用了哪些公钥,每当他们看到可疑的东西时,他们就会尖叫并踢腿。


无论如何,当前的系统并没有被破坏——不是以经济相关的方式。您链接到的违规将加入 Comodo 和 DigiNotar 事故;这是一个简短的清单。此类问题发生的方式很少甚至出现在财务雷达上:如果您将所有使用从“受信任的 CA”获得的虚假服务器证书的欺诈成本加起来,您将获得一个小得离谱的金额来自更普通的信用卡欺诈的数十亿美元。从银行和商家以及在 Internet 上进行商务的人员的角度来看,X.509 PKI有效他们没有动力推动更换。如果每天都有假的谷歌证书,过去实际上是从别人那里偷钱,那情况就不同了。现在,我们每年大约举办一次活动。

您的想法的第一个大缺陷是它并没有真正解决太多问题。一旦您想要有意义的名称,例如当前正在使用的名称,您就需要 DNS 或类似的系统。所以你的失败点又回来了,除了它现在是 DNS 而不是 CA。

与将指纹与 IP 一起放入 DNS 相比,将指纹放入 IP 几乎没有优势,但缺点是路由变得更加复杂和昂贵。

有一个将密钥指纹放入 DNSSEC 的系统,称为DANEChrome 最近增加了对它的支持

有一个名为cjdns的系统可以将指纹放入 IP。它使用 120 位的 IP 和 8 位的加强结构,得到相当于 128 位的指纹。请注意,由于多目标攻击,实际安全级别低于指纹的大小。

您还高估了 PKI 失败的程度。强大的对手偶尔会破坏它,但普通的罪犯通常不会。部署像Certificate Transparency这样的系统也将导致快速检测到此类故障,因此攻击者可以更快地销毁他的宝贵证书。


所有名称解析系统都会遇到Zooko 的三角形如果您想要全局的、有意义的名称,您将需要某种受信任的中央注册表。
Namecoin最接近打破 Zooko 的三角形,但它也有一些问题。IMO最大的一个问题是,由于商标无法强制执行,其所有者google.bit可能不会是知名公司。

您还应该阅读Zooko关于这个主题的文章。

我认为更大的关键是改进撤销 PKI 受信任的根 CA 的方式。如果有根 CA 的主撤销列表,则暴露可能会受到限制,那么只有一个受损的根 CA 才真正重要,并且可以像诺克斯堡那样受到保护。如果它确实受到了损害,那么可以应用当前的补丁修复方法。

另一种可能性是将 SSL 凭据绑定到 DNS 记录。给定的 TLD 必须能够解析什么 SSL 证书是有效的,才能说它是它的身份。然后,这将需要欺骗 DNS 和破坏根 CA,两者都没有检测到触发撤销。例如,如果根 CA 被泄露,并且我制作了一个证明我是 Google.com 的证书,那么只需检查 google.com 的 DNS 记录就可能表明该证书不匹配并且不是真实的。实际上,我们将要求第三方和第一方在两个不同的渠道上达成一致,而不是完全信任第三方。

我意识到它对于 MITM 同时具有受损根 CA 和更改 DNS 结果的能力的情况仍然无济于事,但它严重限制了受损 CA 的潜在有用攻击场景。(与目前能够让大多数用户认为 www.gaggle.com 是一项新的谷歌服务相反,他们应该使用他们的谷歌钱包登录。