CN116846682B - 通信信道建立方法、装置、设备及介质 - Google Patents

通信信道建立方法、装置、设备及介质 Download PDF

Info

Publication number
CN116846682B
CN116846682B CN202311096490.5A CN202311096490A CN116846682B CN 116846682 B CN116846682 B CN 116846682B CN 202311096490 A CN202311096490 A CN 202311096490A CN 116846682 B CN116846682 B CN 116846682B
Authority
CN
China
Prior art keywords
certificate
self
reverse proxy
proxy server
communication channel
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
CN202311096490.5A
Other languages
English (en)
Other versions
CN116846682A (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.)
Shandong Mass Institute Of Information Technology
Original Assignee
Shandong Mass Institute Of Information Technology
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 Shandong Mass Institute Of Information Technology filed Critical Shandong Mass Institute Of Information Technology
Priority to CN202311096490.5A priority Critical patent/CN116846682B/zh
Publication of CN116846682A publication Critical patent/CN116846682A/zh
Application granted granted Critical
Publication of CN116846682B publication Critical patent/CN116846682B/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
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2895—Intermediate processing functionally located close to the data provider application, e.g. reverse proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • 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/40—Network security protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请公开了通信信道建立方法、装置、设备及介质，应用于通信领域，包括：向反向代理服务器发送针对业务服务器的访问请求；获取所述反向代理服务器返回的自签名证书；所述自签名证书包括所述业务服务器的一级证书和/或所述反向代理服务器的二级证书；对所述自签名证书进行验证，该验证过程包括验证所述自签名证书是否在可信执行环境中生成；若所述自签名证书通过验证，则与所述反向代理服务器建立https连接，形成客户端与所述反向代理服务器之间的目标通信信道。能够解决对可信CA机构的依赖问题，并且能够避免中间人攻击，从而提升通信的安全性。

Description

