WO2023216275A1 - Procédé d'authentification, appareil, dispositif de communication et support de stockage - Google Patents

Procédé d'authentification, appareil, dispositif de communication et support de stockage Download PDF

Info

Publication number
WO2023216275A1
WO2023216275A1 PCT/CN2022/092889 CN2022092889W WO2023216275A1 WO 2023216275 A1 WO2023216275 A1 WO 2023216275A1 CN 2022092889 W CN2022092889 W CN 2022092889W WO 2023216275 A1 WO2023216275 A1 WO 2023216275A1
Authority
WO
WIPO (PCT)
Prior art keywords
tls
certificate
type
security domain
entity
Prior art date
Application number
PCT/CN2022/092889
Other languages
English (en)
Chinese (zh)
Inventor
商正仪
陆伟
Original Assignee
北京小米移动软件有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 北京小米移动软件有限公司 filed Critical 北京小米移动软件有限公司
Priority to PCT/CN2022/092889 priority Critical patent/WO2023216275A1/fr
Priority to CN202280001718.5A priority patent/CN117413557A/zh
Publication of WO2023216275A1 publication Critical patent/WO2023216275A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys

Definitions

  • 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.
  • 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).
  • SBA Service Based Architecture
  • 5G 5th Generation Mobile Communication Technology
  • CMPv2 Certificate Management Protocol v2
  • CMPv2 Certificate Management Protocol v2
  • the SBA also has no standardized protocol for managing certificate lifecycle events. Therefore, automated certificate management in SBA architecture remains to be studied.
  • the embodiments of the present disclosure disclose an authentication method, device, communication equipment and storage medium.
  • an authentication method is provided, wherein the method is executed by a first root certificate authority CA, and the method includes:
  • 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 is at least used for TLS verification between entities in the first security domain and the second security domain.
  • the method further includes:
  • 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.
  • generating a predetermined certificate based on secure transport protocol TLS includes:
  • generating a predetermined certificate based on secure transport protocol TLS includes:
  • the root certificate is used to generate the first type certificate.
  • the entity includes at least one of the following:
  • an authentication method is provided, wherein the method is performed by a first type entity, and the method includes:
  • 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 is at least used for TLS verification between entities in the first security domain and the second security domain.
  • the obtaining a predetermined certificate based on the secure transport protocol TLS includes:
  • the first type entity includes at least one of the following:
  • the method further includes:
  • the third type of certificate based on the private key signature of the first type of entity is generated.
  • the method further includes:
  • 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:
  • 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:
  • 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:
  • sending the third type certificate to the second type entity includes:
  • the second type entity includes at least one of the following:
  • an authentication method is provided, wherein the method is performed by a second type entity, and the method includes:
  • the third-type certificate contains a public key and is used to establish a TLS tunnel between different entities.
  • obtaining the third type of certificate includes:
  • the first type entity includes at least one of the following:
  • the first type entity is a TLS client CA; the second type entity is a TLS client; and obtaining the third type certificate includes:
  • the first type entity is a TLS server CA; the second type entity is a TLS server; and obtaining the third type certificate includes:
  • the first type entity is a TLS proxy CA; the second type entity is a TLS proxy; and obtaining the third type certificate includes:
  • obtaining the third type of certificate includes:
  • the second type entity includes at least one of the following:
  • an authentication method is provided, wherein the method is executed by a TLS client, and the method includes:
  • the TLS server and the TLS client are in the same security domain.
  • determining the credibility of the TLS server certificate includes:
  • the method further includes:
  • an authentication method is provided, wherein the method is performed by a first TLS proxy in a first security domain, and the method includes:
  • determining the credibility of the second TLS proxy certificate includes:
  • the method further includes:
  • the method further includes:
  • an authentication method is provided, wherein the method is performed by a first TLS proxy in a first security domain, and the method includes:
  • determining the credibility of the TLS client certificate includes:
  • the method further includes:
  • an authentication method is provided, wherein the method is performed by a first TLS proxy in a first security domain, and the method includes:
  • determining the credibility of the TLS server certificate includes:
  • the method further includes:
  • an authentication device includes:
  • a generation module configured to generate a predetermined certificate based on the secure transport protocol TLS
  • 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 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
  • 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 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;
  • 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 includes:
  • memory for storing instructions executable by the processor
  • the processor is configured to implement the method described in any embodiment of the present disclosure when running the executable instructions.
  • a computer storage medium stores a computer executable program.
  • the executable program is executed by a processor, the method described in any embodiment of the present disclosure is implemented. .
  • 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.
  • 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.
  • 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.
  • first information may also be called second information, and similarly, the second information may also be called first information.
  • word “if” as used herein may be interpreted as "when” or "when” or "in response to determining.”
  • 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”.
  • FIG. 1 shows a schematic structural diagram of a wireless communication system provided by an embodiment of the present disclosure.
  • 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.
  • 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).
  • RAN Radio Access Network
  • 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.
  • the user equipment 110 may also be equipment of an unmanned aerial vehicle.
  • 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.
  • 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.
  • 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.
  • the wireless communication system may also be a next-generation system of the 5G system.
  • 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.
  • the base station 120 may also be a base station (gNB) that adopts a centralized distributed architecture in the 5G system.
  • eNB evolved base station
  • gNB base station
  • 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
  • PDCP Packet Data Convergence Protocol
  • RLC Radio Link Control
  • MAC Media Access Control
  • 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.
  • 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.
  • an E2E (End to End, end-to-end) connection can also be established between user equipments 110 .
  • V2V vehicle to vehicle, vehicle to vehicle
  • V2I vehicle to infrastructure, vehicle to roadside equipment
  • V2P vehicle to pedestrian, vehicle to person
  • the above user equipment can be considered as the terminal equipment of the following embodiments.
  • the above-mentioned wireless communication system may also include a network management device 130.
  • the network management device 130 may be a core network device in a wireless communication system.
  • 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).
  • 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.
  • serving gateway Serving GateWay, SGW
  • public data network gateway Public Data Network GateWay, PGW
  • Policy and Charging Rules Policy and Charging Rules
  • PCRF Policy and Charging Rules
  • HSS Home Subscriber Server
  • the embodiments of the present disclosure enumerate multiple implementations to clearly describe the technical solutions of the embodiments of the present disclosure.
  • 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.
  • 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.
  • SBI Scaleable Bandwidth Interconnect
  • 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,
  • NPN Non-Public Network
  • 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.
  • 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.
  • NF Network Function
  • 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;
  • the reservation 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 is at least used for TLS verification between entities in the first security domain and the second security domain.
  • 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.
  • the entity can be deployed as a communication node alone, or can be deployed uniformly in existing network elements.
  • entities can be understood as logical nodes that can be flexibly deployed in a network, and are not limited here.
  • 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 corresponds to the first security domain in step 21;
  • Security Domain B (Security Domain B) corresponds to the first security domain in step 21.
  • the SBA includes at least one of the following entities:
  • Root CA A (Root CA A );
  • TLS server CA A TLS server CA A (TLS server CA A );
  • TLS client CA A TLS client CA A (TLS client CA A );
  • TLS server CA B TLS server CA B (TLS server CA B );
  • TLS client CA B TLS client CA B (TLS client CA B );
  • TLS Proxy A2 TLS Proxy A2
  • TLS Proxy B2 TLS Proxy B2
  • TLS Proxy B1 TLS Proxy B1
  • TLS Server A TLS Server A(TLS Server A );
  • TLS Client A TLS Client A(TLS Client A );
  • the solid arrow represents certificate distribution (Issues a certificate); the dotted arrow represents the establishment of a TLS connection (Establishes a TLS connection).
  • security domain A may also correspond to the second security domain
  • security domain B may also correspond to the first security domain, which is not limited here.
  • the first root certificate management authority CA is TLS server CA A
  • the first root certificate management authority CA is TLS server CA B.
  • the number of security domains may be greater than 2, for example, 3, which is not limited here.
  • Root 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.
  • 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.
  • TLS Transport Layer Protocol
  • 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.
  • the first root CA may be the root CA A in security domain A.
  • 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.
  • 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.
  • AMF mobility management function entity
  • SMF Session Management Function
  • 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.
  • 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.
  • AMF mobility management function entity
  • SMF Session Management Function
  • 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).
  • SBA Service Based Architecture
  • 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.
  • TLS client certificate may be required.
  • TLS entity certificates include TLS server certificates, TLS client certificates and TLS proxy certificates.
  • TLS connections between security domains are mainly established between TLS proxies in different security domains.
  • Figure 5 shows the cross-domain trust chain.
  • TLS proxyA trusts TLS proxy CA A
  • TLS Proxy CA A trusts Root CA A
  • Root CA A trusts Root CA B.
  • TLS proxyA trusts the TLS entity in security domain B.
  • TLS proxy B trusts TLS proxy CA B
  • TLS proxy CA B trusts Root CA B
  • Root CA B trusts Root CA A.
  • Root CA A is the trust anchor in security domain A
  • TLS proxyB trusts the TLS entities within security domain A.
  • 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.
  • generating the certificate in the SBA may include:
  • 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.
  • the intermediate CA can be any one of TLS server CA, TLS client CA or TLS proxy CA.
  • 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.
  • the certificate can be verified in the SBA
  • 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.
  • the 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.
  • 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.
  • 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).
  • 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.
  • 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).
  • 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.
  • the first root certificate authority CA can generate the first type certificate.
  • 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.
  • 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:
  • 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 is at least used for TLS verification between entities in the first security domain and the second security domain.
  • 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:
  • 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 is at least used for TLS verification between entities in the first security domain and the second security domain.
  • the entity after the entity receives the predetermined certificate, it can use the predetermined certificate for authentication of the entity.
  • 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.
  • 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;
  • 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.
  • 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.
  • 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;
  • the reservation 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 is at least used for TLS verification between entities in the first security domain and the second security domain.
  • the obtaining a predetermined certificate based on the secure transport protocol TLS includes:
  • the first type entity includes at least one of the following:
  • 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 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.
  • the intermediate CA can be any one of TLS server CA, TLS client CA or TLS proxy CA.
  • 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.
  • the second type entity includes at least one of the following:
  • 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.
  • the intermediate CA can be any one of TLS server CA, TLS client CA or TLS proxy CA.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • obtaining the third type of certificate includes:
  • the second type entity includes at least one of the following:
  • 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.
  • the intermediate CA can be any one of TLS server CA, TLS client CA or TLS proxy CA.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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;
  • the TLS server and the TLS client are in the same security domain.
  • 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.
  • the 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.
  • 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
  • the TLS server and the TLS client are in the same security domain.
  • 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.
  • the 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.
  • 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
  • the TLS server and the TLS client are in the same security domain.
  • 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.
  • the 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • determining the credibility of the TLS client certificate includes:
  • the method further includes:
  • 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.
  • 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.
  • determining the credibility of the TLS server certificate includes:
  • the method further includes:
  • 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.
  • 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;
  • 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 is at least used for TLS verification between entities in the first security domain and the second security domain.
  • 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;
  • 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 is at least used for TLS verification between entities in the first security domain and the second security domain.
  • 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.
  • 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;
  • the TLS server and the TLS client are in the same security domain.
  • 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.
  • 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.
  • 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:
  • Memory used to store instructions executable by the processor
  • 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.
  • one embodiment of the present disclosure provides a terminal structure.
  • the terminal 800 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. .
  • 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.
  • processing component 802 may include one or more modules that facilitate interaction between processing component 802 and other components.
  • 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.
  • SRAM static random access memory
  • EEPROM electrically erasable programmable read-only memory
  • EEPROM erasable programmable read-only memory
  • EPROM Programmable read-only memory
  • PROM programmable read-only memory
  • ROM read-only memory
  • 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.
  • 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.
  • multimedia component 808 includes a front-facing camera and/or a rear-facing camera.
  • 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.
  • 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 .
  • 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 .
  • 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.
  • 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.
  • the communication component 816 receives broadcast signals or broadcast related information from an external broadcast management system via a broadcast channel.
  • communications component 816 also includes a near field communications (NFC) module to facilitate short-range communications.
  • NFC near field communications
  • 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.
  • RFID radio frequency identification
  • IrDA infrared data association
  • UWB ultra-wideband
  • Bluetooth Bluetooth
  • 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.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGA field programmable Gate array
  • controller microcontroller, microprocessor or other electronic components are implemented for executing the above method.
  • 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.
  • non-transitory computer-readable storage media may be ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.
  • an embodiment of the present disclosure shows the structure of a base station.
  • the base station 900 may be provided as a network side device.
  • 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.
  • 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 ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM or the like.

