密码学《图解密码技术》记录学习第十章

公钥证书（Public-Key Certificate，PKC）其实和驾照很相似，里面记有姓名、组织、邮箱地址等个人信息,以及属于此人的公钥,并由认证机构(Certification Authority、 CertifyingAuthority,CA)施加数字签名。只要看到公钥证书，我们就可以知道认证机构认定该公钥的确属于此人。公钥证书也简称为证书(certificate)。

可能很多人都没听说过认证机构,认证机构就是能够认定“公钥确实属于此人”并能够生成数字签名的个人或者组织。认证机构中有国际性组织和政府所设立的组织,也有通过提供认证服务来盈利的一般企业,此外个人也可以成立认证机构。有名的认证机构包括VeriSign。等,稍后我们将使用赛门铁克的试用版Class1 Digital ID服务来生成Bob的证书。关于认证机构我们将在后文中详细介绍(10.4.3 节)。

10.2.2 证书的应用场景

下面我们来通过证书的代表性应用场景来理解证书的作用。图10-1展示了Alice向Bob发送密文的场景,在生成密文时所使用的Bob的公钥是通过认证机构获取的。

认证机构必须是可信的，对于“可信的第三方”，本书中会使用 Trent 这个名字，这个词是从 trust（信任）一词演变而来的。下面让我们对照着图10-1来看一看这些步骤具体都做了些什么。

（1) Bob 生成密钥对

要使用公钥密码进行通信，首先需要生成密钥对。Bob 生成了一对公钥和私钥，并将私钥自行妥善保管。

在这里，密钥对是由 Bob 自己生成的，也可以由认证机构代为生成（10.4.3 节）。

(2) Bob在认证机构Trent注册自己的公钥

在第 5 章中,Bob直接将自己的公钥发给了Alice (5.4.3 节),但是在这里 Bob 则将公钥发送给了认证机构 Trent，这是因为 Bob 需要请认证机构 Trent 对他的公钥加上数字签名（也就是生成证书）。

Trent 收到 Bob 的公钥后,会确认所收到的公钥是否为 Bob 本人所有(参见专栏“身份确认和认证业务准则”）。

(3)认证机构Trent用自己的私钥对Bob的公钥施加数字签名并生成证书

Trent对 Bob 的公钥加上数字签名。为了生成数字签名,需要 Trent自身的私钥,因此Trent需要事先生成好密钥对。

(4) Alice得到带有认证机构Trent的数字签名的Bob的公钥(证书)

现在Alice需要向 Bob 发送密文,因此她从Trent处获取证书。证书中包含了Bob的公钥,并带有Trent对该公钥签署的数字签名。

(5) Alice使用认证机构Trent的公钥验证数字签名,确认Bob的公钥的合法性

Alice使用认证机构Trent的公钥对证书中的数字签名进行验证。如果验证成功,就相当于确认了证书中所包含的公钥的确是属于Bob的。到这里, Alice就得到了合法的Bob的公钥。

(6) Alice用Bob的公钥加密消息并发送给Bob

Alice 用 Bob 的公钥加密要发送的消息，并将消息发送给 Bob。尽管这里写的是“用公钥加密”,但使用第6章中介绍的混合密码系统来加密也是可以的。

(7) Bob用自己的私钥解密密文得到Alice的消息

Bob 收到 Alice发送的密文,然后用自己的私钥解密,这样就能够看到 Alice的消息了。上面就是利用认证机构Trent进行公钥密码通信的流程。其中(1)、(2)、(3)几个步骤仅在注册新公钥时才会进行，并不是每次通信都需要。此外，步骤（4）仅在 Alice 第一次用公钥密码向Bob发送消息时才需要进行,只要Alice将Bob的公钥保存在电脑中,在以后的通信中就可以直接使用了。

看了上面的介绍,细心的读者可能已经在脑海中设想出了各种各样的攻击方法。关于攻击方法，我们将稍后探讨。

--------------------------------------------------------------------------------------------------------------------------------- 小测验 1 认证机构忙得不可开交？（答案见 10.8 节）

看了关于认证机构的介绍，Alice 想：

我有点明白认证机构到底是什么了。不过，每次收到带有数字签名的邮件都要让认证机构Trent 来验证数字签名，Trent 是不是会忙得不可开交呢？

Alice的想法是错误的,这是为什么呢?

---------------------------------------------------------------------------------------------------------------------------------

10.3 实际生成一张证书

下面我们来使用赛门铁克的Digital ID免费试用服务来实际生成一张Bob的证书吧。

10.3.1 赛门铁克的Digital ID免费试用服务

赛门铁克提供了面向个人的证书(称为Digital ID )服务,可供用户免费试用25天。通过Web 浏览器就可以马上颁发证书,身份确认是通过确认邮件来进行的(相当于VeriSign Class 1 )。

10.3.2 生成证书

在赛门铁克的网站上输入邮箱地址，就可以生成证书（图 10-2)。在这里输入的邮箱地址必须是有效的,因为生成证书的后续步骤需要根据赛门铁克所发送的邮件来完成。这种方式其实就相当于通过“接收电子邮件”来对本人身份进行确认。

