Security authentication method, readable medium and electronic device

Abstract

The present application relates to a security authentication method, a readable medium and an electronic device. The method includes: a first electronic device detects a triggering event that triggers data transmission with a server; the first electronic device sends the identity information of the server to a second electronic device; the second electronic device verifies the identity information of the server received from the first electronic device, and sends the verification result to the first electronic device; the first electronic device determines whether to transmit data with the server based on the received verification result. The technical solution of the present application can effectively utilize the memory resources and computing resources of the resource-rich device to improve the overall efficiency of each device in the device network by having the identity authentication process of the server be completed by the resource-rich device when the lightweight device transmits data to the server, and can also reduce the operating power consumption of the lightweight device and improve the battery life of the lightweight device.

Description

Technical Field

[0001] The present application relates to the field of network security, and in particular to a security authentication method, a readable medium and an electronic device. Background Art

[0002] With the development of Internet information technology, people's daily lives are increasingly dependent on various smart electronic devices. For example, smart home devices provide users with a smarter home life experience; wearable smart electronic devices can plan exercise paths for users and monitor their health status; smartphones can provide users with smart experiences such as online shopping, chatting, office work, and learning. However, the complex network environment and the limited resources of smart electronic devices have put forward higher requirements for network security and power consumption of smart electronic devices.

[0003] For example, for IoT devices, assuming that the IoT devices need to interact with cloud servers for business purposes, in order to ensure a secure connection between the IoT devices and the cloud servers, and to prevent the data exchanged between the IoT devices and the cloud servers from being hijacked or tampered with, security authentication needs to be performed on the IoT devices and the cloud servers respectively. After the authentication is passed, business data can be interacted with. However, since the security authentication of the cloud server on the IoT device requires a large amount of memory and computing resources of the IoT device, when the computing resources and memory resources of the IoT device that establishes a connection with the cloud server are insufficient, the speed of using the IoT device to perform security authentication on the cloud server will be slow, and the performance and battery life of the IoT device will be affected. Summary of the invention

[0004] The embodiments of the present application provide a security authentication method, a readable medium, and an electronic device. The technical solution of the present application can effectively utilize the memory resources and computing resources of the resource-rich device to improve the overall efficiency of each device in the device network by completing the identity authentication process of the server by the resource-rich device when the lightweight device transmits data with the server. In addition, it can also reduce the operating power consumption of the lightweight device and improve the endurance of the lightweight device.

[0005] In a first aspect, an embodiment of the present application provides a security authentication method, including: a first electronic device detects a triggering event that triggers data transmission with a server; the first electronic device sends identity information of the server to a second electronic device; the second electronic device verifies the identity information of the server received from the first electronic device, and sends the verification result to the first electronic device; the first electronic device determines whether to transmit data with the server based on the received verification result.

[0006] For example, in some embodiments, the first electronic device detects a user operation that triggers a request for a video service from a server. In order to establish a network security connection between the first electronic device and the server, the first electronic device needs to verify the identity information of the server. If at this time the computing resources and storage resources of the first electronic device are insufficient to support the first electronic device to complete the verification of the identity information of the server, or even if the computing resources and storage resources of the first electronic device can support the first electronic device to complete the verification of the identity information of the server, but there is a second electronic device that is idle or has sufficient computing resources and storage resources in the local area network, Internet of Things, or device ad hoc network where the first electronic device is located, in order to increase the speed of verifying the identity information of the server and not to affect the main performance of the first electronic device itself, the second electronic device can be used to replace the first electronic device to perform the verification of the identity information of the server.

[0007] In a possible implementation of the first aspect, the method further includes: the identity authentication capability of the second electronic device is greater than that of the first electronic device.

[0008] In a possible implementation of the first aspect, the method further includes: when the first electronic device determines that the identity authentication capability of the second electronic device is greater than that of the first electronic device, the first electronic device sends the identity information of the server to the second electronic device.

[0009] In some embodiments, when the first electronic device determines that the computing power and storage power of the second electronic device are greater than those of the first electronic device, the first electronic device sends the identity information of the server to the second electronic device.

[0010] In some embodiments, the first electronic device sends the identity information of the server to the second electronic device when determining that one of the computing capability and the storage capability of the second electronic device is greater than that of the first electronic device.

[0011] In some embodiments, the first electronic device sends the identity information of the server to the second electronic device when it is determined that the combined capacity of the computing power and storage capacity of the second electronic device is greater than that of the first electronic device. The combined capacity of computing power and storage capacity refers to the capacity obtained after comprehensive evaluation of computing power and storage capacity. For example, the computing power of the second electronic device is less than that of the first electronic device, but the storage capacity of the second electronic device is greater than that of the first electronic device, and the combined capacity of the computing power and storage capacity of the second electronic device is greater than that of the first electronic device. In this case, the first electronic device sends the identity information of the server to the second electronic device.

[0012] In some embodiments, the computing capacity and storage capacity are the overall computing capacity and storage capacity of the first electronic device and the second electronic device respectively.

[0013] In some embodiments, the computing capacity and storage capacity are computing capacity and storage capacity available to the first electronic device and the second electronic device, respectively.

[0014] In a possible implementation of the first aspect, the method further includes: the identity authentication capability is determined based on at least one of computing capability, storage capability, and security capability.

[0015] For example, in some embodiments, identity authentication capabilities include computing capabilities, storage capabilities, and security capabilities.

[0016] As another example, in some embodiments, identity authentication capability is comprehensively assessed based on computing capability, storage capability, and security capability.

[0017] In a possible implementation of the first aspect, the method further includes: the computing capability includes at least one of the computing capability of a central processing unit, the computing capability of a graphics processing unit, and the computing capability of an image signal processor.

[0018] For example, in some embodiments, the first electronic device and the second electronic device each include a central processing unit (CPU), a graphics processing unit (GPU), and an image signal processor (ISP), then the computing power of each of the first electronic device and the second electronic device is the sum of the CPU computing power, the GPU computing power, and the ISP computing power.

[0019] In a possible implementation of the first aspect, the method further includes: the second electronic device verifies the identity information of the server received from the first electronic device, including:

[0020] The second electronic device verifies the identity information of the server based on the root certificate received from the first electronic device.

[0021] In a possible implementation of the first aspect, the method further includes: the first electronic device includes a plurality of applications;

[0022] The first electronic device detects a triggering event that triggers data transmission with a server, including: at least one of the plurality of applications of the first electronic device detects a triggering event that triggers data transmission with a server;

[0023] The above method further includes:

[0024] When detecting a triggering event that triggers data transmission with a server, at least one of the multiple applications of the first electronic device obtains a root certificate and sends the root certificate to the second electronic device.

[0025] In a possible implementation of the first aspect, the method further includes: the identity information of the server includes a server certificate issued by a digital certificate issuing authority to the server, and the verification result of the identity information of the server by the second electronic device is obtained in the following manner:

[0026] The second electronic device verifies the server certificate received from the first electronic device based on the root certificate received from the first electronic device, and obtains a verification result of the server certificate by the second electronic device.

[0027] For example, in some embodiments, when at least one of the video application, shopping application, game application, and chat application of the first electronic device detects a trigger event that triggers data transmission with the server, the same root certificate stored in the first electronic device can be obtained from the storage space of the first electronic device, thereby using the same root certificate to verify the identity information of the server. In this way, by normalizing the management of root certificates, the first electronic device does not need to store multiple root certificates corresponding to multiple applications, which can reduce the memory usage of the first electronic device.

[0028] In a possible implementation of the first aspect above, the method above also includes: the server certificate includes a digital document, a signature generated by encrypting a digital summary of the digital document calculated by a digital certificate issuing authority based on a preset summary algorithm, and a preset summary algorithm.

[0029] In a possible implementation of the first aspect, the method further includes: the second electronic device verifies the identity information of the server received from the first electronic device, including: the second electronic device decrypts the signature in the server certificate based on the root certificate received from the first electronic device to obtain a first digital summary of the signature;

[0030] Performing hash calculation on the digital document based on a preset digest algorithm to obtain a second digital digest;

[0031] The second digital digest is compared with the first digital digest, and a verification result of the server certificate by the second electronic device is determined based on the comparison result.

[0032] In a possible implementation of the first aspect, the method further includes: the first electronic device detecting a triggering event that triggers data transmission with the server, including:

[0033] The first electronic device detects a user operation that triggers data transmission with a server, where the user operation is used to trigger the first electronic device to send a network security connection request to the server.

[0034] In a possible implementation of the first aspect, the method further includes: the first electronic device determines whether to perform data transmission with the server based on the verification result, including:

[0035] When the first electronic device determines that the identity of the server is legitimate based on the verification result, the first electronic device establishes a network security connection with the server;

[0036] The first electronic device performs data transmission with the server via the established network security connection.

[0037] In a possible implementation of the first aspect, the method further includes: the network security connection is a secure socket layer protocol connection or a transport layer security protocol connection.

[0038] In a possible implementation of the first aspect, the method further includes: an operating system of the first electronic device is a lightweight embedded operating system.

[0039] In a possible implementation of the first aspect, the method further includes: the operating system of the second electronic device includes Android TM Operating system, Hongmeng TM Operating System and IOS TM At least one of the operating systems.

[0040] In a second aspect, an embodiment of the present application provides a security authentication method, including:

[0041] The first electronic device detects a triggering event that triggers data transmission with the server;

[0042] The first electronic device sends the identity information of the server to the second electronic device;

[0043] The first electronic device determines whether to perform data transmission with the server based on the verification result received from the second electronic device.

[0044] In a possible implementation of the second aspect, the method further includes: the identity authentication capability of the second electronic device is greater than that of the first electronic device.

[0045] In a possible implementation of the second aspect, the method further includes: when the first electronic device determines that the identity authentication capability of the second electronic device is greater than that of the first electronic device, the first electronic device sends the identity information of the server to the second electronic device.

[0046] In a possible implementation of the second aspect, the method further includes: the identity authentication capability is obtained based on at least one of computing capability, storage capability and security capability.

