WO2023216275A1

WO2023216275A1 - Authentication method, apparatus, communication device, and storage medium

Info

Publication number: WO2023216275A1
Application number: PCT/CN2022/092889
Authority: WO
Inventors: 商正仪; 陆伟
Original assignee: 北京小米移动软件有限公司
Priority date: 2022-05-13
Filing date: 2022-05-13
Publication date: 2023-11-16
Also published as: CN117413557A

Abstract

Provided in the embodiments of the present disclosure are an authentication method. The method is executed by a first root certificate management mechanism CA, the method comprising: generating a predetermined certificate based on transport layer security (TLS), the predetermined certificate comprising at least one of the following: a first-type certificate of an entity in a first security domain in which a first root CA is located, and a second-type certificate of an entity in a second security domain in which a second root CA is located, the second-type certificate being at least used for TLS validation between the entities of the first security domain and the second security domain.

Description

Authentication method, device, communication equipment and storage medium

Technical field

The present disclosure relates to the field of wireless communication technology but is not limited to the field of wireless communication technology, and in particular, to an authentication method, device, communication equipment and storage medium.

Background technique

The secure transport layer protocol (TLS, Transport Layer Security) is used everywhere in the service-based architecture (SBA, Service Based Architecture) of the fifth generation mobile communication technology (5G, 5th Generation Mobile Communication Technology). However, unlike the standardized model that uses Certificate Management Protocol v2 (CMPv2, Certificate Management Protocol v2) in wireless networks, the SBA does not have a standardized model and set of procedures for automated certificate management. The SBA also has no standardized protocol for managing certificate lifecycle events. Therefore, automated certificate management in SBA architecture remains to be studied.

Contents of the invention

The embodiments of the present disclosure disclose an authentication method, device, communication equipment and storage medium.

According to a first aspect of an embodiment of the present disclosure, an authentication method is provided, wherein the method is executed by a first root certificate authority CA, and the method includes:

Generate a scheduled certificate based on the secure transport protocol TLS;

Wherein, the predetermined certificate includes at least one of the following:

The first type certificate of the entity in the first security domain where the first root CA is located;

A second type certificate of an entity in the second security domain where the second root CA is located. The second type certificate is at least used for TLS verification between entities in the first security domain and the second security domain.

In one embodiment, the method further includes:

Send the predetermined certificate to the entity.

In one embodiment, generating a predetermined certificate based on secure transport protocol TLS includes:

The second type of certificate is generated in response to an interconnection agreement being reached between the first security domain and the second security domain.

Generate the first type certificate signed based on the private key of the first root CA;

and / or,

Generate the second type of certificate signed based on the private key of the first root CA.

Generate said root certificate;

Wherein, the root certificate is used to generate the first type certificate.

In one embodiment, the entity includes at least one of the following:

rootCA;

TLS server CA;

TLS client CA;

TLS proxy CA;

TLS server;

TLS client;

TLS proxy.

According to a second aspect of an embodiment of the present disclosure, an authentication method is provided, wherein the method is performed by a first type entity, and the method includes:

Obtain a scheduled certificate based on the secure transport protocol TLS;

Wherein, the predetermined certificate includes at least one of the following:

In one embodiment, the obtaining a predetermined certificate based on the secure transport protocol TLS includes:

Obtain the pre-configured scheduled certificate;

or,

Receive the predetermined certificate sent by the first root CA.

In one embodiment, the first type entity includes at least one of the following:

TLS server CA;

TLS client CA;

TLS proxy CA.

In one embodiment, the method further includes:

The third type of certificate based on the private key signature of the first type of entity is generated.

In one embodiment, the method further includes:

Send a third type certificate to the second type entity, where the third type certificate contains a public key and is used to establish a TLS tunnel between different entities.

In one embodiment, the first type entity is a TLS client CA; the second type entity is a TLS client; and sending the third type certificate to the second type entity includes:

Send the TLS client certificate to the TLS client.

In one embodiment, the first type entity is a TLS server CA; the second type entity is a TLS server; and sending the third type certificate to the second type entity includes:

Send the TLS server certificate to the TLS server.

In one embodiment, the first type entity is a TLS proxy CA; the second type entity is a TLS proxy; and sending the third type certificate to the second type entity includes:

Send the TLS proxy certificate to the TLS proxy.

In one embodiment, sending the third type certificate to the second type entity includes:

Send a TLS client certificate and a TLS server certificate to the second type entity.

In one embodiment, the second type entity includes at least one of the following:

TLS server

TLS client

TLS proxy.

According to a third aspect of an embodiment of the present disclosure, an authentication method is provided, wherein the method is performed by a second type entity, and the method includes:

Obtain a third-type certificate, where the third-type certificate contains a public key and is used to establish a TLS tunnel between different entities.

In one embodiment, obtaining the third type of certificate includes:

Obtain the preconfigured third category certificate;

or,

Receive the third type certificate sent by the first type entity.

TLS server CA;

TLS client CA;

TLS proxy CA.

In one embodiment, the first type entity is a TLS client CA; the second type entity is a TLS client; and obtaining the third type certificate includes:

Receive the TLS client certificate sent by the TLS client CA.

In one embodiment, the first type entity is a TLS server CA; the second type entity is a TLS server; and obtaining the third type certificate includes:

Receive the TLS server certificate sent by the TLS server CA.

In one embodiment, the first type entity is a TLS proxy CA; the second type entity is a TLS proxy; and obtaining the third type certificate includes:

Receive the TLS proxy certificate sent by the TLS proxy CA.

In one embodiment, obtaining the third type of certificate includes:

Receive the TLS client certificate and TLS server certificate sent by the first type entity.

TLS server;

TLS client;

TLS proxy.

According to a fourth aspect of the embodiment of the present disclosure, an authentication method is provided, wherein the method is executed by a TLS client, and the method includes:

In response to receiving the TLS server certificate of the TLS server, determining the trustworthiness of the TLS server certificate;

Wherein, the TLS server and the TLS client are in the same security domain.

In one embodiment, determining the credibility of the TLS server certificate includes:

Verify whether the TLS server certificate is trustworthy based on the TLS server CA certificate.

In one embodiment, the method further includes:

Verify whether the certificate of the TLS server CA is trustworthy based on the root certificate generated by the root CA of the security domain.

According to a fifth aspect of an embodiment of the present disclosure, an authentication method is provided, wherein the method is performed by a first TLS proxy in a first security domain, and the method includes:

In response to receiving the second TLS proxy certificate sent by the second TLS proxy in the second security domain, determining the credibility of the second TLS proxy certificate.

In one embodiment, determining the credibility of the second TLS proxy certificate includes:

Verify whether the second TLS proxy certificate is trustworthy based on the TLS proxy CA certificate in the second security domain.

In one embodiment, the method further includes:

Verify whether the TLS proxy CA certificate is trusted based on the root certificate in the second security domain.

In one embodiment, the method further includes:

Verifying whether the root certificate in the second security domain is trustworthy based on the root certificate in the first security domain.

According to a sixth aspect of an embodiment of the present disclosure, an authentication method is provided, wherein the method is performed by a first TLS proxy in a first security domain, and the method includes:

In response to receiving the TLS client certificate sent by the TLS client in the first security domain, determining the trustworthiness of the TLS client certificate.

In one embodiment, determining the credibility of the TLS client certificate includes:

Verifying whether the TLS client certificate is trustworthy based on the TLS client CA certificate in the first security domain.

In one embodiment, the method further includes:

Verify whether the TLS client CA certificate is trusted based on the root certificate in the first security domain.

According to a seventh aspect of an embodiment of the present disclosure, an authentication method is provided, wherein the method is performed by a first TLS proxy in a first security domain, and the method includes:

In response to receiving the TLS server certificate sent by the TLS server in the first security domain, determining the credibility of the TLS server certificate.

Verify whether the TLS server certificate is trusted based on the public key of the TLS server CA in the first security domain.

In one embodiment, the method further includes:

Verify whether the TLS server CA certificate is trusted based on the root certificate in the first security domain. According to an eighth aspect of the embodiment of the present disclosure, an authentication device is provided, wherein the device includes:

a generation module configured to generate a predetermined certificate based on the secure transport protocol TLS;

Wherein, the predetermined certificate includes at least one of the following:

According to a ninth aspect of an embodiment of the present disclosure, an authentication device is provided, wherein the device includes:

a receiving module configured to receive a predetermined certificate based on the secure transport protocol TLS;

Wherein, the predetermined certificate includes at least one of the following:

According to a tenth aspect of the embodiment of the present disclosure, an authentication device is provided, wherein the device includes:

The receiving module is configured to obtain a third-type certificate, where the third-type certificate contains a public key and is used to establish a TLS tunnel between different entities.

According to an eleventh aspect of an embodiment of the present disclosure, an authentication device is provided, wherein the device includes:

a determining module configured to: in response to receiving the TLS server certificate of the TLS server, determine the credibility of the TLS server certificate;

Wherein, the TLS server and the TLS client are in the same security domain.

According to a twelfth aspect of an embodiment of the present disclosure, an authentication device is provided, wherein the device includes:

The determining module is configured to: in response to receiving the second TLS proxy certificate sent by the second TLS proxy in the second security domain, determine the credibility of the certificate of the second TLS proxy.

According to a thirteenth aspect of an embodiment of the present disclosure, an authentication device is provided, wherein the device includes:

The determining module is configured to: in response to receiving the TLS client certificate sent by the TLS client in the first security domain, determine the credibility of the TLS client certificate.

According to a fourteenth aspect of an embodiment of the present disclosure, an authentication device is provided, wherein the device includes:

The determining module is configured to: in response to receiving the TLS server certificate sent by the TLS server in the first security domain, determine the credibility of the TLS server certificate.

According to a fifteenth aspect of the embodiment of the present disclosure, a communication device is provided, and the communication device includes:

processor;

memory for storing instructions executable by the processor;

Wherein, the processor is configured to implement the method described in any embodiment of the present disclosure when running the executable instructions.

According to a sixteenth aspect of an embodiment of the present disclosure, a computer storage medium is provided. The computer storage medium stores a computer executable program. When the executable program is executed by a processor, the method described in any embodiment of the present disclosure is implemented. .

In the embodiment of the present disclosure, a predetermined certificate based on the secure transport protocol TLS is generated; wherein the predetermined certificate includes at least one of the following: a first-type certificate of an entity in the first security domain where the first root CA is located; a second root CA A second type of certificate of an entity located in the second security domain. The second type of certificate is at least used for TLS verification between entities in the first security domain and the second security domain. In this way, since the first root certificate authority CA can generate the first type of certificate and/or the second type of certificate, entities in the same security domain can implement authentication between entities based on the first type of certificate, And/or, entities in different security domains can implement authentication between entities in different security domains based on the second type of certificate. Compared with the situation without intra-domain entity authentication and/or inter-domain entity authentication, the authentication mechanism of the wireless communication network is improved and the authentication reliability of the wireless communication network is improved.

Description of the drawings

Figure 1 is a schematic structural diagram of a wireless communication system according to an exemplary embodiment.

Figure 2 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 3 is a schematic diagram of an SBA architecture according to an exemplary embodiment.

Figure 4 is a schematic diagram of a trust chain according to an exemplary embodiment.

Figure 5 is a schematic diagram of a trust chain according to an exemplary embodiment.

Figure 6 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 7 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 8 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 9 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 10 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 11 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 12 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 13 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 14 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 15 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 16 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 17 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 18 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 19 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 20 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 21 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 22 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 23 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 24 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 25 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 26 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 27 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 28 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 29 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 30 is a schematic flowchart of an authentication method according to an exemplary embodiment.

Figure 31 is a schematic diagram of an authentication device according to an exemplary embodiment.

Figure 32 is a schematic diagram of an authentication device according to an exemplary embodiment.

Figure 33 is a schematic diagram of an authentication device according to an exemplary embodiment.

Figure 34 is a schematic diagram of an authentication device according to an exemplary embodiment.

Figure 35 is a schematic diagram of an authentication device according to an exemplary embodiment.

Figure 36 is a schematic diagram of an authentication device according to an exemplary embodiment.

Figure 37 is a schematic diagram of an authentication device according to an exemplary embodiment.

Figure 38 is a schematic structural diagram of a terminal according to an exemplary embodiment.

Figure 39 is a block diagram of a base station according to an exemplary embodiment.

Detailed ways

Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with embodiments of the present disclosure. Rather, they are merely examples of apparatus and methods consistent with aspects of embodiments of the present disclosure as detailed in the appended claims.

The terminology used in the embodiments of the present disclosure is for the purpose of describing specific embodiments only and is not intended to limit the embodiments of the present disclosure. As used in the embodiments of the present disclosure and the appended claims, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used to describe various information in the embodiments of the present disclosure, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of the embodiments of the present disclosure, the first information may also be called second information, and similarly, the second information may also be called first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "when" or "in response to determining."

For the purpose of simplicity and ease of understanding, this article uses the terms "greater than" or "less than" when characterizing the size relationship. However, those skilled in the art can understand that the term “greater than” also encompasses the meaning of “greater than or equal to”, and “less than” also encompasses the meaning of “less than or equal to”.

Please refer to FIG. 1 , which shows a schematic structural diagram of a wireless communication system provided by an embodiment of the present disclosure. As shown in Figure 1, the wireless communication system is a communication system based on mobile communication technology. The wireless communication system may include several user equipments 110 and several base stations 120.

Where user equipment 110 may be a device that provides voice and/or data connectivity to a user. The user equipment 110 may communicate with one or more core networks via a Radio Access Network (RAN). The user equipment 110 may be an Internet of Things user equipment, such as a sensor device, a mobile phone, and a computer with an Internet of Things user equipment. , for example, it can be a fixed, portable, pocket-sized, handheld, computer-built-in or vehicle-mounted device. For example, station (STA), subscriber unit (subscriber unit), subscriber station (subscriber station), mobile station (mobile station), mobile station (mobile), remote station (remote station), access point, remote user equipment (remote terminal), access user equipment (access terminal), user device (user terminal), user agent (user agent), user equipment (user device), or user equipment (user equipment). Alternatively, the user equipment 110 may also be equipment of an unmanned aerial vehicle. Alternatively, the user equipment 110 may also be a vehicle-mounted device, for example, it may be an on-board computer with a wireless communication function, or a wireless user equipment connected to an external on-board computer. Alternatively, the user equipment 110 may also be a roadside device, for example, it may be a streetlight, a signal light or other roadside device with a wireless communication function.

The base station 120 may be a network-side device in a wireless communication system. Among them, the wireless communication system can be the 4th generation mobile communication technology (the 4th generation mobile communication, 4G) system, also known as the Long Term Evolution (LTE) system; or the wireless communication system can also be a 5G system, Also called new air interface system or 5G NR system. Alternatively, the wireless communication system may also be a next-generation system of the 5G system. Among them, the access network in the 5G system can be called NG-RAN (New Generation-Radio Access Network).

The base station 120 may be an evolved base station (eNB) used in the 4G system. Alternatively, the base station 120 may also be a base station (gNB) that adopts a centralized distributed architecture in the 5G system. When the base station 120 adopts a centralized distributed architecture, it usually includes a centralized unit (central unit, CU) and at least two distributed units (distributed units, DU). The centralized unit is equipped with a protocol stack including the Packet Data Convergence Protocol (PDCP) layer, the Radio Link Control protocol (Radio Link Control, RLC) layer, and the Media Access Control (Media Access Control, MAC) layer; distributed The unit is provided with a physical (Physical, PHY) layer protocol stack, and the embodiment of the present disclosure does not limit the specific implementation of the base station 120.

A wireless connection may be established between the base station 120 and the user equipment 110 through a wireless air interface. In different implementations, the wireless air interface is a wireless air interface based on the fourth generation mobile communication network technology (4G) standard; or the wireless air interface is a wireless air interface based on the fifth generation mobile communication network technology (5G) standard, such as The wireless air interface is a new air interface; alternatively, the wireless air interface may also be a wireless air interface based on the next generation mobile communication network technology standard of 5G.

In some embodiments, an E2E (End to End, end-to-end) connection can also be established between user equipments 110 . For example, V2V (vehicle to vehicle, vehicle to vehicle) communication, V2I (vehicle to infrastructure, vehicle to roadside equipment) communication and V2P (vehicle to pedestrian, vehicle to person) communication in vehicle networking communication (vehicle to everything, V2X) Wait for the scene.

