vault backup: 2026-11-07 16:33:44
This commit is contained in:
@@ -0,0 +1,37 @@
|
||||
RSA定义的 PKCS 各版本,用途各不相同;
|
||||
|
||||
PKCS #1 定义私钥签名运算的填充方式。
|
||||
v1.5 是 PKCS1_PADDING
|
||||
v2.1 是 PKCS1_PSS_PADING;
|
||||
|
||||
PKCS#2:涉及了RSA的消息摘要加密,这已被并入PKCS#1中。
|
||||
|
||||
PKCS#3:Diffie-Hellman密钥协议标准。PKCS#3描述了一种实现Diffie- Hellman密钥协议的方法。
|
||||
|
||||
PKCS#4:最初是规定RSA密钥语法的,现已经被包含进PKCS#1中。
|
||||
|
||||
PKCS #5 基于口令的加密标准。PKCS#5描述了使用由口令生成的密钥来加密8位位组串并产生一个加密的8位位组串的方法。PKCS#5可以用于加密私钥,以便于密钥的安全传输(这在PKCS#8中描述)。定义了加密运算的填充方式,8字节填充,Java标准接口支持;例如,串0x56在经过PKCS5填充之后会成为0x56 0x07 0x07 0x07 0x07 0x07 0x07 0x07因为需要填充7字节,因此填充的内容就是7。当然特殊情况下,如果已经满足了8的整倍数,按照PKCS5的规则,仍然需要在尾部填充8个字节,并且内容是0x08,目的是为了加解密时统一处理填充。
|
||||
|
||||
PKCS#6:扩展证书语法标准。PKCS#6定义了提供附加实体信息的X.509证书属性扩展的语法(当PKCS#6第一次发布时,X.509还不支持扩展。这些扩展因此被包括在X.509中)。
|
||||
|
||||
PKCS #7 密码消息语法标准。PKCS#7为使用密码算法的数据规定了通用语法,比如数字签名和数字信封。PKCS#7提供了许多格式选项,包括未加密或签名的格式化消息、已封装(加密)消息、已签名消息和既经过签名又经过加密的消息。 填充算法扩充了PKCS#5 的限制,填充长度可以是1-255字节;通过第三方库可以在Java中支持 PKCS#7 填充;
|
||||
|
||||
PKCS#8:私钥信息语法标准。PKCS#8定义了私钥信息语法和加密私钥语法,其中私钥加密使用了PKCS#5标准;
|
||||
|
||||
PKCS#9:可选属性类型。PKCS#9定义了PKCS#6扩展证书、PKCS#7数字签名消息、PKCS#8私钥信息和PKCS#10证书签名请求中要用到的可选属性类型。已定义的证书属性包括E-mail地址、无格式姓名、内容类型、消息摘要、签名时间、签名副本(counter signature)、质询口令字和扩展证书属性。
|
||||
|
||||
PKCS#10:证书请求语法标准。PKCS#10定义了证书请求的语法。证书请求包含了一个唯一识别名、公钥和可选的一组属性,它们一起被请求证书的实体签名(证书管理协议中的PKIX证书请求消息就是一个PKCS#10)。
|
||||
|
||||
PKCS#11:密码令牌接口标准。PKCS#11或“Cryptoki”为拥有密码信息(如加密密钥和证书)和执行密码学函数的单用户设备定义了一个应用程序接口(API)。智能卡就是实现Cryptoki的典型设备。注意:Cryptoki定义了密码函数接口,但并未指明设备具体如何实现这些函数。而且Cryptoki只说明了密码接口,并未定义对设备来说可能有用的其他接口,如访问设备的文件系统接口。
|
||||
|
||||
PKCS#12:个人信息交换语法标准。PKCS#12定义了个人身份信息(包括私钥、证书、各种秘密和扩展字段)的格式。PKCS#12有助于传输证书及对应的私钥,于是用户可以在不同设备间移动他们的个人身份信息。
|
||||
|
||||
PKCS#13:椭圆曲线密码标准。PKCS#13标准当前正在完善之中。它包括椭圆曲线参数的生成和验证、密钥生成和验证、数字签名和公钥加密,还有密钥协定,以及参数、密钥和方案标识的ASN.1语法。
|
||||
|
||||
PKCS#14:伪随机数产生标准。PKCS#14标准当前正在完善之中。为什么随机数生成也需要建立自己的标准呢?PKI中用到的许多基本的密码学函数,如密钥生成和Diffie-Hellman共享密钥协商,都需要使用随机数。然而,如果“随机数”不是随机的,而是取自一个可预测的取值集合,那么密码学函数就不再是绝对安全了,因为它的取值被限于一个缩小了的值域中。因此,安全伪随机数的生成对于PKI的安全极为关键。
|
||||
|
||||
PKCS#15:密码令牌信息语法标准。PKCS#15通过定义令牌上存储的密码对象的通用格式来增进密码令牌的互操作性。在实现PKCS#15的设备上存储的数据对于使用该设备的所有应用程序来说都是一样的,尽管实际上在内部实现时可能所用的格式不同。PKCS#15的实现扮演了翻译家的角色,它在卡的内部格式与应用程序支持的数据格式间进行转换。
|
||||
————————————————
|
||||
版权声明:本文为CSDN博主「zhbpd」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
|
||||
原文链接:[https://blog.csdn.net/zhbpd/article/details/107732995](https://blog.csdn.net/zhbpd/article/details/107732995)
|
||||
|
||||
@@ -0,0 +1,82 @@
|
||||
**1.CA最初目的是签发数字证书**
|
||||
|
||||
为解决数字证书的签发问题,PKI引入CA.用于对数字证书进行集中签发。CA是Certificate Authority昀缩写,字面含义是证书权威,也称作CA中心、认证中心。CA中心拥有自己的公钥和私钥,使用其私钥给用户(包含CA巾心自己)签发数字证书,具体签发过程如下:
|
||||
|
||||
(1)将用户身份信息和用户公钥信息,按照特定格式组成数据D。
|
||||
|
||||
(2)选择摘要算法对数据D进行计算得到摘要H。
|
||||
|
||||
(3)使用CA私钥对摘要H进行加密得到数字签名S。
|
||||
|
||||
(4)将用户身份信息、用户公钥信息和数字签名S,按照特定格式就可组成数字证书。
|
||||
|
||||
**2.CA应对数字证书的全生命周期进行管理**
|
||||
|
||||
CA实际是一种特殊的公钥管理中心,为实现数字证书的安全性,应对数字证书的全生命周期进行管理,主要包括:
|
||||
|
||||
(1)数字证书的签发和更新。证书签发主要针对新用户;证书更新主要针对已有证书用户,更新时公钥可以改变,也可以不变。
|
||||
|
||||
(2)数字证书的作废(注销、撤销或吊销)。证书作废后将成无效证书,永远不能使用。
|
||||
|
||||
(3)数字证书的冻结(挂失)和解冻。证书冻结后将成无效证书,但可以通过解冻恢复成有效状态。
|
||||
|
||||
(4)数字证书的查询或下载。应提供公开服务方式,允许用户根据条件随时查询证书并下载。常用服务方式有HTTP和LDAP。
|
||||
|
||||
(5)数字证书状态查询。应提供公开服务方式,允许用户随时查询证书状态,以便判断该证书是否处于有效状态。常用服务方式有CRL和OCSP。
|
||||
|
||||
**3.KMC用于管理私钥**
|
||||
|
||||
如果使用公钥(数字证书)对数据进行加密,则只有与公钥对应的私钥才能进行解密,从而可实现用户数据的保密性。当私钥丢失时,如果没有备份和恢复机制,将导致公钥加密的所有数据都无法解密,可能给用户带来损失。
|
||||
|
||||
为解决私钥的备份与恢复问题,PKI引入了KMC,用于对私钥的全生命周期进行管理。KMC是Key Management Center的缩写。
|
||||
|
||||
用户公私钥对可由KMC产生,提交CA签发数字证书后,将私钥和数字证书同时安全移交给用户,而KMC将私钥留作备份,可按需要给用户恢复。用户公私钥对也可由用户自己产生(使用软件或密码设备),在向CA中心申请数字证书时,可将私钥安全提交KMC留作备份。
|
||||
|
||||
**4.双证书机制**
|
||||
|
||||
为防止用户身份被冒用,应保证用户私钥的唯一性,不允许备份恢复。为防止公钥加密后的数据无法解密,应提供用户私钥的备份恢复机制。
|
||||
|
||||
为解决这两种矛盾的应用需求,PKI引入双证书机制:签名证书和加密证书。
|
||||
|
||||
签名证书及私钥只用于签名验签,不能用于加密解密;为保证签名私钥的唯一性,该公私钥对必须由用户自己产生,同时采用硬件技术(如只允许在硬件密码设备内产生公私钥对、私钥不允许导出等)保证无法复制,在证书签发过程中CA中心并不知道该私钥,只对其公钥进行操作。该私钥没有备份,因此永远不能恢复。
|
||||
|
||||
加密证书及私钥只用于加密解密,不能用于签名验签。为实现解密私钥的备份恢复机制,该公私钥对必须由KMC产生,由CA签发完数字证书后安全移交给用户,用户应采用硬件技术保证该私钥的安全性。KMC可根据需要恢复该私钥。
|
||||
|
||||
**5.LDAP**
|
||||
|
||||
CA中心存储着所有数字证书,并通过公开服务形式供用户随时查询或下载。为解决数字证书查询或下载的性能问题,避免CA中心成为性能瓶颈,PKI引入了LDAP技术,通过LDAP方式对外提供高速证书查询或下载服务。
|
||||
|
||||
专业的关系型数据库管理系统(如Oracle、DB2等)专门对结构化数据进行管理,应用系统只需通过SQL语句(报文协议)发送各种数据管理指令,而具体管理工作完全由数据库管理系统负责。尽管这种数据管理方式大大简化了应用系统的复杂度,但由于其读写功能相对均衡,很难满足高性能的查询服务。为获得高性能的查询服务,需要对数据管理的读取功能进行特殊优化,于是出现了目录服务技术(DAP,Directory Access Protocol)。目录服务技术对查询功能进行优化,比修改操作快10倍以上,适合快速响应和大容量查询服务。DAP技术通过目录树方式对数据进行管理,应用系统只需通过x.500协议就能对数据进行快速查询。
|
||||
|
||||
由于X.500协议过于复杂,实现成本很高,于是国际组织对X.500进行了简化,形成LDAP标准,而且LDAP支持TCP/IP协议,更适合于互联网领域使用。LDAP为轻量目录访问协议,是Light-weight Directory Access Protocol的缩写。
|
||||
|
||||
由于数字证书是可以公开的,CA中心也可以将其签发的数字证书存储到其他地方,供用户查询或下载。
|
||||
|
||||
**6.CRL和OCSP**
|
||||
|
||||
当用户私钥泄露后,CA中心有责任将该用户的证书标记为失效。但用户如何获得对方证书足否失效的状态呢?为方便用户获得证书状态,PKI引入了CRL和OCSP技术。
|
||||
|
||||
(1) CRL(Certificate Revocation List)
|
||||
|
||||
CRL为证书作废列表,是Certificate Revocation List的缩写,也称作证书黑名单,是一种特殊的文件格式,包含所有失效的证书清单、下次CRL生成时间和CA中心私钥的签名。
|
||||
|
||||
CA中心定期生成CRL.并将下次生成时问写入CRL中,方便用户按时定期下载CRL。跟数字证书类似,CRL也是通过CA中心私钥的签名来保证CRL无法被篡改的。用户只需定期获取CRL后,就可在本地脱机验证证书是否失效,在下次CRL生成时间之前无需联系CA中心。
|
||||
|
||||
由于CRL是可以公开的,CA中心也可以将其链发的CRL存储到其他地方,供用户查询或下载。CRL也可以发布到LDAP中,提供高速下载服务。
|
||||
|
||||
(2) OCSP (Online Certificate Status Protocol)
|
||||
|
||||
当CA中心将私钥已泄露的用户证书标记为失效后,如果还未到下次CRL生成时间,此时其他用户通过最新CRL并不知道该用户证书已经失效,依然将该用户当作有效用户继续进行各种保密通信和合法交易,因此可能会造成一定的损失。
|
||||
|
||||
为解决CRL滞后的缺陷,避免给高实时性或高风险交易造成重大损失,PKI引入了OCSP,对用户提供实时的证书状态查询服务。OCSP为在线证书状态协议,是Online Certificate Status Protocol的缩写。当用户需要实时查询对方证书是否有效时,可通过OCSP协议实时访问CA中心获得对方证书的当前状态。
|
||||
|
||||
**7.RA**
|
||||
|
||||
在保证CA系统安全性的前提下,为方便证书业务远程办理、方便证书管理流程与应用系统结合,PKI引入了RA,专门用于对用户提供面对面的证书业务服务,负责用户证书办理/作废申请、用户身份审核、制作证书并移交用户等功能,而涉及证书签发时则提交CA系统集中处理。RA是Registry Authority的缩写,又称作RA中心、注册中心。有时候,证书管理流程会与应用业务流程结合,并不单独体现出来,如对于网上银行,证书管理流程就会融合到网银业务流程中。
|
||||
|
||||
RA可以部署多个,既可以单独部署,也可以与应用系统集成。
|
||||
|
||||
CA主要模块组成如下图所示。
|
||||
|
||||

|
||||
|
||||
@@ -0,0 +1,70 @@
|
||||
**1.数字证书的最初目的是建立公钥与用户之间的对应关系**
|
||||
|
||||
由于公钥是随机产生的,从公钥无法直接判断属于哪个用户。为解决公钥与用户映射关系问题,PKI引入数字证书,用于建立公钥与用户之间的对应关系。
|
||||
|
||||
数字证书实际是一种特殊的文件格式,包含用户身份信息、用户公钥信息和CA私钥的数字签名。用户身份信息由姓名或名称、单位、城市、国家等组成。X.509标准规定了数字证书的具体格式。
|
||||
|
||||
由于数字证书中包含用户身份信息和公钥信息,根据数字证书就可直接判断该公钥属于哪个用户。如某数字证书包含用户信息“诸葛亮”和公钥PK,则可判断公钥PK就是诸葛亮的。
|
||||
|
||||
由于数字证书中包含CA私钥的数字签名,使用CA公钥对数字证书中CA私钥的数字签名进行解密处理后,就可立刻判断该数字证书是否被篡改,因此数字证书具有防伪性,于是,数字证书中公钥和用户之间对应关系也值得可信。当然,数字证书防伪性的前提是公钥算法和CA私钥都是安全的。
|
||||
|
||||
由于数字证书中不包含秘密信息,因此数字证书可公开发布。
|
||||
|
||||
数字证书主要内容显示如图2-2所示,其中,“使用者”为用户身份信息,“公钥”为用户公钥信息,“有效期”属于附加策略。
|
||||
|
||||

|
||||
|
||||
**图2-2 数字证书主要内容显示**
|
||||
|
||||
**2.数字证书可作为网络身份证**
|
||||
|
||||
现实生活中,公安部为每人颁发一张二代身份证,身份证上包含姓名、性别、出生日期、省份、身份证号、照片等信息。当购票、住店、坐飞机时,身份证持有人(或持证人)只需出示身份证即可证明自己的身份。只有通过以下四个方面的合法性验证,才能完全确认持证人的合法身份:
|
||||
|
||||
(1)验证身份证是否伪造。需要专门的二代身份证读写设备来验证。
|
||||
|
||||
(2)验证身份证信息是否正确。需要查询身份证数据库,需要公安部门提供;也可由公安部门在发放身份证时保证。
|
||||
|
||||
(3)验证身份证是否与持证人一致。需要对比身份证上照片与持证人的长相。
|
||||
|
||||
(4)验证身份证是否在黑名单上。需要查询黑名单数据库,如公安部通缉犯清单,需要公安部门提供。
|
||||
|
||||
既然数字证书包含用户身份信息,而且具有防伪性且可以公开,那么数字证书持有人(或持证人)在网络世界中能否也像现实生活中一样,只需出示数字证书即可证明自己身份呢?答案是肯定的。如果能通过类似二代身份证的四个方面合法性验证,数字证书就可作为网络身份证。下面来确认一下,数字证书能否通过四个方面的合法性验证:
|
||||
|
||||
(1)验证数字证书是否伪造。可通过CA公钥验证。
|
||||
|
||||
(2)验证数字证书中信息是否正确。可由CA中心在签发数字证书时保证。
|
||||
|
||||
(3)验证数字证书是否与持证人一致。可要求持证人使用私钥对特定数据进行加密或签名,然后使用数字证书中的公钥来解密该数据或验签,从而可验证持证人是否持有与数字证书中的公钥对应的私钥。
|
||||
|
||||
(4)验证数字证书是否在黑名单上。可通过查询黑名单数据库来实现,但需要CA中心提供黑名单。
|
||||
|
||||
因此,数字证书作为网络身份证,可有效解决网络世界中“你是谁”的问题。由于数字证书采用公钥密码技术实现,从技术上保证了每个人“钥匙”的唯一性,既不重复也无法复制,所以数字证书比现实生活中的各种钥匙安全很多。
|
||||
|
||||
**3.数字证书可附加很多策略**
|
||||
|
||||
由于数字证书具有防伪性和公开性,因此数字证书中不仅可包含用户身份信息和用户公钥信息,而且还可以附加其他策略信息,这些信息同样具有防伪性和公开性。
|
||||
|
||||
X.509数字证书标准中规定常用策略信息主要包括:
|
||||
|
||||
(1)有效期。包括起始时间和终止时问。
|
||||
|
||||
(2)密钥用途。表示该公钥和私钥用于什么目的,如数据签名、数据加密、签发证书、用于安全电子邮件等。
|
||||
|
||||
(3)别名。包括持证人别名和CA中心别名。
|
||||
|
||||
(4)黑名单地址。
|
||||
|
||||
(5)是否CA中心的数字证书。如果是CA中心的数字证书,则规定能签发几级证书。
|
||||
|
||||
**4.CA中心的数字证书**
|
||||
|
||||
用户在验证数字证书是否被篡改时,必须首先获得CA中心的公钥。为方便用户识别CA中心的公钥,CA中心也为自己签发数字证书。该证书包含CA中心公钥、CA中心身份信息和CA中心私钥的签名。CA中心的数字证书有时也称作CA证书。
|
||||
|
||||
由于CA证书是验证其他证书合法性的前提和基础,所以CA证书的正确性至关重要。尽管可通过网络直接下载获取CA证书,但为避免被欺骗,需要通过其他方式验证CA证书的正确性。可通过电话方式、官方报纸或官方电视公布CA证书的摘要值,用户通过核对该摘要值即可确认该证书的正确性。
|
||||
|
||||
**5.私钥**
|
||||
|
||||
对于公钥密码技术,公钥和私钥是成对出现的。公钥以数字证书形式存在,可以公开,但私钥必须保密。为保证私钥的安全性,一般将私钥保存在硬件密码设备中(如个人的私钥可保存在USB Key或lC卡中,系统的私钥可保存在加密机或加密卡中),而且不允许私钥导出硬件密码设备:通过口令、指纹等方式来访问控制该硬件密码没备。如果将私钥保存在硬盘文件中,则需要通过口令进行加密保护,但私钥文件容易被复制。
|
||||
|
||||
为保证私钥的唯一性,可只允许在硬件密码设备内产生公私钥对,通过硬件技术保证私钥无法导出,然后只导出公钥提交CA中心签发数字证节。
|
||||
|
||||
@@ -0,0 +1,44 @@
|
||||
PKI是Public Key Infrastructure的缩写,其主要功能是绑定证书持有者的身份和相关的密钥对(通过为公钥及相关的用户身份信息签发数字证书),为用户提供方便的证书申请、证书作废、证书获取、证书状态查询的途径,并利用数字证书及相关的各种服务(证书发布,黑名单发布,时间戳服务等)实现通信中各实体的身份认证、完整性、抗抵赖性和保密性。
|
||||
|
||||
根据数字证书格式及密钥管理方式的不同,PKI也包括多种模式,如X.509模式、PGP模式、IBE/CPK模式、EMV模式等。X.509模式的PKI也称作PKIX。由于X.509标准已经成为数字证书格式的事实标准,因此大部分情况下PKI特指PKIX。如非特殊说明,本文中PKI均指PKIX。
|
||||
|
||||
PKI体系框架主要包括三部分内容。
|
||||
|
||||
**1.数字证书与私钥**
|
||||
|
||||
用户或系统只有拥有自己的公钥和私钥后,才能实现数字签名和加解密功能。由于公钥是随机产生的,因此从公钥无法直接判断属于哪个用户。
|
||||
|
||||
为解决公钥与用户映射关系问题,PKI引入了数字证书,用于建立公钥与用户之间的对应关系。数字证书实际上是一种特殊的文件格式,包含用户身份信息、用户公钥信息和CA私钥的数字签名。X.509标准规定了数字证书的具体格式。数字证书中只包含公钥,并不包括私钥。由于数字证书中包含CA私钥的数字签名,因此数字证书具有防伪性。由于数字证书中不包含秘密信息,因此数字证书具有公开性。数字证书作为网络身份证,可有效解决网络世界中“你是谁”的问题。
|
||||
|
||||
为保证私钥的安全性,一般将私钥保存在硬件密码设备中(如个人的私钥可保存在USBKey或lC卡中,系统的私钥可保存在加密机或加密卡中),而且不允许私钥导出硬件密码设备:通过口令、指纹等方式来访问控制该硬件密码设备。如果将私钥保存在硬盘文件中,则需要通过口令进行加密保护,但私钥文件容易被复制。
|
||||
|
||||
**2.数字证书的管理**
|
||||
|
||||
为解决数字证书的签发问题,PKI引入CA,对数字证书进行集中签发。CA是Certificate Authority的缩写,字面含义是证书权威,也称作CA中心、认证中心。CA中心拥有自己的公钥和私钥,使用其私钥给用户(包含CA中心自己)签发数字证书。
|
||||
|
||||
CA实际是一种特殊的公钥管理中心,为实现数字证书的安全性,对数字证书的全生命周期进行管理,主要包括:数字证书的签发和更新、数字证书的作废(注销、撤销或吊销)、数字证书的冻结(挂失)和解冻、数字证书的查询或下载、数字证书状态查询等。当私钥丢失时,如果没有备份和恢复机制,将导致公钥加密的所有数据都无法解密,可能给用户带来损失。为解决私钥的备份与恢复问题,PKI引入了KMC,用于对私钥的全生命周期进行管理。KMC是Key Management Center的缩写。用户公私钥对可由KMC产生,提交CA签发数字证书后,将私钥和数字证书同时安全移交给用户,而KMC将私钥留作备份,可按需要给用户恢复。用户公私钥对也可由用户自己产生(使用软件或密码设备),在向CA中心申请数字证书时,可将私钥安全提交KMC留作备份。
|
||||
|
||||
为防止用户身份被冒用,应保证用户私钥的唯一性,不允许备份恢复。为防止公钥加密后的数据无法解密,应提供用户私钥的备份恢复机制。为解决这两种矛盾的应用需求,PKI引入双证书机制:签名证书和加密证书。签名证书及私钥只用于签名验签,不能用于加密解密,该公私钥对必须由用户自己产生,KMC不备份签名私钥。加密证书及私钥只用于加密解密,不能用于签名验签,该公私钥对必须由KMC产生,且KMC对加密私钥进行备份。
|
||||
|
||||
CA中心存储着所有数字证书,并通过公开服务形式供用户随时查询或下载。为解决数字证书查询或下载的性能问题.避免CA中心成为性能瓶颈,PKI引入了LDAP技术,通过LDAP方式对外提供高速证书查询或下载服务。LDAP为轻量目录访问协议,是Light-weight Directory Access Protocol的缩写。
|
||||
|
||||
当用户私钥泄露后,CA中心有责任将该用户的证书标记为失效。但用户如何获得对方证书是否失效的状态呢?为方便用户获得证书状态,PKI引入了CRL和OCSP技术。CRL为证书作废列表,是Certificate Revocation List的缩写,也称作证书黑名单。OCSP为在线证书状态协议,是Online Certificate Status Protocol的缩写。
|
||||
|
||||
在保证CA系统安全性的前提下,为方便证书业务远程办理、方便证书管理流程与应用系统结合,PKI引入了RA,专门用RA对用户提供面对面的证书业务服务,负责用户证书办理/作废申请、用户身份审核、制作证书并移交用户等功能,而涉及证书签发时则提交CA系统集中处理。RA是Registry Authority的缩写,又称作RA中心、注册中心。有时候,证书管理流程会与应用业务流程结合,并不单独体现出来,如对于网上银行,证书管理流程就会融合到网银业务流程中。
|
||||
|
||||
为保证CA系统在数字证书管理方面的规范性、合规性和安全性,PKI引入电子认证服务机构,以第三方运营的方式对外提供数字证书相关服务。《电子签名法》规定:“电子签名需要第三方认证的,由依法设立的电子认证服务提供者提供认证服务。”显然,电子签名法不仅赋予了电子签名的法律效力,而且明确了电子认证服务提供者的法律地位。电子认证服务提供者,又称作电子认证服务机构或CA中心,需要独立运营,不仅需要满足政策法规的各项要求,而且需要满足业务运营的业务需求。
|
||||
|
||||
**3.数字证书的应用**
|
||||
|
||||
基于数字证书可实现四种基本安全功能:身份认证、保密性、完整性和抗抵赖性。
|
||||
|
||||
基于证书接口中间件(模块或组件),应用系统可以很方便地使用数字证书技术,从而提高应用系统的身份认证强度、保证应用系统中各种敏感数据的保密性、保证应用系统中各种敏感数据和交易记录的完整性、用户各种操作或交易的不可否认性(抗抵赖性)。
|
||||
|
||||
PKI技术经过30多年的发展历程,已经形成比较完善的标准规范体系,几乎覆盖应用系统的各个方面,目前很多软件都已经支持数字证书技术,如操作系统、数据库系统、Web服务器、应用服务器等。由于受应用环境多样性和应用技术复杂性的影响或限制,在不同的应用环境和应用技术下,数字证书技术应用的方式可能差异很大。
|
||||
|
||||
网上报税和网上银行是数字证书应用的典型案例。国内大部分省份上千万家企业已经通过数字证书在进行网上报税。数字证书(俗称U盾)已经成为国内网上银行的标准配置。如果没有数字证书,企业用户将不允许使用网上银行。上亿个人用户已经通过数字证书访问网上银行实现转账或汇款等资金操作。
|
||||
|
||||
PKI体系框架如下图:
|
||||
|
||||

|
||||
|
||||
Reference in New Issue
Block a user