CN114070569B - 利用证书透明化技术控制交叉证书信任传递的方法及系统 - Google Patents

利用证书透明化技术控制交叉证书信任传递的方法及系统 Download PDF

Info

Publication number
CN114070569B
CN114070569B CN202111347539.0A CN202111347539A CN114070569B CN 114070569 B CN114070569 B CN 114070569B CN 202111347539 A CN202111347539 A CN 202111347539A CN 114070569 B CN114070569 B CN 114070569B
Authority
CN
China
Prior art keywords
certificate
sct
log server
issuing
terminal entity
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202111347539.0A
Other languages
English (en)
Other versions
CN114070569A (zh
Inventor
林璟锵
温舒尚
俞能海
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Zhongke Research Institute
Original Assignee
Beijing Zhongke Research Institute
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Zhongke Research Institute filed Critical Beijing Zhongke Research Institute
Priority to CN202111347539.0A priority Critical patent/CN114070569B/zh
Publication of CN114070569A publication Critical patent/CN114070569A/zh
Application granted granted Critical
Publication of CN114070569B publication Critical patent/CN114070569B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明公开了一种利用证书透明化技术控制交叉证书信任传递的方法，包括：1)签发CA收到主体CA的交叉证书签名请求时，签发交叉证书并添加包含必选日志服务器获取方式的必选日志服务器扩展项，必选日志服务器为签发CA控制的透明化日志服务器；2)主体CA签发的终端实体证书须提交给相关必选日志服务器，必选日志服务器审核通过后返回SCT；3)证书校验时，检查各CA证书是否存在必选日志服务器扩展项；若是，则检查终端实体证书的SCT列表是否满足2)中的要求；若不满足，则拒绝接受证书。采用本方法，对给定的证书认证路径中任意主体CA的签发CA，均能通过必选日志服务器对签发的交叉证书的信任传递过程加以细粒度控制，避免信任传递的失控。

Description