通信信道建立方法、装置、设备及介质
技术领域
本申请涉及通信技术领域，特别涉及通信信道建立方法、装置、设备及介质。
背景技术
随着互联网应用的发展，基于反向代理服务器实现负载均衡的方式受到了各种大型网站的普遍运用。
目前，客户端和反向代理服务器之间的证书基本都是采用公有CA（即CertificateAuthority，证书授权）的证书体系，客户端需要先存有反向代理服务器公钥证书的根证书，然后利用根证书验证反向代理的证书，进而建立HTTPS（即Hypertext Transfer ProtocolSecure，超文本传输安全协议）链接。此种方案不仅需要可信的CA机构，同时客户端还需要保存相应CA证书。同时还容易因CA机构颁发证书失误，形成中间人攻击。
发明内容
有鉴于此，本申请的目的在于提供通信信道建立方法、装置、设备及介质，能够解决对可信CA机构的依赖问题，并且能够避免中间人攻击，从而提升通信的安全性。其具体方案如下：
第一方面，本申请公开了一种通信信道建立方法，应用于客户端，包括：
向反向代理服务器发送针对业务服务器的访问请求；
获取所述反向代理服务器返回的自签名证书；所述自签名证书包括所述业务服务器的一级证书和/或所述反向代理服务器的二级证书；
对所述自签名证书进行验证，该验证过程包括验证所述自签名证书是否在可信执行环境中生成；
若所述自签名证书通过验证，则与所述反向代理服务器建立https连接，形成客户端与所述反向代理服务器之间的目标通信信道。
可选的，验证所述自签名证书是否在可信执行环境中生成，包括：
将所述自签名证书中的远程证明数据发送至第三方可信验证中心进行验证，得到验证结果；所述远程证明数据为可信执行环境对应的证明数据；
基于所述验证结果判断所述自签名证书是否在所述可信执行环境中生成。
可选的，在所述将所述自签名证书中的远程证明数据发送至第三方可信验证中心进行验证之前，还包括：
获取所述远程证明数据中的公钥哈希以得到第一哈希；
获取所述自签名证书中的公钥信息，并对该公钥信息进行哈希计算以得到第二哈希；
比对所述第一哈希与所述第二哈希，若所述第一哈希与所述第二哈希一致，则触发所述将所述自签名证书中的远程证明数据发送至第三方可信验证中心进行验证的步骤。
可选的，所述基于所述验证结果判断所述自签名证书是否在所述可信执行环境中生成，包括：
基于所述验证结果确定生成所述自签名证书的信任中心是否运行在可信执行环境中；
若生成所述自签名证书的信任中心运行在可信执行环境中，则判定所述自签名证书在所述可信执行环境中生成。
可选的，若所述自签名证书包括所述业务服务器的一级证书，则获取所述远程证明数据中的公钥哈希以得到第一哈希，包括：
获取所述一级证书中远程证明数据的公钥哈希以得到第一哈希；该远程证明数据为所述业务服务器的可信执行环境对应的证明数据。
可选的，所述基于所述验证结果判断所述自签名证书是否在所述可信执行环境中生成，包括：
基于所述验证结果判断所述一级证书是否在所述业务服务器的可信执行环境中生成。
可选的，若所述自签名证书包括反向代理服务器的二级证书，则获取所述远程证明数据中的公钥哈希以得到第一哈希，包括：
获取所述二级证书中远程证明数据的公钥哈希以得到第一哈希；该远程证明数据为所述反向代理服务器的可信执行环境对应的证明数据。
可选的，所述基于所述验证结果判断所述自签名证书是否在所述可信执行环境中生成，包括：
基于该验证结果判断所述二级证书是否在所述反向代理服务器的可信执行环境中生成。
可选的，对所述自签名证书进行验证，还包括：
利用所述自签名证书的公钥验证所述自签名证书中的自签名信息是否为利用所述公钥对应的私钥生成的签名信息。
可选的，若所述自签名证书包括反向代理服务器的二级证书，所述对所述自签名证书进行验证，还包括：
利用所述二级证书中的多重签名信息验证所述二级证书是否由多个业务服务器的一级证书签名而形成。
可选的，所述对所述自签名证书进行验证，还包括：
获取信任中心的工作负载参考值；其中，信任中心在可信执行环境中创建；
将所述工作负载参考值与所述自签名证书中的工作负载值进行比对，若所述工作负载参考值与所述工作负载值一致，则通过工作负载验证；
其中，所述工作负载值为信任中心的初始程序对应的唯一标识。
可选的，若所述自签名证书包括所述业务服务器的一级证书，所述获取信任中心的工作负载参考值，包括：
获取一级信任中心的工作负载参考值；其中，所述一级信任中心为业务服务器的可信执行环境中创建的信任中心；
相应的，所述将所述工作负载参考值与所述自签名证书中的工作负载值进行比对，包括：
将所述工作负载参考值与所述一级证书中的工作负载值进行比对。
可选的，若所述自签名证书包括所述反向代理服务器的二级证书，所述获取信任中心的工作负载参考值，包括：
获取二级信任中心的工作负载参考值；其中，所述二级信任中心为反向代理服务器的可信执行环境中创建的信任中心；
相应的，所述将所述工作负载参考值与所述自签名证书中的工作负载值进行比对，包括：
将所述工作负载参考值与所述二级证书中的工作负载值进行比对。
可选的，所述获取信任中心的工作负载参考值，包括：
从指定中心获取信任中心的工作负载参考值；
或，与所述反向代理服务器协商，获取信任中心的工作负载参考值。
可选的，当所述自签名证书包括所述业务服务器的一级证书和所述反向代理服务器的二级证书，则获取所述反向代理服务器返回的自签名证书；对所述自签名证书进行验证；若所述自签名证书通过验证，则与所述反向代理服务器建立https连接，包括：
获取所述反向代理服务器返回的二级证书；
对所述二级证书进行验证，若所述二级证书通过验证，则与所述反向代理服务器建立https连接，以形成第一通信信道；
通过所述第一通信信道获取所述反向代理服务器返回的一级证书；
对所述一级证书进行验证，若所述一级证书通过验证，则与所述反向代理服务器建立https连接，以形成目标通信信道，所述目标通信信道的数据经由反向代理服务器透明传输至业务服务器。
可选的，所述通过所述第一通信信道获取所述反向代理服务器返回的一级证书之前，所述反向代理服务器对所述一级证书进行验证，并在一级证书通过验证时，则与所述业务服务器建立https连接。
第二方面，本申请公开了一种通信信道建立方法，应用于反向代理服务器，包括：
获取客户端发送的针对业务服务器的访问请求；
向所述客户端返回自签名证书，以便所述客户端对所述自签名证书进行验证，该验证过程包括验证所述自签名证书是否在可信执行环境中生成，并在所述自签名证书通过验证时，与所述反向代理服务器建立https连接，形成客户端与所述反向代理服务器之间的目标通信信道；
其中，所述自签名证书包括所述业务服务器的一级证书和/或所述反向代理服务器的二级证书。
第三方面，本申请公开了一种通信信道建立装置，应用于客户端，包括：
访问请求发送模块，用于向反向代理服务器发送针对业务服务器的访问请求；
签名证书获取模块，用于获取所述反向代理服务器返回的自签名证书；所述自签名证书包括所述业务服务器的一级证书和/或所述反向代理服务器的二级证书；
签名证书验证模块，用于对所述自签名证书进行验证，该验证过程包括验证所述自签名证书是否在可信执行环境中生成；
通信信道建立模块，用于若所述自签名证书验证模块确定所述自签名证书通过验证，则与所述反向代理服务器建立https连接，形成客户端与所述反向代理服务器之间的目标通信信道。
第四方面，本申请公开了一种电子设备，包括存储器和处理器，其中：
所述存储器，用于保存计算机程序；
所述处理器，用于执行所述计算机程序，以实现前述的通信信道建立方法。
第五方面，本申请公开了一种计算机可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述的通信信道建立方法。
可见，本申请的有益效果为：先向反向代理服务器发送针对业务服务器的访问请求，获取所述反向代理服务器返回的自签名证书，所述自签名证书包括所述业务服务器的一级证书和/或所述反向代理服务器的二级证书，之后对所述自签名证书进行验证，该验证过程包括验证所述自签名证书是否在可信执行环境中生成，若所述自签名证书通过验证，则与所述反向代理服务器建立https连接，形成客户端与所述反向代理服务器之间的目标通信信道。也即，本申请中，客户端对业务服务器的和/或反向代理服务器的自签名证书进行验证，验证自签名证书是否在可信执行环境中生成，并在自签名证书通过验证时，与所述反向代理服务器建立https连接，形成客户端与反向代理服务器之间的安全通信信道，这样，能够解决对可信CA机构的依赖问题，并且能够避免中间人攻击，从而提升通信的安全性。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本申请实施例公开的一种通信信道建立方法流程图；
图2为本申请实施例公开的一种一级证书示意图；
图3为本申请实施例公开的一种二级证书示意图；
图4为本申请实施例公开的一种通信系统示意图；
图5为本申请实施例公开的另一种的通信信道建立方法流程图；
图6为本申请实施例公开的一种通信信道建立装置结构示意图；
图7为本申请实施例公开的一种电子设备结构图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
随着互联网应用的发展，当一台Web服务器的性能无法满足项目需求后，就需要对服务器进行横向扩展，当多台分布式服务器集群后，Web系统的性能得到显著提升，也有效的提高了系统的安全性和可靠性，任何一台服务器因故障退出，都不影响系统的正常运行。基于反向代理搭建集群以进行负载均衡的方式也受到了各种大型网站的普遍运用，可以通过适当地增减服务器数量，提高网站扩展性并且解决大型网站的并发压力。Nginx是一种高性能的反向代理服务器，目前很多主流互联网公司都采用这种技术实现负载均衡。
目前，互联网上采用HTTPS技术的网站越来越多，很多网站采用反向代理的方式实现HTTPS，为众多内部网站提供加密服务。主流的做法是客户端到反向代理的流量(前端流量)使用HTTPS加密，反向代理到真实服务器的流量(后端流量)还是使用HTTP（即HyperText Transfer Protocol，超文本传输协议）。Nginx在充当反向代理时，代理服务器通常会终止HTTPS加密流量并将其转发到后端实例。HTTPS流量的加密、解密和身份验证发生在客户端和反向代理服务器之间。虽然客户端到反向代理的流量是加密的，但是反向代理到后端服务器的流量还是明文的。如果服务器内网有安全设备在拦截和分析流量，例如安全态势感知系统，或者配置错误，流量经过非授权设备，导致敏感信息暴露。客户端和反向代理服务器之间的证书基本都是采用公有CA的证书体系，客户端需要先存有反向代理服务器公钥证书的根证书，然后利用根证书验证反向代理的证书，进而建立Https链接。此种不仅需要可信的CA机构，同时客户端还需要保存相应CA证书。同时还容易因此CA机构颁发证书失误，形成中间人攻击。为此，本申请提供了通信信道建立方案，能够解决对可信CA机构的依赖问题，并且能够避免中间人攻击，从而提升通信的安全性。
参见图1所示，本申请实施例公开了一种通信信道建立方法，应用于客户端，包括：
步骤S11：向反向代理服务器发送针对业务服务器的访问请求。
可以理解的是，业务服务器中部署相关的业务程序，集群中可以存在多台业务服务器，反向代理服务器将客户端的访问流量转发至指定的业务服务器中。也即，客户端经过反向代理访问业务服务器。
步骤S12：获取所述反向代理服务器返回的自签名证书；所述自签名证书包括所述业务服务器的一级证书和/或所述反向代理服务器的二级证书。
在具体的实施方式中，可以包括多个一级信任中心和二级信任中心。二级信任中心运行在反向代理服务器的可信执行环境中（即机密计算环境中）。一级信任中心运行在后端业务服务器的可信执行环境中。每个一级信任中心均各自生成一个自签名证书用于https安全通信。一级信任中心可以产生与硬件绑定的自签名证书即一级证书。一级证书在一级信任中心的可信执行环境中产生，不需要外部公有CA进行签发，也不需要自签名的根证书对证书进行签发。证书在可信执行环境中产生，保证生成过程的安全，同时将公钥哈希嵌入到可信执行环境的远程证明数据中，将远程证明数据嵌入到证书的对象标识符中，形成一个相互嵌套，保证客户端可以通过远程证明信息来验证证书的合法性，进而基于自签名证书建立https信道。例如，参见图2所示，图2为本申请实施例提供的一种具体的一级证书示意图。二级信任中心生成一个自签名证书用于https安全通信，此证书还需要多个一级证书对应的私钥进行多重签名，此处的多重签名方案可以是门限签名，也可以采用环签名等，形成两级信任链。此证书称之为二级证书。二级证书与反向代理服务中的可信执行环境进行相互绑定，也不需要外部公有CA进行签发，也不需要自签名的根证书对证书进行签发。证书在可信执行环境中产生，保证生成过程的安全，同时将公钥哈希嵌入到可信执行环境的远程证明数据中，将远程证明数据嵌入到证书的对象标识符中，形成一个相互嵌套，保证客户端可以通过远程证明信息来验证证书的合法性，进而基于自签名证书建立https信道。例如，参见图3所示，图3为本申请实施例提供的一种具体的二级证书示意图。
其中，可信执行环境（Trusted Execution Environment，TEE），为通过软硬件方法在中央处理器中构建的一个安全区域，保证其内部加载的程序和数据在机密性和完整性上得到保护。可信的中央处理器一般是指可信执行控制单元已被预置集成的CPU计算芯片，无法后置，本申请实施例可以基于可行执行环境在可信执行环境中构造可信的自签名证书，将硬件可信执行环境作为硬件可信根，将证书与硬件环境强绑定，剔除了公有CA的影响。认证者需要在TLS连接阶段向挑战者提供必要的证据，以便挑战者能够证明认证者正在可信执行环境中运行。
步骤S13：对所述自签名证书进行验证，该验证过程包括验证所述自签名证书是否在可信执行环境中生成。
在具体的实施方式中，可以将所述自签名证书中的远程证明数据发送至第三方可信验证中心进行验证，得到验证结果；所述远程证明数据为可信执行环境对应的证明数据；基于所述验证结果判断所述自签名证书是否在所述可信执行环境中生成。其中，可以基于所述验证结果确定生成所述自签名证书的信任中心是否运行在可信执行环境中；若生成所述自签名证书的信任中心运行在可信执行环境中，则判定所述自签名证书在所述可信执行环境中生成。
并且，在所述将所述自签名证书中的远程证明数据发送至第三方可信验证中心进行验证之前，还包括：获取所述远程证明数据中的公钥哈希以得到第一哈希；获取所述自签名证书中的公钥信息，并对该公钥信息进行哈希计算以得到第二哈希；比对所述第一哈希与所述第二哈希，若所述第一哈希与所述第二哈希一致，则触发所述将所述自签名证书中的远程证明数据发送至第三方可信验证中心进行验证的步骤。
进一步的，在具体的实施方式中，若所述自签名证书包括所述业务服务器的一级证书，则获取所述远程证明数据中的公钥哈希以得到第一哈希，包括：获取所述一级证书中远程证明数据的公钥哈希以得到第一哈希；该远程证明数据为所述业务服务器的可信执行环境对应的证明数据。相应的，可以基于所述验证结果判断所述一级证书是否在所述业务服务器的可信执行环境中生成。若所述自签名证书包括反向代理服务器的二级证书，则获取所述远程证明数据中的公钥哈希以得到第一哈希，包括：获取所述二级证书中远程证明数据的公钥哈希以得到第一哈希；该远程证明数据为所述反向代理服务器的可信执行环境对应的证明数据。相应的，可以基于该验证结果判断所述二级证书是否在所述反向代理服务器的可信执行环境中生成。
另外，本申请实施例可以利用所述自签名证书的公钥验证所述自签名证书中的自签名信息是否为利用所述公钥对应的私钥生成的签名信息。
进一步的，若所述自签名证书包括反向代理服务器的二级证书，所述对所述自签名证书进行验证，还包括：利用所述二级证书中的多重签名信息验证所述二级证书是否由多个业务服务器的一级证书签名而形成。
另外，在一种实施方式中，可以获取信任中心的工作负载参考值；其中，信任中心在可信执行环境中创建；将所述工作负载参考值与所述自签名证书中的工作负载值进行比对，若所述工作负载参考值与所述工作负载值一致，则通过工作负载验证；其中，所述工作负载值为信任中心的初始程序对应的唯一标识。比如，初始程序的哈希值。
其中，若所述自签名证书包括所述业务服务器的一级证书，所述获取信任中心的工作负载参考值，包括：获取一级信任中心的工作负载参考值；其中，所述一级信任中心为业务服务器的可信执行环境中创建的信任中心；相应的，将所述工作负载参考值与所述一级证书中的工作负载值进行比对。若所述自签名证书包括所述反向代理服务器的二级证书，所述获取信任中心的工作负载参考值，包括：获取二级信任中心的工作负载参考值；其中，所述二级信任中心为反向代理服务器的可信执行环境中创建的信任中心；相应的，可以将所述工作负载参考值与所述二级证书中的工作负载值进行比对。
进一步的，可以从指定中心获取信任中心的工作负载参考值；或，与所述反向代理服务器协商，获取信任中心的工作负载参考值。当然，工作负载参考值也可以为公开值，其中，指定中心可以为第三方信任中心。
步骤S14：若所述自签名证书通过验证，则与所述反向代理服务器建立https连接，形成客户端与所述反向代理服务器之间的目标通信信道。
在一种实施方式中，可以获取所述反向代理服务器返回的二级证书；对所述二级证书进行验证，若所述二级证书通过验证，则与所述反向代理服务器建立https连接，以形成第一通信信道；通过所述第一通信信道获取所述反向代理服务器返回的一级证书；对所述一级证书进行验证，若所述一级证书通过验证，则与所述反向代理服务器建立https连接，以形成目标通信信道，所述目标通信信道的数据经由反向代理服务器透明传输至业务服务器。其中，所述通过所述第一通信信道获取所述反向代理服务器返回的一级证书之前，所述反向代理服务器对所述一级证书进行验证，并在一级证书通过验证时，则与所述业务服务器建立https连接。
需要指出的是，在具体的实施方式中，可以采用多种通信链路建立方式，安全等级由弱到强。等级1：客户端和反向代理之间http通信，反向代理和业务服务器之间http通信。等级2：客户端和反向代理之间http通信，反向代理和业务服务器之间https通信。等级3：客户端和反向代理之间https通信，反向代理和业务服务器之间http通信。等级4：客户端和反向代理之间https通信，反向代理和业务服务器之间https通信。等级4为最安全的通信方式。通信等级由全部业务服务器根据业务的安全等级进行设置。全部业务服务器协商相同的客户端和反向代理之间的通信方式，比如，均采用相同http通信，或者https通信。每个业务服务器和反向代理服务器之间的通信方式由每个业务服务器根据安全等级各自设定。例如，某个业务服务器与反向代理服务器之间采用http方式通信，而另一个业务服务器与反向代理服务器之间采用https方式通信。例如，参见图4所示，图4为本申请实施例公开的一种具体的通信系统示意图。
并且，在具体的实施方式中，客户端验证自签名证书的方式可以包括：弱验证模式、中等验证模式、强验证模式。弱验证模式：客户端只验证业务服务器的一级证书或者反向代理服务器的二级证书。中等验证模式：客户端验证业务服务器的一级证书及反向代理服务器的二级证书。强验证模式：客户端验证业务服务器的一级证书及反向代理服务器的二级证书，一级信任中心和二级信任中心工作负载的可靠性。这样，采用基于硬件产生的自签名证书建立https连接。那么客户端的验证方式就不在是经过CA根证书验证https证书的方式。其中，
弱验证模式：客户端只验证业务服务器的一级证书或者反向代理服务器的二级证书。首先客户端验证在对象标识符quote（即远程证明数据）中确实存在与证书相同的公钥hash值，然后将quote发送到第三方可信验证中心进行验证，返回验证结果。客户端根据验证结果判断一级信任中心或者二级信任中心是否真实运行在可信执行环境中，进而判断一级证书或者二级证书是否是在一级信任中心或者二级信任中心中生成。下一步，客户端利用一级证书的自签名信息去验证证书是否用公钥对应的私钥形成合法自签名。或者，客户端利用二级证书的自签名信息去验证证书是否用公钥对应的私钥形成合法自签名，并利用多重签名信息去验证二级证书是否由多个一级证书签名形成的。从而判断一级证书或者二级证书是否合法有效。此过程只验证一级证书或者二级证书。
中等验证模式：客户端验证业务服务器的一级证书及反向代理服务器的二级证书。此步骤采用弱验证中的验证方式，验证一级证书和二级证书。
强验证模式：客户端验证业务服务器的一级证书及反向代理服务器的二级证书，以及一级信任中心和二级信任中心工作负载的可靠性。采用中等验证中的验证方式，验证一级证书和二级证书。客户端根据一级信任中心工作负载的参考值验证其与一级证书中quote中的工作负载值是否一致，保证运行在一级信任中心中的工作负载值未被篡改，且无恶意代码。客户端根据二级信任中心工作负载的参考值验证其与二级证书中quote中的工作负载值是否一致，保证运行在二级信任中心中的工作负载未被篡改，且无恶意代码。工作负载参考值可以是公开的，也可以存在某些信任中心，也可以客户端预先与业务服务器或反向代理服务器协商获得。
下面，以安全通信的安全等级4、验证模式为强验证方式为例，说明整个系统的工作过程。
首先，业务服务器在可信执行环境上创建一级信任中心，并在一级信任中心中生成一级证书。业务服务器部署相关业务程序在业务服务器上运行。反向代理服务器在可信执行环境上创建二级信任中心，并在二级信任中心中生成自签名证书，并将证书发送给所有一级信任中心，一级信任中心协议进行多重签名，形成二级证书。反向代理服务器启动代理服务。
客户端访问某个业务服务器，首先访问请求发送到反向代理服务器上，获取到反向代理服务器的二级证书。首先客户端验证在二级证书的对象标识符quote中确实存在与证书相同的公钥hash值，然后将quote发送到验证中心进行验证，返回验证结果。客户端根据验证结果判断二级信任中心是否真实运行在可信执行环境中，进而判断二级证书是否是在二级信任中心中生成。客户端利用二级证书的自签名信息去验证证书是否用公钥对应的私钥形成的合法自签名。客户端根据二级信任中心工作负载的参考值验证二级证书中quote中的工作负载值是否一致，保证运行在二级信任中心中的工作负载未被篡改，且无恶意代码。客户端与反向代理服务器建立https连接，称为第一安全通信信道。
反向代理服务器转发客户端的请求到某一个业务服务器上，反向代理服务器获取相应的一级证书。首先二级信任中心验证在一级证书的对象标识符quote中确实存在与证书相同的公钥hash值，然后将quote发送到验证中心进行验证，返回验证结果。二级信任中心根据验证结果判断一级信任中心是否真实运行在可信执行环境中，进而判断一级证书是否是在一级信任中心中生成。二级信任中心利用一级证书的自签名信息去验证证书是否用公钥对应的私钥形成的合法自签名。二级信息中心根据一级信任中心工作负载的参考值验证一级证书中quote中的工作负载值是否一致，保证运行在一级信任中心中的工作负载未被篡改，且无恶意代码。反向代理服务器该业务服务器建立https连接，称为第二安全通信信道。
反向代理服务器将一级证书通过第一安全通信信道发送到客户端。客户端利用多重签名信息去验证二级证书是否由多个一级证书签名形成的。进一步判断二级证书是否合法。客户端验证在一级证书的对象标识符quote中确实存在与证书相同的公钥hash值，然后将quote发送到验证中心进行验证，返回验证结果。客户端根据验证结果判断一级信任中心是否真实运行在可信执行环境中，进而判断一级证书是否是在一级信任中心中生成。客户端利用一级证书的自签名信息去验证证书是否用公钥对应的私钥形成的合法自签名。客户端根据一级信任中心工作负载的参考值验证一级证书中quote中的工作负载值是否一致，保证运行在一级信任中心中的工作负载未被篡改，且无恶意代码。客户端与反向代理服务器建立https连接，称为第三安全通信信道。第三安全通信信道的数据经由反向代理服务器透明传输至业务服务器，第三安全通信信道即为目标通信信道，数据直接在业务服务器解密。此时，客户端可以安全的与某个业务服务器进行通信，发送相关数据。需要指出的是，透明传输即发送方发送的数据，不管数据传输过程是如何实现的，接收方将收到与发送方发送的数据一致的数据，若未建立第三安全通信信道，而采用第一安全通信信道以及第二安全通信信道进行数据传输，反向代理服务器需要对数据进行解密后再加密传输至业务服务器，建立第三安全通信信道能够避免反向代理服务器的加解密步骤，从而降低通信复杂度。
这样，采用了新的证书结构进行大规模业务服务器访问时的安全信道建立。一级证书位于一级信任中心，二级证书位于二级信任中心，同时二级证书的有效性不仅由自身的可信执行环境保证，同时还由业务服务区的多重签名来保证有效性。将安全信道进行等级划分，不同安全等级具有不同的保护强度。客户端实行不同的验证等级，不同的验证等级得到不同的信任强度。证书的有效性和真实性由硬件可信执行环境保证，不需要CA证明。不同的业务服务器可以采用不同的通信方式与反向代理服务器建立连接，充分体现自适应。
可见，本申请实施例先向反向代理服务器发送针对业务服务器的访问请求，获取所述反向代理服务器返回的自签名证书，所述自签名证书包括所述业务服务器的一级证书和/或所述反向代理服务器的二级证书，之后对所述自签名证书进行验证，该验证过程包括验证所述自签名证书是否在可信执行环境中生成，若所述自签名证书通过验证，则与所述反向代理服务器建立https连接，形成客户端与所述反向代理服务器之间的目标通信信道。也即，本申请中，客户端对业务服务器的和/或反向代理服务器的自签名证书进行验证，验证自签名证书是否在可信执行环境中生成，并在自签名证书通过验证时，与所述反向代理服务器建立https连接，形成客户端与反向代理服务器之间的安全通信信道，这样，能够解决对可信CA机构的依赖问题，并且能够避免中间人攻击，从而提升通信的安全性。
参见图5所示，本申请实施例公开了一种通信信道建立方法，应用于反向代理服务器，包括：
步骤S21：获取客户端发送的针对业务服务器的访问请求。
步骤S22：向所述客户端返回自签名证书，以便所述客户端对所述自签名证书进行验证，该验证过程包括验证所述自签名证书是否在可信执行环境中生成，并在所述自签名证书通过验证时，与所述反向代理服务器建立https连接，形成客户端与所述反向代理服务器之间的目标通信信道；
其中，所述自签名证书包括所述业务服务器的一级证书和/或所述反向代理服务器的二级证书。
可见，本申请实施例获取客户端发送的针对业务服务器的访问请求；向所述客户端返回自签名证书，以便所述客户端对所述自签名证书进行验证，该验证过程包括验证所述自签名证书是否在可信执行环境中生成，并在所述自签名证书通过验证时，与所述反向代理服务器建立https连接，形成客户端与所述反向代理服务器之间的目标通信信道；其中，所述自签名证书包括所述业务服务器的一级证书和/或所述反向代理服务器的二级证书。也即，本申请中，客户端对业务服务器的和/或反向代理服务器的自签名证书进行验证，验证自签名证书是否在可信执行环境中生成，并在自签名证书通过验证时，与所述反向代理服务器建立https连接，形成客户端与反向代理服务器之间的安全通信信道，这样，能够解决对可信CA机构的依赖问题，并且能够避免中间人攻击，从而提升通信的安全性。
参见图6所示，本申请实施例公开了一种通信信道建立装置，应用于客户端，包括：
访问请求发送模块11，用于向反向代理服务器发送针对业务服务器的访问请求；
签名证书获取模块12，用于获取所述反向代理服务器返回的自签名证书；所述自签名证书包括所述业务服务器的一级证书和/或所述反向代理服务器的二级证书；
签名证书验证模块13，用于对所述自签名证书进行验证，该验证过程包括验证所述自签名证书是否在可信执行环境中生成；
通信信道建立模块14，用于若所述自签名证书验证模块确定所述自签名证书通过验证，则与所述反向代理服务器建立https连接，形成客户端与所述反向代理服务器之间的目标通信信道。
可见，本申请实施例先向反向代理服务器发送针对业务服务器的访问请求，获取所述反向代理服务器返回的自签名证书，所述自签名证书包括所述业务服务器的一级证书和/或所述反向代理服务器的二级证书，之后对所述自签名证书进行验证，该验证过程包括验证所述自签名证书是否在可信执行环境中生成，若所述自签名证书通过验证，则与所述反向代理服务器建立https连接，形成客户端与所述反向代理服务器之间的目标通信信道。也即，本申请中，客户端对业务服务器的和/或反向代理服务器的自签名证书进行验证，验证自签名证书是否在可信执行环境中生成，并在自签名证书通过验证时，与所述反向代理服务器建立https连接，形成客户端与反向代理服务器之间的安全通信信道，这样，能够解决对可信CA机构的依赖问题，并且能够避免中间人攻击，从而提升通信的安全性。
其中，签名证书验证模块13，具体包括：
验证结果获取子模块，用于将所述自签名证书中的远程证明数据发送至第三方可信验证中心进行验证，得到验证结果；所述远程证明数据为可信执行环境对应的证明数据；
签名证书验证子模块，用于基于所述验证结果判断所述自签名证书是否在所述可信执行环境中生成。
并且，签名证书验证模块13，还包括：
第一哈希获取子模块，用于获取所述远程证明数据中的公钥哈希以得到第一哈希。
第二哈希获取子模块，用于获取所述自签名证书中的公钥信息，并对该公钥信息进行哈希计算以得到第二哈希。
哈希比对子模块，用于比对所述第一哈希与所述第二哈希，若所述第一哈希与所述第二哈希一致，则触发验证结果获取子模块执行所述将所述自签名证书中的远程证明数据发送至第三方可信验证中心进行验证的步骤。
其中，签名证书验证子模块，具体用于基于所述验证结果确定生成所述自签名证书的信任中心是否运行在可信执行环境中；若生成所述自签名证书的信任中心运行在可信执行环境中，则判定所述自签名证书在所述可信执行环境中生成。
在具体的实施方式中，若所述自签名证书包括所述业务服务器的一级证书，第一哈希获取子模块，具体用于获取所述一级证书中远程证明数据的公钥哈希以得到第一哈希；该远程证明数据为所述业务服务器的可信执行环境对应的证明数据。相应的，签名证书验证子模块，用于基于所述验证结果判断所述一级证书是否在所述业务服务器的可信执行环境中生成。
在具体的实施方式中，若所述自签名证书包括反向代理服务器的二级证书，第一哈希获取子模块，具体用于获取所述二级证书中远程证明数据的公钥哈希以得到第一哈希；该远程证明数据为所述反向代理服务器的可信执行环境对应的证明数据。相应的，签名证书验证子模块，用于基于该验证结果判断所述二级证书是否在所述反向代理服务器的可信执行环境中生成。
进一步的，签名证书验证模块13，还用于利用所述自签名证书的公钥验证所述自签名证书中的自签名信息是否为利用所述公钥对应的私钥生成的签名信息。
进一步的，签名证书验证模块13，还用于：若所述自签名证书包括反向代理服务器的二级证书，利用所述二级证书中的多重签名信息验证所述二级证书是否由多个业务服务器的一级证书签名而形成。
并且，签名证书验证模块13，还包括：
工作负载参考值获取子模块，用于获取信任中心的工作负载参考值；其中，信任中心在可信执行环境中创建；
比对子模块，用于将所述工作负载参考值与所述自签名证书中的工作负载值进行比对，若所述工作负载参考值与所述工作负载值一致，则通过工作负载验证；其中，所述工作负载值为信任中心的初始程序对应的唯一标识。
在一种实施方式中，工作负载参考值获取子模块，用于若所述自签名证书包括所述业务服务器的一级证书，获取一级信任中心的工作负载参考值；其中，所述一级信任中心为业务服务器的可信执行环境中创建的信任中心；
相应的，比对子模块，用于将所述工作负载参考值与所述一级证书中的工作负载值进行比对。
在一种实施方式中，工作负载参考值获取子模块，用于若所述自签名证书包括所述反向代理服务器的二级证书，获取二级信任中心的工作负载参考值；其中，所述二级信任中心为反向代理服务器的可信执行环境中创建的信任中心；
相应的，比对子模块，用于将所述工作负载参考值与所述二级证书中的工作负载值进行比对。
并且，工作负载参考值获取子模块，用于从指定中心获取信任中心的工作负载参考值；或，与所述反向代理服务器协商，获取信任中心的工作负载参考值。
在一种实施方式中，所述装置具体用于获取所述反向代理服务器返回的二级证书；对所述二级证书进行验证，若所述二级证书通过验证，则与所述反向代理服务器建立https连接，以形成第一通信信道；通过所述第一通信信道获取所述反向代理服务器返回的一级证书；对所述一级证书进行验证，若所述一级证书通过验证，则与所述反向代理服务器建立https连接，以形成目标通信信道，所述目标通信信道的数据经由反向代理服务器透明传输至业务服务器。
其中，所述通过所述第一通信信道获取所述反向代理服务器返回的一级证书之前，所述反向代理服务器对所述一级证书进行验证，并在一级证书通过验证时，则与所述业务服务器建立https连接。
参见图7所示，本申请实施例公开了一种电子设备20，包括处理器21和存储器22；其中，所述存储器22，用于保存计算机程序；所述处理器21，用于执行所述计算机程序，前述实施例公开的通信信道建立方法。
关于上述通信信道建立方法的具体过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。
并且，所述存储器22作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，存储方式可以是短暂存储或者永久存储。
另外，所述电子设备20还包括电源23、通信接口24、输入输出接口25和通信总线26；其中，所述电源23用于为所述电子设备20上的各硬件设备提供工作电压；所述通信接口24能够为所述电子设备20创建与外界设备之间的数据传输通道，其所遵循的通信协议是能够适用于本申请技术方案的任意通信协议，在此不对其进行具体限定；所述输入输出接口25，用于获取外界输入数据或向外界输出数据，其具体的接口类型可以根据具体应用需要进行选取，在此不进行具体限定。
进一步的，本申请实施例还公开了一种计算机可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述实施例公开的通信信道建立方法。
关于上述通信信道建立方法的具体过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器（RAM）、内存、只读存储器（ROM）、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
以上对本申请所提供的通信信道建立方法、装置、设备及介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (19)

