数字证书及其认证过程

数字证书及其认证过程

   众所周知，公钥密码学通过使用公钥和私钥这一密钥对，使数字签名和加密通讯等密钥服务变得容易起来。公钥技术之所以能得到广泛的应用，原因就在于对那些使 用密钥对中的公钥来获得安全服务的实体，他们能很方便地取得公钥，即密钥分发与管理比起对称密钥的分发与管理变得简单了。所以有人称，非对称密码算法是计 算机安全通讯的一次技术革命。
    当然，公钥的分发也需要数据完整性保护措施，即需要数据完整性服务来保障公钥不被篡改，并保证公钥一定要有与其声明持有者的身份相对应绑定的机制，最终目 的是能提供一种简单安全识别的机制，其一可以使公钥及其相关信息的完整性得到保障；其二可以使公钥及其相关信息以一种可信的方式与其声明所有者绑定在一 起。
    这就是证书机制，证书在电子商务中是一种权威性的文档，证书的颁发者必须具有可信赖性，它是由权威性、可信任性和公正性的第三方机构所颁发的。证书是一种安全机制，它能保证实现和完成PKI的身份认证、完整性、保密性及不可否认性的安全服务。
    证书是一种新的安全机制，一般初期使用者会感到困惑。如一个网上购物者或网上银行客户，或是一个某银行支付网关的管理员，他（她）们经常会想：为什么浏览器/服务器中装入数字证书就会在互联网上变得安全了呢？它们在实际认证中是如何操作的？它是如何保证安全的呢？针对这些常见的问题，本文通过讨论X.509V3版公钥证书的结构和语义、内容和用途以及对证书的哪些项要进行检查和如何进行检查的全部过程等，来说明证书认证的安全性。相信广大读者在了解了证书认证的“游戏规则”以后，对证书机制所能完成的身份识别和鉴别认证的安全服务会有所理解。证书确实是网上交易安全的守护神。
一、有关概念
   1.关于CA
   CA(Certification Authority)在PKI中称“认证机构”，它为电子商务环境中各个实体颁发电子证书，即对实体的身份信息和相应公钥数据进行数字签名，用以捆绑该实体的公钥和身份，以证明各实体在网上身份的真实性；并负责在交易中检验和管理证书。CA是认证电子商务和网上银行交易的权威性、可信赖性及公正性的第三方机构，是电子商务的重要基础设施，是电子商务的安全保证。
   2.关于数字证书
    数字证书也叫电子证书,或简称证书，在很多场合下,数字证书、电子证书和证书都是X.509公钥证书的同义词，它符合ITU－T X.509 V3标准。证书是随PKI的形成而 新发展起来的安全机制，它实现身份的鉴别与识别（认证）、完整性、保密性及不可否认性安全服务（安全需求）；数字证书是电子商务中各实体的网上身份的证 明，它证明实体所声明的身份与其公钥的匹配关系，使得实体身份与证书上的公钥相绑定；从公钥管理的机制来讲，数字证书是公钥体制密钥管理的媒介，即在公钥 体制中，公钥的分发、传送是靠证书机制来实现的。所以有时也将数字证书称为公钥证书；数字证书是一种权威性的电子文档，它是由具有权威性、可信任性及公正性的第三方机构（CA）所颁发。