[0047] In a possible implementation of the second aspect, the method further includes: the computing capability includes at least one of the computing capability of a central processing unit, the computing capability of a graphics processing unit, and the computing capability of an image signal processor.

[0048] In a possible implementation of the second aspect, the method further includes: the first electronic device includes a plurality of applications;

[0049] The first electronic device detects a triggering event that triggers data transmission with the server, including:

[0050] At least one of the plurality of applications of the first electronic device detects a triggering event that triggers data transmission with the server;

[0051] The above method further includes:

[0052] At least one of the multiple applications of the first electronic device, when detecting a triggering event that triggers data transmission with the server, obtains a root certificate and sends the root certificate to the second electronic device, where the root certificate is used by the second electronic device to verify the identity information of the server. In a possible implementation of the second aspect, the method further includes: the first electronic device detecting a triggering event that triggers data transmission with the server, including:

[0053] The first electronic device detects a user operation that triggers data transmission with a server, where the user operation is used to trigger the first electronic device to send a network security connection request to the server.

[0054] In a possible implementation of the second aspect, the method further includes: the first electronic device determines whether to perform data transmission with the server based on the verification result, including:

[0055] When the first electronic device determines that the identity of the server is legitimate based on the verification result, the first electronic device establishes a network security connection with the server;

[0056] The first electronic device performs data transmission with the server via the established network security connection.

[0057] In a possible implementation of the second aspect, the method further includes: the network security connection is a secure socket layer protocol connection or a transport layer security protocol connection.

[0058] In a possible implementation of the second aspect, the method further includes: an operating system of the first electronic device is a lightweight embedded operating system.

[0059] In a third aspect, an embodiment of the present application provides a security authentication method, including:

[0060] The second electronic device verifies the identity information of the server received from the first electronic device, and sends the verification result to the first electronic device.

[0061] In a possible implementation of the third aspect, the method further includes: the second electronic device verifies the identity information of the server received from the first electronic device, including:

[0062] The second electronic device verifies the identity information of the server based on the root certificate received from the first electronic device.

[0063] In a possible implementation of the third aspect, the method further includes: the identity information of the server includes a server certificate issued by a digital certificate issuing authority to the server, and the verification result of the identity information of the server by the second electronic device is obtained in the following manner:

[0064] The second electronic device verifies the server certificate received from the first electronic device based on the root certificate received from the first electronic device, and obtains a verification result of the server certificate by the second electronic device.

[0065] In a possible implementation of the third aspect above, the method above also includes: the server certificate includes a digital document, a signature generated by encrypting a digital summary of the digital document calculated by a preset digest algorithm by a digital certificate issuing authority, and a preset digest algorithm.

[0066] In a possible implementation of the third aspect, the method further includes: the second electronic device verifies the identity information of the server received from the first electronic device, including: the second electronic device decrypts the signature in the server certificate based on the root certificate received from the first electronic device to obtain a first digital summary of the signature;

[0067] Performing hash calculation on the digital document based on a preset digest algorithm to obtain a second digital digest;

[0068] The second digital digest is compared with the first digital digest, and a verification result of the server certificate by the second electronic device is determined based on the comparison result.

[0069] In a possible implementation of the third aspect, the method further includes: the operating system of the second electronic device includes Android TM Operating system, Hongmeng TM Operating System and IOS TM At least one of the operating systems.

[0070] In a fourth aspect, an embodiment of the present application provides a readable medium having instructions stored thereon, which, when executed on an electronic device, enables the electronic device to execute any one of the security authentication methods of the first to third aspects and various possible implementations of the first to third aspects.

[0071] In a fifth aspect, an embodiment of the present application provides an electronic device, including:

[0072] a memory for storing instructions to be executed by one or more processors of the electronic device, and

[0073] The processor is one of the processors of the electronic device, and is used to execute any security authentication method in the above-mentioned first to third aspects and various possible implementations of the first to third aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0074] Figure 1 According to some embodiments of the present application, a schematic diagram of a scenario of network security authentication between a client device and a server is shown;

[0075] Figure 2 The process of establishing a secure connection between a lightweight device and a server using the SSL protocol is shown;

[0076] Figure 3 According to some embodiments of the present application, a schematic diagram of the hardware structure of a client device is shown;

[0077] Figure 4 According to some embodiments of the present application, a schematic diagram of a software architecture of a client device is shown;

[0078] Figure 5 According to some embodiments of the present application, a process of establishing a secure connection between a smart watch and a server using the SSL protocol is shown;

[0079] FIG6( a ) shows a schematic diagram of a network in which a smart watch is connected to a server via a local area network according to some embodiments of the present application;

[0080] FIG6( b ) is a schematic diagram showing automatic networking of multiple devices according to some embodiments of the present application;

[0081] Figure 7 According to some embodiments of the present application, a flow chart of a digital certificate issuing authority issuing a digital certificate for a server is shown;

[0082] Figure 8 According to some embodiments of the present application, a flow chart of a smart watch requesting a video service from a server is shown;

[0083] Fig. 9According to some embodiments of the present application, another flow chart of a smart watch requesting a video service from a server is shown;

[0084] Fig.10 According to some embodiments of the present application, a structural block diagram of a system is shown. DETAILED DESCRIPTION

[0085] The illustrative embodiments of the present application include, but are not limited to, a security authentication method, a readable medium, and an electronic device.

[0086] In order to better understand the technical solution of the present application, some terms involved in the embodiments of the present application are first explained.

[0087] (1) Digital Certificate

[0088] A digital certificate is an electronic certificate issued by a digital certificate authority (CA) to identify the identity of the digital certificate holder (such as a client device). It provides a way to verify the identity of the communication peer. A digital certificate may include the public key information assigned by the CA to the digital certificate holder, the identity information of the digital certificate holder, and the signature information of the CA.

[0089] Among them, CA is the authority responsible for issuing and managing digital certificates. As a trusted third party in the network, CA can verify the identity of the digital certificate application device, manage and update digital certificates, maintain digital certificate revocation lists, etc.

[0090] For example, if the first client device needs to obtain a digital certificate of its own, the first client device first applies to the CA. After the CA determines the identity of the first client device, it allocates a public key to the first client device, and the CA binds the public key with the identity information of the first client device, signs it, and then forms a digital certificate and sends it to the first client device (applicant).

[0091] For another example, if the second client device needs to verify the authenticity of the first digital certificate of the first client device, the second client device verifies the signature on the first digital certificate using the CA's public key. If the verification is successful, the first digital certificate is considered valid.

[0092] (2) Root Certificate

[0093] The root certificate is the basis for the CA certification center to establish a trust relationship with other electronic devices. It is a digital certificate issued by the CA to itself and the starting point of the trust chain. To verify the authenticity of a certificate (that is, to verify whether the signature of the CA center on the certificate information is valid), it is necessary to verify it with the public key of the CA center. The public key of the CA center exists in the certificate that signed this certificate, that is, the public key of the CA center exists in the root certificate issued by the CA for itself. Therefore, in order for an electronic device to verify the authenticity of a certificate, it is necessary to pre-install a root certificate in the electronic device.

[0094] (3) SSL (Secure Sockets Layer) protocol

[0095] The SSL protocol is a protocol layer located between the reliable connection-oriented network layer protocol and the application layer protocol. SSL achieves secure communication between the client and the server through mutual authentication, using digital signatures to ensure integrity, and using encryption to ensure privacy.

[0096] (4) TLS (Transport Layer Security) protocol

[0097] The TLS protocol is used to provide confidentiality and data integrity between two applications.

[0098] The technical solution of the present application is described in detail below with reference to the accompanying drawings.

[0099] First combine Figure 1 Introduce the scenarios to which the technical solution of this application is applicable. Figure 1 According to some embodiments of the present application, a schematic diagram of a scenario of security authentication between a client device and a server is shown, which includes a lightweight device 10, a resource-rich device 20, a server 300, and a digital certificate issuing authority 400.

[0100] In some embodiments, the lightweight device 10 has limited memory resources and computing resources, and can run a lightweight operating system, such as a lightweight embedded operating system, to implement relatively simple functions. Figure 1 The camera 110 shown can capture abnormal images and upload the surveillance video to the cloud server. Figure 1 The smart watch 100 shown can measure the user's heart rate, blood oxygen saturation, display time, etc.

[0101] In some embodiments, the resource-rich device 20 has more memory resources and computing resources than the lightweight device 10, and can run Android TM , Hongmeng TM etc. operating systems to achieve more complex functions. For example, Figure 1The smart TV 210 shown can implement functions such as AI voice control, video on demand, and screen projection. Figure 1 The smart phone 200 shown can not only make and receive calls and send and receive messages, but also install multiple applications (APPs) to provide users with multiple functions such as chatting, shopping, games, audio and video, office work, navigation, etc.

[0102] In some embodiments, the lightweight device 10 and the resource-rich device 20 can communicate with the server 300 to request services from the server 300. For example, the lightweight device 10 and the resource-rich device 20 send wireless signals to the server 300 through a wireless communication link, requesting the server 300 to process specific business requirements of the lightweight device 10 and the resource-rich device 20, such as user registration, data acquisition and monitoring, etc.

[0103] In some embodiments, the digital certificate issuing authority 400 can act as a trusted third party in the local area network or Internet of Things where the lightweight device 10 and the resource-rich device 20 are located, and can issue, manage and update digital certificates for the lightweight device 10 and the resource-rich device 20, as well as maintain a digital certificate revocation list, etc.

[0104] In some embodiments of the related technical solution, in order to ensure the secure transmission of data exchanged between the lightweight device 10 and the server 300 and to prevent the data exchanged between the lightweight device 10 and the server 300 from being intercepted or tampered with, it is necessary to establish a secure and reliable connection between the lightweight device 10 and the server 300. For example, the data transmitted between the lightweight device 10 and the server 300 is encrypted using the SSL protocol to ensure the security of the transmitted data. The process of establishing a secure connection between the lightweight device 10 and the server 300 using the SSL protocol is as follows: Figure 2 As shown, the specific steps include:

[0105] Step 201: the lightweight device 10 sends a lightweight device 10 handshake request message "ClientHello" to the server 300, which carries information such as the encryption suite candidate list, compression algorithm candidate list, random number, and extension field of the lightweight device 10.

[0106] Step 202 : the server 300 sends a server 300 handshake request message “Server Hello” to the lightweight device 10 in response to the received lightweight device 10 handshake request message “Client Hello”.

[0107] Step 203 : the server 300 sends the server certificate “ServerCertificate” of the server 300 to the lightweight device 10 , so that the lightweight device 10 can authenticate the server 300 .

[0108] Step 204: the server 300 sends a server 300 handshake request completion message “ServerHello Done” to the lightweight device 10, to notify the lightweight device 10 that the authentication preparation work on the server 300 side has been completed.

[0109] Step 205: The lightweight device 10 verifies the received certificate of the server 300 to verify whether the identity of the server 300 is legitimate, for example, verify whether the certificate of the server 300 is revoked, whether it is within the valid time range, etc.

[0110] Step 206: The lightweight device 10 sends a lightweight device 10 key exchange message “ClientKey Exchange” to the server 300. That is, after the identity legitimacy of the server 300 is verified, the lightweight device 10 calculates and generates a random number Pre-master, encrypts it with a public key, and sends it to the server 300.

[0111] Step 207: The lightweight device 10 sends a message “Change CiperSpec” for changing encryption attributes to the server 300 to notify the server 300 that subsequent communications will all use the negotiated communication key and encryption algorithm for encrypted communications.

[0112] Step 208: The server 300 sends a message “Change CiperSpec” for changing encryption attributes to the lightweight device 10, so as to inform the lightweight device 10 that subsequent communications will adopt the negotiated key and algorithm for encrypted communications.

[0113] Step 209 : The server 300 sends a completion message “Finished” to the lightweight device 10 .

[0114] The server 300 calculates the hash value of the key exchange message “Client KeyExchange” received from the lightweight device 10 , verifies the correctness of the data and key sent by the lightweight device 10 , and completes the handshake if the verification is successful.

[0115] It can be understood that after the lightweight device 10 and the server 300 complete the handshake, they start to use the negotiated key and algorithm for encrypted communication.

[0116] In the process of transmitting data between the lightweight device 10 and the server 300 through the SSL protocol, the lightweight device 10 needs to verify the identity information of the server 300. However, for lightweight devices 10 with low computing power, the process of verifying the identity information of the server 300 will occupy a large amount of memory and computing resources, and have a great impact on the performance of the lightweight device 10.

[0117] The technical solution provided in the embodiment of the present application is to reduce the computing burden of the lightweight device 10 and reduce the memory occupancy of the lightweight device 10. When it is determined that there is a rich resource device 20 with high computing power and large storage space in the network to which the lightweight device 10 belongs, the lightweight device 10 can send the root certificate issued by the digital certificate issuing authority 400 to the rich resource device 20, and forward the digital certificate issued by the server 300 and carrying the identity information of the server 300 (hereinafter referred to as the "server certificate" for ease of description) to the rich resource device 20 for parsing to authenticate the legitimacy of the identity of the server 300. Then, the rich resource device 20 forwards the result of the identity authentication of the server 300 to the lightweight device 10, so that the lightweight device 10 can determine whether to interact with the server 300 for business data based on the result of the authentication.

[0118] Compared with the related technical solutions, in which the root certificate is pre-set by the lightweight device 10 and the identity information of the server 300 is directly verified by the lightweight device 10, the technical solution of the present application can transmit the root certificate and other data pre-set by the lightweight device 10 to the rich resource device 20 when it is determined that other rich resource devices 20 are connected to the same network. When the lightweight device 10 interacts with the server 300, the parsing of the server certificate is completed by the rich resource device 20, which can reduce the resource occupancy of the lightweight device 10, effectively utilize the memory resources and computing resources of the rich resource device 20, avoid resource waste, and also reduce the operating power consumption of the lightweight device 10.

[0119] In some embodiments, the lightweight device 10 includes but is not limited to Figure 1 The smart watch 100 and the smart camera 110 shown in the figure, as well as the cleaning robot, smart speakers, smart door locks, smart rice cookers, smart alarm clocks, smart sockets and other electronic devices with low computing power that are not shown in the figure. In some embodiments, the lightweight device 10 runs a lightweight embedded system.

[0120] In some embodiments, the resource-rich device 20 includes but is not limited to Figure 1The smart TV 210, the smart phone 200 shown, and the laptop computer, desktop computer, tablet computer, a television set having one or more processors embedded or coupled thereto, or other electronic devices with high computing power capable of accessing the Internet, which are not shown. In some embodiments, the resource-rich device 20 runs Android TM , Hongmeng TM And other operating systems.

[0121] Figure 3 According to an embodiment of the present application, a schematic diagram of the hardware structure of a client device is shown. The client device can be a lightweight device 10 or a resource-rich device 20. The hardware structure of the client device is introduced below by taking the lightweight device 10 as an example.

[0122] The client device 10 can execute the security authentication method provided in the embodiment of the present application. Figure 3 In the drawings, similar parts have the same reference numerals. Figure 3 As shown, the client device 10 includes a display screen 122, a processor 103, a micro control unit (MCU) 114, a memory 105, a communication module 116, a sensor module 118, a power module 111, and the like.

[0123] The display screen 122 can be used to display information input by the user or prompt information provided to the user and various menus on the client device 10. For example, the display screen 122 can be used to display a video downloaded by the client device 10 from the server 300. For another example, when the client device 10 is a smart camera, the display screen 122 can be used to display abnormal images captured by the smart camera and surveillance videos stored in the server 300.

[0124] The processor 103 includes a plurality of processing units, which can be used to verify the legitimacy of the identity of the server 300 that has established a reliable connection with the client device 10. For example, the client device 10 determines whether there is access to a rich resource device in the same network. If there is access to a rich resource device, the client device 10 controls the client device 10 through the processor 103 to forward the server certificate issued by the server 300 to the rich resource device for analysis; if there is no access to a rich resource device in the same network, the client device 10 directly analyzes the server certificate issued by the server 300 through the processor 103.

[0125] The micro control unit 114 is used to control the sensor module 118 , perform operations on the data collected by the sensor module 118 , and communicate with the processor 103 .

[0126] The memory 105 is used to store software programs and data. The processor 103 executes various functional applications and data processing of the client device 10 by running the software programs and data stored in the memory 105. For example, in some embodiments of the present application, the memory 105 can store the root certificate issued by the digital certificate authority of the client device 10. At the same time, the memory 105 can also store the user's registration information, login information, etc.

[0127] The communication module 116 can be used to enable the client device 10 to communicate with other electronic devices and connect to the network through other electronic devices. For example, in some embodiments of the present application, the client device 10 can establish a communication connection with the server 300 through a wireless fidelity (WiFi) network, Bluetooth (BT), near field communication (NFC), etc., and obtain a server certificate issued by the server 300 from the server 300. For another example, the client device 10 determines whether there is access to a rich resource device in the same network. If there is access to a rich resource device, the client device 10 sends the root certificate preset by the client device 10 and the server certificate issued by the server 300 to the rich resource device through the communication module 116, and receives the analysis result of the server certificate by the rich resource device through the communication module 116. After determining that the identity of the server 300 is legal, the client device 10 interacts with the server 300 through the communication module 116.

[0128] The power module 111 is used to supply power to various components of the client device 10. In some embodiments, the power module 111 includes a battery.

[0129] Understandably, Figure 3 What is shown is merely an exemplary hardware structure for realizing the functions of the client device 10 in the technical solution of the present application. Client devices 10 having other structures and realizing similar functions are also applicable to the technical solution of the present application, and are not limited here.

[0130] Figure 4 According to an embodiment of the present application, a schematic diagram of the software architecture of a client device is shown. The client device can be a lightweight device 10 or a resource-rich device 20. The software architecture of the client device will be introduced below by taking the lightweight device 10 as an example. Figure 4 As shown, the software architecture of the client device 10 includes an application layer 301 , a system layer 302 and a driver layer 303 .

[0131] like Figure 4As shown, the application layer 301 may include applications such as camera 301a, calendar 301b, map 301c, music 301d, short message 301e, navigation 301f, video 301g, gallery 301h, etc. For example, when the client device is a smart watch 100, after the smart watch 100 receives a user click on the icon of a video APP, in response to the user's click operation, the video APP is opened to play the video for the user.

[0132] The system layer 302 may include multiple functional modules. Figure 4 As shown, the system layer 302 includes a certificate management module 302a, which is used to import the root certificate pre-installed in the client device 10 into the opened application after the application of the client device 10 is opened, when there is a rich resource device 20 in the same network to which the client device 10 belongs, in response to a certificate import request sent by the application, and call the driver layer 303 to drive the communication module 116 of the client device 10 to send the root certificate pre-installed in the client device 10 and the server certificate issued to the client device 10 by the server 300 to the rich resource device 20 in the same network as the client device 10.

[0133] In some embodiments, the system layer 302 also includes Figure 4 Functional modules not shown in the figure, such as: surface manager, media library, 3D graphics processing library (such as OpenGL ES), etc. The surface manager is used to manage the display function of the client device 10, and provide fusion of 2D and 3D layers for multiple applications of the client device 10. The media library supports playback and recording of multiple commonly used audio and video formats, as well as static image files, etc. The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, synthesis and layer processing, etc.

[0134] The driver layer 303 includes a secure channel 303a, a WiFi driver 303b, a Bluetooth driver 303c, etc. Among them, the WiFi driver 303b and the Bluetooth driver 303c are respectively used to drive the WiFi module and the Bluetooth module in the communication module 116 of the client device 10 to enable the communication functions of the WiFi module and the Bluetooth module. The secure channel 303a is used to encrypt the data communicated between the client device 10 and other electronic devices to ensure the security of data transmission between the client device 10 and other electronic devices.

