PKI基本原理与网络信任锚点——CA根公钥

2022-07-14 15:38

181

在商用密码应用方案的设计和研讨中，证书相关内容几乎在每个方案中都要碰到。虽然用得多，但PKI仍然是一个让不少人感到困扰的概念，公钥、证书、CA和PKI的含义是什么，他们之间的关系是什么？用公钥就必须证书吗？我们的国密CA和书上介绍的通用PKI相比有什么特点？下面，我们就来捋一捋这些基本概念，希望对大家理解PKI和用好PKI进行商用密码保障系统设计有所帮助。

一、中间人攻击与公钥真实性问题

密码技术起源于军事应用，在一战和二战的态势发展中起到关键作用，那时加密通信离不开一个关键的用来传递密钥信息的密码本，解密方必须获得加密方在加密时采用的密钥，才能顺利解密信息。直到1976年Diffie和Hellman发表《密码学的新动向》，证明了在发送端和接收端无需传输密钥也可进行保密通讯，从此开启了公钥密码学的新纪元。随后RSA公钥密码算法发表，公钥密码得到广泛应用，不仅用于保密通信，提供信息的机密性功能（如图1所示），也用于数字签名，提供信息的完整性、真实性和不可否认功能（如图2所示）。

在图1的加解密通信过程中，发送端A采用接收端B公钥对消息进行加密，接收端B收到密文后，用自己的私钥进行解密即可得到明文。在基于公钥体制的保密通信中，通过公钥无法推出私钥，公钥可以公开给任何人，不必担心密文被知道公钥的人解密。

虽然公钥不用保密，但是，如何保证公钥的真实性也是一个难题。如果发送方A事先并没有接收方B的公钥，需要从网络上获取公钥时，主动攻击者Eve就有机会发起攻击，对双方通信进行窃听。针对公钥密钥的中间人攻击过程如图3所示。

在上述过程中，攻击者Eve在网络中截获Alice和Bob间的所有通信报文，并按需要进行转发或者替换，就能用自己的公钥PKe替换Bob的公钥PKb，进而解密Alice发给Bob的消息，并伪造出Bob能正常解密的消息。

同理，在签名验证过程中，签名方A用自己的私钥对消息进行了签名，验证方B收到签名后，需要用A的公钥对签名值进行运算，以判断签名值是否真正由A产生。如果在不知情的情况下采用了攻击者Eve的公钥，那攻击者伪造的任何签名都能通过验证了。

数字签名和验证的具体过程分别如图4和图5所示。图4中，A对消息进行签名时，首先对消息进行杂凑，然后用A的私钥对杂凑值进行一次私钥运算，也就是签名运算（顺及，由于杂凑值长度短且固定，对杂凑值签名比对消息直接签名要快很多）。当B对A发来的消息和签名值进行验证时，B也会对消息进行杂凑，得到一个杂凑值，并采用A的公钥（此处划重点）对收到的签名值进行一次公钥运算，将结果同消息杂凑值相比较，如果一致，则验证通过。

从前述过程可以看出，验证运算时采用了谁的公钥，就能判断签名是不是谁签发的。如果B验证运算时采用了Eve的公钥，但B仍以为是A的公钥，那么Eve的签名就会被误以为是A的签名了。这也是PKI体系中必须确保验证公钥真实性的原因。

因此，在基于公钥体制的安全通信中，无论是消息的加解密过程，还是消息的签名验证过程，得到通信对方真实的公钥非常重要。也就是说，在公钥密码体制中，虽然公钥不需要保密，但是在使用公钥的时候，必须要保证公钥的真实性，知道公钥属于哪个主体。

二、PKI基本原理与组成

证书就是为了解决公钥真实性而提出的技术手段。

认证机构CA将主体的身份信息及其公钥放在一起，用自己的私钥进行签名后发放的文件就是证书。基于证书建立的公钥真实性信任链条如图6所示。

图6 基于证书建立的公钥真实性信任链

验证者使用自己信任的认证机构CA的公钥PKca，经过验证运算可以判断一张证书的真实性；通过一张真实的证书，可以相信证书中实体公钥的真实性。在这个信任链条中，使用认证机构的真实公钥是信任的源头。