二、证书的内容及用途
   CFCA所发放的证书均遵循X.509 V3标准，其基本格式及其用途如下：
   1.Certificate Format Version
    证书版本号,用来指定证书格式用的X.509版本号，用于目录查询。
   2.Certificate Serial Number
    证书序列号,证书颁发者指定证书唯一序列号, 以标识CA发出的所有证书，用于目录查询。
   3.Signature Algorithm Identifier
    签名算法标识,用来指定本证书所用的签名算法（如SHA－1、RSA）。
   4.Issuer
    签发此证书的CA名称,用来指定签发证书的CA的可识别的唯一名称(DN, Distinguished Name)，用于认证。
   5.Validity Period
    证书有效期,指定证书起始日期（notBefore）和终止日期（notAfter），用于校验证书的有效性。
   6.Subject
    用户主体名称,用来指定证书用户的X.500唯一名称(DN)，用于认证。
   7.Subject Public Key Information
    用户主体公钥信息。
   (1)Algorithm Identifier,算法标识。用来标识公钥使用的算法。
   (2)Subject Public Key,用户主体公钥。用来标识公钥本身，用于加/解密和数字签名。
   8.Issuer Unique ID
    颁发者可选唯一标识，很少用。
   9.Subject Unique ID
    主体证书拥有者唯一标识，很少用。
   10.Extensions
    证书扩充部分(扩展域)，用来指定额外信息。
   (1)Authority Key Identifier,签发者CA的公钥标识。
   Key Identifier,公钥标识;
   Cert Issuer,证书签发者的甄别名,电子邮件、IP地址等;
   Cert Serial Number,签发证书的序列号,用于签发根证书及交叉认证。
   (2)Subject Key Identifier,用户主体的公钥标识。证书主体所含密钥的唯一标识，用来区分一个证书拥有者的多对密钥，主要用于对由以前公钥加密过的文件进行解密。
   (3)CRL Distribution Point, CRL分布。指明CRL分段的地点，用于分布式存放。
   (4)Key Usage,证书中的公钥用途，用来指定公钥用途,数字签名、加密等。

(5)Private Key Usage Period,用户的私钥有效期。用来指定用户签名私钥的起始日期和终止日期。
   (6)Certificate Policies,CA承认的证书政策列表。用来指定用户证书所适用的政策, 证书政策可由对象标识符表示，一个详细提示（200字符）。
   (7)Policy Mappings,策略映射。表明在两个CA之间一个或多个策略标识的等价映射关系——仅在CA证书里存在。
   (8)Subject Alt Name,用户的代用名。用来指定用户的代用名。
   (9)Issuer Alt Name,CA的代用名。用来指定CA的代用名。
   (10)Basic Constraints,基本制约。用来表明证书用户是最终用户还是CA，用于交易路径。
   (11)Subject Directory Attributes,用户主体目录属性。指出证书拥有者的一系列属性。
   11.Signature Acgorithm
   CA签名算法标识。
   12.CA Signature
   CA签名。