[0135] In some embodiments, the driving layer 303 further includes Figure 4 Display driver, camera driver, audio driver, sensor driver, etc. not shown.

[0136] Understandably, Figure 4 What is shown is merely an exemplary software architecture for realizing the functions of the client device 10 in the technical solution of the present application. Client devices 10 having other structures and capable of realizing similar functions are also applicable to the technical solution of the present application and are not limited here.

[0137] The following will be Figure 1 As shown in the figure, the smart watch 100 and the server 300 use the SSL protocol to establish a secure connection as an example. Figures 5 to 7 , the security authentication method provided in the embodiment of the present application is introduced.

[0138] It is understandable that in order to achieve secure communication between the smart watch 100 and the server 300, other communication protocols may be used for communication between the smart watch 100 and the server 300, such as the TLS protocol, which is not limited in this application.

[0139] As mentioned above, in the process of establishing a secure connection between the smart watch 100 and the server 300 using the SSL protocol, the smart watch 100 can parse the server certificate through the rich resource device 20 to verify the legitimacy of the identity of the server 300. In this way, the memory resources and computing resources occupied by the smart watch 100 for parsing the server certificate can be released, so that the performance of the smart watch 100 is not affected, and the power consumption of the smart watch 100 can be reduced.

[0140] Specifically, Figure 5 As shown, the process of establishing a secure connection between the smart watch 100 and the server 300 using the SSL protocol includes the following steps:

[0141] Step 501: The smart watch 100 sends a handshake request message of the smart watch 100 to the server 300. In some embodiments, the message carries information such as the encryption suite candidate list, the compression algorithm candidate list, the random number, and the extension field of the smart watch 100.

[0142] For example, in some embodiments, the handshake request message of the smart watch 100 (hereinafter referred to as the handshake message) sent by the smart watch 100 to the server 300 includes the following fields as shown in Table 1:

[0143] Field Name Numeric value or field length Handshake Type Ox01 Length 3Bytes Version 2Bytes Random 32Bytes Session ID 1 Byte Cipher Suites 2Bytes Compression methods 2Bytes Extension 117Bytes hostname 54Bytes signature_algorithms 26Bytes supported_elliptic_curves 12Bytes supported_point_formats 6Bytes max_fragment_length 5Bytes encrypt_then_mac 4Bytes extended_ms 4Bytes session_ticket 4Bytes

[0144] Table 1

[0145] The fields in Table 1 are described as follows:

[0146] Handshake Type: Handshake type, Ox01 means Client Hello, that is, the smart watch 100 sends a handshake message to the server 300.

[0147] Length: Handshake message length.

[0148] Version: the version number of the highest version of the SSL protocol supported by the smart watch 100.

[0149] Random: Random number sequence, consisting of a 4-byte UNIX format timestamp and a 28-byte secure random number, with a total length of 32 bytes.

[0150] Session ID: In the subsequent connection process, this field will save the unique identifier of the session. The server 300 can use this field to find the corresponding session status in the cache. If the smart watch 100 and the server 300 close the session, and the smart watch 100 wants to re-initiate the session, this field can be used by both parties to negotiate whether to perform a re-handshake process.

[0151] Cipher Suites: Cipher suites supported by the smart watch 100. Since the smart watch 100 and the server 300 have different support levels for some encryption and decryption algorithms, but the SSL protocol transmission process requires that the smart watch 100 and the server 300 must use the same encryption and decryption algorithm. Therefore, the smart watch 100 must first inform the server 300 which cipher suites it supports, and the smart watch 100 sends the supported cipher suite list to the server 300.

[0152] For example, in some embodiments, the cryptographic suites supported by the smart watch 100 include, but are not limited to, one or more of the following cryptographic suites:

[0153] MBEDTLS_TLS_ECDHE_ECDSA WITH_AES_256_GCM_SHA384;

[0154] MBEDTLS_TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;

[0155] MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_256_CCM;

[0156] MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_256CBC SHA384;

[0157] MBEDTLS_TLS_ECDHE_RSA_WITH_AES_256CBC_SHA384;

[0158] MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA;

[0159] MBEDTLS_TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA;

[0160] MBEDTLS_TLS_PSK_WITH_AES_128_CCM_8.

[0161] Compression methods: Compression method, indicating the compression methods supported by the smart watch 100.

[0162] Extension: Extended option. In the SSL protocol, the extended option appears at the end of the Client Hello message in the form of an extension block. The extension block consists of multiple extension items, each of which consists of a 2-byte extension identifier and corresponding data.

[0163] In the embodiment shown in Table 1, the following extension items are included:

[0164] hostname: the name of the object that the smart watch 100 wants to access.

[0165] signature_algorithms: the smart watch 100 notifies the server 300 of the signature algorithms and one-way hash functions that it supports.

[0166] supported_elliptic_curves: the smart watch 100 notifies the server 300 of the list of elliptic curves it supports.

[0167] supported_point_formats: the smart watch 100 notifies the server 300 of the elliptic curve coordinate point types supported by the smart watch 100.

[0168] max_fragment_length: the longest fragment length supported by the smart watch 100.

[0169] encrypt_then_mac: Uses the MAC-then-encryption method for the "authentication+encryption" algorithm.

[0170] extended_ms: key calculation method.

[0171] session_ticket: The smartwatch 100 supports stateless session recovery.

[0172] It can be understood that what is shown in Table 1 is only an example of a handshake request message sent by the smart watch 100 to the server 300, and the present application is not limited thereto.

[0173] Step 502: The server 300 sends a server 300 handshake message to the smart watch 100 in response to the received handshake request information sent by the smart watch 100. In some embodiments, the server 300 handshake message carries information such as the server 300's encryption suite candidate list, compression algorithm candidate list, random number, and extension field.

[0174] For example, in some embodiments, the handshake message of the server 300 sent by the server 300 to the smart watch 100 includes the following fields as shown in Table 2:

[0175] Field Name Numeric value or field length Handshake Type Ox02 Length 3Bytes Version 2Bytes Random 32Bytes Session ID 1 Byte Ciphersuite 2Bytes Extension 2Bytes

[0176] Table 2

[0177] The fields in Table 2 are described as follows:

[0178] Handshake Type: handshake type, 0x2 means ServerHello, that is, the handshake message sent by the server 300 to the smart watch 100.

[0179] Length: Handshake message length.

[0180] Version: the version number of the highest version of the SSL protocol supported by the server 300.

[0181] Random: Random number sequence, also composed of a 4-byte UNIX format timestamp and a 28-byte secure random number, with a total length of 32 bytes.

[0182] Session ID: Session ID.

[0183] Ciphersuite: The cipher suite selected by server 300 after negotiation.

[0184] Extension: extension options of server 300.

[0185] It can be understood that what is shown in Table 2 is only an example of a handshake message of the server 300 sent by the server 300 to the smart watch 100, and the present application is not limited thereto.

[0186] Step 503: The server 300 sends a server certificate to the smart watch 100. In some embodiments, the server certificate is Figure 1The digital certificate issued by the digital certificate issuing authority 400 to the server 300 includes the public key information of the server 300, the identity information of the server 300, and the signature information of the digital certificate issuing authority 400. The specific process of the digital certificate issuing authority 400 issuing the digital certificate to the server 300 will be described in detail below.

[0187] For example, in some embodiments, the server certificate sent by the server 300 to the smart watch 100 includes the following fields as shown in Table 3:

[0188] Field Name Numeric value or field length Handshake Type OxY Length 3Bytes Certificates Length 3Bytes Certificates 3Bytes

[0189] Table 3

[0190] The fields in Table 3 are described as follows:

[0191] Handshake Type: Handshake type. Ox0b means Certificate, indicating the server certificate.

[0192] Length: Handshake message length.

[0193] Certificates Length: The total length of the server certificate.

[0194] Certificates: Server certificate content.

[0195] Some server certificates include the following:

[0196] Certificate Length: The total length of the server certificate.

[0197] Version: The version of the server certificate.

[0198] SerialNumber: the serial number of the server certificate assigned by the certificate issuer (eg, digital certificate authority 400).

[0199] Signature: Certificate signature algorithm, including the algorithm used by the certificate issuer to sign the certificate.

[0200] Issure: Issuer ID, which identifies the entity that signed and issued the certificate.

[0201] Validity: Validity period, including the effective date and expiration date of the server certificate.

[0202] Subject: The name of the server's certificate subject, used to identify the entity that obtained the certificate.

[0203] Subject Public Key Info: Public key, used to indicate the user's public key information.

[0204] Extensions: One or more extension fields.

[0205] Algorithm Identifier: Identifies the algorithm, parameters, and data used by the certificate issuer to sign the certificate. The specific fields are as follows:

[0206] Algorithm Id: Same as Signature, certificate signature algorithm.

[0207] Padding: The padding method used to fill the data before signing.

[0208] Encrypted: This field is obtained by performing a hash calculation on the certificate information and then using the private key to digitally sign the hash.

[0209] It can be understood that Table 3 is merely an example of a server certificate sent by the server 300 to the smart watch 100, and the present application is not limited thereto.

[0210] Step 504: The server 300 sends a handshake request completion message to the smart watch 100, which is used to notify the smart watch 100 that the authentication preparation work on the server 300 side has been completed.

[0211] After the server 300 sends all the handshake information to the smart watch 100, it will send a handshake request completion message to indicate that the server 300 has completed sending the handshake message.

[0212] For example, in some embodiments, the handshake request completion message of the smart watch 100 sent by the server 300 to the smart watch 100 includes the following fields as shown in Table 4:

[0213] Field Name Numeric value or field length Handshake Type OxO Length 3Bytes

[0214] Table 4

[0215] The fields in Table 4 are described as follows:

[0216] Handshake Type: Handshake type. Ox0e means ServerHelloDone, indicating that the handshake request of server 300 is completed.

[0217] Length: Handshake message length.