利用证书透明化技术控制交叉证书信任传递的方法及系统
技术领域
本发明涉及信息安全中身份认证技术领域，尤其涉及一种利用证书透明化技术控制交叉证书信任传递的方法及系统。
背景技术
随着5G技术和人工智能技术的广泛普及，包括商业行为、政务办公在内的众多对数据安全、隐私保护和身份认证要求较高的行业领域，也越来越依赖于通过线上的方式进行活动的宣传和开展，例如：网上购物、线上会议等。数据的价值正随着网络应用的不断扩大而上升。因此，如何在使用应用系统的过程中确保通信双方实体身份的可验证性、确保通信数据的保密性和完整性也愈发重要。
公钥基础设施(Public Key Infrastructure，PKI)，是基于公钥密码学算法的安全基础服务设施。基于数字证书的PKI系统在当今互联网中发挥着信任建立等重要的基础性作用。PKI技术采用数字证书在网络中建立并传递信任。在PKI系统应用和部署中，认证机构(Certificate Authority，CA)作为信任锚负责签发证书，绑定证书订户(Subscriber)的身份信息和公钥。在通信过程中，通信双方通过本地信任的根CA证书验证对方发送来的证书链，可信地获得对方公钥，进而用于确保数据传输过程中的真实性、机密性、完整性和不可否认。
在PKI实施应用与部署中，某一CA机构通常只被一定范围内的PKI用户(RelyingParty，以下称为证书依赖方)所信任，各个PKI体系之间无法相互传递信任关系，导致某一CA机构签发的证书可能不被所有PKI用户信任并接受，继而形成分离的“信任孤岛”。为此，业界提出了交叉认证的解决方案，即通过已被PKI用户信任的CA机构(Issuer CA，以下称为签发CA)为其他不被信任的CA机构签发证书的方式，使得信任该CA的证书依赖方能够与更多的证书持有者进行安全通信。通过交叉认证为其他CA机构(Subject CA，以下称为主体CA)签发的证书，称之为交叉证书。这样，对于已被信任的CA可以通过交叉认证的方式扩展PKI用户对其他不被信任的CA的信任。
然而，近年来发生的多起安全事件及现有的研究成果表明，一方面CA系统可能会遭受各种网络攻击，CA机构可能因行为不当、错误操作或私钥被盗等原因，为任何用户甚至是攻击者颁发证书，导致虚假证书；另一方面，持有交叉证书的主体CA在获得交叉证书之后，有可能扩大自己服务的订户范围，为更多原先签发CA没有预计的订户颁发证书，这将导致交叉证书信任传递的失控。
已有的证书透明化(Certificate Transparency，CT)方案在解决CA机构证书颁发行为的公开可审计上已经被证实起到了很好的效果。在证书透明化方案中，借助第三方日志服务器的Append-only(即只允许追加内容，不可修改)特性，CA机构和证书订户将自己所颁发或拥有的证书提交到日志服务器上。证书依赖方在验证证书时，需要额外地检查该证书是否已经被记录在日志服务器上；若未出现在日志服务器中，则依赖方拒绝接受该证书。此外，任何利益相关方均可通过公开的接口访问日志服务器，一旦日志服务器中出现虚假证书，该虚假证书的利益相关方就能观察到该证书，并采取相关措施避免由该虚假证书导致的潜在安全风险。
如何合理地借助现有的证书透明化技术对交叉证书的信任传递进行细粒度控制，这将对PKI体系的整体安全性产生显著影响，但是目前还没有相关技术方案。
发明内容
本发明的目的是提供一种利用证书透明化技术控制交叉证书信任传递的方法及系统，它是一种对主体CA所签发证书的信任增强方案，使得签发CA可以对主体CA的证书签发行为进行实时监控，极大地提升了安全性，避免交叉证书的信任传递失控。
本发明的目的是通过以下技术方案实现的：
(与权利要求相对应，暂略)
由上述本发明提供的技术方案可以看出，一方面，主体CA签发的证书不仅需要满足证书依赖方原有的认证要求，还需满足本发明所阐述的增强的认证方式；另一方面，签发CA能够对主体CA所签发的所有证书进行集中化监视，进而对交叉证书的信任传递进行控制，避免了交叉证书信任传递失控所带来的风险，达到了细粒度控制的目的；此外，签发交叉证书的CA除了需要额外控制一个必选日志服务器外，其他原来所具有的功能和现有支持证书透明化的PKI体系完全一致，CA机构无需在操作和商业模式上做过多的变化，这有利于本发明提出的方案的部署。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他附图。
图1为本发明实施例提供的一种利用证书透明化技术控制交叉证书信任传递的方法的流程图；
图2为本发明实施例提供的一种利用证书透明化技术控制交叉证书信任传递的方法的原理结构图；
图3为本发明实施例提供的一种证书签发阶段的流程图；
图4为本发明实施例提供的一种主体CA签发终端实体证书的流程图；
图5为本发明实施例提供的一种常规CA签发终端实体证书的流程图；
图6为本发明实施例提供的一种X.509证书标准格式与本发明证书格式对比示意图；
图7为本发明实施例提供的一种证书验证阶段的流程图；
图8为本发明实施例提供的一种利用证书透明化技术控制交叉证书信任传递的系统的示意图。
具体实施方式
下面结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明的保护范围。
首先对本文中可能使用的术语进行如下说明：
术语“包括”、“包含”、“含有”、“具有”或其它类似语义的描述，应被解释为非排它性的包括。例如：包括某技术特征要素(如原料、组分、成分、载体、剂型、材料、尺寸、零件、部件、机构、装置、步骤、工序、方法、反应条件、加工条件、参数、算法、信号、数据、产品或制品等)，应被解释为不仅包括明确列出的某技术特征要素，还可以包括未明确列出的本领域公知的其它技术特征要素。
下面对本发明所提供的一种利用证书透明化技术控制交叉证书信任传递的方法进行详细描述。本发明实施例中未作详细描述的内容属于本领域专业技术人员公知的现有技术。本发明实施例中未注明具体条件者，按照本领域常规条件或制造商建议的条件进行。本发明实施例中所用试剂或仪器未注明生产厂商者，均为可以通过市售购买获得的常规产品。
如图1所示，为本发明实施例提供的一种利用证书透明化技术控制交叉证书信任传递的方法的流程图，其主要包括如下步骤：
1、证书签发阶段。
1)当签发CA收到某个CA发送的证书签名请求时，若请求签名的证书是交叉证书，则签发CA生成带有必选日志服务器扩展项的交叉证书发送至相关的CA，相关CA变为主体CA；其中，所述CA表示认证机构，所述必选日志服务器扩展项标识了如何获取与签发CA运行的必选日志服务器有关的信息。
2)当主体CA收到来自证书订户的证书签名请求时，下发终端实体证书至所述证书订户，所述证书订户存储的终端实体证书具有相应的SCT(Signed CertificateTimestamp，签名证书时间戳)列表，所述SCT列表嵌入在所述终端实体证书中后一并存储，或者SCT列表与所述终端实体证书分别存储；所述SCT列表至少包含了当前证书认证路径下交叉证书给出的必选日志服务器扩展项中记录的必选日志服务器审核后返回的SCT，所述SCT表示终端实体证书被记录在必选日志服务器中。
本发明实施例中，可以存在多级证书链(即允许存在多个处于不同PKI体系的中间CA)，上级的中间CA机构，相当于下级中间CA机构的签发CA。
本领域技术人员可以理解，终端实体证书处于证书链的最末端，终端实体证书直接包含了与证书订户有关的信息；中间证书，也可称为中间CA(中间证书颁发机构Intermediate certificate authority,Intermedia CA)证书，位于终端实体证书和根证书之间的证书，通常情况下，根CA机构出于安全性考虑，并不会直接签发终端实体证书，而是委派一个二级CA机构(即中间CA机构)去签发终端实体证书。特别地，中间CA机构的数量可以是一个或者多个，持有中间证书的中间CA还可以继续签发其他中间证书。
2、证书验证阶段。
1)证书依赖方收到来自证书订户的证书链后，通过迭代校验证书链中每张证书的签名，直至根证书，如果依赖方的可信根存储区中存在该根证书，则继续检查该证书链。进一步，为了对终端实体证书的身份进行校验，自顶向下对证书链中的中间证书进行校验。2)依次检查当前证书链中各中间证书是否存在本发明新增的必选日志服务器扩展项；若存在，则记录必选日志服务器扩展项所给出的各必选日志服务器。之后，对终端实体证书的SCT合规性进行额外检查，检查终端实体证书对应的SCT列表中是否存在以上记录的各必选日志服务器返回的SCT，若均存在，则进一步对终端实体证书执行常规证书校验；若SCT列表中缺少任意一个必选日志服务器所返回的SCT，则拒绝接受证书。
本发明实施例上述两个阶段中，主要涉及两类日志服务器，一类称为常规日志服务器(即当前CT方案中的日志服务器)，另一类为本发明引入的必选日志服务器。证书签发阶段终端实体证书所对应的SCT列表中必须具有必选日志服务器所返回的SCT；对SCT列表是否包含常规日志服务器返回的SCT不做限定，即根据CA机构或证书订户的实际情况，对应的SCT列表可以包含常规日志服务器返回的SCT，或者也可以不包含。在证书验证阶段，对于证书依赖方来说，对于某一终端实体证书的SCT列表，若无法同时满足CT策略和本发明所提的要求时，即SCT列表中必选日志服务器或常规日志服务器返回的SCT不合规时，则终端实体证书不会被证书依赖方所信任。
以Apple客户端CT策略为例，对于证书生效时间在2021年4月21日后的证书，Apple根据证书的有效期范围对SCT(以嵌入证书方式获取的)的数量提出了不同的要求：证书有效期在180天内的证书，至少需要2个来自不同常规日志服务器返回的SCT；证书有效期在181天至398天内的证书，至少需要3个来自不同常规日志服务器返回的SCT。当然此处仅为示例，现有的CT方案下，对于不同的证书依赖方有着各自的CT策略，因此，可按照现有方案来验证SCT列表的其余SCT是否满足证书依赖方当前的CT策略。
本发明实施例上述方案与现有的交叉认证方案相比，主要获取如下有益效果：
1、显著增强当前PKI体系的安全性。在本发明实施例提出的方案中，主体CA签发的证书不仅要满足原有的CT策略(即证书透明化策略，主体CA签发的证书需要根据证书持有者的要求，将相应的证书提交给符合证书依赖方访问策略的一个或多个常规日志服务器)，而且需要满足本发明所提出的信任增强方案(即终端实体证书必须提交到当前证书认证路径中交叉证书所给出的必选日志服务器中进行额外审核)。通过此步骤，使得证书依赖方能在原有的认证基础上，再加上一层针对主体CA所签发证书的增强的认证方式。
2、相比于传统的PKI系统，本发明使得签发CA对交叉证书的管理更加集中可靠。在传统的PKI体系中，主体CA由于具有任意签发证书的权限，这很容易导致主体CA证书签发行为的失控。而本发明实施例提出的方案中，签发CA通过控制一个专用的必选日志服务器，使得签发CA对主体CA所签发的所有证书进行集中化监视，进而对交叉证书的信任传递进行控制，避免了交叉证书信任传递失控所带来的风险，达到了细粒度控制的目的。
3、与现有的PKI体系是后向兼容的。在本发明提出的方案中，签发交叉证书的签发CA除了需要额外控制一个必选日志服务器外，其他原来所具有的功能和现有的PKI体系完全一致，CA无需在操作和商业模式上做过多的变化。这有利于本发明提出的方案的部署。
为了更加清晰地展现出本发明所提供的技术方案及所产生的技术效果，下面以具体实施例对本发明实施例所提供的一种利用证书透明化技术控制交叉证书信任传递的方法进行详细描述。
如图2所示，为本发明实施例提供的方法原理结构图。首先，针对本发明实施例提供的方法中所涉及的参与方以及功能与要求进行说明。
1、所涉及的参与方主要包括：证书依赖方(Relying Party)、证书订户(Subscriber)、主体CA(SubjectCA)、签发CA(Issuer CA)、必选日志服务器(Mandatory LogServer)、常规日志服务器(Regular Log Server)。对于交叉证书，国际标准RFC 5280的定义为：证书签发者和证书主体属于不同实体的CA证书，描述了两个CA之间的信任关系。在本发明中，沿用此定义。
箭头上各参数符号说明如下：TrustAnchor表示证书依赖方的信任锚，Manage表示Issuer CA运行必选日志服务器，Cross-signing表示Issuer CA对Subject CA进行交叉签名，Pre-certificate表示预证书，SCT1～n表示可能存在一个或多个由常规日志服务器所返回的SCT，SCTn+1表示必选日志服务器所返回的SCT。
示例性的，证书依赖方可以以浏览器的形式实现，证书订户可以以Web网站服务器的形式实现，证书依赖方与证书订户位于不同PKI体系中。
2、功能设定和要求如下：
1)现有PKI体系下各参与方职责不变，现有的证书验证方式依然保留。
2)对于签发CA，其运行着一个公开可审计的必选日志服务器，且能对必选日志服务器制定相应的审核规则，即指定必选日志服务器对被提交的证书做哪些额外的审核。
3)主体CA与签发CA的根证书分别位于不同的根存储区，即本发明仅讨论跨域互联的情况。
4)主体CA假定为不可信的，即主体CA可能不按照与签发CA、证书订户协商好的安全策略提供服务，如主体CA签发的证书未及时提交至签发CA所运行的必选日志服务器中等情况。
5)证书依赖方支持CT方案。
然后，介绍本发明改进后的证书签发阶段与证书验证阶段的流程。
1、证书签发阶段。
证书签发阶段证书订户作为目标实体，如图3、图4与图5所示，提供了证书签发阶段的主要流程，主要包括如下步骤：
步骤1)当根证书可信的签发CA收到某个CA发送的证书签名请求时，判断请求签名的证书是否为中间证书；若是，则转入步骤2)；否则，转入步骤5)。
步骤2)判断中间证书的类别是否为交叉证书，若是，则转入步骤3)；否则，转入步骤6)。
步骤3)如图3中间部分所示，签发CA签发交叉证书。
本发明实施例中，当前证书体系下已有的证书扩展项不变，新增一个证书扩展项(必选日志服务器扩展项)专门用于发布如何获取与签发该交叉证书的签发CA所控制和管理的必选日志服务器有关的信息；对于签发CA来说，当其为某个不受当前证书依赖方所信任的CA机构签发交叉证书时，将会对该CA机构签发的证书做出要求，主体CA之后所签发的所有终端实体证书必须提交到由签发CA所运行的必选日志服务器中进行审核。
如图6所示，展示了X.509证书标准格式与本发明证书格式对比，左侧为X.509证书标准格式，右侧为本发明证书格式，额外增加了一个必选日志服务器扩展项。
本发明实施例中，与签发CA运行的必选日志服务器有关的信息所涉及的信息数目以及信息的具体内容可以由签发CA根据实际情况或者经验进行设定，例如，必选日志服务器的地址、唯一标识、公钥和审核标准等信息。
本发明实施例中，对于必选日志服务器，为了将记录到日志服务器中的每张证书与其签发者联系起来，必选日志服务器需要维护一个它所允许接受的根CA机构列表。
基于此，本步骤的优选实施方式如下：签发CA对CA机构的主体身份进行审核(具体可参照常规方式实现)，审核通过后再生成带有必选日志服务器扩展项的交叉证书发送至相关的CA，相关CA收到所述带有必选日志服务器扩展项的交叉证书后变为主体CA。
步骤4)当主体CA收到来自证书订户的证书签名请求时，下发终端实体证书至所述证书订户，所述证书订户存储的终端实体证书中具有相应的SCT列表，所述SCT列表嵌入在所述终端实体证书中后一并存储，或者SCT列表与所述终端实体证书分别存储；所述SCT列表至少包含了当前证书认证路径下交叉证书必选日志服务器扩展项中对应的必选日志服务器审核后返回的SCT。
本步骤中包含两种实现方式，可以通过任一种方式来实现。
方式一、所述主体CA对所述证书订户进行身份审核(具体可参照常规方式实现)，审核通过后生成相应的预证书；之后，将预证书分别发送至当前证书认证路径下交叉证书必选日志服务器扩展项中所对应的必选日志服务器；各必选日志服务器收到所述预证书后进行审核，审核通过后返回相应的SCT；如果审核失败，则不记录该证书并且不返回相应的SCT；所述主体CA将收到的所有SCT整合形成SCT列表，生成带有SCT扩展的证书，并将SCT列表嵌入至带有SCT扩展的证书中形成终端实体证书发送至所述证书订户，所述证书订户存储嵌入有SCT列表的终端实体证书。
本发明实施例中，预证书是应用在CT方案中的一种特殊类型的证书，它包括了终端实体证书所具有的全部信息，但是其不具有任何认证功能，其存在的唯一目的是使得SCT可直接嵌入在终端实体证书中，而不用作为单独的文件形式而存在。
方式二、所述主体CA对所述证书订户进行身份审核，审核通过后直接生成终端实体证书发送至所述证书订户；所述证书订户将终端实体证书发送给当前证书认证路径下交叉证书必选日志服务器扩展项所对应的必选日志服务器；各必选日志服务器收到终端实体证书后进行审核，审核通过后返回相应的SCT；所述证书订户将收到的所有SCT整合形成SCT列表并与终端实体证书分别存储。
该方式下，证书依赖方与证书订户在通信链接建立阶段，证书订户通过TLS扩展或OCSP扩展方式返回证书有关的SCT信息。
本发明实施例提供的上述两种方式中，证书都需要提交给签发CA运行的必选日志服务器，由必选日志服务器进行审核，使得签发CA得以对交叉证书的信任传递加以细粒度控制，从而避免主体CA的失控。
可选的，为了满足证书依赖方CT策略，证书需要提交给满足证书依赖方CT策略的一个或多个常规日志服务器，所述一个或多个常规日志服务器收到证书后，记录到日志中，并返回相应的SCT，常规日志服务器返回的SCT与必选日志服务器返回的SCT将一同整合形成SCT列表。
需要说明的是，必选日志服务器对证书的审核标准由签发CA自定义实施，本发明不对该审核的具体内容做任何限制。
本发明实施例中，如果考虑将预证书或者终端实体证书发送至两类日志服务器，在发送阶段，对于发送至必选日志服务器，以及一个或多个常规日志服务器时的先后顺序不做限定，即可以同时发送给两类日志服务器，也可以一前一后分别发送。图4提供了方式一下的一种发送顺序的示例。
本发明实施例中，对于SCT获取方式不作限制，CA机构和证书订户均可向必选日志服务器或常规日志服务器请求证书的SCT信息。
本发明实施例中，进一步地，必选日志服务器与常规日志服务器使用了相同的存储结构，通过Merkle树的结构来记录由主体CA所签发的证书，保证每一个提交的证书都会被记录在日志中。此外，由于必选日志服务器具有仅可追加特性，确保了日志中的每一个条目都不可篡改或删除。当主体CA或证书订户想要验证证书是否被记录在了日志中时，日志会提供一条基于当前Merkle树根下验证路径，以证明其存在性。此外，对于必选日志服务器返回的SCT，其结构体与常规日志服务器返回的SCT结构保持一致，两者的区别仅在于主体CA将证书提交给日志服务器阶段，日志服务器是否对提交的证书进行了额外的特定检查。
步骤5)如图3右侧部分所示，如果签发CA判断请求签名的证书不为中间证书，表示请求签名的证书为终端实体证书，则签发CA按照常规签发方式进行证书的签发。
常规签发方式可以为：CA机构通过线上线下的方式审核订户是否为证书签名请求中公钥所对应的私钥持有者，即确保信息的真实性，审核通过后进行证书签发。
需要说明的是，证书订户可自行决定代表其身份信息的终端实体证书是否支持证书依赖方的CT访问策略，本发明不对证书订户或CA是否支持CT策略做任何限制。
本发明实施例中，当为了满足证书依赖方CT策略，而选择将证书提交给满足证书依赖方CT策略的一个或多个常规日志服务器时，既可由CA通过将预证书提交给日志服务器获取SCT(图3右侧部分给出了此情况的示例)，也可由证书订户自行提交得到SCT，本发明并不对SCT的获取方式做限制，需要注意的是，对于订户自行将证书提交给日志服务器的方式所获取的SCT并不嵌入在证书中。
步骤6)如图3左侧部分所示，如果请求签名的证书为中间证书，但类别不为交叉证书，则对于中间证书以及中间证书签发的终端实体证书均按照常规签发方式进行证书的签发。特别地，对于该中间证书签发终端实体证书的流程同步骤5)，图5提供了一种终端实体证书签发流程示例。
2、证书验证阶段。
证书验证阶段证书依赖方作为目标实体，如图5所示，提供了证书验证阶段的主要流程，主要包括如下步骤：
为便于解释说明，以下证书验证阶段所述SCT的获取均采用嵌入证书形式。
步骤1)证书依赖方收到来自证书订户的证书链后，证书依赖方通过迭代校验每张证书的签名，直至根证书，并判断证书依赖方的可信根存储区中是否存在该根证书；若是，则继续检查该证书链，转入步骤2)；否则，转入步骤7)。
步骤2)判断证书链中是否存在中间证书，若存在，则转入步骤3)；否则转入步骤5)。
步骤3)检查中间证书中是否存在必选日志服务器扩展项，若存在，则转入步骤4)；否则转入步骤5)。
步骤4)记录中间证书必选日志服务器扩展项中所给出的必选日志服务器；再对终端实体证书的SCT合规性进行额外检查，检查终端实体证书对应的SCT列表中是否存在相应必选日志服务器返回的SCT，若存在，转入步骤5)；否则若不存在，则转入步骤7)。
本发明实施例中，对于中间证书，需要检查证书扩展项中是否存在与签发CA控制的必选日志服务器有关的信息(即对必选日志服务器扩展项进行校验)，若存在则记录相应的URL地址(以HTTP获取方式为例)，以便下级终端实体证书校验；由于终端实体证书由主体CA所签发，因此，需要判断证书的SCT列表是否存在由以上所记录的必选日志服务器返回的SCT，列表中其余的SCT用于判断是否满足浏览器的CT策略(通过后续步骤5)实现)。
本发明实施例中，对于终端实体证书的SCT列表，校验终端实体证书的SCT列表中是否存在必选日志服务器返回的SCT，该步骤可通过校验当前SCT结构中的Log ID字段进行唯一识别。若不存在必选日志服务器返回的SCT，则表明当前证书的签发不被必选日志服务器审核通过，必选日志服务器拒绝接受该证书，进而导致证书依赖方拒绝接受证书；若证书中存在必选日志服务器返回的SCT，则继续执行步骤5)。
步骤5)通过设定方式对证书执行常规证书校验，校验通过后，转入步骤6)，若未通过校验，则转入步骤7)。
常规证书校验主要是校验证书是否处于有效期内，证书是否撤销、密钥用法是否符合设定要求等基本信息和部分扩展信息校验，或者，还可以包括：校验终端实体证书的SCT列表是否满足相应的CT策略，具体可通过常规方案实现，本发明不做赘述；图7所示的流程中，提供了包含CT策略校验的示例。
如图7所示，本步骤5)存在如下三种情况：a)当根证书的下级证书不为中间证书，则表示证书为终端实体证书，直接对终端实体证书执行常规证书校验。b)当中间证书不存在必选日志服务器扩展项时，对其下级终端实体证书执行常规证书校验。c)当终端实体证书通过前述步骤4)的检查后，直接执行常规证书校验。
由于不同浏览器有各自的CT策略且对SCT的数量存在不同的要求，因此对于给定的浏览器，需要校验证书的SCT列表是否满足相应的CT策略，从而决定是否接受证书，本发明不对具体的CT策略内容进行限定。
步骤6)接受证书。
步骤7)拒绝证书。
如之前所述，本发明其他实施例中，可以存在多级证书链(即允许存在多个处于不同PKI体系的中间CA)。为了便于理解，图2～图5、图7均以三级证书链为例(即根证书-中间证书-终端实体证书)进行介绍。
本发明另一实施例还提供一种利用证书透明化技术控制交叉证书信任传递的系统，其主要用于实现前述实施例提供的方法，如图8所示，该系统主要包括：证书签发模块与证书验证模块；其中，所述证书签发模块应用于证书签发，所述证书验证模块用于证书验证；证书签发与证书验证两个阶段的实施方式在之前的实施例中已经做了详细的说明，故不再赘述。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例可以通过软件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，上述实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将系统的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。
以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明披露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求书的保护范围为准。