1.一种通信信道建立方法，其特征在于，应用于客户端，包括：
向反向代理服务器发送针对业务服务器的访问请求；
获取所述反向代理服务器返回的自签名证书；所述自签名证书包括所述业务服务器的一级证书和所述反向代理服务器的二级证书；其中，所述二级证书还包括由多个所述一级证书进行签名后形成的多重签名信息；
对所述自签名证书进行验证，该验证过程包括验证所述自签名证书是否在可信执行环境中生成，以及利用所述二级证书中的所述多重签名信息验证所述二级证书是否由多个业务服务器的一级证书签名而形成；其中，验证所述自签名证书是否在可信执行环境中生成包括：验证所述一级证书是否在所述业务服务器的可信执行环境中生成、验证所述二级证书是否在所述反向代理服务器的可信执行环境中生成；
若所述自签名证书通过验证，则与所述反向代理服务器建立https连接，形成客户端与所述反向代理服务器之间的目标通信信道。
2.根据权利要求1所述的通信信道建立方法，其特征在于，验证所述自签名证书是否在可信执行环境中生成，包括：
将所述自签名证书中的远程证明数据发送至第三方可信验证中心进行验证，得到验证结果；所述远程证明数据为可信执行环境对应的证明数据；
基于所述验证结果判断所述自签名证书是否在所述可信执行环境中生成。
3.根据权利要求2所述的通信信道建立方法，其特征在于，在所述将所述自签名证书中的远程证明数据发送至第三方可信验证中心进行验证之前，还包括：
获取所述远程证明数据中的公钥哈希以得到第一哈希；
获取所述自签名证书中的公钥信息，并对该公钥信息进行哈希计算以得到第二哈希；
比对所述第一哈希与所述第二哈希，若所述第一哈希与所述第二哈希一致，则触发所述将所述自签名证书中的远程证明数据发送至第三方可信验证中心进行验证的步骤。
4.根据权利要求2所述的通信信道建立方法，其特征在于，所述基于所述验证结果判断所述自签名证书是否在所述可信执行环境中生成，包括：
基于所述验证结果确定生成所述自签名证书的信任中心是否运行在可信执行环境中；
若生成所述自签名证书的信任中心运行在可信执行环境中，则判定所述自签名证书在所述可信执行环境中生成。
5.根据权利要求3所述的通信信道建立方法，其特征在于，获取所述远程证明数据中的公钥哈希以得到第一哈希，包括：
获取所述一级证书中远程证明数据的公钥哈希以得到第一哈希；该远程证明数据为所述业务服务器的可信执行环境对应的证明数据。
6.根据权利要求5所述的通信信道建立方法，其特征在于，所述基于所述验证结果判断所述自签名证书是否在所述可信执行环境中生成，包括：
基于所述验证结果判断所述一级证书是否在所述业务服务器的可信执行环境中生成。
7.根据权利要求3所述的通信信道建立方法，其特征在于，获取所述远程证明数据中的公钥哈希以得到第一哈希，包括：
获取所述二级证书中远程证明数据的公钥哈希以得到第一哈希；该远程证明数据为所述反向代理服务器的可信执行环境对应的证明数据。
8.根据权利要求7所述的通信信道建立方法，其特征在于，所述基于所述验证结果判断所述自签名证书是否在所述可信执行环境中生成，包括：
基于该验证结果判断所述二级证书是否在所述反向代理服务器的可信执行环境中生成。
9.根据权利要求1所述的通信信道建立方法，其特征在于，对所述自签名证书进行验证，还包括：
利用所述自签名证书的公钥验证所述自签名证书中的自签名信息是否为利用所述公钥对应的私钥生成的签名信息。
10.根据权利要求1至9任一项所述的通信信道建立方法，其特征在于，所述对所述自签名证书进行验证，还包括：
获取信任中心的工作负载参考值；其中，信任中心在可信执行环境中创建；
将所述工作负载参考值与所述自签名证书中的工作负载值进行比对，若所述工作负载参考值与所述工作负载值一致，则通过工作负载验证；
其中，所述工作负载值为信任中心的初始程序对应的唯一标识。
11.根据权利要求10所述的通信信道建立方法，其特征在于，所述获取信任中心的工作负载参考值，包括：
获取一级信任中心的工作负载参考值；其中，所述一级信任中心为业务服务器的可信执行环境中创建的信任中心；
相应的，所述将所述工作负载参考值与所述自签名证书中的工作负载值进行比对，包括：
将所述工作负载参考值与所述一级证书中的工作负载值进行比对。
12.根据权利要求10所述的通信信道建立方法，其特征在于，所述获取信任中心的工作负载参考值，包括：
获取二级信任中心的工作负载参考值；其中，所述二级信任中心为反向代理服务器的可信执行环境中创建的信任中心；
相应的，所述将所述工作负载参考值与所述自签名证书中的工作负载值进行比对，包括：
将所述工作负载参考值与所述二级证书中的工作负载值进行比对。
13.根据权利要求10所述的通信信道建立方法，其特征在于，所述获取信任中心的工作负载参考值，包括：
从指定中心获取信任中心的工作负载参考值；
或，与所述反向代理服务器协商，获取信任中心的工作负载参考值。
14.根据权利要求1所述的通信信道建立方法，其特征在于，获取所述反向代理服务器返回的自签名证书；对所述自签名证书进行验证；若所述自签名证书通过验证，则与所述反向代理服务器建立https连接，包括：
获取所述反向代理服务器返回的二级证书；
对所述二级证书进行验证，若所述二级证书通过验证，则与所述反向代理服务器建立https连接，以形成第一通信信道；
通过所述第一通信信道获取所述反向代理服务器返回的一级证书；
对所述一级证书进行验证，若所述一级证书通过验证，则与所述反向代理服务器建立https连接，以形成目标通信信道，所述目标通信信道的数据经由反向代理服务器透明传输至业务服务器。
15.根据权利要求14所述的通信信道建立方法，其特征在于，所述通过所述第一通信信道获取所述反向代理服务器返回的一级证书之前，所述反向代理服务器对所述一级证书进行验证，并在一级证书通过验证时，则与所述业务服务器建立https连接。
16.一种通信信道建立方法，其特征在于，应用于反向代理服务器，包括：
获取客户端发送的针对业务服务器的访问请求；
向所述客户端返回自签名证书，以便所述客户端对所述自签名证书进行验证，该验证过程包括验证所述自签名证书是否在可信执行环境中生成，以及利用二级证书中的多重签名信息验证所述二级证书是否由多个所述业务服务器的一级证书签名而形成；并在所述自签名证书通过验证时，与所述反向代理服务器建立https连接，形成客户端与所述反向代理服务器之间的目标通信信道；
其中，所述自签名证书包括所述业务服务器的一级证书和所述反向代理服务器的二级证书，所述二级证书还包括由多个所述一级证书进行签名后形成的所述多重签名信息；验证所述自签名证书是否在可信执行环境中生成包括：验证所述一级证书是否在所述业务服务器的可信执行环境中生成、验证所述二级证书是否在所述反向代理服务器的可信执行环境中生成。
17.一种通信信道建立装置，其特征在于，应用于客户端，包括：
访问请求发送模块，用于向反向代理服务器发送针对业务服务器的访问请求；
签名证书获取模块，用于获取所述反向代理服务器返回的自签名证书；所述自签名证书包括所述业务服务器的一级证书和所述反向代理服务器的二级证书；其中，所述二级证书还包括由多个所述一级证书进行签名后形成的多重签名信息；
签名证书验证模块，用于对所述自签名证书进行验证，该验证过程包括验证所述自签名证书是否在可信执行环境中生成，以及利用所述二级证书中的所述多重签名信息验证所述二级证书是否由多个业务服务器的一级证书签名而形成；其中，验证所述自签名证书是否在可信执行环境中生成包括：验证所述一级证书是否在所述业务服务器的可信执行环境中生成、验证所述二级证书是否在所述反向代理服务器的可信执行环境中生成；
通信信道建立模块，用于若所述自签名证书验证模块确定所述自签名证书通过验证，则与所述反向代理服务器建立https连接，形成客户端与所述反向代理服务器之间的目标通信信道。
18.一种电子设备，其特征在于，包括存储器和处理器，其中：
所述存储器，用于保存计算机程序；
所述处理器，用于执行所述计算机程序，以实现如权利要求1至16任一项所述的通信信道建立方法。
19.一种计算机可读存储介质，其特征在于，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现如权利要求1至16任一项所述的通信信道建立方法。
CN202311096490.5A 2023-08-29 2023-08-29 通信信道建立方法、装置、设备及介质 Active CN116846682B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311096490.5A CN116846682B (zh) 2023-08-29 2023-08-29 通信信道建立方法、装置、设备及介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311096490.5A CN116846682B (zh) 2023-08-29 2023-08-29 通信信道建立方法、装置、设备及介质