[0218] It can be understood that Table 4 is merely an example of a handshake request completion message sent by the server 300 to the smart watch 100, and the present application is not limited thereto.

[0219] Step 505: The smart watch 100 determines whether there is a rich resource device 20 in the same network. If yes, it means there is a rich resource device 20 in the same network of the smart watch 100, and then proceeds to step 507; otherwise, it means there is no rich resource device 20 in the same network of the smart watch 100, and then proceeds to step 506.

[0220] For example, in the embodiment shown in FIG6(a), the smart watch 100 and the device A, the device B, and the device C are located in the same local area network, and the smart watch 100 and the device A, the device B, and the device C are connected to the server 300 through the router 500. For another example, the smart watch 100 and the device A, the device B, and the device C are located in the same Internet of Things. In some other embodiments, the smart watch 100 and the device A, the device B, and the device C can also form a distributed device ad hoc network as shown in FIG6(b). For example, in some embodiments, the smart watch 100, the device A, the device B, and the device C establish a distributed device ad hoc network based on WIFI, the smart watch 100 and one of the devices A, the device B, and the device C are connected to the WIFI router, and the other devices are connected to the device connected to the WIFI router through their respective WIFI modules.

[0221] In some embodiments, when any one of the smart watch 100, device A, device B, and device C in the same network is started, a message to which fields representing the current device information, resource usage information, and available computing power information of each device in the network are added can be broadcast to other electronic devices in the network. Other electronic devices can parse the received broadcast information and extract fields representing the device information, resource usage information, and available computing power information, etc., thereby determining whether the corresponding electronic device is a rich-resource device based on the content of fields such as resource usage information and available computing power information.

[0222] In some embodiments, electronic devices in the same network may be divided into capability levels. For example, it is assumed that the smart watch 100, device A, device B, and device C form a virtual super terminal system. A distributed operating system is installed on at least one electronic device in the virtual super terminal, and the distributed operating system has a certificate management module, which can classify the various capabilities of each electronic device according to a unified capability classification standard, and when a certain electronic device needs to verify the server certificate, the electronic device with the best capability can be selected from each electronic device as the resource-rich device that actually performs the server certificate verification operation.

[0223] It is understandable that the resource-rich device selected above that actually performs the server certificate verification operation and the electronic device that originally needs to verify the server certificate are mutually trusted devices. For example, in some embodiments, the various electronic devices of the virtual super terminal system are uniformly authorized and authenticated by the user, so that the electronic devices are mutually trusted devices. For example, each electronic device can complete the unified authorization authentication through the user's PIN code authentication, face recognition authentication, fingerprint authentication, voiceprint authentication, etc., which is not limited here.

[0224] In addition, the unified capability grading standards adopted by the above-mentioned distributed operating system may include but are not limited to: computing capability levels of 0-18, recorded as P0-P18; storage capability levels of 0-12, recorded as S0-S12; security capability levels of 0-8, recorded as T0-T8, etc. The computing capability level of the electronic device can be used as the capability level of each electronic device, or the capability level of the electronic device can be divided by comprehensively considering the computing capability, storage capability, security capability and other capabilities of the electronic device. Finally, the device with a higher capability level is determined as a resource-rich device.

[0225] In some embodiments, the computing capability of the electronic device includes at least one of the computing capability of a central processing unit, the computing capability of a graphics processing unit, and the computing capability of an image signal processor.

[0226] For example, in some embodiments, the electronic device includes a central processing unit (CPU), a graphics processing unit (GPU) and an image signal processor (ISP), then the computing power of the electronic device is the sum of the CPU computing power, the GPU computing power and the ISP computing power, or the power obtained by comprehensive evaluation of the CPU computing power, the GPU computing power and the ISP computing power.

[0227] For example, in a super terminal system composed of a smart watch 100, device A, device B, and device C, the capability level of the smart watch 100 is L0, the capability level of device A is L1, the capability level of device B is L2, and the capability level of device C is L3. Among them, the smart watch 100 with capability level L0 has the lowest capability, and the device C with capability level L3 has the highest capability. Then the certificate management module in the distributed operating system can determine device A, device B, and device C as the rich resource devices of the smart watch 100, and can select the device C with the highest capability as the rich resource device that actually performs the server certificate verification operation. And because the smart watch 100 and device C have completed the authorization authentication of the same user and are mutually trusted devices, device C can verify the server certificate sent by the smart watch 100. It can be understood that the above is only an exemplary description of the selection rules when there are multiple rich resource devices in the same network. In actual applications, the capability level of the electronic device can also be divided by comprehensive consideration in combination with other capabilities of the electronic device. For example, the capability level of the electronic device can also be divided in combination with the current power of the electronic device and the above-mentioned computing power, storage capacity, security capability, etc. This application is not limited to this.

[0228] Step 506 : The smart watch 100 verifies the server certificate and then proceeds to step 510 .

[0229] In some embodiments, the server certificate is a digital certificate issued by a digital certificate authority 400. For example, the server 300 sends certificate application information to the digital certificate authority 400, and the digital certificate authority 400 creates a digital document based on the certificate application information sent by the server 300. The digital document may include the public key, identity identification, validity date of the digital document, name of the digital certificate authority 400, etc. of the server 300. The digital certificate authority 400 uses a digest algorithm to calculate the aforementioned created digital document to obtain a digital digest. Then, the digital certificate authority 400 calls the signature private key of the root certificate to encrypt the digital digest of the server 300 and generate a signature. The server certificate is composed of the signature, the digital document, and the digest algorithm used.

[0230] The smart watch 100 verifies the server certificate, that is, verifies that the server certificate is issued by the digital certificate issuing authority 400 and is trustworthy. In some embodiments, after receiving the server certificate, the smart watch 100 uses the public key of the digital certificate issuing authority 400, that is, calls the public key of the root certificate, decrypts the signature in the server certificate, obtains the digital summary in the signature, and then uses the summary algorithm included in the digital server certificate to perform hash calculation on the digital document to obtain a new digital summary, and compares the new digital summary with the summary in the signature. If the new digital summary is consistent with the summary in the signature, it means that the server certificate has not been tampered with, indicating that the server certificate is a legal certificate issued by the digital certificate issuing authority 400 and is trustworthy, that is, the server identity is legal.

[0231] Step 507 : the smart watch 100 sends the preset root certificate and the received server certificate to the rich resource device 20 .

[0232] For example, in some embodiments, the smart watch 100 sends the root certificate preset in the smart watch 100 and the received server certificate to the rich resource device 20 via WiFi, Bluetooth, or the like.

[0233] In some embodiments, after determining that there is a rich resource device 20 in the same network, the smart watch 100 can directly send the root certificate preset by the smart watch 100 to the rich resource device 20, and then after the smart watch 100 initiates an SSL connection to the server 300, send the server certificate issued by the server 300 to the rich resource device 20. In this way, the occupation of the memory and computing resources of the smart watch 100 caused by the need to preset the root certificate and verify the server certificate can be avoided, that is, the communication security between the smart watch 100 and the server 300 can be guaranteed, and the performance of the smart watch 100 can be guaranteed, and the power consumption of the smart watch 100 can be reduced.

[0234] It should be noted that the smart watch 100 can also send the preset root certificate to the rich resource device 20 before initiating an SSL handshake request message to the rich resource device 20. Alternatively, the smart watch 100 can also send the preset root certificate to the rich resource device 20 after initiating an SSL handshake request message to the rich resource device 20 and before the smart watch 100 sends the server certificate to the rich resource device 20. This application does not limit the specific step in which the smart watch 100 sends the preset root certificate to the rich resource device 20, as long as the preset root certificate is sent to the rich resource device 20 before the smart watch 100 sends the server certificate to the rich resource device 20.

[0235] Step 508: The rich resource device 20 verifies the server certificate. For example, the rich resource device 20 parses the server certificate in a similar manner to step 506 to verify the legitimacy of the identity of the server 300, which will not be described in detail here.

[0236] Step 509 : the rich resource device 20 sends the verification result of the server certificate to the smart watch 100 .

[0237] Step 510: The smart watch 100 determines whether the identity of the server 300 is legitimate based on the verification result of the server certificate.

[0238] For example, in some embodiments, the smart watch 100 determines that the identity of the server 300 is legitimate, then after the smart watch 100 and the server 300 establish an SSL connection, they begin to use the negotiated key and algorithm for encrypted communication to request business services from the server 300. In some embodiments, the smart watch 100 determines that the identity of the server 300 is not legitimate, then the smart watch 100 terminates the connection with the server 300.

[0239] Step 511: the smart watch 100 sends a smart watch 100 key exchange message to the server 300. That is, after the identity legitimacy of the server 300 is verified, the smart watch 100 calculates and generates a random number Pre-master, encrypts it with a public key, and sends it to the server 300.

[0240] Step 512: The smart watch 100 sends a message of changing encryption attributes to the server 300, so as to inform the server 300 that subsequent communications will adopt the negotiated communication key and encryption algorithm for encrypted communication.

[0241] Step 513: The server 300 sends a message of changing encryption attributes to the smart watch 100, so as to inform the smart watch 100 that subsequent communications will adopt the negotiated communication key and encryption algorithm for encrypted communication.

[0242] Step 514 : The server 300 sends a completion message to the smart watch 100 .

[0243] The server 300 calculates the hash value of the key exchange message received from the smart watch 100, verifies the correctness of the data and key sent by the smart watch 100, and completes the handshake if the verification is successful. The smart watch 100 and the server 300 successfully establish an SSL connection, and begin to use the negotiated key and algorithm for encrypted communication to request business services from the server 300.

[0244] In some embodiments, the server certificate is Figure 1 Specifically, for example, the process of the digital certificate issuing authority 400 issuing a digital certificate to the server 300 may include: Figure 7 Steps shown:

[0245] (1) The server 300 generates a symmetric key, which includes a pair of public key and private key.