Landscapes

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

Abstract

Les modes de réalisation de la présente divulgation concernent un procédé d'authentification. Le procédé est exécuté par un premier mécanisme de gestion de certificat racine (CA), le procédé comprenant : la génération d'un certificat prédéterminé sur la base d'une sécurité de couche de transport (TLS), le certificat prédéterminé comprenant au moins l'un des éléments suivants : un certificat d'un premier type d'une entité dans un premier domaine de sécurité dans lequel une première CA racine est située, et un certificat d'un second type d'une entité dans un second domaine de sécurité dans lequel une seconde CA racine est située, le certificat de second type étant au moins utilisé pour une validation TLS entre les entités du premier domaine de sécurité et les entités du second domaine de sécurité.
PCT/CN2022/092889 2022-05-13 2022-05-13 Procédé d'authentification, appareil, dispositif de communication et support de stockage WO2023216275A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2022/092889 WO2023216275A1 (fr) 2022-05-13 2022-05-13 Procédé d'authentification, appareil, dispositif de communication et support de stockage
CN202280001718.5A CN117413557A (zh) 2022-05-13 2022-05-13 认证方法、装置、通信设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/092889 WO2023216275A1 (fr) 2022-05-13 2022-05-13 Procédé d'authentification, appareil, dispositif de communication et support de stockage