Publications (2)

Publication Number Publication Date
CN116846682A CN116846682A (zh) 2023-10-03
CN116846682B true CN116846682B (zh) 2024-01-23

Family

ID=88165512

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311096490.5A Active CN116846682B (zh) 2023-08-29 2023-08-29 通信信道建立方法、装置、设备及介质

Country Status (1)

Country Link
CN (1) CN116846682B (zh)

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109120644A (zh) * 2018-10-23 2019-01-01 山东浪潮云信息技术有限公司 一种基于数字证书和账号口令的双重身份认证方法
CN110011801A (zh) * 2018-11-16 2019-07-12 阿里巴巴集团控股有限公司 可信应用程序的远程证明方法及装置、电子设备
CN110674494A (zh) * 2018-07-02 2020-01-10 阿里巴巴集团控股有限公司 进程的保护方法、系统及数据处理方法
CN110768940A (zh) * 2018-07-27 2020-02-07 深信服科技股份有限公司 基于https协议密文数据管控方法、系统及相关装置
CN113302893A (zh) * 2019-01-08 2021-08-24 华为技术有限公司 用于信任验证的方法及装置
CN113438256A (zh) * 2021-08-26 2021-09-24 北京天空卫士网络安全技术有限公司 一种基于双层ssl的数据传输方法、系统和代理服务器
CN113472579A (zh) * 2021-07-01 2021-10-01 山东浪潮通软信息科技有限公司 一种访问外网应用程序接口的配置方法、设备及介质
CN114553449A (zh) * 2020-11-24 2022-05-27 北京金山云网络技术有限公司 基于https的加解密方法、装置、系统、电子设备和存储介质
CN116112187A (zh) * 2023-04-10 2023-05-12 山东海量信息技术研究院 一种远程证明方法、装置、设备及可读存储介质
CN116506134A (zh) * 2023-06-28 2023-07-28 山东海量信息技术研究院 数字证书管理方法、装置、设备、系统及可读存储介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11658944B2 (en) * 2020-03-13 2023-05-23 Arm Ip Limited Methods and apparatus for encrypted communication

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110674494A (zh) * 2018-07-02 2020-01-10 阿里巴巴集团控股有限公司 进程的保护方法、系统及数据处理方法
CN110768940A (zh) * 2018-07-27 2020-02-07 深信服科技股份有限公司 基于https协议密文数据管控方法、系统及相关装置
CN109120644A (zh) * 2018-10-23 2019-01-01 山东浪潮云信息技术有限公司 一种基于数字证书和账号口令的双重身份认证方法
CN110011801A (zh) * 2018-11-16 2019-07-12 阿里巴巴集团控股有限公司 可信应用程序的远程证明方法及装置、电子设备
CN113302893A (zh) * 2019-01-08 2021-08-24 华为技术有限公司 用于信任验证的方法及装置
CN114553449A (zh) * 2020-11-24 2022-05-27 北京金山云网络技术有限公司 基于https的加解密方法、装置、系统、电子设备和存储介质
CN113472579A (zh) * 2021-07-01 2021-10-01 山东浪潮通软信息科技有限公司 一种访问外网应用程序接口的配置方法、设备及介质
CN113438256A (zh) * 2021-08-26 2021-09-24 北京天空卫士网络安全技术有限公司 一种基于双层ssl的数据传输方法、系统和代理服务器
CN116112187A (zh) * 2023-04-10 2023-05-12 山东海量信息技术研究院 一种远程证明方法、装置、设备及可读存储介质
CN116506134A (zh) * 2023-06-28 2023-07-28 山东海量信息技术研究院 数字证书管理方法、装置、设备、系统及可读存储介质