[0246] In some embodiments, the server 300 may generate a pair of public and private keys using an asymmetric encryption algorithm, wherein the private key is kept by the server 300 and the public key may be broadcast to multiple client devices communicating with the server 300 .

[0247] In some embodiments, the symmetric key of the server 300 may also be generated by the digital certificate issuing authority 400, and this application does not impose any restrictions on this.

[0248] (2) The server 300 sends certificate application information to the digital certificate issuing authority 400 to apply for a digital certificate from the digital certificate issuing authority 400.

[0249] In some embodiments, the certificate application information includes information such as the public key and identity identifier of the server 300 .

[0250] (3) The digital certificate issuing authority 400 issues the generated digital certificate of the server 300 to the server 300 .

[0251] In some embodiments, the digital certificate authority 400 creates a digital document based on the certificate application information sent by the server 300. The digital document may include the public key, identity identification, validity date of the digital document, name of the digital certificate authority 400, etc. of the server 300.

[0252] Then, the digital certificate issuing authority 400 uses the digest algorithm to calculate the digital document created above to obtain a digital digest. In order to prove that the digital certificate of the server 300 is issued by the digital certificate issuing authority 400, the digital certificate issuing authority 400 needs to use its own private key to encrypt the calculated digital digest of the server 300 and generate a signature. The signature, the digital document and the digest algorithm used constitute the server certificate. Finally, the digital certificate issuing authority 400 issues the generated digital certificate of the server 300 to the server 300.

[0253] After receiving the digital certificate issued by the digital certificate issuing authority 400, the server 300 can use the digital certificate for identity authentication during the communication process, thereby providing secure and reliable communication for both parties.

[0254] It is understandable that the server 300 has a private key known only to the server 300, which is used to decrypt and sign the received data. At the same time, the server 300 has a public key that can be made public to other electronic devices, which is used to encrypt and verify the signature of the sent data. When the server 300 sends data, the server 300 uses the public key to encrypt the data, and the receiving device uses the private key assigned to the device by the digital certificate authority 400 to decrypt the received data. In this way, the data transmitted between the server 300 and the client device can be transmitted safely and accurately. Even if it is intercepted by a third party, it cannot be decrypted due to the lack of the corresponding private key, thereby ensuring the security of data transmission.

[0255] The above briefly introduces the security authentication method provided in the embodiment of the present application by taking the use of the SSL protocol to establish a secure connection between the smart watch 100 and the server 300 as an example.

[0256] In order to better understand the technical solution of the present application, the following example is taken as follows: a secure connection is established between a smart watch 100 and a server 300 using the SSL protocol, the smart watch 100 requests a video service from the server 300, and there is a rich resource device 20 in the same network where the smart watch 100 is located, and the rich resource device 20 verifies the server certificate. Figure 3 The hardware structure diagram shown in the figure, Figure 4 The software architecture diagram shown in FIG. 1 is a detailed introduction to the security authentication method provided by the present application. It is understandable that the smart watch 100 can also request other types of services such as game downloads, navigation, and instant messaging from the server 300.

[0257] Specifically, Figure 8 As shown, the process of the smart watch 100 requesting a video service from the server 300 includes the following steps:

[0258] Step 801: The smart watch 100 starts the video application 301g after detecting a user operation.

[0259] For example, in some embodiments, the user clicks on the icon corresponding to the video application 301g on the desktop of the smart watch 100. After the smart watch 100 detects that the icon of the video application 301g is clicked, it opens the video application 301g.

[0260] Step 802: The video application 301g of the smart watch 100 initiates a root certificate import request to the certificate management module 302a of the smart watch 100. The certificate management module 302a is requested to import the root certificate pre-set in the storage space of the smart watch 100 into the opened video application 301g, so that the video application 301g can use the root certificate to verify the server certificate issued by the server 300 when requesting services from the server 300. After receiving the root certificate import request, the certificate management module 302a of the smart watch 100 executes steps 803 and 804 at the same time.

[0261] In this way, for different applications, the smart watch 100 only needs to preset a root certificate. When each application requests a service from the server 300, it only needs to import the preset root certificate into each application, so as to verify the server certificate based on the imported root certificate. The smart watch 100 does not need to preset a root certificate for each application, so that the smart watch 100 can achieve normalized management of root certificates and reduce the memory usage of the smart watch 100.

[0262] Step 803: The certificate management module 302a of the smart watch 100 imports the root certificate preset in the storage space of the smart watch 100 into the opened video application 301g.

[0263] Step 804: The certificate management module 302a of the smart watch 100 reads the status information of the secure channel 303a, confirms whether the secure channel 303a is available, and prepares for sending or receiving data. The secure channel 303a is used to encrypt the data communicated between the smart watch 100 and other electronic devices, so that the smart watch 100 and other electronic devices can communicate securely.

[0264] Step 805: The certificate management module 302a of the smart watch 100 sends the root certificate of the smart watch 100 to the rich resource device 20 through the secure channel 303a of the smart watch 100. That is, when there is a rich resource device 20 in the same network of the smart watch 100, in order to reduce the memory occupation of the smart watch 100 by the preset root certificate, the preset root certificate can be sent to the rich resource device 20.

[0265] Step 806 : The rich resource device 20 verifies the root certificate received from the smart watch 100 .

[0266] For example, in some embodiments, the resource-rich device 20 may use the same method as described above for the received root certificate. Figure 5 The root certificate is verified by a similar method to step 506 in the above to verify whether the root certificate is legitimate. Figure 5 The text description of step 506 in the above description will not be repeated here.

[0267] Step 807 : the rich resource device 20 sends the verification result of the root certificate to the certificate management module 302 a of the smart watch 100 through the secure channel 303 of the smart watch 100 .

[0268] Step 808 : The certificate management module 302 a of the smart watch 100 sends the verification result of the received root certificate to the video application 301 g of the smart watch 100 .

[0269] Step 809: The video application 301g of the smart watch 100 determines whether to initiate an SSL secure connection to the server 300 based on the verification result of the received root certificate. If yes, it indicates that the root certificate is legitimate, and the video application 301g of the smart watch 100 initiates an SSL secure connection to the server 300, and the process proceeds to step 810; otherwise, it indicates that the root certificate is not legitimate, and the video application 301g of the smart watch 100 does not initiate an SSL secure connection to the server 300, and the process ends.

[0270] Step 810: The video application 301g of the smart watch 100 initiates an SSL secure connection to the server 300. When there is a rich resource device 20 in the same network of the smart watch 100, an SSL session is opened between the video application 301g of the smart watch 100 and the server 300.

[0271] For example, in some embodiments, the video application 301g of the smart watch 100 sends a handshake request message to the server 300, which includes information such as the cipher suite, data compression method, random number, extension field, etc. supported by the smart watch 100, to notify the server 300 to start an SSL session.

[0272] The server 300 responds to the handshake request message of the smart watch 100 and sends the handshake request message of the server 300 to the smart watch 100 , which includes information such as the cipher suite supported by the server 300 , data compression method, session ID, random number, and extension field.

[0273] Step 811: The server 300 sends a server certificate to the video application 301g of the smart watch 100. That is, when there is a rich resource device 20 in the same network as the smart watch 100, the server 300 responds to the SSL session of the smart watch 100 and sends a server certificate to the smart watch 100.

[0274] For example, in some embodiments, when there is a rich resource device 20 in the same network of the smart watch 100, the server 300 sends a server certificate to the video application 301g of the smart watch 100, and sends a handshake request completion message to notify the smart watch 100 that the authentication preparation work on the server 300 side has been completed and is waiting for a response from the smart watch 100.

[0275] Step 812: The video application 301g of the smart watch 100 sends an interrupt to the certificate management module 302a of the smart watch 100 to request the certificate management module 302a to read the server certificate.

[0276] Step 813: The certificate management module 302a of the smart watch 100 sends the server certificate to the rich resource device 20 through the secure channel 303a of the smart watch 100. That is, when there is a rich resource device 20 in the same network of the smart watch 100, after the certificate management module 302a of the smart watch 100 reads the server certificate from the video application 301g, in order to securely transmit the read server certificate to the rich resource device 20, the secure channel 303a of the smart watch 100 can be called to send the server certificate to the rich resource device 20 through the secure channel.

[0277] In some embodiments, the certificate management module 302a of the smart watch 100 can register a callback function corresponding to the video application 301g. When the certificate management module 302a of the smart watch 100 receives the server certificate, it can trigger the smart watch 100 to call the callback function to send the server certificate to the rich resource device 20.

[0278] Then, the server certificate is called into the secure channel 303 a through the callback function, and the server certificate is sent to the rich resource device 20 .

[0279] Step 814: The rich resource device 20 verifies the received server certificate. That is, when there is a rich resource device 20 in the same network as the smart watch 100, the verification process of the server certificate of the smart watch 100 is handed over to the rich resource device 20, which can release the computing resources of the smart watch 100 for verifying the server certificate, ensure the performance of the smart watch 100, and reduce the power consumption of the smart watch 100.

[0280] For example, in some embodiments, the rich resource device 20 may use the same method as described above to process the received server certificate. Figure 5 The server certificate is verified by a similar method to step 506 in the above, thereby verifying whether the identity of the server 300 is legitimate. Figure 5 The text description of step 506 in the above description will not be repeated here.

[0281] In some embodiments, the server certificate sent by the server 300 to the video application 301g of the smart watch 100 is issued in the form of a certificate chain, and the bottom-level certificate is a secondary certificate signed by the root certificate of the server 300. In order to verify the certificate chain issued by the server 300, the rich resource device 20 verifies the server certificate in the form of a certificate chain obtained from the smart watch 100 based on the root certificate received from the smart watch 100.

[0282] Step 815 : the rich resource device 20 sends the verification result of the server certificate to the certificate management module 302 a of the smart watch 100 via the secure channel 303 a of the smart watch 100 .

[0283] Step 816 : The certificate management module 302 a of the smart watch 100 sends the verification result of the received server certificate to the video application 301 g of the smart watch 100 .