为了解决公钥的真实性问题，引入了证书，由认证机构来进行签名。但是，认证机构为什么可信，证书如何颁发，私钥泄露后证书如何作废，证书如何查询，这些问题需要建立系列规范来解决，否则，公钥的真实性仍然无法在网络系统中得到确认。PKI就由此而生了。

PKI全称为公钥基础设施（Public-Key Infrastructure），是为了有效运用公钥而制定的一系列规范和规格的总称。它是总称，而不是一个单独的标准或规格。RSA公司的PKCS系列，某些IETF RFC标准，ITU-T的X.509，都是PKI的标准，根据具体所采用的规格，PKI有很多变种。虽然PKI涉及的内容似乎很多，但其基本组成可以总结为三个部分，如图7所示：

图7 PKI的三个基本组成要素

1：PKI用户（实体）

如上图5所示，PKI包括两类用户，一类是注册公钥的PKI用户，另一类是使用公钥的PKI用户。

注册公钥的PKI用户在PKI系统中的主要操作包括：

—向认证机构注册公钥，申请证书。公钥可以自己产生后提交给认证机构，也可以由认证机构产生。

—根据需要申请作废已注册的公钥，表示自己不再使用该公钥。

—用私钥解密接收到的密文。

—用私钥对消息进行数字签名。

使用公钥的PKI用户在PKI系统中的主要操作包括：

—查找某个实体的证书。

—对查找或获取的证书进行验证（验证内容包括：证书的真实性，证书的有效期，证书是否撤销）获取可信的公钥。

—用对方的公钥将消息加密后发送给接收者。

—用对方的公钥验证数字签名。

2：认证机构（CA）

认证机构（CA：Certification Authority）负责审核注册公钥的PKI用户提交的身份信息，并为用户颁发证书。其在PKI系统中的主要操作包括：

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

—在注册公钥时对用户身份及信息进行认证

—生成并颁发证书

—作废证书（CRL：Certificate Revocation List ）

其中，公钥注册和用户身份认证这部分工作可以由注册机构（RA）来分担。

3：证书库

证书库也叫证书目录，是树形的数据库DB。PKI用户在需要时从其中获取证书。查找证书的标准协议有LDAP和OCSP两类。LDAP（轻型目录访问协议，Lightweight Directory Access Protocol），用户通过LDAP服务可以直接查到需要的证书和CRL。OCSP（在线证书状体协议，Online Certificate Status Protocol）：用户通过OCSP服务可以查询到某个证书的状态（有效/注销/未知）。

4：两个深化问题

1）用公钥一定要用证书吗？如果不，需要什么条件？

前文讲过，证书的本质在于通过认证机构签名的方式来确保证书的真实性。在采用公钥体制的密码系统中，如果通信各方能够通过其他途径（比如当面交换，预先安全设置等）取得真实可信的公钥，则不必使用证书。也就说是，用公钥体制并非都一定要用证书。

2）用证书一定要PKI体系吗？如果不，需要什么条件？

当我们说PKI体系时，至少都包括PKI用户、认证机构和证书库三大基本要素，其实质在于通过规范可信的证书颁发、吊销及查询等功能为通信各方提供公钥的真实性服务。如果密码系统中的终端证书不需要修改或撤销（尽管这种情况不常见），密码系统可以采用证书的方式来为系统中的终端用户分发可信的公钥，但就没有必要建立完整的PKI体系来提供证书的查询、吊销等功能，这时，证书只是系统为终端用户分发公钥时采用的一种具体格式。

三、网络信任锚点：ＣＡ根公钥

现在我们知道了，PKI注册用户的公钥真实性是靠认证机构CA对证书中公钥及相关信息进行签名来保证的。PKI使用用户对证书中的签名进行验证时，一定要得到认证机构CA的真实公钥才行，否则就会出现图书所示的中间人攻击。那认证机构CA的真实公钥是以什么形式如何分发的呢？