Publications (1)

Publication Number Publication Date
WO2023216275A1 true WO2023216275A1 (fr) 2023-11-16

Family

ID=88729532

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/092889 WO2023216275A1 (fr) 2022-05-13 2022-05-13 Procédé d'authentification, appareil, dispositif de communication et support de stockage

Country Status (2)

Country Link
CN (1) CN117413557A (fr)
WO (1) WO2023216275A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102932350A (zh) * 2012-10-31 2013-02-13 华为技术有限公司 一种tls扫描的方法和装置
CN106375123A (zh) * 2016-08-31 2017-02-01 迈普通信技术股份有限公司 一种802.1x认证的配置方法及装置
US20170339130A1 (en) * 2016-05-18 2017-11-23 Cisco Technology, Inc. Network security system to validate a server certificate
CN107800682A (zh) * 2016-08-30 2018-03-13 株式会社和冠 用传输层安全在签名装置与主机间的数据认证和安全传输
CN113422684A (zh) * 2021-06-15 2021-09-21 芜湖雄狮汽车科技有限公司 安全认证的证书生成方法、装置、电子设备及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102932350A (zh) * 2012-10-31 2013-02-13 华为技术有限公司 一种tls扫描的方法和装置
US20170339130A1 (en) * 2016-05-18 2017-11-23 Cisco Technology, Inc. Network security system to validate a server certificate
CN107800682A (zh) * 2016-08-30 2018-03-13 株式会社和冠 用传输层安全在签名装置与主机间的数据认证和安全传输
CN106375123A (zh) * 2016-08-31 2017-02-01 迈普通信技术股份有限公司 一种802.1x认证的配置方法及装置
CN113422684A (zh) * 2021-06-15 2021-09-21 芜湖雄狮汽车科技有限公司 安全认证的证书生成方法、装置、电子设备及存储介质

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Network Domain Security (NDS); Authentication Framework (AF) (Release 17)", 3GPP STANDARD; TECHNICAL SPECIFICATION; 3GPP TS 33.310, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG3, no. V17.0.0, 23 September 2021 (2021-09-23), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, pages 1 - 59, XP052056668 *
JINGJIA CHEN: "Analysis and Realization of SSL/TLS Security ", JOURNAL OF WUHAN AUTOMOTIVE POLYTECHNIC UNIVERSITY, vol. 27, no. 5, 28 October 2005 (2005-10-28), pages 70 - 72, XP093106284 *
PARADISE NIU: "TLS1.2 protocol security analysis", SOFTWARE GUIDE, vol. 14, no. 5, 26 May 2015 (2015-05-26), pages 154 - 157, XP093106270 *