[0284] For example, in some embodiments, after receiving the verification result of the server certificate, the certificate management module 302a of the smart watch 100 sends an interrupt message to the video application 301g of the smart watch 100. After receiving the interrupt message sent by the certificate management module 302a, the video application 301g of the smart watch 100 reads the verification result of the server certificate from the certificate management module 302a.

[0285] In some embodiments, since the smart watch 100 cannot directly perceive the verification result of the server certificate by the rich resource device 20, a callback function can be registered in the application of the smart watch 100 (e.g., the video application 301g), so that when the rich resource device 20 verifies the server certificate and obtains the verification result, the certificate management module of the rich resource device 20 sends the verification result to the certificate management module 302a of the smart watch 100 through the soft bus or WIFI. After receiving the verification result, the certificate management module 302a of the smart watch 100 triggers the call to the above callback function, and the callback function returns the above verification result to the application.

[0286] Step 817: The video application 301g of the smart watch 100 determines whether the identity of the server 300 is legitimate based on the verification result of the server certificate by the rich resource device 20. If the identity of the server 300 is legitimate, proceed to step 818; otherwise, if the identity of the server 300 is not legitimate, the video application 301g of the smart watch 100 terminates the SSL connection with the server 300.

[0287] That is, when there is a rich resource device 20 in the same network as the smart watch 100 , after the rich resource device 20 verifies the identity of the server 300 , the video application 301 g of the smart watch 100 determines whether to request a video service from the server 300 .

[0288] Step 818: The video application 301g of the smart watch 100 sends a video service request to the server 300 to request a video service from the server 300. That is, after the video application 301g of the smart watch 100 determines that the identity of the server 300 is legitimate, the video application 301g of the smart watch 100 can request a video service from the server 300, and the smart watch 100 and the server 300 perform encrypted communication using the negotiated encryption algorithm.

[0289] Combined with the above Figure 8 It can be seen from the text description that the technical solution of the present application can transmit the root certificate preset in a lightweight device 10 with low computing power, such as a smart watch 100, to the resource-rich device 20 when it is determined that there are other resource-rich devices 20 in the same network. When the lightweight device 10 interacts with the server 300, the parsing of the server certificate is completed by the resource-rich device 20, which can reduce the occupation of the resources of the lightweight device 10 caused by the parsing process of the server certificate, and can effectively utilize the memory resources and computing resources of the resource-rich device 20 to avoid resource waste. In addition, it can also reduce the operating power consumption of the lightweight device 10 and improve the battery life of the lightweight device 10.

[0290] The following is an example in which there is no rich resource device 20 in the same network as the smart watch 100, the smart watch 100 directly verifies the server certificate, the smart watch 100 and the server 300 use the SSL protocol to establish a secure connection, and the smart watch 100 requests a video service from the server 300. Fig. 9 , the process of the smart watch 100 requesting a video service from the server 300 includes the following steps:

[0291] Step 901: The smart watch 100 starts the video application 301g after detecting a user operation.

[0292] Step 902: The video application 301g of the smart watch 100 initiates a root certificate import request to the certificate management module 302a of the smart watch 100. The certificate management module 302a is requested to import the root certificate pre-set in the storage space of the smart watch 100 into the opened video application 301g, so that the video application 301g can use the root certificate to verify the server certificate issued by the server 300 when requesting services from the server 300. After receiving the root certificate import request, the certificate management module 302a of the smart watch 100 executes steps 903 and 904 at the same time.

[0293] Step 903: The certificate management module 302a of the smart watch 100 imports the root certificate preset in the storage space of the smart watch 100 into the opened video application 301g.

[0294] Step 904: the video application 301g of the smart watch 100 initiates an SSL secure connection to the server 300. In the case where there is no rich resource device 20 in the same network of the smart watch 100, an SSL session is opened between the video application 301g of the smart watch 100 and the server 300.

[0295] For example, in some embodiments, the video application 301g of the smart watch 100 sends a handshake request message to the server 300, which includes information such as the cipher suite, data compression method, random number, extension field, etc. supported by the smart watch 100, to notify the server 300 to start an SSL session.

[0296] In response to the handshake request message of the smart watch 100, the server 300 sends a handshake request message of the server 300 to the smart watch 100. The message includes information such as the cipher suite supported by the server 300, the data compression method, the session ID, the random number, and the extension field.

[0297] Step 905 : The server 300 sends a server certificate to the video application 301 g of the smart watch 100 .

[0298] For example, in some embodiments, the server 300 sends a server certificate to the video application 301g of the smart watch 100 and sends a handshake request completion message to notify the smart watch 100 that the authentication preparation work on the server 300 side has been completed and waits for the response of the smart watch 100.

[0299] Step 906: The video application 301g of the smart watch 100 verifies the server certificate. That is, when there is no rich resource device 20 in the same network of the smart watch 100, the smart watch 100 directly verifies the identity of the server 300.

[0300] For example, in some embodiments, the video application 301g of the smart watch 100 uses and Figure 5 The server certificate is verified in a similar manner to step 506 shown in FIG. Figure 5 The text description of step 506 in the above description will not be repeated here.

[0301] In some embodiments, the server certificate sent by the server 300 to the video application 301g of the smart watch 100 is issued in the form of a certificate chain. The bottom-level certificate is a secondary certificate signed by the root certificate of the server 300. In order to verify the certificate chain issued by the server 300, it is necessary to preset a root certificate corresponding to the certificate chain issued by the server 300 in the smart watch 100, and use the root certificate to verify the server certificate in the form of a certificate chain.

[0302] Step 907: The video application 301g of the smart watch 100 determines whether the identity of the server 300 is legitimate. That is, when there is no rich resource device 20 in the same network of the smart watch 100, the video application 301g of the smart watch 100 directly verifies the identity of the server 300, and then determines whether the identity of the server 300 is legitimate. If the identity of the server 300 is legitimate, proceed to step 908; otherwise, if the identity of the server 300 is not legitimate, the video application 301g of the smart watch 100 terminates the SSL connection with the server 300.

[0303] That is, when there is no rich resource device 20 in the same network of the smart watch 100 , after the smart watch 100 verifies the identity of the server 300 , the video application 301 g of the smart watch 100 determines whether to request a video service from the server 300 .

[0304] Step 908: The video application 301g of the smart watch 100 sends a video service request to the server 300 to request a video service from the server 300. That is, after the video application 301g of the smart watch 100 determines that the identity of the server 300 is legitimate, the video application 301g of the smart watch 100 can request a video service from the server 300, and the smart watch 100 and the server 300 perform encrypted communication using the negotiated encryption algorithm.

[0305] Fig.10According to some embodiments of the present application, a structural block diagram of a system 10000 is schematically shown. In some embodiments, the system 1000 may include one or more processors 1004, a system control logic 1008 connected to at least one of the processors 1004, a system memory 1012 connected to the system control logic 1008, a non-volatile memory (NVM) 1016 connected to the system control logic 1008, and a network interface 1020 connected to the system control logic 1008.

[0306] In some embodiments, the processor 1004 may include one or more single-core or multi-core processors. In some embodiments, the processor 1004 may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, baseband processors, etc.). In embodiments where the system 1000 uses an ENB (Evolved Node B) 101 or a RAN (Radio Access Network) controller, the processor 1004 may be configured to execute various embodiments, such as Figure 5 and Figure 8 In the illustrated embodiment, the processor 1004 determines whether there is access to a rich-resource device in the same network. If there is access to a rich-resource device, the smart watch 100 controls the smart watch 100 through the processor 1004 to forward the server certificate issued by the server 300 to the rich-resource device for resolution. If there is no access to a rich-resource device in the same network, the smart watch 100 directly resolves the server certificate issued by the server 300 through the processor 1004.

[0307] In some embodiments, system control logic 1008 may include any suitable interface controller to provide any suitable interface to at least one of processors 1004 and / or any suitable device or component in communication with system control logic 1008 .

[0308] In some embodiments, the system control logic 1008 may include one or more memory controllers to provide an interface to the system memory 1012. The system memory 1012 may be used to load and store data and / or instructions. For example, in some embodiments of the present application, the system memory 1012 may store a root certificate of the smart watch 100 issued by a digital certificate authority. At the same time, the system memory 1012 may also store user registration information, login information, and the like.

[0309] NVM / memory 1016 may include one or more tangible, non-transitory computer-readable media for storing data and / or instructions. In some embodiments, NVM / memory 1016 may include any suitable non-volatile memory such as flash memory and / or any suitable non-volatile storage device, such as at least one of a HDD (Hard Disk Drive), a CD (Compact Disc) drive, and a DVD (Digital Versatile Disc) drive.

[0310] NVM / storage 1016 may include a portion of storage resources on the device on which system 1000 is installed, or it may be accessible by a device but not necessarily a portion of the device. For example, NVM / storage 1016 may be accessed over a network via network interface 1020.

[0311] In particular, system memory 1012 and NVM / storage 1016 may include, respectively, a temporary copy and a permanent copy of instructions 1024. Instructions 1024 may include instructions that, when executed by at least one of processors 1004, cause system 1000 to implement the following: Figure 5 , Figure 8 and Fig. 9 In some embodiments, instructions 1024, hardware, firmware, and / or software components thereof may additionally / alternatively be placed in system control logic 1008, network interface 1020, and / or processor 1004.

[0312] The network interface 1020 may include a transceiver for providing a radio interface for the system 1000 to communicate with any other suitable devices (such as a front-end module, an antenna, etc.) through one or more networks. In some embodiments, the network interface 1020 may be integrated with other components of the system 1000. For example, the network interface 1020 may be integrated with at least one of the processor 1004, the system memory 1012, the NVM / storage 1016, and a firmware device (not shown) having instructions. When at least one of the processors 1004 executes the instructions, the system 1000 implements the following. Figure 5 , Figure 8 and Fig. 9 The method shown.

[0313] The network interface 1020 may further include any suitable hardware and / or firmware to provide a multiple-input multiple-output radio interface. For example, the network interface 1020 may be a network adapter, a wireless network adapter, a telephone modem and / or a wireless modem.