三、证书的认证过程
    以上介绍了证书结构、内容及用途，那么证书是如何相互认证的呢？相互的身份是如何识别的？为什么应用证书机制就是安全的呢？
    首先看一下证书的认证过程（也称验证过程）。
   1.拆封证书
    所谓证书的拆封，是验证发行者CA的公钥能否正确解开客户实体证书中的“发行者的数字签名”（见上节第11、12项）。两个证书在交换传递之后，要进行拆封，看是否能够拆封。一个证书或证书链的拆封操作，是为了从中获得一个公钥。可示为X1p·X1<>,这为一个中缀操作，其左操作数为一个认证机构的公钥，右操作数则为该认证机构所颁发的一个证书。如果能正确解开，输出结果为用户的公钥。
    从证书内容列表中可以看出，证书结构的最后内容是认证机构CA的数字签名，即一个可信任的CA已经在证书上用自己的私钥做了签名。如果用该CA的公钥就可以拆封一个用户实体的证书，那么，这个签名被验证是正确的。因为它证明了这个证书是由权威的、可信任的认证机构所签发。因此，这个实体证书是真实可信的。
   2.证书链的验证
    所谓证书链的验证，是想通过证书链追溯到可信赖的CA的根（ROOT）。换句话说，要验证签发用户实体证书的CA是否是权威可信的CA，如CFCA。证书链验证的要求是，路径中每个证书从最终实体到根证书都是有效的，并且每个证书都要正确地对应发行该证书的权威可信任性CA。操作表达式为Ap·A<>B<>,指出该操作使用A的公钥，从B的证书中获得B的公钥Bp，然后再通过Bp来解封C的证书。操作的最终结果得到了C的公钥Cp。这就是一个证书链的认证拆封过程。
   (1)证书链的定义。证书链也称认证链，它是最终实体到根证书的一系列证书组成，这个证书链的处理过程是所有根的前辈指向最开始的根证书，即子辈连向父辈。如图1所示。

 证书（无论是SET或是Non－SET证书）是通过图1所显示的信任层次来验证的，每个证书都对应于发行该证书的实体的数字签名。如图所示，SET：CCA（MCA、PCA）—B—R；non－SET：CCA（BCA、UCA）—P—R。这样就可用一级一级的公钥解开每级的数字签名，一直上溯到可信任的根CA ROOT。它们是通过直到根CA ROOT的信任层次来验证证书的。
   (2)从用户实体证书到ROOT CA的证书链确认，其具体的做法如下页图2所示。
    从以上对比中可以看出：用户实体证书中的Authority Key Identifier扩展项Cert Issuer，即证书签发者的甄别名，应当与CA证书中签发此证书的CA名称相匹配，如图中箭头所指。即CA证书中的Subject Name是用户实体证书中Issuer Name的父名，对上级CA来说又成为子名，CA证书中Issuer Name是上一级CA的名字，成为可信任的链状结构。这样通过各级实体证书的验证，逐渐上溯到链的终止点——可信任的根CA，如CFCA。
   3．序列号验证
    序列号的验证是指检查实体证书中的签名实体序列号是否与签发者证书的序列号相一致，验证证书的真伪。验证操作过程是：用户实体证书中的Authority Key Identifier扩展项Cert Serial Number,即签发证书的序列号，检查CA证书中的Certificate Serial Number 证书序列号，二者应该相一致，否则证书不是可信任的认证机构CA所签发。
   4．有效期验证
    有效期验证就是检查用户证书使用的日期是否合法，有无过期。具体做法为：
    （1）用户实体证书的有效期Validity Period及私钥的有效期Priva Key Usege Period,应当在CA证书的有效日期Validity Period之内。如图2中粗箭头所示，超过CA证书有效期，实体证书应作废，交易是不安全的。
    （2）用户实体证书有效期开始时间Validity Period中notBefore日期应在CA证书的私钥有效期Private Key Usagc Period日期之内，否则证书是不安全的。
   5．证书作废止列表查询
    所谓证书作废止列表查询，是检查用户的证书是否已经作废，并发布在证书吊销列表中。一般称CRL查询，俗称“黑名单查询”。一个实体证书因私钥泄密等原因，需要废止时，应及时向CA声明作废。CA实时地通过LDAP标准协议向证书库中以X.500的格式进行发布，以供访问时实体间进行开放式查询。如图3所示。

 图3中所示为浏览器和Web服务器之间进行的双方认证，即进行双向CRL查询，在Web服务器查询浏览器证书是否为“黑名单”的同时，浏览器也去证书库查询Web服务器证书是否为有效。此为“双向认证”，CFCA的企业级高级证书即为这种机制，是中国金融CA PKI的特点。一般B to B模式的网上银行、网上购物皆采取这种方式。当然，也有“单向认证”方式，即Web服务器只去查验浏览器证书的有效性，如SSL证书的认证，这是一般CA的普遍做法。
   6.证书使用策略的认证
    证书的使用方式与任何声明的策略Certificate Policy或使用限制相一致，即用户实体证书中的Certificate Policies应为CA所承认的证书政策列表。它是用特殊扩展域来限定的，用来指定用户证书所适用的政策，这些政策应在CA的CPS中有明确规定，对象标识符不超过200个字符。没有CA承认的政策，用户证书是不能执行的。如Policy URL、 Policy E－mail地址，必须由根政策陈述。
   7.最终用户实体证书的确认
    为了证书的使用安全，CA所签发的认证机构内部管理员的证书要与最终用户实体证书相区分。为此：
   (1)在扩展域基本制约Basic Constraints中其默认值表示最终实体（End Entity），以区别其他CA内部管理证书，防止证书用于不同的目的。
   (2)在扩展域Key Usage中要对声明的用途有效，用于数字签名或用于传输加密，为确保安全，要明确分开，不能混用，以备争议时审计，为仲裁提供依据。
当然，以上这些操作对用户来说都是透明的。