Also Published As

Publication number Publication date
CN116846682A (zh) 2023-10-03

Similar Documents

Publication Publication Date Title
CN111066286B (zh) 使用高可用性的可信执行环境检索区块链网络的公共数据
TWI725655B (zh) 用於在可信執行環境中執行子邏輯代碼的程式執行和資料證明的方法、設備和系統
CN112422532B (zh) 业务通信方法、系统、装置及电子设备
CN110677240B (zh) 通过证书签发提供高可用计算服务的方法、装置及介质
US11095635B2 (en) Server authentication using multiple authentication chains
EP1714422B1 (en) Establishing a secure context for communicating messages between computer systems
Cervesato et al. Breaking and fixing public-key Kerberos
CN110198297B (zh) 流量数据监控方法、装置、电子设备及计算机可读介质
US9935995B2 (en) Embedded script security using script signature validation
US11570213B2 (en) Collaborative security for application layer encryption
CN112417494A (zh) 基于可信计算的电力区块链系统
CN114584306B (zh) 一种数据处理方法和相关装置
CN112118242A (zh) 零信任认证系统
Alzomai et al. The mobile phone as a multi OTP device using trusted computing
Fongen et al. Integrity attestation in military IoT
Arnedo-Moreno et al. Secure communication setup for a p2p-based jxta-overlay platform
CN113630244A (zh) 面对通信传感网的端到端安全保障方法及边缘服务器
CN115378740B (zh) 一种基于可信openssh双向认证登录的实现方法
CN116846682B (zh) 通信信道建立方法、装置、设备及介质
CN115834149A (zh) 一种基于国密算法的数控系统安全防护方法及装置
Fongen et al. The integration of trusted platform modules into a tactical identity management system
Khattak et al. Security, trust and privacy (STP) framework for federated single sign-on environment
Ahn et al. mdTLS: How to Make middlebox-aware TLS more efficient?
Abbdal et al. An Efficient Public Verifiability and Data Integrity Using Multiple TPAs in Cloud Data Storage
US20240064137A1 (en) Decentralized edge node authentication

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