☰

验证 GPG 密钥签名的真实性

tag-icon • tag-icon authentication gpg keys
验证 GPG 密钥签名的真实性

我正在尝试验证我的图像的完整性httpd-2.2.17.tar.gz。
我按照以下页面中写的步骤进行操作：

但我得到了：

警告：此密钥未经可信签名认证！
gpg：没有迹象表明该签名属于所有者。

我需要做什么才能验证密钥的真实性？

答案1

验证的常用方法是联系密钥所有者并要求他/她向您提供（通过电话或亲自）其密钥指纹。如果您有充分理由相信您确实在与密钥识别的人交谈，并且该人提供的指纹与您拥有的密钥的指纹相匹配，那么您可以确信您拥有所有者的真实公钥（而不是冒名顶替者为冒充该人而创建的伪造密钥）。

一旦您对密钥的真实性进行了满意的验证，您就应该用自己的私钥签署该公钥。签署密钥后，您将不再收到这些警告，因为通过签署密钥，您已表明您相信该密钥是真实的。

答案2

文件验证有两个不同的目的：

  1. A. 防止下载过程中意外损坏

  2. 以防止中间人攻击或者甚至在私有 pgp 密钥尚未泄露的情况下网络服务器也会被泄露。

对于 A，像 SHA-1、MD5 等哈希函数已经足够令人满意。不过，使用仍被认为是加密。

对于 B，事情变得更加复杂。首先，你应该通过以下方式进行所有沟通正确认证HTTPSSSL证书：

https://httpd.apache.org/download.cgi#verify
https://httpd.apache.org/dev/verification.html#Validating
https://www.apache.org/dist/httpd/KEYS

你很幸运，apache 确实提供了对其网站的此类访问。

现在让我们评估一下哪些风险仍然存在，哪些风险已经得到缓解。简单的 MITM 攻击已不再可能。但是，要继续执行 MITM 攻击，攻击者可以：

  1. 从以下网站获取证书：证书颁发机构经过：

    • 欺骗他们相信他们拥有这个网站并向他们付钱。
    • 欺骗浏览器接受它们作为 CA（请注意一些政府被纳入浏览器作为 CA并且现有 CA 可以在不通知的情况下将其收到的信任委托给第三方，请参阅阿联酋电信事件) 如果随后发现该子 CA 做了一些坏事，并且 CA 拒绝撤销该子 CA，那么仍然会存在所有由该 CA 合法认证的网站，这会给浏览器带来压力，迫使其继续信任该 CA。
    • 通过入侵并窃取 CA 的私钥
    • 以法律强制他们作出该等证明书（传票）

  2. 窃取发送数据的服务器的私钥。

哇，这可能并不完美，但想象一下必须做这样的事情。我敢打赌你楼上的书呆子小弟弟通常不会这样做。这大大提高了攻击者的门槛。

此外，如果攻击者能够攻陷网站的服务器，他们就可以更改文件以及 md5、sha1 或其他哈希值以及它提供的 pgp 密钥，因此不必进行 MITM 攻击。最后一个选项是迄今为止首选的，因为进入服务器通常比获取证书更简单。

请注意，有时哈希值和下载的文件不是从同一位置提供的。这本身是件好事。这会使攻击者的工作复杂化。因此，假设我有一个 https 认证的网站，并且您提供一些文件供下载。我可能会将这些文件的哈希值放在我的网站上以帮助您。或者在 apache 的情况下，实际下载位于没有 https 的镜像上。

现在哈希值是验证的关键环节。请注意MD5 已被破解然后SHA1 正在路上。出于安全目的，Apache 仍然提供这些是不好的。如果所有其他方法都失败并且它们都可用，请检查它们。据我所知，尚未发现对两个文件产生相同 md5 和 sha1 值的碰撞攻击。

如果给定站点无法使用 https，该怎么办？好吧，从该服务器提供给您的文件与网站上的哈希值（如果在同一台服务器上）或 pgp 密钥或其他任何内容一样安全。

超越 https：

如果 https 不能满足您的安全需求（事实上不应该) 或 https 不适用于该网站，您该怎么办？

如果您可以从签名者那里获得合法的公钥，那么使用 pgp 密钥验证签名可能允许您验证文件。PGP 使用一种称为信任之网来验证其密钥，而不是 HTTPS 中使用的中央证书颁发机构。

当您在密钥环中包含 pgp 密钥时，不一定知道此密钥是否真的属于随附的用户 ID。为了能够验证这一点，用户在验证彼此的身份后签署彼此的密钥，例如通过亲自会面或致电该人。此外，如果您没有亲自验证过他们，但您遇到的某人验证过，或者他们遇到了验证过的人，那么您可以在您和 apache 签名密钥之间构建一个链...

因此，当一个新密钥进入您的密钥环，并且密钥环中其他已经验证的密钥均未对此密钥进行签名而您尝试使用它时，gpg 或 pgp 将发出警告，就像您浏览无法验证证书的 https 网站时浏览器会向您发出警告一样。

除了亲自签署密钥以验证其合法性之外，如果您完全信任的联系人之一签署了该密钥，或者 3 个边缘信任的联系人签署了该密钥，软件可能会自动接受该密钥为有效密钥……这取决于实现/用户。就像您的浏览器会默默接受任何 SSL 证书一样，如果它是由已知受信任的 CA 签署的（即您的浏览器信任的 CA）。

这一切在实践中意味着什么？好吧，如果你身处极客世界，这可能为你提供了合理的保护。对于世界其他地方来说，这更像是一辆没有汽油的巨型卡车。

对于普通人来说，pgp 和信任网存在一些相当大的问题：

  • 不当使用 gpg 和 web of trust 会破坏其安全性
  • 正确使用它很困难，很复杂，而且像 gnupg 这样的免费工具和它的前端都很粗糙
  • 如果你或另一方没有很好地建立在信任网络中，那么验证密钥几乎是不可能的
  • 信任链实际上意味着你必须信任其间的所有人。信任链越长，安全性就越低。如果你所有指向 Apache 签名密钥的链接都经过可能发起 MITM 攻击的同一群人，那么 pgp 只能提供虚假的安全感。
  • Web of Trust 帮助当局绘制您的社交网络地图，就像 Facebook 一样。

但是它没有 https 的一些限制，比如 pgp 无法说服一家公司收下你的钱并给你一个可以欺骗全世界的证书。另一方面，它对普通公众的可用性要差得多。它说明了简单性是安全性的关键决定因素。

总之，重要的是要认识到 HTTPS 和 PGP 并不相互排斥。没有人会阻止您尽力使用两者。应该意识到的是，任何安全链的强度都取决于最薄弱的环节。假设通过 https 下载的 pgp 密钥具有 pgp 的弱点和 https 的弱点。链中的每个环节都会将其弱点添加到结果中。

当我发现有趣的链接时，我会继续添加到这个答案中。

也可以看看：

相关内容