接下来，根据赛门铁克发送的邮件中的指示，在一个自助页面中生成密钥对(Generate Key& Install ),然后将证书保存下来( Install Certificate ),这样我们便得到了一个名叫SelfService.action.p7s 的证书文件。

10.3.3 显示证书

下面让我们用密码软件GnuPG中附带的gpgsm命令来显示一下上一节中生成的Bob的证书的内容（图 10-3）。

10.3.4 证书标准规范

证书是由认证机构颁发的，使用者需要对证书进行验证,因此如果证书的格式千奇百怪那就不方便了。于是,人们制定了证书的标准规范,其中使用最广泛的是由ITU (InternationalTelecommunication Union,国际电信联盟)和ISO ( International Organization for Standardization,国际标准化组织)制定的X.509-规范(RFC3280)。很多应用程序都支持X.509并将其作为证书生成和交换的标准规范。

X.509 证书所包含的构成要素与刚刚生成的 Bob 的证书之间的大致对应关系如表 10-1 所示。

10.4 公钥基础设施(PKI)

仅制定证书的规范还不足以支持公钥的实际运用，我们还需要很多其他的规范，例如证书应该由谁来颁发,如何颁发,私钥泄露时应该如何作废证书,计算机之间的数据交换应采用怎样的格式等。这一节我们将介绍能够使公钥的运用更加有效的公钥基础设施。

10.4.1 什么是公钥基础设施

公钥基础设施（Public-Key Infrastructure）是为了能够更有效地运用公钥而制定的一系列规范和规格的总称。公钥基础设施一般根据其英语缩写而简称为PKI。

PKI 只是一个总称，而并非指某一个单独的规范或规格。例如，RSA公司所制定的PKCS （ Public-Key Cryptography Standards，公钥密码标准）系列规范也是 PKI 的一种，而互联网规格RFC ( Request for Comments)中也有很多与PKI相关的文档。此外,上一节中我们提到的X.509这样的规范也是 PKI的一种。在开发PKI程序时所使用的由各个公司编写的API(Application Programming Interface,应用程序编程接口)和规格设计书也可以算是PKI的相关规格。

因此，根据具体所采用的规格，PKI 也会有很多变种，这也是很多人难以整体理解 PKI 的原因之一。