Claims (9)

1.一种利用证书透明化技术控制交叉证书信任传递的方法，其特征在于，包括：
证书签发阶段：当签发CA收到某个CA发送的证书签名请求时，若请求签名的证书是交叉证书，则签发CA生成带有必选日志服务器扩展项的交叉证书发送至相关的CA，相关CA变为主体CA；当主体CA收到来自证书订户的证书签名请求时，下发终端实体证书至所述证书订户，所述证书订户存储的终端实体证书具有相应签名证书时间戳SCT列表，所述SCT列表嵌入在所述终端实体证书中后一并存储，或者SCT列表与所述终端实体证书分别存储；所述SCT列表至少包含了当前证书认证路径下交叉证书必选日志服务器扩展项中记录的必选日志服务器审核后返回的SCT，所述SCT表示终端实体证书被记录在必选日志服务器中；其中，所述CA表示认证机构，所述必选日志服务器扩展项标识了如何获取与签发CA中运行的必选日志服务器有关的信息；
证书验证阶段：证书依赖方收到来自证书订户的证书链后，自顶向下对证书链中的中间证书进行校验，依次检查当前证书链中各中间证书是否存在必选日志服务器扩展项；若存在，则记录必选日志服务器扩展项中所给出的必选日志服务器，并结合以上记录的必选日志服务器，对终端实体证书的SCT合规性进行额外检查，检查终端实体证书对应的SCT列表中是否存在相应必选日志服务器返回的SCT，若不存在，则证书依赖方拒绝接受证书。
2.根据权利要求1所述的一种利用证书透明化技术控制交叉证书信任传递的方法，其特征在于，所述证书签发阶段还包括：
如果签发CA判断请求签名的证书不为交叉证书，则签发CA按照常规签发方式进行证书的签发。
3.根据权利要求1所述的一种利用证书透明化技术控制交叉证书信任传递的方法，其特征在于，所述签发CA生成带有必选日志服务器扩展项的交叉证书发送至相关的CA，相关CA变为主体CA包括：
签发CA对相关的CA的主体身份进行审核，审核通过后再生成带有必选日志服务器扩展项的交叉证书发送至相关的CA，相关CA收到所述带有必选日志服务器扩展项的交叉证书后变为主体CA。
4.根据权利要求1所述的一种利用证书透明化技术控制交叉证书信任传递的方法，其特征在于，所述主体CA收到来自证书订户的证书签名请求时，下发终端实体证书至所述证书订户包括：
所述主体CA收到来自证书订户的证书签名请求时，先对所述证书订户身份进行审核，审核通过后再下发终端实体证书至所述证书订户。
5.根据权利要求1或4所述的一种利用证书透明化技术控制交叉证书信任传递的方法，其特征在于，所述证书订户存储的终端实体证书具有相应SCT列表，采用如下任一种方式实现：
方式一、所述主体CA对所述证书订户进行身份审核，审核通过后生成相应的预证书；之后，将预证书分别发送至当前证书认证路径下交叉证书必选日志服务器扩展项中对应的必选日志服务器；各必选日志服务器收到所述预证书后进行审核，审核通过后返回相应的SCT；如果审核失败，则不记录该证书并且不返回相应的SCT；所述主体CA将收到的所有SCT整合形成SCT列表，生成带有SCT扩展的证书，并将SCT列表嵌入至带有SCT扩展的证书中形成终端实体证书发送至所述证书订户，所述证书订户存储嵌入有SCT列表的终端实体证书；
方式二、所述主体CA对所述证书订户进行身份审核，审核通过后直接生成终端实体证书发送至所述证书订户；所述证书订户将终端实体证书发送给当前证书认证路径下交叉证书必选日志服务器扩展项中对应的必选日志服务器；各必选日志服务器收到终端实体证书后进行审核，审核通过后返回相应的SCT；所述证书订户将收到的所有SCT整合形成SCT列表并与终端实体证书分别存储。
6.根据权利要求1所述的一种利用证书透明化技术控制交叉证书信任传递的方法，其特征在于，所述证书验证阶段还包括：
如果证书依赖方的可信根存储区中不存在该证书链的根证书，则拒绝接受该证书；
如果证书依赖方的可信根存储区中存在该证书链的根证书，根证书的下级证书不为中间证书，或者根证书的下级证书为中间证书且中间证书中不存在必选日志服务器扩展项，或者中间证书存在必选日志服务器扩展项，且相关终端实体证书通过额外的SCT合规性检查时，进行常规证书校验。
7.根据权利要求6所述的一种利用证书透明化技术控制交叉证书信任传递的方法，其特征在于，所述常规证书校验包括：证书基本信息和扩展信息校验，或者，还包括：校验相关终端实体证书的SCT列表是否满足相应的证书透明化CT策略。
8.根据权利要求1所述的一种利用证书透明化技术控制交叉证书信任传递的方法，其特征在于，终端实体证书对应的SCT列表中还包括：提交给满足证书依赖方证书透明化CT策略的一个或多个常规日志服务器后，由所述一个或多个常规日志服务器返回的SCT；
所述必选日志服务器与常规日志服务器使用了相同的存储结构，并且返回的SCT采用相同的结构，所述存储结构采用Merkle树的结构。
9.一种利用证书透明化技术控制交叉证书信任传递的系统，其特征在于，包括：证书签发模块与证书验证模块；
所述证书签发模块应用于证书签发，证书签发阶段：当签发CA收到某个CA发送的证书签名请求时，若请求签名的证书是交叉证书，则签发CA生成带有必选日志服务器扩展项的交叉证书发送至相关的CA，相关CA变为主体CA；当主体CA收到来自证书订户的证书签名请求时，下发终端实体证书至所述证书订户，所述证书订户存储的终端实体证书具有相应签名证书时间戳SCT列表，所述SCT列表嵌入在所述终端实体证书中后一并存储，或者SCT列表与所述终端实体证书分别存储；所述SCT列表至少包含了当前证书认证路径下交叉证书必选日志服务器扩展项中记录的必选日志服务器审核后返回的SCT，所述SCT表示终端实体证书被记录在必选日志服务器中；其中，所述CA表示认证机构，所述必选日志服务器扩展项标识了如何获取与签发CA中运行的必选日志服务器有关的信息；
所述证书验证模块应用于证书验证，证书验证阶段：证书依赖方收到来自证书订户的证书链后，自顶向下对证书链中的中间证书进行校验，依次检查当前证书链中各中间证书是否存在必选日志服务器扩展项；若存在，则记录必选日志服务器扩展项中所给出的必选日志服务器，并结合以上记录的必选日志服务器，对终端实体证书的SCT合规性进行额外检查，检查终端实体证书对应的SCT列表中是否存在相应必选日志服务器返回的SCT，若不存在，则证书依赖方拒绝接受证书。
CN202111347539.0A 2021-11-15 2021-11-15 利用证书透明化技术控制交叉证书信任传递的方法及系统 Active CN114070569B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111347539.0A CN114070569B (zh) 2021-11-15 2021-11-15 利用证书透明化技术控制交叉证书信任传递的方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111347539.0A CN114070569B (zh) 2021-11-15 2021-11-15 利用证书透明化技术控制交叉证书信任传递的方法及系统

