公钥基础设施pki简介_公钥基础设施

公钥基础设施pki简介

不久前，我被要求为我的同事创建一个介绍公共密钥基础结构，其组件，功能，其一般工作原理的演示文稿。为了创建该演示文稿，我已经收集了有关该主题的一些资料，而这仅仅是消散把它扔出去。 该演示完全不是技术性的，并且该帖子也不是技术性的。 它只会给出一个概念性的高级图片，我认为，在开始研究细节之前，这可能是一个很好的基础知识。

我将从加密本身开始。 我们为什么需要它？ 至少有三个原因–机密性，身份验证和完整性。 机密性是最明显的。 显而易见，我们需要加密技术才能对他人隐藏信息。 身份验证确认消息是由我们可以识别的主题发送的，并且我们对此的主张是真实的。 最后，Integrity确保在传输过程中不会修改或破坏邮件。

我们可能会尝试使用对称密码术来帮助我们实现目标。 它仅使用一个共享密钥，也称为秘密。 该机密用于加密和解密数据。 让我们看看它如何帮助我们实现目标。 它会加密邮件吗？ 是。 好了，只要通信双方（没有其他人）知道秘密，就可以解决保密问题。 它提供身份验证吗？ 嗯...我会说，不。 如果只有两方进行对话，这似乎可以，但是如果有数百名，则应该有数百个秘密，这很难管理和分发。 诚信呢？

是的，它工作正常–很难修改加密的消息。 如您所料，对称密码术存在一个大问题-该问题是“共享机密”。 这两个词……它们甚至彼此不匹配。 如果某人知道某事，那就不再是秘密。 此外，要共享该秘密，必须以某种方式转移该秘密，在此过程中，有太多的秘密可以被窃取。 这意味着这种类型的密码很难解决我们的问题。 但是它仍在使用，并且可以很好地用于其目的。 它的速度非常快，可以用于大量数据的加密/解密，例如您的硬盘。 而且，它的速度比不对称加密快数百甚至数千倍，它用于混合模式（如TLS aka SSL），其中不对称加密仅用于传输对称密钥，而加密/解密则通过对称算法完成。

让我们看一下非对称密码学。 它是在40年前发明的。 Whitfield Diffie和Martin Hellman于1976年发表了第一篇论文（“ 密码学的新方向 ”）。 他们的工作受到拉尔夫·默克尔 （ Ralph Merkle ）的影响，他被认为是1974年提出公钥密码术（ http://www.merkle.com/1974/ ）的人，并向其导师兰斯·霍夫曼 （ Lance Hoffman ）提出了建议，谁拒绝了 “密码学的新方向”描述了称为“ Diffie-Hellman密钥交换”的密钥交换算法。 有趣的事实是，早在1974年，马尔科姆·J·威廉姆森（Malcolm J. Williamson）便在英国的政府通信总部发明了相同的密钥交换算法，但该信息已被分类，事实在1997年才被披露。

非对称密码学使用一对密钥-一个私钥和一个公钥。 私钥必须保密，不得与任何人共享。 公钥可以公开使用； 它不必是秘密的。 用公钥加密的信息只能用相应的私钥解密。 只要不共享私钥，就无需分发它，并且它被泄露的可能性很小。 因此，这种信息交换方式可以解决机密性问题。 身份验证和完整性如何？ 这些问题也可以解决，并利用称为数字签名的机制。 如果数字签名可以使用以下方案，则是最简单的变体-主题基于消息创建哈希，使用私钥对该哈希加密并将其附加到消息。

现在，如果收件人想要验证创建邮件的主题，他将使用主题的公钥（即身份验证）对该哈希进行加密，并将其与收件人方生成的哈希（完整性）进行比较。 实际上，哈希不是完全加密的，而是用于特殊的签名算法中，但是总体概念是相同的。 重要的是要注意，在非对称密码学中，每对密钥仅用于一个目的，例如，如果将这对密钥用于签名，则不能将其用于加密。

数字签名也是数字证书AKA公钥证书的基础。 证书和护照差不多。 它具有身份信息，类似于护照中的姓名，出生日期等。 证书的所有者必须具有与存储在证书中的公共密钥相匹配的私钥，类似的护照具有与所有者的脸相匹配的所有者照片。 最后，证书具有签名，其含义与护照上的印章相同。 签名证明该证书是由进行签名的组织签发的。 在公钥基础结构世界中，此类组织称为证书颁发机构。 如果一个系统发现证书是由“受信任的”证书颁发机构签名的，则意味着系统将信任证书中的信息。

最后一段可能并不明显，尤其是其中的“信任”部分。 在这种情况下，“信任”是什么意思？ 让我们看一个简单的例子。 Web上使用加密连接的每个站点都通过基于证书的TLS（SSL）协议来实现。 当您转到https://www.amazon.co.uk并将其证书发送回浏览器时。 该证书中包含有关网站的信息以及对签署该证书的证书颁发机构的引用。 第一个浏览器将查看证书中的名称-在我们的示例中，它必须与网站域名完全相同，即“ www.amazon.co.uk”。 然后浏览器将验证证书是否由受信任的证书颁发机构签名，如果是Amazon，则为VeriSing。 您的浏览器已经有一个证书颁发机构列表（这只是带有公共密钥的证书的列表），这些列表被称为受信任证书颁发机构，因此它可以验证证书是由其中一个颁发的。 还有其他一些验证步骤，这两个步骤是最重要的。

