pki++-

在网上发现的<PKI技术及应用开发指南> 个人认为是关于pki的一篇不错的文章!

                        Identifier）：签发者唯一标识符在第2版加入证书定义中。此域用在当同一个X.500名字用于多个认证机构时，用一比特字符串来唯一标识签发者的X.500名字。可选。 
                        <BR>证书持有者唯一标识符（Subject Unique 
                        Identifier）：持有证书者唯一标识符在第2版的标准中加入X.509证书定义。此域用在当同一个X.500名字用于多个证书持有者时，用一比特字符串来唯一标识证书持有者的X.500名字。可选。 
                        <BR>签名值（Issuer's 
                        Signature）：证书签发机构对证书上述内容的签名值。<BR><BR>X.509 
                        V3证书是在v2的基础上一标准形式或普通形式增加了扩展项，以使证书能够附带额外信息。标准扩展是指由X.509 
                        V3版本定义的对V2版本增加的具有广泛应用前景的扩展项，任何人都可以向一些权威机构，如ISO，来注册一些其他扩展，如果这些扩展项应用广泛，也许以后会成为标准扩展项。<BR><BR>3.1.2 
                        CRL格式 <BR>证书废除列表CRL（Certificate revocation 
                        lists，又称证书黑名单）为应用程序和其它系统提供了一种检验证书有效性的方式。任何一个证书废除以后，证书机构CA会通过发布CRL的方式来通知各个相关方。目前，同X.509 
                        V3证书对对应的CRL为X.509 v2 CRL，其所包含的内容格式如下： 
                        <BR><BR>CRL的版本号：0表示X.509 V1 标准；1表示X.509 V2 
                        标准；目前常用的是同X.509 V3证书对应的CRL V2版本。 
                        <BR>签名算法：包含算法标识和算法参数，用于指定证书签发机构用来对CRL内容进行签名的算法。 
                        <BR>证书签发机构名：签发机构的DN名，由国家、省市、地区、组织机构、单位部门和通用名等组成。 
                        <BR>此次签发时间：此次CRL签发时间，遵循ITU-T X.509 
                        V2标准的CA在2049年之前把这个域编码为UTCTime类型，在2050或2050年之后年之前把这个域编码为GeneralizedTime类型。 
                        <BR>下次签发时间：下次CRL签发时间，遵循ITU-T X.509 
                        V2标准的CA在2049年之前把这个域编码为UTCTime类型，在2050或2050年之后年之前把这个域编码为GeneralizedTime类型。 
                        <BR>用户公钥信息，其中包括废除的证书序列号和证书废除时间。废除的证书序列号是指要废除的由同一个CA签发的证书的一个唯一标识号，同一机构签发的证书不会有相同的序列号。 
                        <BR>签名算法：对CRL内容进行签名的签名算法。 
                        <BR>签名值：证书签发机构对CRL内容的签名值。<BR><BR>另外，CRL中还包含扩展域和条目扩展域。CRL扩展域用于提供与CRL有关的额外信息部份，允许团体和组织定义私有的CRL扩展域来传送他们独有的信息；CRL条目扩展域则提供与CRL条目有关的额外信息部份，允许团体和组织定义私有的CRL条目扩展域来传送他们独有的信息。<BR><BR>3.1.3 
                        证书的存放 <BR>数字证书作为一种电子数据格式，可以直接从网上下载，也可以通过其他方式。 
                        <BR><BR>使用IC卡存放用户证书。即把用户的数字证书写到IC卡中，供用户随身携带。这样用户在所有能够读IC卡证书的电子商务终端上都可以享受安全电子商务服务。 
                        <BR>用户证书直接存放在磁盘或自己的终端上。户将从CA申请来的证书下载或复制到磁盘或自己的PC机或智能终端上，当用户使用自己的终端享受电子商务服务时，直接从终端读入即可。<BR><BR>另外，CRL一般通过网上下载的方式存储在用户端。<BR><BR><BR>3.2 
                        CA框架模型 <BR><BR><BR>证书机构CA用于创建和发布证书，它通常为一个称为安全域（security 
                        domain）的有限群体发放证书。创建证书的时候，CA系统首先获取用户的请求信息，其中包括用户公钥（公钥一般由用户端产生，如电子邮件程序或浏览器等），CA将根据用户的请求信息产生证书，并用自己的私钥对证书进行签名。其他用户、应用程序或实体将使用CA的公钥对证书进行验证。如果一个CA系统是可信的，则验证证书的用户可以确信，他所验证的证书中的公钥属于证书所代表的那个实体。<BR><BR>CA还负责维护和发布证书废除列表CRL（certificate 
                        revocation 
                        lists，又称为证书黑名单）。当一个证书，特别是其中的公钥因为其他原因无效时（不是因为到期），CRL提供了一种通知用户和其他应用的中心管理方式。CA系统生成CRL以后，要么是放到LDAP服务器中供用户查询或下载，要么是放置在Web服务器的合适位置，以页面超级连接的方式供用户直接查询或下载。<BR><BR>一个典型的CA系统包括安全服务器、注册机构RA、CA服务器、LDAP目录服务器和数据库服务器等。如图2所示。<BR><BR><IMG 
                        src="PKI技术及应用开发指南.files/fig2.gif"><BR><BR><BR>图2 
                        典型CA框架模型<BR><BR>安全服务器：安全服务器面向普通用户，用于提供证书申请、浏览、证书撤消列表以及证书下载等安全服务。安全服务器与用户的的通信采取安全信道方式（如SSL的方式，不需要对用户进行身份认证）。用户首先得到安全服务器的证书（该证书由CA颁发），然后用户与服务器之间的所有通信，包括用户填写的申请信息以及浏览器生成的公钥均以安全服务器的密钥进行加密传输，只有安全服务器利用自己的私钥解密才能得到明文，这样可以防止其他人通过窃听得到明文。从而保证了证书申请和传输过程中的信息安全性。 
                        <BR>CA服务器：CA服务器使整个证书机构的核心，负责证书的签发。CA首先产生自身的私钥和公钥（密钥长度至少为1024位），然后生成数字证书，并且将数字证书传输给安全服务器。CA还负责为操作员、安全服务器以及注册机构服务器生成数字证书。安全服务器的数字证书和私钥也需要传输给安全服务器。CA服务器是整个结构中最为重要的部分，存有CA的私钥以及发行证书的脚本文件，出于安全的考虑，应将CA服务器与其他服务器隔离，任何通信采用人工干预的方式，确保认证中心的安全。 
                        <BR>注册机构RA：登记中心服务器面向登记中心操作员，在CA体系结构中起承上启下的作用，一方面向CA转发安全服务器传输过来的证书申请请求，另一方面向LDAP服务器和安全服务器转发CA颁发的数字证书和证书撤消列表。 
                        <BR>LDAP服务器：LDAP服务器提供目录浏览服务，负责将注册机构服务器传输过来的用户信息以及数字证书加入到服务器上。这样其他用户通过访问LDAP服务器就能够得到其他用户的数字证书。 
                        <BR>数据库服务器：数据库服务器是认证机构中的核心部分，用于认证机构中数据（如密钥和用户信息等）、日志合统计信息的存储和管理。实际的的数据库系统应采用多种措施，如磁盘阵列、双机备份和多处理器等方式，以维护数据库系统的安全性、稳定性、可伸缩性和高性能。<BR><BR>3.3 
                        证书的申请和撤销 
                        <BR>证书的申请有两种方式，一是在线申请，另外一个就是离线申请。在线申请就是通过浏览器或其他应用系统通过在线的方式来申请证书，这种方式一般用于申请普通用户证书或测试证书。离线方式一般通过人工的方式直接到证书机构证书受理点去办理证书申请手续，通过审核后获取证书，这种方式一般用于比较重要的场合，如服务器证书和商家证书等。下面讨论的主要是在线申请方式。<BR><BR>当证书申请时，用户使用浏览器通过Internet访问安全服务器，下载CA的数字证书（又叫做根证书），然后注册机构服务器对用户进行身份审核，认可后便批准用户的证书申请，然后操作员对证书申请表进行数字签名，并将申请及其签名一起提交给CA服务器。<BR><BR>CA操作员获得注册机构服务器操作员签发的证书申请，发行证书或者拒绝发行证书，然后将证书通过硬拷贝的方式传输给注册机构服务器。注册机构服务器得到用户的证书以后将用户的一些公开信息和证书放到LDAP服务器上提供目录浏览服务，并且通过电子邮件的方式通知用户从安全服务器上下载证书。用户根据邮件的提示到指定的网址下载自己的数字证书，而其他用户可以通过LDAP服务器获得他的公钥数字证书。<BR><BR>证书申请的步骤如下： 
                        <BR><BR>用户申请。<BR>用户首先下载CA的证书，又叫根证书，然后在证书的申请过程中使用SSL安全方式与服务器建立连接，用户填写个人信息，浏览器生成私钥和公钥对，将私钥保存客户端特定文件中，并且要求用口令保护私钥，同时将公钥和个人信息提交给安全服务器。安全服务器将用户的申请信息传送给注册机构服务器。 
                        <BR><BR>注册机构审核<BR>用户与注册机构人员联系，证明自己的真实身份，或者请求代理人与注册机构联系。 
                        注册机构操作员利用自己的浏览器与注册机构服务器建立SSL安全通信，该服务器需要对操作员进行严格的身份认证，包括操作员的数字证书、IP地址，为了进一步保证安全性，可以设置固定的访问时间。<BR>操作员首先查看目前系统中的申请人员，从列表中找出相应的用户，点击用户名，核对用户信息，并且可以进行适当的修改，如果操作员同意用户申请证书请求，必须对证书申请信息进行数字签名。操作员也有权利拒绝用户的申请。<BR>操作员与服务器之间的所有通信都采用加密和签名，具有安全性、抗否认性，保证了系统的安全性和有效性。 
                        <BR>CA发行证书<BR>注册机构RA通过硬拷贝的方式向CA传输用户的证书申请与操作员的数字签名，CA操作员查看用户的详细信息，并且验证操作员的数字签名，如果签名验证通过，则同意用户的证书请求，颁发证书。然后CA将证书输出。如果CA操作员发现签名不正确，则拒绝证书申请，<BR>CA颁发的数字证书中包含关于用户及CA自身的各种信息，如：能唯一标识用户的姓名及其他标识信息，如个人的email地址；证书持有者的公钥。公钥用于为证书持有者加密敏感信息、签发个人证书的认证机构的名称、个人证书的序列号和个人证书的有效期（证书有效起止日期）等 
                        <BR>注册机构证书转发<BR>注册机构RA操作员从CA处得到新的证书，首先将证书输出到LDAP目录服务器以提供目录浏览服务，最后操作员向用户发送一封电子邮件，通知用户证书已经发行成功，并且把用户的证书序列号告诉用户到指定的网址去下载自己的数字证书。并且告诉用户如何使用安全服务器上的LDAP配置，让用户修改浏览器的客户端配置文件以便访问LDAP服务器，获得他人的数字证书。 
                        <BR>用户证书获取<BR>用户使用证书申请时的浏览器到指定的网址，键入自己的证书序列号，服务器要求用户必须使用申请证书时的浏览器，因为浏览器需要用该证书相应的私钥去验证数字证书。只有保存了相应私钥的浏览器才能成功下载用户的数字证书。<BR><BR>这时用户打开浏览器的安全属性，就可以发现自己已经拥有了CA颁发的数字证书，可以利用该数字证书与其他人以及web服务器（拥有相同CA颁发的证书）使用加密、数字签名进行安全通信。<BR><BR>认证中心还涉及到CRL的管理。用户向特定的操作员（仅负责CRL的管理）发一份加密签名的邮件，申明自己希望撤消证书。操作员打开邮件，填写CRL注册表，并且进行数字签名，提交给CA，CA操作员验证注册机构操作员的数字签名，批准用户撤消证书，并且更新CRL，然后CA将不同格式的CRL输出给注册机构，公布到安全服务器上，这样其他人可以通过访问服务器得到CRL。<BR><BR>证书撤销流程步骤如下： 
                        <BR><BR>用户向注册机构操作员CRLManager发送一封签名加密的邮件，声明自己自愿撤消证书。 
                        <BR>这册机构同意证书撤消，操作员键入用户的序列号，对请求进行数字签名。 
                        <BR>CA查询证书撤消请求列表，选出其中的一个，验证操作员的数字签名，如果正确的话，则同意用户的证书撤消申请，同时更新CRL列表，然后将CRL以多种格式输出。 
                        <BR>注册机构转发证书撤消列表。操作员导入CRL，以多种不同的格式将CRL公布于众。 
                        <BR>用户浏览安全服务器，下载或浏览CRL。<BR><BR>在一个PKI，特别是CA中，信息的存储是一个非常核心的问题，它包括两个方面：一是CA服务器利用数据库来备份当前密钥和归档过期密钥，该数据库需高度安全和机密，其安全等级同CA本身相同；另外一个就是目录服务器，用于分发证书和CRL，一般采用LDAP目录服务器。<BR><BR>3.4 
                        密钥管理 
                        <BR>密钥管理也是PKI（主要指CA）中的一个核心问题，主要是指密钥对的安全管理，包括密钥产生、密钥备份、密钥恢复和密钥更新等。<BR><BR>1. 
                        密钥产生<BR>密钥对的产生是证书申请过程中重要的一步，其中产生的私钥由用户保留，公钥和其他信息则交于CA中心进行签名，从而产生证书。根据证书类型和应用的不同，密钥对的产生也有不同的形式和方法。对普通证书和测试证书，一般由浏览器或固定的终端应用来产生，这样产生的密钥强度较小，不适合应用于比较重要的安全网络交易。而对于比较重要的证书，如商家证书和服务器证书等，密钥对一般由专用应用程序或CA中心直接产生，这样产生的密钥强度大，适合于重要的应用场合。<BR>另外，根据密钥的应用不同，也可能会有不同的产生方式。比如签名密钥可能在客户端或RA中心产生，而加密密钥则需要在CA中心直接产生。<BR><BR>2. 
                        密钥备份和恢复<BR>在一个PKI系统中，维护密钥对的备份至关重要，如果没有这种措施，当密钥丢失后，将意味着加密数据的完全丢失，对于一些重要数据，这将是灾难性的。所以，密钥的备份和恢复也是PKI密钥管理中的重要一环。<BR>使用PKI的企业和组织必须恩能够得到确认：即使密钥丢失，受密要加密保护的重要信息也必须能够恢复，并且不能让一个独立的个人完全控制最重要的主密钥，否则将引起严重后果。<BR>企业级的PKI产品至少应该支持用于加密的安全密钥的存储、备份和恢复。密钥一般用口令进行保护，而口令丢失则是管理员最常见的安全疏漏之一。所以，PKI产品应该能够备份密钥，即使口令丢失，它也能够让用户在一定条件下恢复该密钥，并设置新的口令。<BR>例如，在某些情况下用户可能有多对密钥，至少应该有两个密钥：一个用于加密，一个用于签名。签名密要不需要备份，因为用于验证签名的公钥（或公钥证书）广泛发布，即使签名私钥丢失，任何用于相应公要的人都可以对已签名的文档进行验证。但PKI系统必须备份用于加密的密钥对，并允许用户进行恢复，否则，用于解密的私钥丢失将意味着加密数据的完全不可恢复。<BR>另外，使用PKI的企业也应该考虑所使用密钥的生命周期，它包括密钥和证书的有效时间，以及已撤销密钥和证书的维护时间等。<BR><BR>3. 
                        密钥更新<BR>对每一个由CA颁发的证书都会有有效期，密钥对生命周期的长短由签发证书的CA中心来确定，各CA系统的证书有效期限有所不同，一般大约为2-3年。<BR>当用户的私钥被泄漏或证书的有效期快到时，用户应该更新私钥。这时用户可以废除证书，产生新的密钥对，申请新的证书。<BR><BR>3.5 
                        证书的使用 
                        <BR>在实际应用中，为了验证信息的数字签名，用户首先必须获取信息发送者的公钥证书，以及一些额外需要的证书（如CA证书等，用于验证发送者证书的有效性）。<BR><BR>证书的获取可以有多种方式，如发送者发送签名信息时附加发送自己的证书，或以另外的单独信息发送证书，或者可以通过访问证书发布的目录服务器来获得，或者直接从证书相关的实体处获得。在一个PKI体系中，可以采取某种或某几种上述方式获得证书。<BR><BR>在电子商务系统中，证书的持有者可以是个人用户、企事业单位、商家、银行等。无论是电子商务中的哪一方，在使用证书验证数据时，都遵循同样的验证流程。一个完整的验证过程有以下几步： 
                        <BR><BR>将客户端发来的数据解密 (如解开数字信封)。 
                        <BR>将解密后的数据分解成原始数据，签名数据和客户证书三部分。 <BR>用CA根证书验证客户证书的签名完整性。 
                        <BR>检查客户证书是否有效 (当前时间在证书结构中的所定义的有效期内)。 <BR>检查客户证书是否作废 
                        (OCSP方式或CRL方式)。 <BR>验证客户证书结构中的证书用途。 
                        <BR>客户证书验证原始数据的签名完整性。<BR><BR>如果以上各项均验证通过，则接受该数据。<BR><BR>4 
                        PKI应用 
                        <BR>---PKI技术的广泛应用能满足人们对网络交易安全保障的需求。当然，作为一种基础设施，PKI的应用范围非常广泛，并且在不断发展之中，下面给出几个应用实例。<BR><BR>1. 
                        虚拟专用网络（VPN）<BR>VPN是一种架构在公用通信基础设施上的专用数据通信网络，利用网络层安全协议（尤其是IPSec）和建立在PKI上的加密与签名技术来获得机密性保护。基于PKI技术的IPSec协议现在已经成为架构VPN的基础，它可以为路由器之间、防火墙之间或者路由器和防火墙之间提供经过加密和认证的通信。虽然它的实现会复杂一些，但其安全性比其他协议都完善得多。<BR><BR>2. 
                        安全电子邮件<BR>----作为Internet上最有效的应用，电子邮件凭借其易用、低成本和高效已经成为现代商业中的一种标准信息交换工具。随着Internet的持续增长，商业机构或政府机构都开始用电子邮件交换一些秘密的或是有商业价值的信息，这就引出了一些安全方面的问题，包括：消息和附件可以在不为通信双方所知的情况下被读取、篡改或截掉；发信人的身份无法确认。电子邮件的安全需求也是机密、完整、认证和不可否认，而这些都可以利用PKI技术来获得。目前发展很快的安全电子邮件协议是S/MIME 
                        (The Secure Multipurpose Internet Mail 
                        Extension)，这是一个允许发送加密和有签名邮件的协议。该协议的实现需要依赖于PKI技术。<BR><BR>3. 
                        Web安全 <BR>----浏览Web页面是人们最常用的访问Internet的方式。如果要通过Web 
                        进行一些商业交易，该如何保证交易的安全呢？为了透明地解决Web的安全问题，在两个实体进行通信之前，先要建立SSL连接，以此实现对应用层透明的安全通信。利用PKI技术，SSL协议允许在浏览器和服务器之间进行加密通信。此外服务器端和浏览器端通信时双方可以通过数字证书确认对方的身份。-结合SSL协议和数字证书，PKI技术可以保证Web 
                        交易多方面的安全需求，使Web上的交易和面对面的交易一样安全。<BR><BR>5 应用编程接口API 
                        <BR>协议标准是系统具有可交互性的前提和基础，它规范了PKI系统各部分之间相互通信的格式和步骤。而应用编程界面API（Application 
                        programming 
                        interfaces）则定义了如何使用这些协议，并为上层应用提供PKI服务。当应用需要使用PKI服务，如获取某一用户的公钥、请求证书废除信息或请求证书时将会都会用到API。目前API没有统一的国际标准，大部分都是操作系统或某一公司产品的扩展，并在其产品应用的框架内提供PKI服务。<BR><BR>目前，有很多可以让开发者选择的API类型。IETF建议标准为通用安全服务API：GSS-API（Generic 
                        Security Service Application Program 
                        Interface），它提供了一种接口与网络机制和网络协议相互独立的实现。<BR><BR>欧洲建立的SESAME（Secure 
                        European System for Applications in a Multi-Vendor 
                        Environment）定义了一些安全界面，并作为该组织发展的安全技术的一部分，该接口得到了欧洲许多著名厂商的支持，如Bull 
                        SA、ICL和Seimens等，但没有在美国得到支持，特别是一些大的厂商，如Microsoft和Netscape等。<BR><BR>Entrust也为其产品提供了一套API，如Entrust证书管理服务API（CMS 
                        API，Entrust's Certificate Management Services 
                        API），该API允许应用使用Entrust的证书管理和分发服务。在1996年指定，并与1997年更新的PKIX 
                        Internet草案"Architecture for Public Key