Here, the above user equipment can be considered as the terminal equipment of the following embodiments.

In some embodiments, the above-mentioned wireless communication system may also include a network management device 130.

Several base stations 120 are connected to the network management device 130 respectively. The network management device 130 may be a core network device in a wireless communication system. For example, the network management device 130 may be a mobility management entity (Mobility Management Entity) in an evolved packet core network (Evolved Packet Core, EPC). MME). Alternatively, the network management device can also be other core network devices, such as serving gateway (Serving GateWay, SGW), public data network gateway (Public Data Network GateWay, PGW), policy and charging rules functional unit (Policy and Charging Rules) Function, PCRF) or Home Subscriber Server (HSS), etc. The embodiment of the present disclosure does not limit the implementation form of the network management device 130.

In order to facilitate understanding by those skilled in the art, the embodiments of the present disclosure enumerate multiple implementations to clearly describe the technical solutions of the embodiments of the present disclosure. Of course, those skilled in the art can understand that the multiple embodiments provided in the embodiments of the present disclosure can be executed alone or in combination with the methods of other embodiments in the embodiments of the present disclosure. They can also be executed alone or in combination. It is then executed together with some methods in other related technologies; the embodiments of the present disclosure do not limit this.

In order to better understand the technical solutions described in any embodiment of the present disclosure, first, the application scenarios in related technologies are described:

TLS certificates are used everywhere in 5G SBA. Certificate-based Internet Protocol will be used to protect non-variable bandwidth Scaleable Bandwidth Interconnect (SBI) interfaces. For example, N4 or N9. However, unlike the standardized model for using CMPv2 in wireless networks, the SBA does not have a standardized model and set of procedures for automated certificate management.

The SBA also has no standardized protocol for managing certificate lifecycle events. For example, guide, request, publish, register, revoke and update, etc. in this way,

1. Lack of standardization leads to many custom or proprietary methods and different choices of certificate management protocols resulting in inconsistent models.

2. Once service slicing and Non-Public Network (NPN) are introduced in the service provider network, manual management or lack of standardized procedures for life cycle management of TLS certificates for entities belonging to different laws may make the architecture further complication.

All of the above may increase security risks and affect the deployment and availability of operators' 5G SBA networks.

In order to fill the gap in SBA automated certificate management, the chain of trust in the SBA architecture should first be studied. Only if the chain of trust is confirmed can the standardized protocols used to manage the life cycle be analyzed.

Unlike the standardized model for using CMPv2 in wireless networks, the SBA does not have a standardized model and chain of trust for automated certificate management. Therefore, there are multiple issues in the research on automated certificate management in SBA architecture that require further research.

In some embodiments, at least one of the following needs to be implemented:

1. Establish a chain of trust in the certificate authority hierarchy in the SBA architecture.

2. Issue appropriate certificates to different 5G network functions (NF, Network Function).

3. Ensure that 5G NF can verify certificates issued in the same security domain and different security domains.

As shown in Figure 2, this embodiment provides an authentication method, where the method is executed by the first root certificate authority CA, and the method includes:

Step 21: Generate a scheduled certificate based on the secure transport protocol TLS;

Among them, the reservation certificate includes at least one of the following:

It should be noted that the entities in the SBA involved in this disclosure may be various types of entities, for example, entities of the fifth generation mobile communications (5G) network or other evolved entities. In some implementations of the present disclosure, the entity can be deployed as a communication node alone, or can be deployed uniformly in existing network elements. In short, entities can be understood as logical nodes that can be flexibly deployed in a network, and are not limited here. Referring to Figure 3, a chain of trust for a certificate authority hierarchy in SBA is shown. It includes 2 security domains, namely Security Domain A and Security Domain B. Security Domain A (Security Domain A) corresponds to the first security domain in step 21; Security Domain B (Security Domain B) corresponds to the first security domain in step 21. Second security domain. The SBA includes at least one of the following entities:

Root CA _A (Root CA _A );

Root CA _B _;

TLS server CA _A (TLS server CA _A );

TLS Proxy _CA _A ;

TLS client CA _A (TLS client CA _A );

TLS server CA _B (TLS server CA _B );

TLS Proxy CA _B _;

TLS client CA _B (TLS client CA _B );

TLS Proxy A2 (TLS Proxy _A2 );

TLS Proxy _A1 ;

TLS Proxy B2 (TLS Proxy _B2 );

TLS Proxy B1 (TLS Proxy _B1 );

TLS Server A(TLS Server _A );

TLS Client A(TLS Client _A );

TLS Server _B ;

TLS Client _B.

Among them, the solid arrow represents certificate distribution (Issues a certificate); the dotted arrow represents the establishment of a TLS connection (Establishes a TLS connection). It should be noted that the comparison between Chinese and English in the drawings can be found in the description of this part, and the description will not be repeated in the drawings, for example, the descriptions of Figures 3, 4 and 5.

In this disclosed embodiment, security domain A may also correspond to the second security domain, and security domain B may also correspond to the first security domain, which is not limited here. It should be noted that when the first security domain is security domain A, the first root certificate management authority CA is TLS server CA _A ; when the first security domain is security domain B, the first root certificate management authority CA is TLS server CA _B. . In this embodiment of the present disclosure, the number of security domains may be greater than 2, for example, 3, which is not limited here.

Root Certificate Authority (CA, Certificate Authority): CA is the trust anchor in the trust chain within the security domain. There can be only one root CA in each security domain. The root CA generates a root certificate, which is a self-signed certificate. All certificates in the security domain are signed directly or indirectly by this root certificate. When operators reach an interconnection agreement (here, different operators can correspond to different security domains, for example, operator A can correspond to security domain A), the root CA will generate a cross certificate. Here, the first step in step 21 The second type of certificate can be a cross certificate to ensure that the secure Transport Layer Protocol (TLS, Transport Layer Security) end entities of two different security domains can authenticate each other. The generated cross-certificate can be configured locally in each security domain (the root CA can send this cross-certificate to different entities) and stored together with the root certificate in the TLS end entity. For example, the first root CA may be the root CA _A in security domain A. It should be noted that the generated first-type certificate itself can be the root certificate.

TLS client CA: A CA that distributes TLS client certificates to TLS clients within a specific operator's security domain.

TLS server CA: A CA that distributes TLS server certificates to TLS servers within a specific operator's security domain.

TLS Proxy CA: A CA that distributes TLS proxy certificates to TLS proxies within a specific operator's security domain.

TLS server: TLS terminal entity as a 5G network function (NF, Network Function) producer. The TLS server has a TLS server certificate issued by the TLS server CA. Here, NF can be a mobility management function entity (AMF, Access Control And Mobility Management Function) and a session management function (SMF, Session Management Function), etc.

TLS client: TLS terminal entity that is a consumer of 5G network functions (NF, Network Function). The TLS client has a TLS client certificate issued by the TLS client CA. Here, NF can be a mobility management function entity (AMF, Access Control And Mobility Management Function) and a session management function (SMF, Session Management Function), etc.

TLS proxy: A network function that acts as a proxy function in a Service Based Architecture (SBA, Service Based Architecture) (for example, Service Communication Proxy SCP and Security Edge Protection Proxy SEPP). The TLS proxy can be an intermediate point between the TLS client and the TLS server, and can also assist the TLS terminal entity in establishing a TLS connection between security domains. A TLS entity can verify the identity of a TLS proxy by validating the TLS proxy's TLS proxy certificate.

It should be noted that considering that some TLS end entities can act as both NF producers and NF consumers, a TLS client certificate and a TLS server certificate may be required.

For TLS connections within the security domain, see Figure 4 for the trust chain. Considering that the TLS server, TLS client and TLS proxy trust the same root CA, the TLS server, TLS client and TLS proxy can achieve mutual authentication by verifying the entity certificate. Here, TLS entity certificates include TLS server certificates, TLS client certificates and TLS proxy certificates.

For TLS connections between security domains, see Figure 5 for the trust chain. TLS connections between security domains are mainly established between TLS proxies in different security domains. Figure 5 shows the cross-domain trust chain. As shown in Figure 5, TLS proxyA trusts TLS proxy CA _A , TLS Proxy CA _A trusts Root CA _A , and Root CA _A trusts Root CA _B. Considering that Root CA _B is the trust anchor in security domain B, TLS proxyA trusts the TLS entity in security domain B. Vice versa, TLS proxy B trusts TLS proxy CA _B , TLS proxy CA _B trusts Root CA _B , and Root CA _B trusts Root CA _A. Considering that Root CA _A is the trust anchor in security domain A, TLS proxyB trusts the TLS entities within security domain A.