Also Published As

Publication number Publication date
CN117413557A (zh) 2024-01-16

Similar Documents

Publication Publication Date Title
US10856135B2 (en) Method and apparatus for network access
WO2021037175A1 (fr) Procédé de gestion de tranche de réseau et dispositif associé
CN112202770B (zh) 设备联网方法及装置、设备、存储介质
WO2023216275A1 (fr) Procédé d'authentification, appareil, dispositif de communication et support de stockage
WO2023216276A1 (fr) Procédé et appareil d'authentification, dispositif de communication et support de stockage
WO2023231018A1 (fr) Procédé et appareil de configuration de justificatif d'identité de primitive de réseau ido personnel (pin), dispositif de communication, et support de stockage
WO2024021142A1 (fr) Procédé et appareil d'authentification d'interface de programme d'application (api), dispositif de communication et support de stockage
WO2024021137A1 (fr) Procédé et appareil d'authentification d'appelant d'api, dispositif de communication et support de stockage
WO2024000121A1 (fr) Procédé et appareil de session ims, dispositif de communication et support de stockage
WO2023240657A1 (fr) Procédé et appareil d'authentification et d'autorisation, dispositif de communication et support de stockage
WO2024000115A1 (fr) Procédé et appareil de session ims, et dispositif de communication et support de stockage
WO2024031399A1 (fr) Procédé et appareil permettant à un ue de rejoindre un pin, et dispositif de communication et support de stockage
WO2023000139A1 (fr) Procédé et appareil de transmission de justificatif d'identité, dispositif de communication et support de stockage
WO2024092801A1 (fr) Procédés et appareils d'authentification, dispositif de communication et support d'enregistrement
WO2023230924A1 (fr) Procédé, appareil d'authentification, et dispositif de communication et support de stockage
WO2023240661A1 (fr) Procédé et appareil d'authentification et d'autorisation, et dispositif de communication et support de stockage
WO2023240659A1 (fr) Procédé et appareil d'authentification, dispositif de communication et support d'enregistrement
WO2023070685A1 (fr) Procédé et appareil de communication par relais, dispositif de communication et support de stockage
WO2024007325A1 (fr) Procédé et appareil d'authentification basé sur un protocole eap, dispositif de communication et support d'enregistrement
WO2023245354A1 (fr) Procédé et appareil de protection de sécurité, dispositif de communication et support de stockage
WO2024093923A1 (fr) Procédé et appareil de communication
WO2024092735A1 (fr) Procédé, système et appareil de commande de communication, dispositif de communication et support de stockage
WO2023184548A1 (fr) Procédé et appareil de traitement d'informations, dispositif de communication et support de stockage
WO2023240574A1 (fr) Procédé et appareil de traitement d'informations, dispositif de communication et support de stockage
WO2023240575A1 (fr) Procédés de communication par relais, appareil de communication, et dispositif de communication

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 202280001718.5

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22941225

Country of ref document: EP

Kind code of ref document: A1