认证机构CA的公钥，称为根公钥。由于CA处于顶端，无法通过别的实体来对自己的公钥进行签名，CA就用自己的私钥给自己的公钥及相关信息签发一张证书，称为自签名证书。用户拿到CA自签名证书依然要对证书的真实性进行验证，验证过程仍然如图５所示，只是公钥不需要从别处找，直接从自签名证书中取出公钥就可以了。

现在的问题是，这张自签名证书是怎么发给应用系统中的各个用户端的呢？

如果客户端是专用系统，可以在专用客户端程序中预置根证书，比如手机端的微信APP，在下载时就已经预置好了微信系统的根公钥证书，基于此，微信客户端可以与服务器端就可以开展基于证书的认证和安全通信。

但如果客户端是通用浏览器，互联网上的一个应用系统如何才能让自己使用的根公钥得到浏览器的信任，被浏览器用做验证其他证书真实性的基础源点？

１：互联网浏览器中根公钥的分发

目前，互联网上将根公钥放进常用浏览器的做法主要有以下三种：

１）　浏览器中预置根证书

当然，浏览器厂商并不会随便将什么证书都放预置进去。目前的事实做法是，只有通过 WebTrust 国际安全审计认证，根证书才能预装到主流的浏览器而成为一个全球可信的CA认证机构，从而实现浏览器与数字证书的无缝嵌入。WebTrust 认证是各大主流的浏览器、微软等大厂商支持的标准，是规范 CA 机构运营服务的国际标准，支持的是RSA算法。国内的很多浏览器厂商也是支持该标准。一般，在你自己的浏览器的“设置-安全-证书-受信任的根证书颁发机构”中，可以查看到该浏览器中预置的根证书。这些根CA机构也可以给下级CA机构（称为中间证书颁发机构）颁发证书，然后中间证书颁发机构给互联网上的服务站点颁发证书。服务站点的证书发给浏览器后，浏览器采用预置的中间证书或根证书对服务站点的公钥真实性进行验证，能通过验证的才判断该服务站点是一个可信任的站点，否则视为不信任。

２）　用户将根证书手动导入浏览器。

这种做法虽然看上去可行，但是，一方面让普通浏览器用户去学会导入根证书比较难，另一方面，用户怎么才能获取到一个可信的证书文件也是一个问题。所以，除了特殊场景，这种方式其实对广大互联网用户不太实用。

３）　浏览器弹窗询问后自动导入根证书。

当用户通过浏览器访问站点时，站点主动下载根证书，浏览器通过弹窗询问用户是否信任该站点根证书，用户同意后浏览器自动将其导入。虽然看上去比方法2要简便一些，但用户怎么判断该证书是否可信，也是一个难题，一不小心同意了挂马网站的根证书，就后患无穷了。

２：互联网浏览器中国密根证书的分发

既然互联网浏览器上目前预置的根证书都遵循WebTrust 认证系列标准，支持的是RSA系列算法，那我们的SM2系列算法的根证书在互联网中怎么用呢？

在互联网浏览器应用中要使用SM2证书，无外乎两种路线。一种是把我们的SM2标准纳入WebTrust 认证标准中，另外一种是我们自己搞一个自己的认证标准，预置我们的SM2国密根证书。

近几年，随着网络安全意识和信息产业自主化的不断深化，密SM2证书不仅在专用系统中得到广泛应用，在互联网中的应用也逐渐受到重视。国内浏览器也在筹划根证书计划。比如，360公司在2020年8月，联合统信软件、多家国内CA、网关厂商、Ukey厂商共同发布了“信创国密根证书计划”，共建共享信创SM2国密根证书库，为基于国密SM2证书构建互联网上的信任锚点打下了基石。相信在不久的将来，互联网浏览器中预置国密SM2系列根证书将成为常态。基于我国自主SM2算法的PKI体系，将成为我们从现实走向网络的信任锚点。

来源：密小白

上一篇物联网发展推动关键行业的增长和领导机会

下一篇关于发布《商用密码产品认证目录（第二批）》的公告

昵称：

内容：

验证码：

提交评论

评论一下