In one embodiment, a predetermined certificate based on the secure transport protocol TLS is generated; wherein the predetermined certificate includes at least one of the following: a first-type certificate of an entity in the first security domain where the first root CA is located; a second type of certificate where the second root CA is located. A second type of certificate for an entity in a security domain. The second type of certificate is at least used for TLS verification between entities in the first security domain and the second security domain. Send the scheduled certificate to the entity.

In one embodiment, generating the certificate in the SBA may include:

1. Generate a first-class certificate for the TLS server, TLS client, or TLS proxy within the security domain (for example, within the first security domain):

The root CA generates a first-class certificate for a TLS server CA, TLS client CA, or TLS proxy CA signed with the root CA's private key. The TLS server CA, TLS client CA or TLS proxy CA generates the corresponding third-category certificate of the TLS server, TLS client or TLS proxy signed with the private key of the intermediate CA. The third type of certificate for a TLS server, TLS client, or TLS proxy contains the public key and can be used to establish a TLS tunnel between TLS entities. Here, the intermediate CA can be any one of TLS server CA, TLS client CA or TLS proxy CA.

2. Generate a certificate for a TLS proxy across security domains (for example, between the first security domain and the second security domain):

Root CA _A generates a TLS proxy CA _A certificate signed by Root CA _A 's private key (corresponding to the first type of certificate). TLS proxy CA _A generates a certificate for TLS proxy A (corresponding to the third type of certificate), which is signed using the private key of TLS proxy CA _A. The TLS proxyA certificate contains the public key and can be used to establish TLS tunnels between TLS entities.

Root CA _A generates a cross-certificate of Root CA _B signed by Root CA _A 's private key (corresponding to the second type of certificate). Root CA _B generates a cross-certificate for Root CA _A signed by Root CA _B 's private key. The trust relationship between Root CA _A and Root CA _B allows inter-domain TLS proxies between different security domains to authenticate each other.

In one embodiment, the certificate can be verified in the SBA

Verify the certificate in SBA schema:

1. Verify TLS certificates between TLS entities within the security domain:

It is assumed that the TLS client and TLS server are in the same security domain (for example, the first security domain), and the self-signed certificate of the root CA (that is, the root certificate) is pre-configured. When a TLS client receives the TLS server's certificate as part of the TLS handshake, the TLS client performs the following process:

Step a1: The TLS client checks to ensure that the TLS server certificate has not expired. Considering that the TLS server certificate is signed by the TLS server CA, the TLS client will try to obtain the TLS server CA certificate. Once the TLS server CA certificate is obtained, the TLS client uses the public key in the TLS server CA certificate to verify that the TLS server certificate is correctly signed.

Step a2: The TLS client tries to verify whether the TLS server CA certificate is trustworthy. Considering that the TLS server CA certificate is signed by the root CA, the TLS client uses the public key from the provided self-signed root certificate to verify the signature of the TLS server CA certificate.

Step a3: The TLS client locally presets a self-signed root certificate that the TLS client implicitly trusts, thereby ensuring that the public key in the root certificate is trustworthy. At this point, the TLS client successfully verifies the identity of the TLS server, establishes a trust chain to the TLS server, and completes the TLS handshake within the security domain.

Similarly, in the case of two-way authentication, the TLS server can verify the TLS client certificate, verify the identity of the TLS client, and complete the TLS handshake within the security domain.

2. Verify the TLS certificate between TLS proxies between security domains:

Assume that TLS proxyA and TLS proxyB are in different security domains and have self-signed certificates of their root CAs provisioned (for example, TLS proxyA is provisioned with the self-signed certificate of root CA _A , and TLS proxyB is provisioned with the self-signed certificate of root CA _B. self-signed certificate). When TLS proxyA receives TLS proxyB's certificate as part of the SSL or TLS handshake, TLS proxyA performs the following process.

Step b1: TLS proxyA checks to ensure that the certificate of TLS proxyB has not expired. Considering that TLS proxyB's certificate is signed by TLS proxy CA _B , TLS proxyA will try to obtain the TLS proxy CA _B certificate. Once the TLS proxy CA _B certificate is obtained, TLS proxyA uses the public key in the TLS proxy CA _B certificate to verify that the TLS proxy B certificate is correctly signed.

Step b2: TLS proxyA tries to verify whether the TLS proxy CA _B certificate is trustworthy. Considering that the TLS proxy CA _B certificate is signed by the root CA _B , TLS proxy A will try to obtain the root CA _B certificate. After obtaining the root CA _B certificate, TLS proxyA uses the public key in the root CA _B certificate to verify that the TLS proxy CA _B certificate is correctly signed.

Step b3: TLS proxyA tries to verify whether the Root CA _B certificate is trustworthy. Considering that the Root CA _B certificate is signed by Root CA _A , TLS proxyA uses the public key in the preset self-signed root certificate to verify the signature of the Root CA _B certificate.

Step b4. TLS proxyA locally presets the self-signed root certificate implicitly trusted by TLS proxyA, thereby ensuring that the public key in the Root CA _A root certificate is trustworthy. At this time, TLS proxyA successfully verifies the identity of TLS proxyB, establishes a trust chain to TLS proxyB, and completes the SSL or TLS handshake between security domains.

It should be noted that Root CA _A issues the certificate of Root CA _B , which is called a cross certificate (corresponding to the second type of certificate in this disclosure). TLS entities can request a cross-certificate on demand or provide a cross-certificate in advance (stored with a self-signed root certificate).

In this disclosed embodiment, a predetermined certificate based on the secure transport protocol TLS is generated; wherein the predetermined certificate includes at least one of the following: a first-type certificate of an entity in the first security domain where the first root CA is located; The second type certificate of the entity in the second security domain is at least used for TLS verification between the entities in the first security domain and the second security domain. This is because the first root certificate authority CA can generate the first type certificate. And/or the second type of certificate enables entities in the same security domain to implement authentication between entities based on the first type of certificate, and/or allows entities in different security domains to implement authentication in different security domains based on the second type of certificate. Authentication between entities. Compared with the situation without intra-domain entity authentication and/or inter-domain entity authentication, the authentication mechanism of the wireless communication network is improved and the authentication reliability of the wireless communication network is improved.

It should be noted that those skilled in the art can understand that the methods provided in the embodiments of the present disclosure can be executed alone or together with some methods in the embodiments of the present disclosure or some methods in related technologies.

As shown in Figure 6, this embodiment provides an authentication method, where the method is executed by the first root certificate authority CA, and the method includes:

Step 61: Send a predetermined certificate to the entity, where the predetermined certificate includes at least one of the following:

In one embodiment, a predetermined certificate based on the secure transport protocol TLS is generated; the predetermined certificate is sent to the entity, wherein the predetermined certificate includes at least one of the following:

In this way, after the entity receives the predetermined certificate, it can use the predetermined certificate for authentication of the entity.

As shown in Figure 7, this embodiment provides an authentication method, where the method is executed by the first root certificate authority CA, and the method includes:

Step 71: In response to reaching an interconnection agreement between the first security domain and the second security domain, generate a second type of certificate;

The second type of certificate is a certificate of an entity in the second security domain where the second root CA is located, and the second type of certificate is at least used for TLS verification between entities in the first security domain and the second security domain.

As shown in Figure 8, this embodiment provides an authentication method, where the method is executed by the first root certificate authority CA, and the method includes:

Step 81: Generate the first type of certificate signed based on the private key of the first root CA; and/or generate the second type of certificate signed based on the private key of the first root CA;

Among them, the first type of certificate is the certificate of the entity in the first security domain where the first root CA is located; the second type of certificate is the certificate of the entity in the second security domain where the second root CA is located, and the second type of certificate is used at least for the third TLS verification is performed between entities in one security domain and the second security domain.

As shown in Figure 9, this embodiment provides an authentication method, where the method is executed by the first root certificate authority CA, and the method includes:

Step 91: Generate a root certificate; the root certificate is used to generate a first-type certificate, where the first-type certificate is a certificate of an entity in the first security domain where the first root CA is located.