为了帮助大家整体理解 PKI，我们来简单总结一下 PKI 的基本组成要素(用户、认证机构、仓库）以及认证机构所负责的工作。

关于PKI的详细内容，可以参考独立行政法人信息处理推进机构(IPA)关于PKI相关技术的说明页面( http://www.ipa.go.jp/security/pki/ )。

10.4.2 PKI的组成要素

PKI的组成要素主要有以下3个。

⚪用户——使用 PKI 的人

⚪认证机构——颁发证书的人

⚪仓库——保存证书的数据库

不过,由于PKI中用户和认证机构不仅限于“人”(也有可能是计算机),因此我们可以给他们起一个特殊的名字，叫作实体(entitiy)。实体就是进行证书和密钥相关处理的行为主体。当然，本书中的讲解也不会特别拘泥于这个术语(图 10-4)。

用户

用户就是像Alice、 Bob这样使用PKI的人。用户包括两种:一种是希望使用PKI注册自己的公钥的人,另一种是希望使用已注册的公钥的人。我们来具体看一下这两种用户所要进行的操作。

【注册公钥的用户所进行的操作】

⚪生成密钥对(也可以由认证机构生成)

⚪在认证机构注册公钥

⚪向认证机构申请证书

⚪根据需要申请作废已注册的公钥

⚪解密接收到的密文

⚪对消息进行数字签名

【使用已注册公钥的用户所进行的操作】

⚪将消息加密后发送给接收者

⚪验证数字签名

认证机构（CA）

认证机构(Certification Authority, CA)是对证书进行管理的人。在本章开头的例子(图10-1）中，我们给它起了一个名字叫作 Trent。认证机构具体所进行的操作如下。

⚪生成密钥对（也可以由用户生成）

⚪在注册公钥时对本人身份进行认证

⚪生成并颁发证书

⚪作废证书

认证机构的工作中，公钥注册和本人身份认证这一部分可以由注册机构(RegistrationAuthority,RA)来分担。这样一来，认证机构就可以将精力集中到颁发证书上，从而减轻了认证机构的负担。不过，引入注册机构也有弊端，比如说认证机构需要对注册机构本身进行认证，而且随着组成要素的增加,沟通过程也会变得复杂,容易遭受攻击的点也会增加。

仓库

仓库(repository )是一个保存证书的数据库, PKI用户在需要的时候可以从中获取证书,它的作用有点像打电话时用的电话本。在本章开头的例子中,尽管没特别提到,但Alice获取Bob的证书时,就可以使用仓库。仓库也叫作证书目录。

10.4.3 认证机构的工作

下面我们来详细看一下认证机构所负责的工作。

生成密钥对

生成密钥对有两种方式：一种是由 PKI 用户自行生成，一种是由认证机构来生成。

在认证机构生成用户密钥对的情况下,认证机构需要将私钥发送给用户,具体的方法在RFC7292 ( PKCS #12: Personal Information Exchange Syntax V1.1 )中进行了规定。

注册证书

在用户自行生成密钥对的情况下,用户会请求认证机构来生成证书。申请证书时所使用的规范是由RFC2986 ( PKCS #10: Certification Request Syntax Specification Version 1.7 )等定义的。

认证机构根据其认证业务准则（Certification Practice Statement,CPS)对用户的身份进行认证,并生成证书。在生成证书时,需要使用认证机构的私钥来进行数字签名。生成的证书格式是由 X.509定义的。

作废证书与 CRL

当用户的私钥丢失、被盗时，认证机构需要对证书进行作废（revoke）。此外，即便私钥安然无恙,有时候也需要作废证书,例如用户从公司离职导致其失去私钥的使用权限,或者是名称变更导致和证书中记载的内容不一致等情况。

纸质证书只要撕毁就可以作废了，但这里的证书是数字信息，即便从仓库中删除也无法作废,因为用户会保存证书的副本,但认证机构又不能入侵用户的电脑将副本删除。

要作废证书，认证机构需要制作一张证书作废清单（Certificate Revocation List），简称为 CRL。

CRL是认证机构宣布作废的证书一览表,具体来说,是一张已作废的证书序列号的清单,并由认证机构加上数字签名。证书序列号是认证机构在颁发证书时所赋予的编号,在证书中都会记载。

PKI用户需要从认证机构获取最新的CRL,并查询自己要用于验证签名(或者是用于加密)的公钥证书是否已经作废。这个步骤是非常重要的。

假设我们手上有 Bob的证书，该证书有合法的认证机构签名，而且也在有效期内，但仅凭这些还不能说明该证书一定是有效的,还需要查询认证机构最新的CRL，并确认该证书是否有效。一般来说,这个检查不是由用户自身来完成的,而是应该由处理该证书的软件来完成,但有很多软件并没有及时更新CRL。

对于CRL的攻击方法我们将稍后探讨。

10.4.4 证书的层级结构

到这里为止,认证机构已经对用户的公钥进行了数字签名,并生成了证书。接下来用户需要使用认证机构的公钥,对证书上的数字签名进行验证。

那么,对于用来验证数字签名的认证机构的公钥,怎样才能判断它是否合法呢?对于认证机构的公钥,可以由其他的认证机构施加数字签名,从而对认证机构的公钥进行验证,即生成一张认证机构的公钥证书。

一个认证机构来验证另一个认证机构的公钥，这样的关系可以迭代好几层。这样一种认证机构之间的层级关系,我们可以用某公司的内部PKI来类比。例如,某公司的组织结构如下,每一层组织都设有认证机构。

东京总公司(东京总公司认证机构)

北海道分公司(北海道分公司认证机构)

札幌办事处(札幌办事处认证机构)

假设Bob是札幌办事处的一名员工,札幌办事处员工的公钥都是由札幌办事处认证机构颁发的(因为这样更容易认证本人身份)。

对于札幌办事处认证机构的公钥,则由北海道分公司认证机构颁发证书,而对于北海道分公司认证机构的公钥,则由东京总公司认证机构颁发证书,以此类推……。不过这个链条不能无限延伸,总要有一个终点,如果这个终点就是东京总公司认证机构(即不存在更高一层的认证机构),的话,该认证机构一般就称为根CA(Root CA),而对于东京总公司认证机构,则由东京总公司认证机构自己来颁发证书0,这种对自己的公钥进行数字签名的行为称为自签名(self-signature)。

东京总公司(东京总公司认证机构=根 CA)

北海道分公司(北海道分公司认证机构)

札幌办事处(札幌办事处认证机构)

札幌办事处员工 Bob

现在我们假设 Alice要验证札幌办事处员工 Bob 的数字签名，那么 Alice 需要执行如下步骤。

首先从最高级的认证机构(根CA)开始。如果连根CA 的公钥都不合法的话，那么就无法验证证书了,因此我们假设Alice所持有的东京总公司认证机构的公钥是合法的。

接下来, Alice取得北海道分公司认证机构的公钥证书,这个证书上面带有东京总公司认证机构的数字签名。Alice用合法的东京总公司认证机构的公钥对数字签名进行验证。如果验证成功,则说明Alice获得了合法的北海道分公司认证机构的公钥。

再接下来，Alice取得札幌办事处认证机构的公钥证书，这个证书上面带有北海道分公司认证机构的数字签名。Alice用合法的北海道分公司认证机构的公钥对数字签名进行验证。如果验证成功,则说明Alice获得了合法的札幌办事处认证机构的公钥。

最后，Alice 取得札幌办事处员工 Bob 的公钥证书，这个证书上面带有札幌办事处认证机构的数字签名。Alice用合法的札幌办事处认证机构的公钥对数字签名进行验证。如果验证成功,则说明 Alice 获得了合法的札幌办事处员工 Bob 的公钥。

上面就是Alice对Bob的数字签名进行验证的整个过程。当然,如此复杂的验证链条不会是由人来操作的，而是由电子邮件或者浏览器等软件自动完成的（图 10-5）。

10.4.5 各种各样的PKI

公钥基础设施(PKI)这个名字总会引起一些误解,比如说“面向公众的权威认证机构只有一个”,或者“全世界的公钥最终都是由一个根CA来认证的”,其实这些都是不正确的。

认证机构只要对公钥进行数字签名就可以了，因此任何人都可以成为认证机构，实际上世界上已经有无数个认证机构了。

国家、地方政府、医院、图书馆等公共组织和团体可以成立认证机构来实现PKI,公司也可以出于业务需要在内部实现PKI,甚至你和你的朋友也可以以实验为目的来构建PKI。

日本所规定的PKI称为政府认证基础设施(GPKI)。在GPKI中,规定了认证机构的层级、业务规则、公钥注册及证书颁发等业务的具体办法。详细内容可参见http://www.gpki.go.jp/。

在公司内部使用的情况下，认证机构的层级可以像上一节中一样和公司的组织层级一一对应,也可以不一一对应。例如,如果公司在东京、大阪、北海道和九州都成立了分公司,也可以采取各个分公司之间相互认证的结构。在认证机构的运营方面，可以购买用于构建 PKI的软件产品由自己公司运营,也可以使用外部认证服务。具体要采取怎样的方式,取决于目的和规模，并没有一定之规。

10.5 对证书的攻击

本节中我们将思考针对证书的攻击方法及其对策。由于证书实际上使用的就是数字签名技术,因此针对数字签名的所有攻击方法对证书都有效。下面我们主要来看一看针对PKI的攻击。

10.5.1 在公钥注册之前进行攻击

证书是认证机构对公钥及其持有者的信息加上数字签名的产物，由于加上数字签名之后会非常难以攻击，因此我们可以考虑对施加数字签名之前的公钥进行攻击。

假设 Bob生成了密钥对，并准备在认证机构注册自己的公钥。在认证机构进行数字签名之前，主动攻击者 Mallory将公钥替换成了自己的。这样一来，认证机构就会对“Bob的个人信息”和“Mallory的公钥”这个组合进行数字签名。

要防止这种攻击，我们可以采用下面的做法。例如 Bob可以在将公钥发送给认证机构进行注册时,使用认证机构的公钥对Bob的公钥进行加密。此外,认证机构在确认Bob的身份时,也可以将公钥的指纹一并发送给 Bob 请他进行确认。

10.5.2 注册相似人名进行攻击

证书是认证机构对公钥及其持有者的信息加上数字签名的产物，对于一些相似的身份信息，计算机可以进行区别，但人类往往很容易认错，而这就可以被用来进行攻击。

例如,假设Bob的用户信息中名字的部分是:

Name = Bob （首字母大写)

而 Mallory 用另一个类似的用户信息：

Name = BOB (所有字母大写)

注册了另一个不同的公钥。这个公钥的名字叫作BOB,但实际上却是Mallory的公钥。

随后，Mallory 伪装成 Bob，将

Name = BOB

的公钥发送给Alice。 Alice看到证书中的用户信息,很可能就会将BOB误认为是自己要发送消息的对象 Bob。

要防止这种攻击，认证机构必须确认证书中所包含的信息是否真的是其持有者的个人信息，当本人身份确认失败时则不向其颁发证书。认证机构的认证业务规则（参见10.2.2节的专栏）中就规定了这样的方针。

10.5.3 窃取认证机构的私钥进行攻击

主动攻击者 Mallory 想出了一个大胆的攻击方法，那就是窃取认证机构的私钥。如果得到了认证机构的私钥，那么任何人就都可以以该认证机构的身份颁发证书了。

要窃取认证机构的私钥，需要入侵认证机构的计算机，或者收买有权访问认证机构私钥的人。认证机构是否妥善保卫自己的私钥，是与该认证机构所颁发的证书的可信度密切相关的。认证机构之所以称为认证机构，是因为它的数字签名是可信的，因此认证机构必须花费大量的精力来防止自己的私钥被窃取。一般来说，当发现主动攻击者Mallory利用认证机构的私钥签发的证书时，就可以断定认证机构的私钥被窃取了。由于认证机构记录了自己签发的证书的序列号,因此能够判断某个证书是不是该认证机构自己签发的。

如果认证机构的私钥被窃取(泄露),认证机构就需要将私钥泄露一事通过CRL通知用户。

10.5.4 攻击者伪装成认证机构进行攻击

主动攻击者 Mallory 又想出了一个更加大胆的方法，那就是 Mallory 自己伪装成认证机构的攻击。

运营认证机构既不需要登记，也不需要盖楼房，只要有运营认证机构的软件，任何人都可以成为认证机构。当然，你的认证机构是否被其他认证机构所认可就是另外一码事了。

现在Mallory成立了一个认证机构,然后对自己的公钥颁发了一张证书,并称“这是Bob的公钥”。之后,他将这个证书发送给Alice。

Alice收到证书后使用认证机构Mallory的公钥进行验证,验证当然会成功,因为这个证书就是认证机构Mallory颁发的合法的证书。Alice验证证书成功,于是她相信了这个公钥,并将准备发送给Bob的消息用这个公钥进行了加密。随后Mallory截获密文,就可以将内容解密了,因为Mallory持有用于解密的密钥(私钥)。

从上面的例子可以看出,如果认证机构本身不可信,即便证书合法,其中的公钥也不能使用。虽然这一点是理所当然的,但是要防范这种攻击却需要Alice自己多加留心才行,她必须要注意自己所得到的证书是哪个认证机构颁发的，这个认证机构是否可信。

10.5.5钻CRL的空子进行攻击(1)

从公钥失效到Alice收到证书作废清单(CRL)需要经过一段时间,主动攻击者Mallory可以利用CRL发布的时间差来发动攻击。某天深夜，Mallory 入侵了 Bob 的电脑，窃取了 Bob 的私钥。接下来，Mallory 伪装成 Bob给Alice写了一封邮件,邮件中要求Alice把钱转账到Mallory的账户。当然, Mallory使用了刚刚窃取到的私钥对邮件进行了数字签名。

第二天早上, Bob发现自己的电脑被入侵,而且私钥被盗，于是Bob马上联系认证机构Trent,通知自己的公钥已经失效。

接到这个消息, Trent将Bob的密钥失效一事制作成CRL并发布出来。

另一方面, Alice收到了Bob(其实是Mallory伪装的)发来的邮件,于是准备向指定账号转账。不过在此之前, Alice需要验证数字签名。她用Bob的公钥进行验证,结果成功了,而且Bob 的公钥带有认证机构Trent颁发的证书。于是 Alice相信了邮件中的内容,进行了转账操作。过了一段时间, Alice收到了认证机构Trent发布的最新版CRL,发现Bob的证书其实已经失效了，她深受打击。

要防御上述这样利用 CRL 发布的时间差所发动的攻击是非常困难的。在上面的故事中，Bob察觉到自己的私钥被盗了,但实际上,大多数情况下都是在发现自己没有签名的文件上附带了签名时，才发现私钥被盗的。即便Bob 用最短的时间通知 Trent,发布 CRL 也是需要时间的，在这段时间内，Mallory 完全可以为所欲为。况且，等 Alice 真的收到 CRL 又要经过一段时间。因此，对于这种攻击的对策是：

⚪ 当公钥失效时尽快通知认证机构（Bob）

⚪ 尽快发布 CRL（Trent）

⚪ 及时更新 CRL（Alice）

这些对策和信用卡的运营方法很相似。此外，我们还需要做到：在使用公钥前，再次确认公钥是否已经失效（Alice）

10.5.6 钻 CRL 的空子进行攻击 (2)

虽然数字签名能够防止否认,但通过钻CRL的空子,就有可能实现否认,这种方法实际上是“钻CRL的空子进行攻击(1)”的另一种用法。在下面的故事中,Bob是一个坏人,他设想了一个从Alice手上骗钱的计划。首先，Bob 用假名字开设了一个账户 X-5897，然后他写了一封邮件给 Alice，请她向这个账号转账。邮件使用Bob(自己)的私钥进行数字签名。

Bob 将这封邮件发送给 Alice之后，又向认证机构 Trent 发送了一封邮件告知自己的公钥已经失效。

在从Trent处收到新的CRL之前, Alice已经验证了签名并执行了转账。

Bob赶快从自己用假名字开设的账户X-5897中把钱取出来。

收到Trent的CRL之后, Alice大为震惊,于是她尝试联系Bob

Bob装作不知道这件事，给Alice回信。

Bob 实际上就是在否认这件事。

要完全防止这种攻击是很困难的。尽管我们可以将签名的时间（timestamp）和发送公钥作废请求的时间进行对比,但是私钥泄露之后很久才发现也是很正常的,因此这种对比也没有什么意义。

在这个故事中，通过公钥、证书等技术无法识别出 Bob 的犯罪行为，必须要依靠刑事侦查才行。

为了快速确认证书是否已经失效，人们设计了一种名为OCSP的协议，详情请参见RFC2560(X.509 Internet Public Key Infrastructure Online Certificate Status Protocol )。

10.5.7 Superfish

2015年，PC厂商联想（Lenovo）公司所销售的计算机发生了一起严重的事件，联想公司在其计算机中预装的广告软件 Superfish可能会带来安全问题。

Superfish是一款广告软件,它能够通过监听和收集用户通信中的个人信息来有针对性地展示广告。为了实现这一功能，Superfish 会在系统中安装根证书，并劫持浏览器与服务器之间的通信,将网站的证书替换成自己的证书。也就是说,这是一种典型的通过中间人攻击的方式来监听通信内容的行为。

为了能够针对任意网站动态生成证书，Superfish 内置了用于生成数字签名的私钥。也就是说,用户的计算机变成了一个不可信的认证机构Trent,而且生成签名所需的口令只是一个简单的单词。这样一来,恶意软件就可以利用Superfish随意生成伪造的网站证书,使得钓鱼网站在用户的浏览器上看起来就像真正的网站一样，如果用户因此访问了假冒的银行网站,后果一定不堪设想。

一般来说，我们都会注意新安装的软件是否可信,平时也会注意预防计算机病毒，但却基本上不会去怀疑我们所购买的计算机上预装的软件。对于Superfish这样的事件,消费者的应对措施也只能是购买可信的厂商所销售的硬件产品罢了。关于“信任”的话题,我们将会在第15章深入探讨。

10.6 关于证书的 Q&A

为了加深对证书的理解，下面我们来整理一些 Q&A。

10.6.1为什么需要证书

疑问

我不理解证书的必要性。通过认证机构的证书来获取公钥,和直接获取公钥到底有什么不一样呢？

回答

在通过不可信的途径（例如邮件）获取公钥时，可能会遭到 5.7.4 节中所提到的中间人攻击。Alice本来想要获取的是Bob 的公钥，但实际上得到的却可能是主动攻击者Mallory的公钥。

如果从认证机构获取公钥，就可以降低遭到中间人攻击的风险。因为带有证书的公钥是经过认证机构进行数字签名的，事实上无法被篡改。但现在的问题是，我们又该如何获取认证机构本身的公钥呢？

如果将上面这个问题替换成“我自己现在所持有的公钥中,哪一个最可信”这样一个问题，也许更容易理解。例如,如果Alice和Bob本人见面, Bob直接将自己的公钥交给Alice的话,就不需要认证机构了，这是因为Alice可以确信自己所得到的就是Bob 的公钥。

然而,正如本章开头的故事中所描述的那样,在Alice和Bob无法直接见面的情况下,或者是即便直接见面Alice也无法确信对方就是Bob本人的情况下,认证机构和证书的存在就有意义了。因为 Alice 得到带有认证机构数字签名的 Bob 的公钥,就表示 Alice 将对 Bob 本人身份的确认这项工作委托给了认证机构。认证机构则将认可该公钥确实属于Bob这一事实通过证书(即对公钥进行的数字签名)传达给Alice。

上述内容的要点总结如下。

⚪如果能够取得可信的公钥，则不需要认证机构

⚪当持有可信的认证机构公钥，并相信认证机构所进行的身份确认的情况下，则可以信任该认证机构颁发的证书以及通过该途径取得的公钥

10.6.2 通过自己的方法进行认证是不是更安全

疑问

无论是证书的格式还是 PKI，使用公开的技术总觉得不放心。我觉得使用公开的技术就等于为攻击者提供了用于攻击的信息,相比之下,还是使用公司自己开发的保密的认证方法更安全吧？

回答

不，这是错误的。自己开发保密的认证方法是犯了典型的隐蔽式安全(security by obscurity)错误。本书中已经多次强调,私下开发安全相关的技术是非常危险的。仅靠一家公司的力量无法开发出足以抵御攻击的安全技术,这一点不仅限于密码技术,对于数字签名和证书等认证技术也同样适用。

使用公开的技术的确会为攻击者提供用于攻击的信息，但与此同时，全世界的安全专家也在为这些公开的技术寻找漏洞。

下面我们来更深入地思考一下关于使用公开的技术的问题。

请注意，使用公开的技术和把自己公司采用的技术公开是两码事。

采用已经公开的，并积累了大量成果的技术是正确的决定，然而并不需要将自己公司所采用的技术的细节公开出来。我们拿员工访问公司内部网络的方法为例。验证员工的合法身份可

以采用公开的,积累了大量成果的技术,但是我们并不需要将这些细节公开出来,而是只要告知相关的员工就可以了。这样我们就可以将风险控制到最小,万一有人恶意将技术的详细信息公开出来,也不会产生严重的问题,因为我们所使用的技术原本就是公开的。

反过来说，如果我们使用的技术是依靠对细节的保密来保证安全的，那么一旦有人恶意泄露技术细节,就会造成严重的问题。

靠隐蔽来保证安全是错误的——这个观点在本书中已经反复强调了多次，因为尽管这个观点和人们的直觉相悖，但却是非常重要的。

10.6.3 为什么要相信认证机构

疑问

我已经明白认证机构的作用了，但是我总觉得这件事说来说去还是一个死循环。为了相信公钥，就必须相信为该公钥颁发证书的认证机构，但是我为什么要相信这个认证机构呢？就算有另一个认证机构为它做证明，那我为什么又要相信那个“另一个认证机构”呢？

回答

这个问题很好。

这个问题关系到“信任是如何产生的”这一本质性问题。为什么我们要把钱存进银行呢？为什么我们钱包里的钞票能够在商店里使用呢?为什么我们会相信饭店里提供的食物是安全的呢?我们在每天的生活中还会遇到很多像这样“在某种程度上可信”的例子,那么这种“可信”的感觉到底是怎样产生的呢？

一言以蔽之，就是“感觉貌似是可信的”“从经验上看是可信的”这一类的理由。我们之所以信任某家银行,是因为电视和报纸等众多的媒体上都能看到它的名字和评价,才会让人产生可信的感觉。

认证机构是否让人感到可信，和银行也是一样的。如果各种媒体都报道过某家认证机构，而且说这家机构的业务非常正规,那么这家认证机构就会让人觉得可信。对于公司内部的认证机构，只要公司发出过官方通知，而且你的上司也跟你说“这个就是我们公司的认证机构”，那么它对你就是可信的。如果是一个陌生人通过邮件发给你一个网址,就算上面写着“这个是某公司的认证机构”,我们也不能相信。

在能够处理证书的电子邮件软件和Web浏览器中,已经包含了一些有名的认证机构的证书。我们平常在使用时也不会再自行检查那些软件中已经内置的证书,这是因为我们信任这个软件的作者,我们会认为有名的软件应该不会嵌入一些恶意认证机构的证书(就算没有真的这样认为,从结果上也表明了这样一种态度)。通过上面的思考我们可以看出，即便认证机构是具有层级结构的，但实际上支撑“信任”关系的也并不只是单纯的层级而已。不管证书的链条是否具有层级结构，我们之所以信任某个认证机构，是因为那是我们基于多个可信的情报源所做出的判断。

10.7本章小结

本章中我们从使用证书的场景开始，学习了证书标准规范 X.509、颁发证书的认证机构，以及公钥基础设施(PKI)的相关知识。同时我们还介绍了对PKI的攻击方法和对策。

从结果来看,尽管我们已经进入了数字社会,但依然没有建立起一种完美的信任关系。数字签名技术本身是可信的,而且只要使用证书就能够获得可信的公钥,然而我们也不能忘记,在信任的背后还隐藏着各种各样的前提条件，比如进行签名的认证机构本身是否可信，认证机构对本人身份的认证又是否正确,证书是否已经被登记在CRL上进行了作废……

即使是计算机也不可能无中生有。无论是数字签名、证书,还是认证机构的层级结构,都不可能在完全不可信的状态下创造出信任关系。只有以某种已经存在的信任关系为种子,比如电子邮件能够送达、电话能够打通、住址是真实的、有本人的身份证明、身份证明上的照片和本人的相貌一致等,才能够引申出其他的信任关系。

本章中，我们将视线转向了“社会”这一巨大的实体。在下一章中，我们将转换视角，看一看我们用来保卫自己信息安全时所使用的一种短比特序列——密钥。

------------------------------------------

感谢您阅读本文！如果您对文章内容有任何疑问或者想要提出任何问题，欢迎在评论区留言。我会尽力回答您的疑问，并与您交流。期待与您互动。

御风楼@主人

关注

32
点赞
踩
29

收藏

觉得还不错? 一键收藏
0
评论
密码学《图解密码技术》记录学习第十章

第 5 章中我们学习了公钥密码，第 9 章中我们学习了数字签名。无论是公钥密码还是数字签名,其中公钥都扮演了重要的角色。然而,如果不能判断自己手上的公钥是否合法,就有可能遭到中间人攻击(5.7.4 节)。本章要介绍的证书,就是用来对公钥合法性提供证明的技术。在本章中，我们首先来介绍一下什么是证书，以及证书的应用场景，然后我们会介绍 X.509证书规范,以及利用证书来进行公钥传输的公钥基础设施(PKI)和认证机构。
复制链接

扫一扫