假设在我们的情况下，验证成功（如果不是，则浏览器将显示红色的大警告消息，如该消息）-证书中具有适当的名称，并由受信任的证书颁发机构签名。 它给我们带来什么？ 只是一件事-我们知道我们在www.amazon.co.uk上 ，该名称后面的服务器是Amazon服务器，而不是看起来像Amazon的某些狡猾网站。 当我们输入信用卡详细信息时，我们可以相对确定地将其发送到Amazon，但不会发送到黑客的数据库。 我们的希望基于这样的假设，即像VeriSign这样的证书颁发机构不会提供不可靠的证书，并且不会损害Amazon服务器。 好了，聊胜于无Ĵ

另一个例子是组织中的服务器，服务器使用证书来验证它们可以相互信任。 除了两个区别外，那里的模式与浏览器的模式非常相似：

• 相互认证。 证书通常经过验证，但不仅限于客户，还需要双方验证。 客户端必须将其证书发送到服务器。
• 证书颁发机构，托管在公司内部。

当CA在公司内部时，我们几乎可以确定证书将仅颁发给经过正确验证的主题。 它使黑客确信，即使他可以访问网络基础结构，也无法注入服务器。 仅当CA受到攻击或某些服务器的私钥受到攻击时，才有可能发起攻击。

我们已经知道，证书颁发机构是颁发证书的组织，在Internet中，VeriSing是这种组织的一个示例。 如果创建的证书仅在组织（内部网）内部使用，则可以由充当证书颁发机构的信息安全部门颁发。

当某人想要获得证书时，他必须将称为证书签名请求的证书请求发送到证书颁发机构。 该证书由受试者的身份信息，受试者的公共密钥和签名组成，由受试者的私钥创建，以确保发送请求的受试者具有适当的私钥。 在签署证书颁发机构之前，该请求会传递给注册管理机构，该机构将验证所有详细信息，确保遵循正确的流程，等等。证书颁发机构也可以充当注册机构。 毕竟，如果一切正常，那么证书颁发机构将创建由其私钥签名的新证书，并将其发送回请求证书的主题。

我已经提到了证书验证过程。 这里有一些细节。 值得一提的是他们的细节仍然很高级。 验证包括几个步骤，从广义上讲，可以描述为：

• 证书数据验证–有效日期，必填字段的存在，其值等
• 验证证书是由受信任的证书颁发机构颁发的。 如果您正在浏览Internet，则该列表已内置在浏览器中。 如果这是两个系统之间的通信，则每个系统都有一个受信任的证书颁发机构列表； 通常这只是一个带有证书的文件。
• 证书的签名有效，并由签署该证书的证书颁发机构进行。
• 验证证书未被吊销。
• 密钥验证–证明服务器可以解码通过证书的公共密钥加密的消息。

上面提到的证书吊销可能由于多种原因而发生–证书可能被盗用 ，或者在公司环境中，雇员，拥有证书的公司，离开公司或已停用证书的服务器等。为了验证证书吊销，请使用浏览器或任何其他软件，都必须使用以下一种或两种技术：

• 证书吊销列表（CRL）。 那只是一个文件，可以在http服务器上托管。 它包含已撤销证书ID的列表。 该方法简单明了，不需要大量的实现工作，但是有三个缺点–只是一个文件，这意味着它不是实时的，可以使用大量的网络流量，并且默认情况下不进行检查即使证书具有指向CRL的链接，也可以由大多数浏览器（甚至所有浏览器都可以）表示。
• 在线证书状态协议（OCSP）。 最好的解决方案是利用专用服务器，该服务器实现协议，该协议将通过其ID返回证书的吊销状态。 如果浏览器（至少FireFox> v.3.0）会在证书中找到指向该服务器的链接，它将进行调用以确认证书未被吊销。 唯一的缺点是OCSP服务器必须非常可靠并且能够始终响应请求。

在Internet证书中，证书通常包含指向CRL或OCSP的链接。 在公司网络中使用证书时，这些链接通常是所有各方都知道的，因此无需将其包含在证书中。

那么，最后，什么是公钥基础结构？ 该基础结构支持上面描述的所有内容，并且通常由以下元素组成：

• 订阅者。 证书的用户。 客户和拥有证书的客户。
• 证书。
• 证书颁发机构和注册机构。
• 证书吊销基础结构。 具有证书吊销列表的服务器或OCSP服务器。
• 证书策略和实践文件。 描述证书的格式，证书请求的格式，必须撤消证书的时间等。基本上，所有与基础结构有关的过程。
• 硬件安全模块，通常用于保护根CA的私钥。

整个基础架构都支持以下功能，我们刚刚讨论了这些功能：

• 公钥密码术。
• 证书发行。
• 证书验证。
• 证书吊销。

就是这样。 似乎不是一个大话题；）

参考： Stas博客上来自我们JCG合作伙伴 Stanislav Kobylansky的公钥基础结构 。

翻译自: https://www.javacodegeeks.com/2012/01/public-key-infrastructure.html

公钥基础设施pki简介