[0314] In some embodiments, at least one of the processors 1004 may be packaged together with logic for one or more controllers of the system control logic 1008 to form a system in package (SiP). In some embodiments, at least one of the processors 1004 may be integrated on the same die with logic for one or more controllers of the system control logic 1008 to form a system on chip (SoC).

[0315] The system 1000 may further include an input / output (I / O) device 1032. The I / O device 1032 may include a user interface to enable a user to interact with the system 1000; and a peripheral component interface design to enable peripheral components to interact with the system 1000.

[0316] In some embodiments, the user interface may include, but is not limited to, a display (e.g., an LCD display, a touch screen display, etc.), a speaker, a microphone, one or more cameras (e.g., a still image camera and / or a video camera), a flashlight (e.g., an LED flash), and a keyboard.

[0317] In some embodiments, the peripheral component interface may include, but is not limited to, a non-volatile memory port, an audio jack, and a power interface.

[0318] The various embodiments of the mechanism disclosed in the present application can be implemented in hardware, software, firmware or a combination of these implementation methods. The embodiments of the present application can be implemented as a computer program or program code executed on a programmable system, which includes at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device and at least one output device.

[0319] Program code can be applied to input instructions to perform the functions described in this application and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, a processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.

[0320] Program code can be implemented with high-level programming language or object-oriented programming language to communicate with the processing system. When necessary, program code can also be implemented with assembly language or machine language. In fact, the mechanism described in this application is not limited to the scope of any specific programming language. In either case, the language can be a compiled language or an interpreted language.

[0321] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, instructions may be distributed over a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine (e.g., computer) readable form, including, but not limited to, floppy disks, optical disks, optical disks, read-only memories (CD-ROMs), magneto-optical disks, read-only memories (ROM), random access memories (RAM), erasable programmable read-only memories (EPROM), electrically erasable programmable read-only memories (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable memories for transmitting information (e.g., carrier waves, infrared signal digital signals, etc.) using the Internet in electrical, optical, acoustic, or other forms of propagation signals. Accordingly, machine-readable media include any type of machine-readable media suitable for storing or transmitting electronic instructions or information in a form readable by a machine (eg, a computer).

[0322] In the accompanying drawings, some structural or method features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be required. Instead, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. In addition, the inclusion of structural or method features in a particular figure does not mean that such features are required in all embodiments, and in some embodiments, these features may not be included or may be combined with other features.

[0323] It should be noted that the units / modules mentioned in the various device embodiments of the present application are all logical units / modules. Physically, a logical unit / module can be a physical unit / module, or a part of a physical unit / module, or can be implemented as a combination of multiple physical units / modules. The physical implementation method of these logical units / modules themselves is not the most important. The combination of functions implemented by these logical units / modules is the key to solving the technical problems proposed by the present application. In addition, in order to highlight the innovative part of the present application, the above-mentioned device embodiments of the present application do not introduce units / modules that are not closely related to solving the technical problems proposed by the present application, which does not mean that there are no other units / modules in the above-mentioned device embodiments.

[0324] It should be noted that in the examples and description of this patent, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "including one" do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0325] Although the present application has been illustrated and described with reference to certain preferred embodiments thereof, it will be apparent to those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present application.

Claims

1. A security authentication method, characterized in that: include: The first electronic device detects a triggering event that triggers data transmission with the server; The first electronic device sends the root certificate and the identity information of the server to the second electronic device when determining that the identity authentication capability of the second electronic device is greater than the identity authentication capability of the first electronic device, wherein the identity information of the server includes a server certificate issued to the server by a digital certificate issuing authority; The second electronic device verifies the identity information of the server received from the first electronic device based on the root certificate to obtain a verification result, and sends the verification result to the first electronic device; The first electronic device determines whether to perform data transmission with the server based on the received verification result; When the first electronic device determines that the identity of the server is legitimate based on the verification result, establishing a network security connection with the server; The first electronic device performs data transmission with the server via the established network security connection.

2. The method according to claim 1, characterized in that The identity authentication capability is obtained based on at least one of computing capability, storage capability and security capability.

3. The method according to claim 2, characterized in that The computing capability includes at least one of the computing capability of a central processing unit, the computing capability of a graphics processing unit, and the computing capability of an image signal processor.

4. The method according to claim 1, characterized in that: The first electronic device includes a plurality of applications; The first electronic device detecting a triggering event that triggers data transmission with a server includes: at least one of the plurality of applications of the first electronic device detecting a triggering event that triggers data transmission with a server; The method further comprises: When detecting a triggering event that triggers data transmission with a server, at least one of the plurality of applications of the first electronic device acquires the root certificate and sends the root certificate to the second electronic device.

5. The method according to claim 1, characterized in that The server certificate includes a digital document, a signature generated by encrypting a digital summary of the digital document calculated by a preset summary algorithm by the digital certificate issuing authority, and the preset summary algorithm.

6. The method according to claim 5, characterized in that The second electronic device verifies the server certificate received from the first electronic device based on the root certificate received from the first electronic device to obtain the verification result, including: The second electronic device decrypts the signature in the server certificate based on the root certificate received from the first electronic device to obtain a first digital summary of the signature; Performing a hash calculation on the digital document based on the preset digest algorithm to obtain a second digital digest; The second digital digest is compared with the first digital digest, and a verification result of the server certificate by the second electronic device is determined based on the comparison result.

7. The method according to claim 1, characterized in that The first electronic device detects a triggering event that triggers data transmission with a server, including: The first electronic device detects a user operation that triggers data transmission with the server, where the user operation is used to trigger the first electronic device to send a network security connection request to the server.

8. The method according to claim 7, characterized in that The network security connection is a secure socket layer protocol connection or a transport layer security protocol connection.

9. The method according to claim 1, characterized in that: The operating system of the first electronic device is a lightweight embedded operating system.

10. The method according to claim 1, characterized in that The operating system of the second electronic device includes at least one of an Android operating system, a Hongmeng operating system, and an IOS operating system.

11. A security authentication method, characterized in that: include: The first electronic device detects a triggering event that triggers data transmission with the server; The first electronic device sends the root certificate and the identity information of the server to the second electronic device when determining that the identity authentication capability of the second electronic device is greater than the identity authentication capability of the first electronic device; The first electronic device determines whether to perform data transmission with the server based on the verification result received from the second electronic device; When the first electronic device determines that the identity of the server is legitimate based on the verification result, establishing a network security connection with the server; The first electronic device performs data transmission with the server via the established network security connection; The verification result is obtained by the second electronic device verifying the identity information of the server based on the root certificate sent by the first electronic device, and the identity information of the server includes a server certificate issued to the server by a digital certificate authority.

12. The method according to claim 11, characterized in that The identity authentication capability is obtained based on at least one of computing capability, storage capability and security capability.

13. The method according to claim 12, characterized in that The computing capability includes at least one of the computing capability of a central processing unit, the computing capability of a graphics processing unit, and the computing capability of an image signal processor.

14. The method according to any one of claims 11 to 13, characterized in that: The first electronic device includes a plurality of applications; The first electronic device detects a triggering event that triggers data transmission with a server, including: At least one of the plurality of applications of the first electronic device detects a triggering event that triggers data transmission with a server; The method further comprises: When detecting a triggering event that triggers data transmission with a server, at least one of the multiple applications of the first electronic device obtains a root certificate and sends the root certificate to the second electronic device, where the root certificate is used by the second electronic device to verify the identity information of the server.

15. The method according to claim 11, characterized in that The first electronic device detects a triggering event that triggers data transmission with a server, including: The first electronic device detects a user operation that triggers data transmission with the server, where the user operation is used to trigger the first electronic device to send a network security connection request to the server.

16. The method according to claim 15, characterized in that The network security connection is a secure socket layer protocol connection or a transport layer security protocol connection.

17. The method according to claim 11, characterized in that The operating system of the first electronic device is a lightweight embedded operating system.

18. A security authentication method, characterized in that: include: The second electronic device verifies the identity information of the server received from the first electronic device to obtain a verification result, and sends the verification result to the first electronic device, wherein the identity information of the server includes a server certificate issued to the server by a digital certificate issuing authority; The verification result is used to instruct the first electronic device to establish a network security connection with the server if the identity of the server is legitimate, and to perform data transmission with the server through the established network security connection; The second electronic device verifies the identity information of the server received from the first electronic device to obtain a verification result, including: The second electronic device verifies the server certificate received from the first electronic device based on the root certificate received from the first electronic device to obtain the verification result; The root certificate and the identity information of the server are sent to the second electronic device by the first electronic device when it is determined that the identity authentication capability of the second electronic device is greater than the identity authentication capability of the first electronic device.

19. The method according to claim 18, characterized in that The server certificate includes a digital document, a signature generated by encrypting a digital summary of the digital document calculated by a preset summary algorithm by the digital certificate issuing authority, and the preset summary algorithm.

20. The method according to claim 19, characterized in that The second electronic device verifies the server certificate received from the first electronic device based on the root certificate received from the first electronic device to obtain the verification result, including: The second electronic device decrypts the signature in the server certificate based on the root certificate received from the first electronic device to obtain a first digital summary of the signature; Performing a hash calculation on the digital document based on the preset digest algorithm to obtain a second digital digest; The second digital digest is compared with the first digital digest, and a verification result of the server certificate by the second electronic device is determined based on the comparison result.

21. The method according to claim 18, characterized in that The operating system of the second electronic device includes at least one of an Android operating system, a Hongmeng operating system, and an IOS operating system.

22. A readable medium, characterized in that The readable medium stores instructions, which, when executed on an electronic device, enable the electronic device to execute the security authentication method described in any one of claims 1-21.

23. An electronic device, characterized in that: include: a memory for storing instructions to be executed by one or more processors of the electronic device, and The processor is one of the processors of the electronic device, and is used to execute the security authentication method described in any one of claims 1-21.

Images