(19)国家知识产权局 (12)发明 专利申请 (10)申请公布号 (43)申请公布日 (21)申请 号 202210673509.7 (22)申请日 2022.06.13 (71)申请人 广州大学 地址 510006 广东省广州市大 学城外环西 路230号 (72)发明人 陈祺　李进　吴俊达　艾山　 叶顺良　 (74)专利代理 机构 广州高炬知识产权代理有限 公司 44376 专利代理师 孙明科 (51)Int.Cl. H04L 9/40(2022.01) H04L 9/32(2006.01) H04L 67/10(2022.01) (54)发明名称 一种适用于多条区块链的相互认证方法 (57)摘要 本发明涉及区块链 技术领域， 公开了一种适 用于多条区块链的相互认证方法， 包括以下步 骤： 初始BCerti注册流程， n条区块链所属机构中 的每一个在数字证书基础设施中为自己注册一 个证书， S2： BCerti生成， ES支持信任敏捷性， 这 意味着区块链所属机构可以选择他们的信任根 并使用扩展参数修改他们的信任决策， 每个区块 链所属机构i通过组合来自受信任CA的多个标准 证书来创建ES的证书BC erti。 本发明提出的多条 区块链之间的相互认证方法具有极低的复杂性， 并为CA引入了一个全新的角色， 支持具有类似验 证器功能的主动在线确认， 这提高了多区块链系 统在成本权衡、 可能的资源和激励方面的动态适 应性。 权利要求书3页 说明书6页 附图1页 CN 115277066 A 2022.11.01 CN 115277066 A 1.一种适用于多条区块链的相互认证方法， 其特 征在于： 包括以下步骤： S1： 初始BCer ti注册流程； n条区块链所属机构中的每一个在数字证书基础设施中为自己注册一个证书 (BCerti)； S2： BCerti生成； ES支持信任敏捷性， 这意味着区块链所属机构可以选择他们的信任根并使用扩展参数 修改他们的信任 决策； 每个区块链所属机构i通过组合来自受信任CA的多个标准证书来创 建ES的证书BCer ti； S3： BCerti注册请求； 在ES中， 各区块链所属机构积极参与监控彼此的操作， 注册请求消息背后的核心思想 是让区块链所属机构确指定可信实体CA1、 CA 2和证书链 表； S4： 证书链 表同步； 理想情况下， 同一个BCerti应该在所有证书链表中公开可见； 然而， 同步所有证书链表 可能效率低下， 会导致显著的时间延迟， 从而实用性不 强； 相反， 在ES中， 各证书子链表代表 各区块链所属机构， 负责在所有现有证书链表的至少法定人数中同步BCerti； 这确保了只 有一个BCerti是区块链所属机构i所注册的， 并且所有 区块链所属机构都维护着一致的证 书链表， 以防止假冒攻击； S5： 注册确认； 当大多数证书子链表同意将BCerti添加到其公共完整证书链表中时， 对应于区块链接 所属机构i的证书子链表会操作机构i的BCert i， 使其在下一次更新期间出现在其完整证书 链表中， 并注册接受确认消息； 然后， 证书子链表向CA2发送注册响应消息， 该消息用作向 CA2证明证书子链 表确实接受了区块链接所属机构i的证书的RegReq的证明； 此时， CA2起到验证者的角色来监控并确保每一个证书子链表确实使其它大多数证书 子链表同意在下一次更新时间接受BCerti； 另外， CA1还起到验证者的角色来监控CA2是否 正确监控各证书子链 表； S6： 使用BCer ti访问区块链所属机构中的客户端； 区块链所属机构i现在有一个由多个受信任实体签署的确认消息(Accept)， 并且在收 到Accept和BCer ti后， 客户端可以确保他们正在与区块链所属机构i建立TLS连接； S7： 确认更新和验证； 在证书子链表的RegResp到期之前， 或在证书子链表更新其状态之后， 区块链所属机构 必须获得一个新的证据， 证明其BCer ti确实记录在安全 存储在区块链中； S8： 完整证书链 表确认请求； 区块链所属机构之前在其BCerti中定义了信 任实体， 除非任何一个相同的实体受到威 胁， 否则区块链所属机构会通过 联系他们来更新完整证书链 表的证明； S9： 证明生成； 在每次证书子链表更新时， CA1和CA2下载证书子链表接受的所有请求， 对其进行处理 以维护证书子链表的本地副本， 并监控每个CA本地副本的根hash值是否与证书子链表发布 的内容相匹配； S10： TLS连接；权　利　要　求　书 1/3 页 2 CN 115277066 A 2区块链所属机构现在将证明消息与完整证书链表树根一起提供给TLS连接请求， 而不 是接受消 息， 客户端按照根据确认消 息来验证BCerti， 无论是接受消 息还是带有签名根的 证明消息， 具体地， 证明的正确性验证采用浏览器重新计算完证书链家的根的形式， 使用证 明中指定的中间hash值并与签名的根进行比较； S11： 证书管理； ES支持证书更新、 撤销和从私钥丢失或泄 露中恢复； S12： 更新BCer ti生成； 为了正确更新， 区块链所属机构必须满足在证书子链表中先前注册的BCerti中定义的 信任要求； S13： 证书链 表请求和同步； 为了更新BCer ti， 证书子链 表仅在区块链所属机构存在旧的BCer ti时才继续更新。 S14： 更新确认； 仅当所有现有证书链表的至少法定人数同意时， 证书子链表才会确认用新BCerti替换 旧BCerti。 2.根据权利要求1所述的适用于多条区块链的相互认证方法， 其特征在于： 所述步骤 S14中确保了所有区块链所属机构对区块链所属机构i的BCerti的看法保持一致， 在初始 BCerti注册和后续BCerti更新期间， CA1、 CA2和证书子链表的不当行为检测需相互检查， 因 此， 一次成功的攻击需要对它们三个都进行成功攻击， 因为单个未受攻击的实体会检测并 阻止攻击 。 3.根据权利要求1所述的适用于多条区块链的相互认证方法， 其特征在于： 所述步骤 S10中的信任要求包括区块链所属机构的新BCerti必须由旧BCerti中指定的CA列表中满足 CA数量要求的CA进行签名， 此外， 更新证书的指定实体必须在旧BCerti和新BCerti的CA列 表和证书链 表中； 否则， 更新过程会因冷 静期而延迟。 4.根据权利要求1所述的适用于多条区块链的相互认证方法， 其特征在于： 所述步骤S9 中如果所有步骤都成功， 则区块链所属机构会收到由两个CA验证的完整证书链表证明， 以 及由所有各实体 签名的根hash值， 从而 使自己对自己的行为负责。 5.根据权利要求1所述的适用于多条区块链的相互认证方法， 其特征在于： 所述步骤S6 中客户端 可以通过验证确认真实性， 这意味着确认已经由完整证书链表和CA1与CA2中的受 信任实体签名， 有效性以及正确性， 来验证接受消息的BCerti； 浏览器还对BCerti中的每个 X.509证书执行标准验证； 验证成功后， 客户端接受到区块链所属 机构i的TLS连接； 浏览器 可以存储由各受信任方 所确认根证书， 以供以后进行 可选检查。 6.根据权利要求1所述的适用于多条区块链的相互认证方法， 其特征在于： 所述步骤S3 中ES要求区块链所属 机构必须要联系CA1； CA1的主要职责是验证其各实体操作的正确性， 并充当区块链所属机构与证书链表和CA2之间的信使， 区块链所属机构还指定证书子链表 以确保BCert i在所有证书链表之间同步， CA2主要承担验证者的角色， 并确保各证书子链表 和证书链表相应地运行， 具体地， 需按照承诺将BCert i添加到其证书子链表中， 以验证完整 性。 7.根据权利要求1所述的适用于多条区块链的相互认证方法， 其特征在于： 所述在步骤 S2中， 每个CA都会检查区块链所属机构的身份以正确验证区块链； 下面考虑域任意一个区权　利　要　求　书 2/3 页 3 CN 115277066 A 3