The first type of certificate can be the certificate of a TLS server CA, a TLS client CA or a TLS proxy CA.

As shown in Figure 10, this embodiment provides an authentication method, where the method is executed by a first type entity, and the method includes:

Step 101: Obtain the scheduled certificate based on the secure transmission protocol TLS;

Among them, the reservation certificate includes at least one of the following:

Obtain the pre-configured scheduled certificate;

or,

Receive the predetermined certificate sent by the first root CA.

TLS server CA;

TLS client CA;

TLS proxy CA.

In one embodiment, the root CA generates a first-type certificate of a TLS server CA, a TLS client CA or a TLS proxy CA that is signed using the private key of the root CA. The first-type certificate is a certificate in the first security domain where the first root CA is located. The entity's certificate. The root CA sends the first type of certificate to the first type of entity. The first type entity obtains a first type certificate based on the secure transport protocol TLS. The TLS server CA, TLS client CA or TLS proxy CA generates the corresponding third-category certificate of the TLS server, TLS client or TLS proxy signed with the private key of the intermediate CA. A third-class certificate for a TLS server, TLS client, or TLS proxy contains the public key and can be used to establish a TLS tunnel between TLS entities. Here, the intermediate CA can be any one of TLS server CA, TLS client CA or TLS proxy CA.

As shown in Figure 11, this embodiment provides an authentication method, where the method is executed by a first type entity, and the method includes:

Step 111: Send a third type certificate to the second type entity, where the third type certificate contains a public key and is used to establish a TLS tunnel between different entities.

TLS server;

TLS client;

TLS proxy.

In one embodiment, the TLS server CA, TLS client CA or TLS proxy CA generates a corresponding third-type certificate of the TLS server, TLS client or TLS proxy signed using the private key of the intermediate CA. The third type of certificate for a TLS server, TLS client, or TLS proxy contains the public key and can be used to establish a TLS tunnel between TLS entities. Here, the intermediate CA can be any one of TLS server CA, TLS client CA or TLS proxy CA.

As shown in Figure 12, this embodiment provides an authentication method, where the method is executed by a first type entity, and the method includes:

Step 121: Generate a third type certificate based on the private key signature of the first type entity.

In one embodiment, a third type of certificate based on a private key signature of a first type of entity is generated. Send a third-type certificate to the second-type entity, where the third-type certificate contains a public key and is used to establish a TLS tunnel between different entities.

As shown in Figure 13, this embodiment provides an authentication method, wherein the method is executed by a first type entity, the first type entity is a TLS client CA; the second type entity is a TLS client; The method includes:

Step 131: Send the TLS client certificate to the TLS client.

In one embodiment, a TLS client certificate signed based on the private key of the TLS client CA is generated. Send the TLS client certificate to the TLS client. The TLS client certificate contains the public key and is used to establish TLS tunnels between different entities.

As shown in Figure 14, this embodiment provides an authentication method, wherein the method is executed by a first type entity, the first type entity is a TLS server CA; the second type entity is a TLS server; the method include:

Step 141: Send the TLS server certificate to the TLS server.

In one embodiment, a TLS server certificate signed based on the private key of the TLS server CA is generated. Send the TLS server certificate to the TLS server, where the TLS server certificate contains the public key and is used to establish TLS tunnels between different entities.

As shown in Figure 15, this embodiment provides an authentication method, wherein the method is executed by a first type entity, the first type entity is a TLS proxy CA; the second type entity is a TLS proxy; the method include:

Step 151: Send the TLS proxy certificate to the TLS proxy.

In one embodiment, a TLS proxy certificate signed by the private key of the TLS proxy CA is generated. Send the TLS proxy certificate to the TLS proxy. The TLS proxy certificate contains the public key and is used to establish TLS tunnels between different entities.

As shown in Figure 16, this embodiment provides an authentication method, where the method is executed by a first type entity, and the method includes:

Step 161: Send the TLS client certificate and TLS server certificate to the second type entity.

In one embodiment, a TLS client certificate and a TLS server certificate signed by the private key of the first type entity are generated. Send the TLS client certificate and TLS server certificate to the second type entity, where the TLS client certificate and TLS server certificate contain the public key and are used to establish a TLS tunnel between different entities.

As shown in Figure 17, this embodiment provides an authentication method, where the method is executed by a second type entity, and the method includes:

Step 171: Obtain a third type of certificate, where the third type of certificate contains a public key and is used to establish a TLS tunnel between different entities.

In one embodiment, a third type certificate sent by the first type entity is obtained, wherein the third type certificate contains a public key and is used to establish a TLS tunnel between different entities.

In one embodiment, obtaining the third type of certificate includes:

Obtain the preconfigured third category certificate;

or,

Receive the third type certificate sent by the first type entity.

TLS server;

TLS client;

TLS proxy.

In one embodiment, the TLS server CA, TLS client CA or TLS proxy CA generates a corresponding third type certificate of the TLS server, TLS client or TLS proxy signed using the private key of the intermediate CA, wherein the third Type III certificates contain public keys and are used to establish TLS tunnels between different entities. The second type entity obtains the third type certificate sent by the first type entity. The third type of certificate for a TLS server, TLS client, or TLS proxy contains the public key and can be used to establish a TLS tunnel between TLS entities. Here, the intermediate CA can be any one of TLS server CA, TLS client CA or TLS proxy CA.

As shown in Figure 18, this embodiment provides an authentication method, wherein the method is executed by a second type entity, the first type entity is a TLS client CA; the second type entity is a TLS client; The method includes:

Step 181: Receive the TLS client certificate sent by the TLS client CA.

In one embodiment, the TLS client CA generates a TLS client certificate signed based on the TLS client CA's private key. The TLS client CA sends a TLS client certificate to the TLS client. The TLS client certificate contains the public key and is used to establish a TLS tunnel between different entities. The TLS client receives the TLS client certificate sent by the TLS client CA.

As shown in Figure 19, this embodiment provides an authentication method, wherein the method is executed by a second type entity, the first type entity is a TLS server CA; the second type entity is a TLS server; this method include:

Step 191: Receive the TLS server certificate sent by the TLS server CA.

In one embodiment, the TLS server CA generates a TLS server certificate signed based on the TLS server CA's private key. The TLS server CA sends a TLS server certificate to the TLS server. The TLS server certificate contains the public key and is used to establish TLS tunnels between different entities. The TLS server receives the TLS server certificate sent by the TLS server CA.

As shown in Figure 20, this embodiment provides an authentication method, wherein the method is executed by a second type entity, the first type entity is a TLS proxy CA; the second type entity is a TLS proxy; this method include:

Step 201: Receive the TLS proxy certificate sent by the TLS proxy CA.

In one embodiment, the TLS proxy CA generates a TLS proxy certificate signed by the TLS proxy CA's private key. The TLS proxy sends a TLS proxy certificate to the TLS proxy, where the TLS proxy certificate contains the public key and is used to establish a TLS tunnel between different entities. The TLS proxy receives the TLS proxy certificate sent by the TLS proxy CA.

As shown in Figure 21, this embodiment provides an authentication method, where the method is executed by a second type entity, and the method includes:

Step 211: Receive the TLS client certificate and TLS server certificate sent by the first type entity.

In one embodiment, the first type entity generates a TLS client certificate and a TLS server certificate signed by the private key of the first type entity. The first type entity sends a TLS client certificate and a TLS server certificate to the second type entity, where the TLS client certificate and TLS server certificate contain public keys and are used to establish a TLS tunnel between different entities. The second type entity receives the TLS client certificate and TLS server certificate sent by the first type entity.

As shown in Figure 22, this embodiment provides an authentication method, where the method is executed by a TLS client, and the method includes:

Step 221: In response to receiving the TLS server certificate of the TLS server, determine the credibility of the TLS server certificate;

Wherein, the TLS server and the TLS client are in the same security domain.

In one embodiment, it is assumed that the TLS client and the TLS server are in the same security domain (for example, the first security domain), and the self-signed certificate of the root CA (ie, the root certificate) is pre-configured. When a TLS client receives the TLS server's certificate as part of the TLS handshake, the TLS client performs the following process:

Step a1: The TLS client checks to ensure that the TLS server certificate has not expired. Considering that the TLS server certificate is signed by the TLS server CA, the TLS client will try to obtain the TLS server CA certificate. Once the TLS server CA certificate is obtained, the TLS client uses the public key of the TLS server CA certificate to verify that the TLS server certificate is correctly signed.

Step a2: The TLS client tries to verify whether the TLS server CA certificate is trustworthy. Considering that the TLS server CA certificate is signed by the root CA, the TLS client uses the public key of the provided self-signed root certificate to verify the signature of the TLS server CA certificate.

Step a3: The TLS client locally presets a self-signed root certificate that the TLS client implicitly trusts, thereby ensuring that the public key in the root certificate is trustworthy. At this point, the TLS client successfully verifies the identity of the TLS server, establishes a trust chain to the TLS server, and completes the TLS handshake within the security domain. It should be noted that those skilled in the art can understand that the methods provided in the embodiments of the present disclosure can be executed alone or together with some methods in the embodiments of the present disclosure or some methods in related technologies.

As shown in Figure 23, this embodiment provides an authentication method, where the method is executed by a TLS client, and the method includes:

Step 231: Verify whether the TLS server certificate is trustworthy based on the TLS server CA certificate;

Wherein, the TLS server and the TLS client are in the same security domain.

In one embodiment, it is assumed that the TLS client and the TLS server are in the same security domain (for example, the first security domain), and the self-signed certificate of the root CA (ie, the root certificate) is pre-configured. When a TLS client receives a TLS server's certificate as part of the TLS handshake, the TLS client performs the following process: The TLS client checks to ensure that the TLS server certificate has not expired. Considering that the TLS server certificate is signed by the TLS server CA, the TLS client will try to obtain the TLS server CA certificate. Once the TLS server CA certificate is obtained, the TLS client uses the public key of the TLS server CA certificate to verify that the TLS server certificate is correctly signed.

As shown in Figure 24, this embodiment provides an authentication method, where the method is executed by a TLS client, and the method includes:

Step 241: Verify whether the TLS server CA certificate is trustworthy based on the root certificate of the security domain;

Wherein, the TLS server and the TLS client are in the same security domain.

In one embodiment, it is assumed that the TLS client and the TLS server are in the same security domain (for example, the first security domain), and the self-signed certificate of the root CA (ie, the root certificate) is pre-configured. When a TLS client receives the TLS server's certificate as part of the TLS handshake, the TLS client performs the following process: The TLS client attempts to verify that the TLS server CA certificate is trusted. Considering that the TLS server CA certificate is signed by the root CA, the TLS client uses the public key in the preset self-signed root certificate to verify the signature of the TLS server CA certificate.

As shown in Figure 25, this embodiment provides an authentication method, where the method is executed by the first TLS proxy in the first security domain. The method includes:

Step 251: In response to receiving the second TLS proxy certificate sent by the second TLS proxy in the second security domain, determine the credibility of the second TLS proxy certificate.

In one embodiment, assume that TLS proxyA and TLS proxyB are in different security domains and are provisioned with self-signed certificates of their root CAs (for example, TLS proxyA is provisioned with the self-signed certificate of root CA _A , and TLS proxyB is provisioned with the self-signed certificate of root CA A. The self-signed certificate of root CA _B is set). When TLS proxyA receives TLS proxyB's certificate as part of the SSL or TLS handshake, TLS proxyA performs the following process:

Step b1: TLS proxyA checks to ensure that the certificate of TLS proxyB has not expired. Considering that TLS proxyB's certificate is signed by TLS proxy CA _B , TLS proxyA will try to obtain the TLS proxy CA _B certificate. Once the TLS proxy CA _B certificate is obtained, TLS proxyA uses the public key of the TLS proxy CA _B certificate to verify that the TLS proxy B certificate is correctly signed.

Step b2: TLS proxyA tries to verify whether the TLS proxy CA _B certificate is trustworthy. Considering that the TLS proxy CA _B certificate is signed by the root CA _B , TLS proxy A will try to obtain the root CA _B certificate. After obtaining the root CA _B certificate, TLS proxyA uses the public key of the root CA _B certificate to verify that the TLS proxy CA _B certificate is correctly signed.

Step b3: TLS proxyA tries to verify whether the Root CA _B certificate is trustworthy. Considering that the Root CA _B certificate is signed by Root CA _A , TLS proxyA uses the public key of the preset self-signed root certificate to verify the signature of the Root CA _B certificate.

Step b4. TLS proxyA locally presets the self-signed root certificate implicitly trusted by TLS proxyA, thereby ensuring that the public key in the Root CA _A root certificate is trustworthy. At this time, TLS proxyA successfully verifies the identity of TLS proxyB, establishes a trust chain to TLS proxyB, and completes the SSL or TLS handshake between security domains. It should be noted that those skilled in the art can understand that the methods provided in the embodiments of the present disclosure can be executed alone or together with some methods in the embodiments of the present disclosure or some methods in related technologies.

As shown in Figure 26, this embodiment provides an authentication method, where the method is executed by the first TLS proxy in the first security domain. The method includes:

Step 261: Verify whether the second TLS proxy certificate is trustworthy based on the TLS proxy CA certificate in the second security domain.

In one embodiment, assume that TLS proxyA and TLS proxyB are in different security domains and are provisioned with self-signed certificates of their root CAs (for example, TLS proxyA is provisioned with the self-signed certificate of root CA _A , and TLS proxyB is provisioned with the self-signed certificate of root CA A. The self-signed certificate of root CA _B is set). When TLS proxyA receives TLS proxyB's certificate as part of an SSL or TLS handshake, TLS proxyA performs the following process: TLS proxyA checks to ensure that TLS proxyB's certificate has not expired. Considering that TLS proxyB's certificate is signed by TLS proxy CA _B , TLS proxyA will try to obtain the TLS proxy CA _B certificate. Once the TLS proxy CA _B certificate is obtained, TLS proxyA uses the public key of the TLS proxy CA _B certificate to verify that the TLS proxy B certificate is correctly signed.

As shown in Figure 27, this embodiment provides an authentication method, where the method is executed by the first TLS proxy in the first security domain. The method includes:

Step 271: Verify whether the TLS proxy CA certificate is trustworthy based on the root certificate in the second security domain.

In one embodiment, assume that TLS proxyA and TLS proxyB are in different security domains and are provisioned with self-signed certificates of their root CAs (for example, TLS proxyA is provisioned with the self-signed certificate of root CA _{A, and TLS proxyB is provisioned with the self-signed certificate of root CA A.} The self-signed certificate of root CA _B is set). When TLS proxyA receives the TLS proxyB certificate as part of the SSL or TLS handshake, TLS proxyA performs the following process:

TLS proxyA attempts to verify whether the TLS proxy CA _B certificate is trusted. Considering that the TLS proxy CA _B certificate is signed by the root CA _B , TLS proxy A will try to obtain the root CA _B certificate. After obtaining the root CA _B certificate, TLS proxyA uses the public key in the root CA _B certificate to verify that the TLS proxy CA _B certificate is correctly signed.

As shown in Figure 28, this embodiment provides an authentication method, where the method is executed by the first TLS proxy in the first security domain. The method includes:

Step 281: Verify whether the root certificate in the second security domain is trustworthy based on the root certificate in the first security domain.

In one embodiment, assume that TLS proxyA and TLS proxyB are in different security domains and are provisioned with self-signed certificates of their root CAs (for example, TLS proxyA is provisioned with the self-signed certificate of root CA _A , and TLS proxyB is provisioned with the self-signed certificate of root CA A. The self-signed certificate of root CA _B is set). When TLS proxyA receives TLS proxyB's certificate as part of the SSL or TLS handshake, TLS proxyA performs the following process: TLS proxyA attempts to verify that the Root CA _B certificate is trusted. Considering that the Root CA _B certificate is signed by Root CA _A , TLS proxyA uses the public key in the preset self-signed root certificate to verify the signature of the Root CA _B certificate.

As shown in Figure 29, this embodiment provides an authentication method, where the method is executed by the first TLS proxy in the first security domain. The method includes:

Step 291: In response to receiving the TLS client certificate sent by the TLS client in the first security domain, determine the credibility of the TLS client certificate.

Verify whether the TLS client certificate is trusted based on the public key of the TLS client CA certificate in the first security domain.

In one embodiment, the method further includes:

Verify whether the TLS client CA certificate is trusted based on the public key of the root certificate in the first security domain.

It should be noted that the relevant description of step 291 can be found in the description of steps 251 to 281. The verification process is similar and will not be described again here.

As shown in Figure 30, this embodiment provides an authentication method, where the method is executed by the first TLS proxy in the first security domain. The method includes:

Step 301: In response to receiving the TLS server certificate sent by the TLS server in the first security domain, determine the credibility of the TLS server certificate.

Verify whether the TLS server certificate is trustworthy based on the public key of the TLS server CA certificate in the first security domain.

In one embodiment, the method further includes:

Verify whether the TLS server CA certificate is trusted based on the public key of the root certificate in the first security domain.

It should be noted that the relevant description of step 301 can be found in the description of steps 251 to 281. The verification process is similar and will not be described again here.

As shown in Figure 31, this embodiment provides an authentication device, wherein the device includes:

The generation module 311 is configured to generate a predetermined certificate based on the secure transport protocol TLS;

Wherein, the predetermined certificate includes at least one of the following:

As shown in Figure 32, this embodiment provides an authentication device, wherein the device includes:

The receiving module 321 is configured to receive a predetermined certificate based on the secure transport protocol TLS;

Wherein, the predetermined certificate includes at least one of the following:

As shown in Figure 33, this embodiment provides an authentication device, wherein the device includes:

The receiving module 331 is configured to obtain a third type of certificate, where the third type of certificate contains a public key and is used to establish a TLS tunnel between different entities.

As shown in Figure 34, this embodiment provides an authentication device, wherein the device includes:

The determination module 341 is configured to: in response to receiving the TLS server certificate of the TLS server, determine the validity of the TLS server certificate;

Wherein, the TLS server and the TLS client are in the same security domain.

As shown in Figure 35, this embodiment provides an authentication device, wherein the device includes:

The determining module 351 is configured to: in response to receiving the second TLS proxy certificate sent by the second TLS proxy in the second security domain, determine the credibility of the certificate of the second TLS proxy.

As shown in Figure 36, this embodiment provides an authentication device, wherein the device includes:

The determining module 361 is configured to: in response to receiving the TLS client certificate sent by the TLS client in the first security domain, determine the credibility of the TLS client certificate.

As shown in Figure 37, this embodiment provides an authentication device, wherein the device includes:

The determining module 371 is configured to: in response to receiving the TLS server certificate sent by the TLS server in the first security domain, determine the credibility of the TLS server certificate.

An embodiment of the present disclosure provides a communication device. The communication device includes:

processor;

Memory used to store instructions executable by the processor;

Wherein, the processor is configured to: when executing executable instructions, implement the method applied to any embodiment of the present disclosure.

The processor may include various types of storage media, which are non-transitory computer storage media that can continue to memorize information stored on the communication device after the communication device is powered off.

The processor can be connected to the memory through a bus, etc., and is used to read the executable program stored in the memory.

An embodiment of the present disclosure also provides a computer storage medium, wherein the computer storage medium stores a computer executable program, and when the executable program is executed by a processor, the method of any embodiment of the present disclosure is implemented.

Regarding the devices in the above embodiments, the specific manner in which each module performs operations has been described in detail in the embodiments related to the method, and will not be described in detail here.

As shown in Figure 38, one embodiment of the present disclosure provides a terminal structure.

Referring to the terminal 800 shown in Figure 38, this embodiment provides a terminal 800. The terminal may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc. .

Referring to Figure 38, the terminal 800 may include one or more of the following components: a processing component 802, a memory 804, a power supply component 806, a multimedia component 808, an audio component 810, an input/output (I/O) interface 812, a sensor component 814, and communications component 816.

Processing component 802 generally controls the overall operations of terminal 800, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 802 may include one or more processors 820 to execute instructions to complete all or part of the steps of the above method. Additionally, processing component 802 may include one or more modules that facilitate interaction between processing component 802 and other components. For example, processing component 802 may include a multimedia module to facilitate interaction between multimedia component 808 and processing component 802.

Memory 804 is configured to store various types of data to support operations at device 800 . Examples of such data include instructions for any application or method operating on the terminal 800, contact data, phonebook data, messages, pictures, videos, etc. Memory 804 may be implemented by any type of volatile or non-volatile storage device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EEPROM), Programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disk.

Power supply component 806 provides power to various components of terminal 800. Power component 806 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to terminal 800.

Multimedia component 808 includes a screen that provides an output interface between terminal 800 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. A touch sensor can not only sense the boundaries of a touch or swipe action, but also detect the duration and pressure associated with the touch or swipe action. In some embodiments, multimedia component 808 includes a front-facing camera and/or a rear-facing camera. When the device 800 is in an operating mode, such as a shooting mode or a video mode, the front camera and/or the rear camera may receive external multimedia data. Each front-facing camera and rear-facing camera can be a fixed optical lens system or have a focal length and optical zoom capabilities.

Audio component 810 is configured to output and/or input audio signals. For example, audio component 810 includes a microphone (MIC) configured to receive external audio signals when terminal 800 is in operating modes, such as call mode, recording mode, and voice recognition mode. The received audio signal may be further stored in memory 804 or sent via communication component 816 . In some embodiments, audio component 810 also includes a speaker for outputting audio signals.

The I/O interface 812 provides an interface between the processing component 802 and a peripheral interface module, which may be a keyboard, a click wheel, a button, etc. These buttons may include, but are not limited to: Home button, Volume buttons, Start button, and Lock button.

Sensor component 814 includes one or more sensors that provide various aspects of status assessment for terminal 800 . For example, the sensor component 814 can detect the open/closed state of the device 800, the relative positioning of components, such as the display and keypad of the terminal 800, the sensor component 814 can also detect the position change of the terminal 800 or a component of the terminal 800, the user The presence or absence of contact with the terminal 800, the terminal 800 orientation or acceleration/deceleration and the temperature change of the terminal 800. Sensor assembly 814 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 814 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor component 814 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

The communication component 816 is configured to facilitate wired or wireless communication between the terminal 800 and other devices. The terminal 800 can access a wireless network based on a communication standard, such as Wi-Fi, 2G or 3G, or a combination thereof. In one exemplary embodiment, the communication component 816 receives broadcast signals or broadcast related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communications component 816 also includes a near field communications (NFC) module to facilitate short-range communications. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

In an exemplary embodiment, the terminal 800 may be configured by one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable Gate array (FPGA), controller, microcontroller, microprocessor or other electronic components are implemented for executing the above method.

In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions, such as a memory 804 including instructions, which can be executed by the processor 820 of the terminal 800 to complete the above method is also provided. For example, non-transitory computer-readable storage media may be ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

As shown in Figure 39, an embodiment of the present disclosure shows the structure of a base station. For example, the base station 900 may be provided as a network side device. Referring to Figure 39, base station 900 includes a processing component 922, which further includes one or more processors, and memory resources represented by memory 932 for storing instructions, such as application programs, executable by processing component 922. The application program stored in memory 932 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 922 is configured to execute instructions to perform any of the foregoing methods applied to the base station.

Base station 900 may also include a power supply component 926 configured to perform power management of base station 900, a wired or wireless network interface 950 configured to connect base station 900 to a network, and an input/output (I/O) interface 958. Base station 900 may operate based on an operating system stored in memory 932, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™ or the like.

Other embodiments of the invention will be readily apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. The present disclosure is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common common sense or customary technical means in the technical field that are not disclosed in the present disclosure. . It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

It is to be understood that the present invention is not limited to the precise construction described above and illustrated in the accompanying drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the invention is limited only by the appended claims.

Claims

An authentication method, wherein the method is performed by a first root certificate authority CA, the method includes:

Generate a scheduled certificate based on the secure transport protocol TLS;

Wherein, the predetermined certificate includes at least one of the following:

The first type certificate of the entity in the first security domain where the first root CA is located;

A second type certificate of an entity in the second security domain where the second root CA is located. The second type certificate is at least used for TLS verification between entities in the first security domain and the second security domain.
The method of claim 1, further comprising:

Send the predetermined certificate to the entity.
The method according to claim 1, wherein said generating a predetermined certificate based on secure transport protocol TLS includes:

The second type of certificate is generated in response to an interconnection agreement being reached between the first security domain and the second security domain.
The method according to claim 1, wherein said generating a predetermined certificate based on secure transport protocol TLS includes:

Generate the first type certificate signed based on the private key of the first root CA;

and / or,

Generate the second type of certificate signed based on the private key of the first root CA.
The method according to claim 1, wherein said generating a predetermined certificate based on secure transport protocol TLS includes:

Generate said root certificate;

Wherein, the root certificate is used to generate the first type certificate.
The method of claim 1, wherein the entity includes at least one of the following:

rootCA;

TLS server CA;

TLS client CA;

TLS proxy CA;

TLS server;

TLS client;

TLS proxy.
An authentication method, wherein the method is performed by a first type entity, the method includes:

Obtain a scheduled certificate based on the secure transport protocol TLS;

Wherein, the predetermined certificate includes at least one of the following:

The first type certificate of the entity in the first security domain where the first root CA is located;

A second type certificate of an entity in the second security domain where the second root CA is located. The second type certificate is at least used for TLS verification between entities in the first security domain and the second security domain.
The method according to claim 7, wherein said obtaining a predetermined certificate based on secure transport protocol TLS includes:

Obtain the pre-configured scheduled certificate;

or,

Receive the predetermined certificate sent by the first root CA.
The method of claim 7, wherein the first type entity includes at least one of the following:

TLS server CA;

TLS client CA;

TLS proxy CA.
The method of claim 7, further comprising:

The third type of certificate based on the private key signature of the first type of entity is generated.
The method of claim 10, wherein the method further includes:

Send a third type certificate to the second type entity, where the third type certificate contains a public key and is used to establish a TLS tunnel between different entities.
The method according to claim 11, wherein the first type entity is a TLS client CA; the second type entity is a TLS client; and sending the third type certificate to the second type entity includes:

Send the TLS client certificate to the TLS client.
The method according to claim 11, wherein the first type entity is a TLS server CA; the second type entity is a TLS server; and sending the third type certificate to the second type entity includes:

Send the TLS server certificate to the TLS server.
The method according to claim 11, wherein the first type entity is a TLS proxy CA; the second type entity is a TLS proxy; and sending the third type certificate to the second type entity includes:

Send the TLS proxy certificate to the TLS proxy.
The method according to claim 11, wherein sending the third type certificate to the second type entity includes:

Send a TLS client certificate and a TLS server certificate to the second type entity.
The method according to any one of claims 10 to 15, wherein the second type entity includes at least one of the following:

TLS server

TLS client

TLS proxy.
An authentication method, wherein the method is performed by a second type entity, the method includes:

Obtain a third-type certificate, where the third-type certificate contains a public key and is used to establish a TLS tunnel between different entities.
The method according to claim 17, wherein said obtaining the third type of certificate includes:

Obtain the preconfigured third category certificate;

or,

Receive the third type certificate sent by the first type entity.
The method of claim 17, wherein the first type entity includes at least one of the following:

TLS server CA;

TLS client CA;

TLS proxy CA.
The method according to claim 17, wherein the first type entity is a TLS client CA; the second type entity is a TLS client; and the obtaining the third type certificate includes:

Receive the TLS client certificate sent by the TLS client CA.
The method according to claim 17, wherein the first type entity is a TLS server CA; the second type entity is a TLS server; and obtaining the third type certificate includes:

Receive the TLS server certificate sent by the TLS server CA.
The method according to claim 17, wherein the first type entity is a TLS proxy CA; the second type entity is a TLS proxy; and the obtaining the third type certificate includes:

Receive the TLS proxy certificate sent by the TLS proxy CA.
The method according to claim 17, wherein said obtaining the third type of certificate includes:

Receive the TLS client certificate and TLS server certificate sent by the first type entity.
The method according to any one of claims 20 to 22, wherein the second type entity includes at least one of the following:

TLS server;

TLS client;

TLS proxy.
An authentication method, wherein the method is executed by a TLS client, the method includes:

In response to receiving the TLS server certificate of the TLS server, determining the trustworthiness of the TLS server certificate;

Wherein, the TLS server and the TLS client are in the same security domain.
The method of claim 25, wherein determining the credibility of the TLS server certificate includes:

Verify whether the TLS server certificate is trustworthy based on the TLS server CA certificate.
The method of claim 25, wherein the method further includes:

Verify whether the TLS server CA certificate is trustworthy based on the root certificate generated by the root CA of the security domain.
An authentication method, wherein the method is performed by a first TLS proxy in a first security domain, the method includes:

In response to receiving the second TLS proxy certificate sent by the second TLS proxy in the second security domain, determining the credibility of the second TLS proxy certificate.
The method of claim 28, wherein determining the credibility of the second TLS proxy certificate includes:

Verify whether the second TLS proxy certificate is trustworthy based on the TLS proxy CA certificate in the second security domain.
The method of claim 29, wherein the method further includes:

Verify whether the TLS proxy CA certificate is trusted based on the root certificate in the second security domain.
The method of claim 30, wherein the method further includes:

Verifying whether the root certificate in the second security domain is trustworthy based on the root certificate in the first security domain.
An authentication method, wherein the method is performed by a first TLS proxy in a first security domain, the method includes:

In response to receiving the TLS client certificate sent by the TLS client in the first security domain, determining the trustworthiness of the TLS client certificate.
The method of claim 32, wherein determining the credibility of the TLS client certificate includes:

Verifying whether the TLS client certificate is trustworthy based on the TLS client CA certificate in the first security domain.
The method of claim 33, wherein the method further includes:

Verify whether the TLS client CA certificate is trusted based on the root certificate in the first security domain.
An authentication method, wherein the method is performed by a first TLS proxy in a first security domain, the method includes:

In response to receiving the TLS server certificate sent by the TLS server in the first security domain, determining the credibility of the TLS server certificate.
The method of claim 35, wherein determining the credibility of the TLS server certificate includes:

Verifying whether the TLS server certificate is trustworthy based on the TLS server CA certificate in the first security domain.
The method of claim 36, wherein the method further includes:

Verify whether the TLS server CA certificate is trusted based on the root certificate in the first security domain.
An authentication device, wherein the device includes:

a generation module configured to generate a predetermined certificate based on the secure transport protocol TLS;

Wherein, the predetermined certificate includes at least one of the following:

The first type certificate of the entity in the first security domain where the first root CA is located;

A second type certificate of an entity in the second security domain where the second root CA is located. The second type certificate is at least used for TLS verification between entities in the first security domain and the second security domain.
An authentication device, wherein the device includes:

a receiving module configured to receive a predetermined certificate based on the secure transport protocol TLS;

Wherein, the predetermined certificate includes at least one of the following:

The first type certificate of the entity in the first security domain where the first root CA is located;

A second type certificate of an entity in the second security domain where the second root CA is located. The second type certificate is at least used for TLS verification between entities in the first security domain and the second security domain.
An authentication device, wherein the device includes:

The receiving module is configured to obtain a third-type certificate, where the third-type certificate contains a public key and is used to establish a TLS tunnel between different entities.
An authentication device, wherein the device includes:

a determining module configured to: in response to receiving the TLS server certificate of the TLS server, determine the credibility of the TLS server certificate;

Wherein, the TLS server and the TLS client are in the same security domain.
An authentication device, wherein the device includes:

The determining module is configured to: in response to receiving the second TLS proxy certificate sent by the second TLS proxy in the second security domain, determine the credibility of the certificate of the second TLS proxy.
An authentication device, wherein the device includes:

The determining module is configured to: in response to receiving the TLS client certificate sent by the TLS client in the first security domain, determine the credibility of the TLS client certificate.
An authentication device, wherein the device includes:

The determining module is configured to: in response to receiving the TLS server certificate sent by the TLS server in the first security domain, determine the credibility of the TLS server certificate.
A communication device, including:

memory;

A processor, coupled to the memory, configured to implement claims 1 to 6, 7 to 16, 17 to 24, 25 to 27, 28 to 31 by executing computer-executable instructions stored on the memory , the method described in any one of 32 to 34 or 35 to 37.
A computer storage medium that stores computer-executable instructions. After being executed by a processor, the computer-executable instructions can realize claims 1 to 6, 7 to 16, 17 to 24, 25 to 27, and 28. to the method described in any one of 31 to 32 to 34 or 35 to 37.