Publications (2)

Publication Number Publication Date
CN114070569A CN114070569A (zh) 2022-02-18
CN114070569B true CN114070569B (zh) 2023-12-29

Family

ID=80271961

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111347539.0A Active CN114070569B (zh) 2021-11-15 2021-11-15 利用证书透明化技术控制交叉证书信任传递的方法及系统

Country Status (1)

Country Link
CN (1) CN114070569B (zh)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106972931A (zh) * 2017-02-22 2017-07-21 中国科学院数据与通信保护研究教育中心 一种pki中证书透明化的方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11720718B2 (en) * 2019-07-31 2023-08-08 Microsoft Technology Licensing, Llc Security certificate identity analysis

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106972931A (zh) * 2017-02-22 2017-07-21 中国科学院数据与通信保护研究教育中心 一种pki中证书透明化的方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
Exploring the Security Issues of Trusted CA Certificate Management;Yanduo Fu等;Springer;第384-399页 *
The Invisible Side of Certificate Transparency: Exploring the Reliability of Monitors in the Wild;Bingyu Li等;IEEE;第749-763页 *
X-FTPC: A Fine-Grained Trust Propagation Control Scheme for Cross-Certification Utilizing Certificate Transparency;Shushang Wen等;Springer;第123-137页 *

Also Published As

Publication number Publication date
CN114070569A (zh) 2022-02-18

Similar Documents

Publication Publication Date Title
US7689828B2 (en) System and method for implementing digital signature using one time private keys
JP5179471B2 (ja) データを安全に伝送するための装置および方法
EP1782213B1 (en) Secure messaging system with derived keys
US7308574B2 (en) Method and system for key certification
CN112818368A (zh) 一种基于区块链智能合约的数字证书认证方法
US20090240936A1 (en) System and method for storing client-side certificate credentials
US20050154889A1 (en) Method and system for a flexible lightweight public-key-based mechanism for the GSS protocol
US20050010780A1 (en) Method and apparatus for providing access to personal information
CN108830733A (zh) 一种信息处理方法、区块链集群及系统
WO2007100421A1 (en) Account linking with privacy keys
CN114338242B (zh) 一种基于区块链技术的跨域单点登录访问方法及系统
Muftic Bix certificates: Cryptographic tokens for anonymous transactions based on certificates public ledger
CN111881483A (zh) 基于区块链的资源账户绑定方法、装置、设备和介质
US20020143987A1 (en) Message management systems and method
Hsu et al. Intranet security framework based on short-lived certificates
CN111566647A (zh) 基于区块链的身份识别系统
CN113271207A (zh) 基于移动电子签名的托管密钥使用方法、系统、计算机设备及存储介质
Durán et al. An architecture for easy onboarding and key life-cycle management in blockchain applications
CN114070569B (zh) 利用证书透明化技术控制交叉证书信任传递的方法及系统
Kurbatov et al. Global Digital Identity and Public Key Infrastructure
US11310044B2 (en) Authenticate transactions of secured file in blockchain
Boeyen et al. Liberty trust models guidelines
Russell et al. Virtual certificates and synthetic certificates: new paradigms for improving public key validation
CN115567314B (zh) 一种基于硬件可信信任链的License安全代理方法和平台
CN114553575B (zh) 一种基于Token的跨链通信认证方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant