CN117176362B - Authentication method and device - Google Patents

Abstract

The embodiment of the application provides an authentication method and device, relates to the technical field of communication, and can ensure safe communication between an application program and a server. The method is applied to electronic equipment, wherein a first application is installed in the electronic equipment, and the electronic equipment comprises a Trusted Execution Environment (TEE); the method comprises the following steps: the electronic equipment runs a first application to acquire a first digital certificate from the TEE, wherein the first digital certificate comprises an identification of the first application and an application signature certificate fingerprint; the electronic equipment sends a first digital certificate to a first server; the electronic equipment receives an authentication passing message from the first server, wherein the authentication passing message is used for indicating that the first digital certificate passes authentication and the application signature certificate fingerprint passes authentication; the electronic device communicates securely with the first server based on the first application.

Description

Authentication method and device

Technical field

The present application relates to the field of communication technology, and in particular to an authentication method and device.

Background technique

In order to ensure secure communication between the application and the server, security authentication can be performed on the electronic device and the application (APP) to ensure the legitimacy of the application and the electronic device. Currently, security authentication of electronic devices and applications is implemented based on software capabilities.

For example, when performing device authentication, the unique identifier of the device can be calculated through native code, thereby completing the unique tracking of the device. When performing APP authentication, the APP's signature information (for example, application ID and application signature certificate fingerprint) can be packaged in the APP's native code, or the APP's native code can call the API to obtain the signature information, and then send the signature information to the server. Carry out signature verification. However, this authentication method has security vulnerabilities. The security of the application's signature information cannot be guaranteed, and there is a possibility that the signature information may be tampered with, resulting in the inability to ensure secure communication between the application and the server.

Summary of the invention

The embodiment of the present application provides an authentication method and device, which can ensure secure communication between the application program and the server.

In a first aspect, an embodiment of the present application provides an authentication method, which is applied to an electronic device, in which a first application is installed, and the electronic device includes a trusted execution environment TEE; the method includes: the electronic device runs the first application to obtain a first digital certificate from the TEE, and the first digital certificate includes an identifier of the first application and an application signature certificate fingerprint; the electronic device sends the first digital certificate to a first server; the electronic device receives an authentication success message from the first server, and the authentication success message is used to indicate that the first digital certificate authentication is successful, as well as the identifier of the first application and the application signature certificate fingerprint authentication is successful; the electronic device communicates securely with the first server based on the first application.

Based on the method provided in the embodiment of the present application, the first application of the electronic device can obtain the first digital certificate from the TEE and send the certificate to the first server. When the first digital certificate is authenticated and the fingerprint of the application signature certificate contained in the certificate is authenticated, the first application can communicate securely with the first server. Since the first digital certificate is obtained directly from the TEE, the problem of malicious programs on the terminal side (electronic device side) tampering with the identification of the first application and the fingerprint of the application signature certificate in the first digital certificate can be avoided. In addition, by carrying the identification of the first application and the fingerprint of the application signature certificate to the first server through the first digital certificate, the first server can authenticate both the first digital certificate and the identification and fingerprint of the application signature certificate of the first application. After all authentications are passed, the first application can communicate with the first server, ensuring the communication security between the first application and the first server.

In a possible implementation, the first application obtaining the first digital certificate from the TEE includes: the electronic device runs the first application and calls the universal keystore system HUKS interface to obtain the first digital certificate from the TEE. Among them, the HUKS interface (HUKSAPI) is the interface that HUKS components open to upper-level software (for example, applications). HUKS components run in a secure environment, such as TEE or chips with security capabilities. In this way, the legitimacy of the first digital certificate can be guaranteed.

In one possible implementation, the first digital certificate also includes a unique identifier and a public key of the electronic device. When the secure cloud server (first server) receives a device certificate (first digital certificate) containing a unique identifier of the electronic device (e.g., a first UDID) for the first time, the secure cloud server can generate a device Token based on the first UDID and establish a corresponding relationship between the device Token and the public key. The data requested by subsequent applications can be signed using the private key corresponding to the public key, and the signed data and the device Token can be sent to the secure cloud server. The secure cloud server can verify the device Token to ensure the legitimacy of the electronic device and the application. The secure cloud server can verify the data requested by the application based on the public key corresponding to the device Token to ensure the integrity of the message.

In a possible implementation, the authentication pass message includes a first token, the first token has a corresponding relationship with the public key, and the first token is used to verify the legality of the electronic device and the first application. In this way, the legality of the electronic device and the first application can be verified based on the first token, ensuring communication security between the first application and the first server.

In a possible implementation, the electronic device performing secure communication with the first server based on the first application includes: the electronic device signing the first business data of the first application based on the private key corresponding to the public key. Signature data; the electronic device sends the signature data and the first token to the first server based on the first application. In this way, the legality of the electronic device and the first application can be verified based on the first token, ensuring communication security between the first application and the first server.

In a possible implementation, the electronic device logs in to the first account based on the first application, the first account passes two-factor authentication, and the two-factor verification includes password verification and verification code verification. If the electronic device is a device that passes two-factor verification (that is, the account used to log in to the electronic device (the account used to log in to the application) passes the two-factor verification), and the application authentication, account authentication, and device authentication performed on the electronic device or application At least one of the authentications passed (for example, application authentication, account authentication, device authentication all passed, or application authentication and device authentication passed, or application authentication passed), allowing highly sensitive interface operations, that is, allowing electronic devices Applications call highly sensitive interfaces to process highly sensitive data. In this way, communication security between the first application and the first server can be ensured.

In a second aspect, embodiments of the present application provide an authentication method, applied to an authentication system including an electronic device and a first server. The electronic device has a first application installed, and the electronic device includes a trusted execution environment TEE. The method includes: the electronic device Run the first application to obtain the first digital certificate from the TEE. The first digital certificate includes the identification of the first application and the fingerprint of the application signature certificate; the electronic device sends the first digital certificate to the first server; the first server receives the first digital certificate, based on The certificate chain authenticates the first digital certificate; after the first server authenticates the first digital certificate, it authenticates the identity of the first application and the fingerprint of the application signature certificate; the first server authenticates the identity of the first application and the fingerprint of the application signature certificate After the authentication is passed, an authentication pass message is sent to the first application. The authentication pass message is used to indicate that the first digital certificate has passed the authentication, and that the first application's identity and application signature certificate fingerprint have passed the authentication; the electronic device receives the authentication pass from the first server. Message; the electronic device performs secure communication with the first server based on the first application.

Based on the method provided by the embodiments of this application, the first application of the electronic device can obtain the first digital certificate from the TEE and send the certificate to the first server. The first server may authenticate the first digital certificate and authenticate the identity of the first application and the application signing certificate fingerprint. If the first digital certificate passes the authentication and the application signature certificate fingerprint contained in the certificate passes the authentication, the first application can communicate securely with the first server. Since the first digital certificate is obtained directly from the TEE, the problem of malicious programs on the terminal side (electronic device side) tampering with the identity of the first application and the fingerprint of the application signature certificate in the first digital certificate can be avoided. Furthermore, the first digital certificate carries the identity of the first application and the fingerprint of the application signature certificate to the first server, so that the first server not only authenticates the first digital certificate, but also authenticates the identity of the first application and the fingerprint of the application signature certificate. After the authentication is passed, the first application can communicate with the first server, ensuring the security of communication between the first application and the first server.

In a possible implementation, the electronic device running the first application to obtain the first digital certificate from the TEE includes: the electronic device running the first application calling the universal keystore system HUKS interface to obtain the first digital certificate from the TEE.

In a possible implementation, the first digital certificate also includes a unique identifier and a public key of the electronic device.

In a possible implementation, the method further includes: the first server generates a first token according to the unique identifier of the electronic device; the first server establishes a correspondence between the first token and the public key, and the first token is used to Verify the legality of electronic devices and first applications.

In a possible implementation, the authentication pass message includes the first token.

In a possible implementation, the electronic device performing secure communication with the first server based on the first application includes: the electronic device signing the first business data of the first application based on the private key corresponding to the public key. Signature data; the electronic device sends the signature data and the first token to the first server based on the first application; the first server receives the signature data and the first token; the first server signs the data according to the public key corresponding to the first token Carry out signature verification.

In a possible implementation, the electronic device logs in to the first account based on the first application, the first account passes two-factor authentication, and the two-factor verification includes password verification and verification code verification.

In a third aspect, the present application provides a computer-readable storage medium that includes computer instructions. When the computer instructions are run on an electronic device (such as a mobile phone), the electronic device is caused to execute the method described in the first aspect or the second aspect and any possible design manner thereof.

In the fourth aspect, the present application provides a computer program product. When the computer program product is run on a computer, it causes the computer to execute the method described in the first aspect or the second aspect and any possible design manner thereof. method.

In a fifth aspect, embodiments of the present application provide an authentication device, which includes a processor. The processor is coupled to a memory. The memory stores program instructions. When the program instructions stored in the memory are executed by the processor, the device implements the first step described above. The method described in the aspect or the second aspect and any possible design method thereof. The device may be an electronic device or the first server; or may be a component of the electronic device or the first server, such as a chip.

In the sixth aspect, embodiments of the present application provide an authentication device. The device can be divided into different logical units or modules according to functions, and each unit or module performs different functions, so that the device performs the above first aspect or The method described in the second aspect and any possible design method thereof.

In the seventh aspect, the present application provides an authentication system, including an electronic device and a first server, wherein the electronic device can execute the method described in the first aspect or the second aspect and any possible design thereof, and the first server can execute the method described in the second aspect and any possible design thereof.

In an eighth aspect, the present application provides a chip system, which includes one or more interface circuits and one or more processors. The interface circuit and the processor are interconnected through lines. The above chip system can be applied to an electronic device or a first server including a communication module and a memory. The interface circuit is configured to receive a signal from a memory of the electronic device or the first server and send the received signal to the processor, the signal including computer instructions stored in the memory. When the processor executes the computer instructions, the electronic device or the first server can execute the method described in the first aspect and any possible design manner thereof.

It can be understood that the computer-readable storage medium described in the third aspect, the computer program product described in the fourth aspect, the devices described in the fifth and sixth aspects, the system described in the seventh aspect, and The beneficial effects that can be achieved by the chip system described in the eighth aspect can be referred to the beneficial effects in the first aspect and any of its possible design methods, and will not be described again here.

Description of drawings

FIG1 is a schematic diagram of a system architecture provided in an embodiment of the present application;

Figure 2 is a schematic diagram of another system architecture provided by an embodiment of the present application;

FIG3 is a schematic diagram of a process of joining a trust ring provided in an embodiment of the present application;

Figure 4 is a schematic diagram of the hardware structure of an electronic device provided by an embodiment of the present application;

Figure 5 is a schematic diagram of the software architecture of an electronic device provided by an embodiment of the present application;

FIG6 is a schematic diagram of the hardware structure of a cloud server provided in an embodiment of the present application;

Figure 7 is a schematic diagram of the software architecture of a cloud server provided by an embodiment of the present application;

FIG8 is a schematic diagram of a signal interaction provided in an embodiment of the present application;

Figure 9 is a schematic display diagram provided by an embodiment of the present application;

Figure 10 is another schematic diagram of signal interaction provided by an embodiment of the present application;

Figure 11 is another schematic diagram of signal interaction provided by an embodiment of the present application;

Figure 12 is another schematic diagram of signal interaction provided by an embodiment of the present application;

FIG13 is a schematic diagram of the structure of the chip system provided in an embodiment of the present application.

Detailed ways

In order to describe the following embodiments clearly and concisely, a brief introduction to related concepts or technologies is first given:

Key: A parameter entered into an algorithm that converts plaintext to ciphertext or ciphertext to plaintext. Keys are divided into symmetric keys and asymmetric keys. Asymmetric keys can include a public key (pk) and a private key (secret key, sk). The public key can be freely released, and the private key is kept secretly by the user.

Signatures: The process of encrypting a message (or other information, such as a hash value) using a public key or private key is equivalent to generating a signature.

Signature verification: The process of decrypting using the private key corresponding to the public key or the public key corresponding to the private key is equivalent to signature verification (that is, verifying the signature). If the message decrypted using the public key or private key is consistent with the original message , then the signature verification is successful. Signing the message can ensure the integrity of the message. If the signature verification using the public key or private key is successful, it means that the message has not been tampered with during transmission.

RSA encryption algorithm: It is the first generation encryption algorithm of modern encryption that is widely used today. It is based on the difficult mathematical problem of decomposing large prime numbers to ensure the security of the encryption algorithm.

Elliptic curve cryptography (ECC), also known as elliptic curve cryptography, is based on finite field elliptic curves and complex elliptic curve discrete logarithms. ECC can realize most of the capabilities required for asymmetric encryption, including: encryption, signature, etc. Compared with RSA, ECC can ensure security and save computing resources.

Digital certificate: An authoritative electronic document containing public key owner information and the public key issued by a certificate authority (CA). For example, a digital certificate can contain a public key, name, and digital signature of the certificate authority. Digital certificates can be used to prove the identity of the owner of a public key.

Universal execution environment (rich execution environment, REE): It can also be called rich execution environment or ordinary execution environment or untrusted execution environment. It refers to the system running environment of the mobile terminal, which can run operating systems such as Android, IOS and Linux. REE has good openness and scalability but low security.

Trusted execution environment (TEE): It can also be called the safe side or safe zone. It is an area that requires authorization to access. TEE and REE coexist in the operating environment of electronic devices. Through hardware support, it is isolated from REE, has security capabilities, and can resist software attacks that conventional REEs are prone to. TEE has its own operating space and defines strict protection measures. Therefore, it has a higher security level than REE and can protect assets in TEE, such as data, software, etc., from software attacks and resist specific types of security. threaten.

REE+TEE architecture: refers to an architecture that combines TEE and REE to provide services for applications. In other words, TEE and REE coexist in electronic equipment. For example, TEE can implement an operating mechanism that is isolated from REE through hardware support. TEE has its own running space, which has a higher security level than REE and can protect assets in TEE (such as data, software, etc.) from software attacks. Only authorized security software can be executed in the TEE, and it also protects the confidentiality of the resources and data of the security software. Compared with REE, TEE can better protect the security of data and resources due to its isolation and permission control and other protection mechanisms.

Replay attacks: also known as replay attacks, replay attacks or freshness attacks, refer to the attacker sending a packet that has been received by the destination host to achieve the purpose of deceiving the system. It is mainly used in the identity authentication process. , destroying the correctness of the authentication.

Currently, when APP authentication is performed, the APP's signature information (for example, the application ID and the fingerprint of the application signature certificate) can be packaged in the APP's native code, or the APP's native code can call an API to obtain the signature information, and then send the signature information to the server for signature verification. However, this authentication method has security vulnerabilities. The security of the application's signature information cannot be guaranteed, and there is a possibility that the signature information has been tampered with, which makes the secure communication between the application and the server unguaranteed.

The embodiments of the present application provide an authentication method and device, which can authenticate the legitimacy of electronic devices and applications, thereby ensuring secure communication between the application and the server.

The authentication method and device provided by the embodiments of this application can be applied to the following scenarios:

(1) A cloud server (e.g., a secure cloud server) authenticates the legitimacy of an application.

(2) Scenario where the cloud server authenticates the legality of the application and the legality of the electronic device.

(3) Scenario where the cloud server authenticates the legitimacy of the application, the legitimacy of the device, and the trusted devices of the account (devices that log in to the same account and pass authentication).

Figure 1 exemplarily shows a schematic diagram of a system architecture applicable to the embodiment of the present application. As shown in Figure 1, the system architecture includes: server 001 and electronic device 002. Among them, the server 001 can be connected to the electronic device 002 through a communication network. The server 001 may be a cloud server or a server cluster located on the network side. Server 001 can be a secure cloud server. The server 001 can authenticate the electronic device 002 and the applications installed on the electronic device 002 to ensure the legitimacy of the electronic device 002 and the applications installed on the electronic device 002 .

Figure 2 exemplarily shows another system architecture schematic diagram applicable to the embodiment of the present application. As shown in Figure 2, the system architecture includes: server 001, electronic device 002, electronic device 003, electronic device 004 and server 005. Among them, the server 001 can be connected to the electronic device 002, the electronic device 003 and the electronic device 004 through the communication network. The server 005 can be connected with the electronic device 002, the electronic device 003 and the electronic device 004 through a communication network. Server 001 can be connected to server 005 through a communication network. Among them, server 001 and server 005 are cloud servers or server clusters located on the network side. Server 001 can be a secure cloud server, and server 005 can be an account cloud server.

In Figure 2, the server 005 can interact with the electronic device 002, the electronic device 003 and the electronic device 004. For example, electronic device 002, electronic device 003 and electronic device 004 can obtain system authentication account information (for example, Honor® account) from server 005, so that electronic device 002, electronic device 003 and electronic device 004 can verify whether the other end is logged in to the same System authentication account. If electronic device 002, electronic device 003 and electronic device 004 log in to the same system authentication account, it can be considered that electronic device 002, electronic device 003 and electronic device 004 are in the same trust ring, so that electronic device 002, electronic device 003 and electronic device 004 Data can be shared securely.

In Figure 2, the server 001 can authenticate any one of the electronic devices 002, 003, and 004 as well as the application installed on the electronic device. Furthermore, the server 001 can also authenticate whether any of the electronic devices 002, 003, and 004 belongs to a trusted device in the trust ring (a device that logs in to the same account and passes the authentication).

In Figure 2, electronic device 002, electronic device 003 and electronic device 004 may be various types of electronic devices. For example, electronic device 002 may be a tablet computer, electronic device 003 may be a mobile phone, and electronic device 004 may be a laptop computer.

In Figure 2, electronic device 002, electronic device 003 and electronic device 004 are connected through wired and/or wireless methods. Electronic device 002, electronic device 003 and electronic device 004 can be connected to server 001 through wired and/or wireless methods. Establish a connection wirelessly. For example, the electronic device 002, the electronic device 003, and the electronic device 004 may be interconnected through a wireless communication network. The wireless communication network may be a local area network or a wide area network transferred through a relay device. When the communication network is a local area network, for example, the communication network may be a short-range communication network such as a Wi-Fi hotspot network, a Wi-Fi P2P network, a Bluetooth network, a zigbee network, or an NFC network. When the communication network is a wide area network, for example, the communication network may be a 3rd-generation wireless telephone technology (3G) network or a 4th generation mobile communication technology (4G) network. , fifth-generation mobile communication technology (5th-generation mobile communication technology, 5G) network, future evolved public land mobile network (public land mobile network, PLMN) or the Internet, etc. In the scenario shown in Figure 2, different electronic devices can send data through the communication network, such as sending pictures, texts, videos, or electronic devices' retrieval results for objects such as pictures, texts, or videos, etc.

It should be noted that the above system may include more electronic devices, such as a smart TV, a smart watch, etc. Or the above system may include less than three electronic devices, such as only a mobile phone and a laptop, or only a mobile phone and a tablet computer, etc., and the embodiments of the present application are not limited to this.

In one possible design, the electronic devices (eg, electronic device 002, electronic device 003, and electronic device 004) may adopt the Honor® operating system (MagicOS). MagicOS can provide device authentication services for the interconnection of devices logged in to the same account (for example, Honor® account). Each MagicOS device (i.e., an electronic device using MagicOS) can generate a public and private key pair as its own identity after logging in to the Honor® account, and apply to the secure cloud server for authentication of its public key. Electronic devices under the same Honor® account that have passed the authentication can join the same trust ring, authenticate each other and exchange their respective public keys in the device interconnection business to confirm that the other end is a trusted device. Furthermore, based on the public and private key pairs of both parties, electronic devices logged into the same Honor® account can conduct key negotiation and establish a secure communication channel. Counterfeit devices and other devices not under this account will not be able to pass authentication.

As shown in Figure 3, taking device C as an example, the process of adding device C to the trust ring (the trust ring composed of device A and device B) is explained.

1. The application of device C (for example, Honor® Mall) logs in to the Honor® cloud server.

2. The application (for example, Honor® Mall) sends a login notification to the Trust Ring application.

Among them, the login notification may include the Honor® account used to log in to the application. Trust ring applications can interact with trust ring TA through trust ring services. The trust ring TA runs in a secure environment, such as TEE or a chip with security capabilities. The public key (that is, the public key corresponding to device C) and the private key generated by device C after logging into the Honor® account can be saved in the trust ring TA.

3. The trust ring application registers the device with the secure cloud server and uploads the public key corresponding to device C.

The trust ring application can obtain the public key corresponding to the device C (eg, public key C) from the trust ring TA, and send the public key to the secure cloud server.

4. The security cloud server sends an account verification request to the account cloud server.

5. The account cloud server sends a verification confirmation message to the security cloud server.

After the account cloud server passes the authentication of the account logged in by device C, it can send a verification confirmation message to the security cloud server, indicating that device C is a trusted device that joins the trust ring.

6. The secure cloud server updates the trusted device list.

The secure cloud server can save the public key of device C and the unique identifier of device C (for example, unique device identifier (UDID)) according to the Honor® account logged in by device C to the trusted account corresponding to the Honor® account. Device List. Moreover, the security cloud server can synchronize the trusted device list to the account cloud server.

The secure cloud server can add the identifier of device C (for example, UDID) and the public key of device C to the original trusted device list to obtain a new trusted device list. That is, the trusted ring server can update the version of the trusted device list. For example, if the original trusted device list is version 16, the new trusted device list can be version 17.

For example, the original trusted device list can be as shown in Table 1, including the UDID and public key of device A (public key A), and the UDID and public key of device B (public key B). Device A and device B logs in with the same account, for example, alice@honor.com.

Table 1

The new trusted device list may be as shown in Table 2, and may include the UDIDs and public keys corresponding to device A, device B, and device C respectively. Among them, the public key corresponding to device C is public key C.

Table 2

7. The secure cloud server sends the public key attribute certificate signed by the secure cloud server to device C.

Among them, the public key attribute credential is used to indicate the electronic device under the same Honor® account that has passed the authentication.

Device C holds the public key attribute credentials. Device C can mutually authenticate and exchange their respective public keys with electronic devices under the same Honor® account that have passed the authentication in the device interconnection business to confirm that the other end is a trusted device. Furthermore, based on the public and private key pairs of both parties, electronic devices logged into the same Honor® account can conduct key negotiation and establish a secure communication channel.

The following description takes the electronic device (for example, any one of the electronic device 002 - the electronic device 004 ) as the hardware structure of the electronic device 100 as an example. FIG. 4 shows a schematic diagram of the hardware structure of the electronic device 100. The electronic device 100 may be a mobile phone, a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (personal digital assistant) digital assistant (PDA), augmented reality (AR) device, virtual reality (VR) device, artificial intelligence (AI) device, wearable device, vehicle-mounted device, smart home device and/or Smart city equipment, the embodiment of this application does not place special restrictions on the specific type of electronic equipment.

The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a Universal Serial Bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, and an antenna 2. , mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone interface 170D, sensor module 180, button 190, camera 193, display screen 194, and subscriber identification module (Subscriber Identification Module , SIM) card interface 195, etc.

It can be understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the electronic device 100 . In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown in the figures, or some components may be combined, some components may be separated, or some components may be arranged differently. The components illustrated may be implemented in hardware, software, or a combination of software and hardware.

The processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (Application Processor, AP), a modem processor, a graphics processor (Graphics Processing unit, GPU), an image signal processing unit. Image Signal Processor (ISP), controller, memory, video codec, Digital Signal Processor (DSP), baseband processor, and/or Neural-network Processing Unit (NPU) )wait. Among them, different processing units can be independent devices or integrated in one or more processors.

The controller may be the nerve center and command center of the electronic device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in processor 110 is cache memory. This memory may hold instructions or data that have been recently used or recycled by processor 110 . If the processor 110 needs to use the instructions or data again, it can be called directly from the memory. Repeated access is avoided and the waiting time of the processor 110 is reduced, thus improving the efficiency of the system.

The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100 . The external memory card communicates with the processor 110 through the external memory interface 120 to implement the data storage function. Such as saving music, videos, etc. files in external memory card.

Internal memory 121 may be used to store computer executable program code, which includes instructions. The processor 110 executes instructions stored in the internal memory 121 to execute various functional applications and data processing of the electronic device 100 . The internal memory 121 may include a program storage area and a data storage area. Among them, the stored program area can store the operating system, at least one application program required for a function (such as a sound playback function, an image video playback function, etc.), etc. The storage data area may store data created during use of the electronic device 100 (such as audio data, phone book, etc.).

In some embodiments, processor 110 may include one or more interfaces. The USB interface 130 is an interface that complies with USB standard specifications, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 130 can be used to connect a charger to charge the electronic device 100, and can also be used to transmit data between the electronic device 100 and peripheral devices. It can also be used to connect headphones to play audio through them. This interface can also be used to connect other electronic devices 100, such as AR devices, etc.

The charging management module 140 is used to receive charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger through the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive wireless charging input through a wireless charging coil of the electronic device 100. While the charging management module 140 is charging the battery 142, it may also power the electronic device through the power management module 141.

The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charging management module 140, and supplies power to the processor 110, the internal memory 121, the display screen 194, the camera 193, the wireless communication module 160, and the like. The power management module 141 can also be used to monitor battery capacity, battery cycle times, battery health status (leakage, impedance) and other parameters. In some other embodiments, the power management module 141 may also be provided in the processor 110 . In other embodiments, the power management module 141 and the charging management module 140 may also be provided in the same device.

The wireless communication function of the electronic device 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 may be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization.

The mobile communication module 150 can provide solutions for wireless communication including 2G/3G/4G/5G applied on the electronic device 100 . The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (Low Noise Amplifier, LNA), etc. The mobile communication module 150 can receive electromagnetic waves through the antenna 1, perform filtering, amplification and other processing on the received electromagnetic waves, and transmit them to the modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves through the antenna 1 for radiation.

The wireless communication module 160 can provide wireless local area networks (Wireless Local Area Networks, WLAN) (such as Wi-Fi network), Bluetooth (Bluetooth, BT), and global navigation satellite system (Global Navigation Satellite System, GNSS) applied on the electronic device 100. , Frequency Modulation (FM), NFC, infrared technology (Infrared, IR) and other wireless communication solutions. The wireless communication module 160 may be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2 , frequency modulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 110 . The wireless communication module 160 can also receive the signal to be sent from the processor 110, frequency modulate it, amplify it, and convert it into electromagnetic waves through the antenna 2 for radiation.

In some embodiments, the antenna 1 of the electronic device 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the electronic device 100 can communicate with the network and other devices through wireless communication technology.

The electronic device 100 can implement audio functions through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone interface 170D, and the application processor. Such as music playback, recording, etc.

The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals.

The speaker 170A, also called a "horn", is used to convert audio electrical signals into sound signals.

Receiver 170B, also called "earpiece", is used to convert audio electrical signals into sound signals.

The microphone 170C, also called a "microphone" or "speaker", is used to convert a sound signal into an electrical signal. The electronic device 100 may be provided with at least one microphone 170C.

The headphone interface 170D is used to connect wired headphones.

The sensor module 180 may include one or more sensors, which may be of the same type or different types. The sensor module 180 may include a pressure sensor, a gyroscope sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a touch sensor, an ambient light sensor, and the like.

The buttons 190 include a power button, a volume button, etc. Key 190 may be a mechanical key. It can also be a touch button. The electronic device 100 may receive key inputs and generate key signal inputs related to user settings and function control of the electronic device 100 .

The display screen 194 is used to display images, videos, etc. Display 194 includes a display panel. The display panel can use a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (Active-MatrixOrganic Light Emitting Diode). (AMOLED), Flexible Light-Emitting Diode (FLED), Mini LED, Micro LED, Micro-OLED, Quantum Dot LightEmitting Diodes (QLED), etc. In some embodiments, the electronic device 100 may include 1 or N display screens 194, where N is a positive integer greater than 1.

The electronic device 100 implements display functions through a GPU, a display screen 194, an application processor, and the like. The GPU is an image processing microprocessor and is connected to the display screen 194 and the application processor. GPUs are used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or alter display information.

The electronic device 100 can realize the function of acquiring images through an ISP, a camera 193, a video codec, a GPU, a display screen 194, an application processor, and the like.

ISP is used to process the data fed back by camera 193. For example, when taking a photo, the shutter is opened, and the light is transmitted to the camera photosensitive element through the lens. The light signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to ISP for processing and converts it into an image or video visible to the naked eye. ISP can also perform algorithm optimization on the noise, brightness, and skin of the image. ISP can also optimize the exposure, color temperature and other parameters of the shooting scene. In some embodiments, ISP can be set in camera 193.

Camera 193 is used to capture still images or video. The object passes through the lens to produce an optical image that is projected onto the photosensitive element. The photosensitive element can be a Charge Coupled Device (CCD) or a Complementary Metal-Oxide-Semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, and then passes the electrical signal to the ISP for conversion into a digital image or video signal. ISP outputs digital images or video signals to DSP for processing. DSP converts digital images or video signals into standard RGB, YUV and other formats.

In some embodiments, the electronic device 100 may include 1 or N cameras 193, where N is a positive integer greater than 1. For example, in some embodiments, the electronic device 100 can use N cameras 193 to acquire images with multiple exposure coefficients. Furthermore, in video post-processing, the electronic device 100 can use high dynamic range ( HighDynamic Range (HDR) technology synthesizes HDR images.

Video codecs are used to compress or decompress digital video. Electronic device 100 may support one or more video codecs. In this way, the electronic device 100 can play or record videos in multiple encoding formats, such as: Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

NPU is a neural network (NN) computing processor. By drawing on the structure of biological neural networks, such as the transmission mode between neurons in the human brain, it can quickly process input information and can continuously learn by itself. Intelligent cognitive applications of the electronic device 100 can be implemented through the NPU, such as image recognition, face recognition, speech recognition, text understanding, etc.

The SIM card interface 195 is used to connect a SIM card. The SIM card can be connected to or disconnected from the electronic device 100 by inserting it into or removing it from the SIM card interface 195. The electronic device 100 can support 1 or N SIM card interfaces, where N is a positive integer greater than 1. The electronic device 100 interacts with the network through the SIM card to implement functions such as calls and data communications. In some embodiments, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

In a possible design, as shown in FIG. 5 , the electronic device 100 may include an application program and a Harmony universal keystore (HUKS) component/module. Among them, applications may include, for example, Honor® Mall, Sports and Health, Trust Ring, etc. Among them, applications such as Honor® Mall and Sports Health can log in to the Honor® account and join the trust ring (system) through the trust ring application. The trust ring system is a public key infrastructure (PKI). The description of the trust ring system can be found in the relevant description above and will not be described in detail here.

The HUKS component is used to provide keystore capabilities to applications, including key management and key cryptographic operations. The HUKS environment can include components such as key management components, key library components, functional service components, and external interfaces.

Among them, the key management component can use a multi-level key management method (for example, root key, master key, key encryption key, working key) for key management. Among them, the root key is a key that rarely changes. The root key can ensure the security of the master key. The master key can derive the key encryption key to ensure the security of other working keys in the key database. In the embodiment of this application, the public key and private key generated by the application calling the HUKS interface belong to the working key.

The key library component is used to store, read, and update working keys.

The functional service component defines the functional implementation provided by HUKS key management. The external interface can provide interface functions (for example, HUKS interface) for use by the upper layer (applications, such as Honor® Mall, Sports and Health). For example, applications (for example, Honor® Mall, Sports and Health) can call the HUKS interface to generate keys (for example, public keys and private keys).

The cloud server (for example, a security cloud server or an account cloud server) in the embodiment of the present application can be implemented by the communication device in Figure 6. The communication device 600 includes at least one processor (for example, processor 601 and processor 605), a communication line 602, a memory 603 and at least one communication interface 604.

The processor 601 may be a CPU, a microprocessor, an ASIC, or one or more integrated circuits used to control the execution of the program of the present application.

Communication line 602 may include a path that carries information between the above-mentioned components.

The communication interface 604 uses any transceiver or other device for communicating with other devices or communication networks, such as Ethernet, RAN, WLAN, etc.

The memory 603 can be ROM or other types of static storage devices that can store static information and instructions, RAM or other types of dynamic storage devices that can store information and instructions, or it can be EEPROM, CD-ROM or other optical disk storage, optical disk storage , disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto. The memory may exist independently and be connected to the processor through a communication line 602 . Memory can also be integrated with the processor.

The memory 603 is used to store computer-executable instructions for executing the solution of the present application, and the execution is controlled by the processor 601. The processor 601 is used to execute the computer-executable instructions stored in the memory 603, thereby implementing the method provided in the following embodiments of the present application.

Optionally, the computer-executed instructions in the embodiments of the present application may also be called application codes, which are not specifically limited in the embodiments of the present application.

In specific implementation, as an embodiment, the processor 601 may include one or more CPUs, such as CPU0 and CPU1 in FIG. 6 .

In specific implementation, as an embodiment, the communication device 600 may include multiple processors, such as the processor 601 and the processor 605 in FIG. 6 . Each of these processors can be a single-core processor or a multi-core processor. A processor here may refer to one or more devices, circuits, and/or processing cores for processing data (eg, computer program instructions).

The embodiments of the present application do not particularly limit the specific structure of the execution subject of the method provided in the embodiments of the present application, as long as it can communicate according to the method provided in the embodiments of the present application by running a program that records the code of the method provided in the embodiments of the present application. For example, the execution subject of the method provided in the embodiments of the present application may be an electronic device or a cloud server, or a functional module in the electronic device or cloud server that can call and execute a program.

In a possible design, as shown in Figure 7, the cloud server (for example, a secure cloud server) can include a certificate authentication module, an anti-replay module, an APP signature fingerprint acquisition module, an account authentication module, and a trust ring module. Among them, the certificate authentication module can also be called a cloud certificate service (cloud certificate service, CCS) module.

Among them, the CCS certificate authentication module is used to verify the legitimacy of certificates such as device certificates and intermediate certificates based on the certificate chain.

The anti-replay module is used to determine the number of times a request received by the secure cloud server is triggered within a specific period of time (for example, 5 minutes, 10 minutes, etc.) to prevent replay attacks.

The APP signature fingerprint acquisition module is used to authenticate the application signature certificate fingerprint to determine the legitimacy of the application.

The account authentication module is used to authenticate the account used to log in to the device (for example, a Honor® account).

The trust ring module is used to authenticate whether the device is a trusted device in the trust ring (a device that logs in with the same account and has passed the authentication).

The network architecture and business scenarios described in the embodiments of this application are for the purpose of explaining the technical solutions of the embodiments of this application more clearly, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those of ordinary skill in the art will know that with the network With the evolution of architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. Among them, in the description of this application, unless otherwise specified, "at least one" refers to one or more, and "plurality" refers to two or more than two. In addition, in order to facilitate a clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as “first” and “second” are used to distinguish identical or similar items with basically the same functions and effects. Those skilled in the art can understand that words such as "first" and "second" do not limit the number and execution order, and words such as "first" and "second" do not limit the number and execution order.

For ease of understanding, the authentication method provided by the embodiment of the present application will be introduced in detail below with reference to the accompanying drawings.

As shown in Figure 8, this embodiment of the present application provides an authentication method, including an account authentication process, an application authentication process, and a device authentication process. Among them, the account authentication process includes the following steps 801 to 803.

801. The application sends a user authentication request to the secure cloud server.

In response to the user's operation to log in to the application (for example, Honor® Mall), the application can send a user authentication request to the secure cloud server. The user authentication request is used to request the secure cloud server to verify the user's identity. The operation for the user to log in to the application may be, for example, the user clicking the login button to log in, or the user triggering the automatic login operation, which is not limited in this application.

Among them, the user authentication request can carry the login token (Token). Among them, the login token is issued to the application by the security cloud server when the application logs in successfully for the first time. Login Token can be used to verify user identity. If the user logs in for the first time, the user authentication request can carry the account number and password so that the secure cloud server can verify whether the user's account (for example, Honor® account) and password are correct.

Among them, the application program may be the first application. The secure cloud server can be the first server.

802. The secure cloud server performs account authentication, and generates a random number if the authentication passes.

After receiving the user authentication request sent by the application, the security cloud server parses the login token and verifies the login token. If the verification passes, a random number can be generated as a Challenge and delivered to the application.

803. The secure cloud server sends an account authentication success message and a random number to the application.

The application receives the account authentication success message and a random number from the secure cloud server, and saves the random number.

It should be noted that steps 801 to 803 are optional steps. Steps 801 to 803 may be executed before the steps of application authentication and device authentication (steps 804 to 810), may be executed after steps 804 to 810, or may not be executed. This embodiment does not make specific limitations.

The application authentication process and the device authentication process include the following steps 804 to 810.

804. The application calls the HUKS interface to generate a pair of public and private keys.

After the user completes the installation of the application, when the user opens the application for the first time, in response to the user's operation of opening the application for the first time, the application can call the HUKS interface to generate a pair of public and private keys.

Among them, the HUKS interface (HUKS API) is the interface that HUKS components open to upper-level software (for example, applications). HUKS components run in a secure environment, such as TEE or chips with security capabilities. The HUKS interface can be the HUKS application layer interface provided by Honor® MagicOS.

Among them, the public key and private key are used to encrypt and verify the business data of the application respectively. Public and private keys can be generated according to ECC or RSA algorithms.

805a. The application calls the HUKS interface to generate a device certificate.

The application can call the HUKS interface based on the public key and private key generated in step 804 to obtain the device certificate (an example of the first digital certificate). Device certificates can be signed with a private key. Among them, the device certificate is used to authenticate the legality of electronic devices (for example, mobile phones).

In the embodiment of the present application, the device certificate may include an application identifier (ID), an application signature certificate fingerprint, a unique identifier of the electronic device (e.g., UDID), and a public key (the public key generated in step 804). The unique identifier of the electronic device may also be other identifiers that can uniquely identify the electronic device, which is not limited in the present application.

Among them, the application signing certificate fingerprint is used to verify the legitimacy of the application. The application signing certificate fingerprint is used to ensure that the communication between the application and the server (for example, a secure cloud server) is secure and trusted, avoiding the risk of man-in-the-middle attacks and malicious hijacking. The application signing certificate fingerprint can be obtained based on the signature file of the APK package of the application. The signature file of the APK package may include CERT.RSA and CERT.SF, for example. CERT.RSA and CERT.SF can be stored in the META-INF directory. Among them, CERT.RSA may contain the public key information and issuing agency information of the application signing certificate. Exemplarily, the application signing certificate fingerprint may be a hash value used to verify the legitimacy of the application.

In an embodiment of the present application, the private key generated in step 804 and the device certificate generated in step 805a can be stored in the TEE to prevent the private key and the device certificate from being stolen or tampered with.

Optionally, the application may also fill a random number into the device certificate, that is, the device certificate may also include a random number.

805b. The application uploads the device certificate to the secure cloud server.

That is, the application sends the device certificate to the secure cloud server.

806. The secure cloud server verifies the legality of the device certificate.

After receiving the device certificate, the secure cloud server can parse the device certificate to extract information such as application ID, application signature certificate fingerprint, UDID, public key, etc. Optionally, the secure cloud server can also parse to obtain information such as random numbers.

The secure cloud server can verify the legitimacy of the device certificate based on the certificate chain. Among them, the certificate chain can include the device certificate, one or more intermediate certificates (for example, intermediate_cert_1, ..., intermediate_cert_n), and the root certificate (for example, honor_root_cert). Among them, the root certificate can be a self-signed certificate and can be stored in a secure cloud server.

For each certificate in the device certificate and all intermediate certificates, the secure cloud server can verify whether the validity period of the certificate is within the legal date, and verify whether the signature of the certificate is issued by its issuing authority, that is, whether it is signed with the issuing authority's public key. If the verification of the device certificate and all intermediate certificates is successful, that is, the certificate chain verification passes, the device certificate is determined to be legal. If the device certificate is legal, the electronic device is considered legal, that is, the device authentication passes.

If the device certificate is valid, the secure cloud server can continue to perform steps 807-810. If the device certificate is illegal, the secure cloud server may not perform further processing (that is, steps 808-810 will not be performed).

807. The secure cloud server determines the number of times the random number is triggered within a specific period of time to prevent replay attacks.

Optionally, the secure cloud server can also determine the number of times the random number is triggered within a specific period of time (for example, 5 minutes, 10 minutes, etc.) to prevent replay attacks. If the random number is triggered only once within a specific period of time, it is determined that a replay attack has not occurred, and the following steps (step 808, step 809, etc.) can be performed normally. If the random number is triggered multiple times within a specific period of time, a replay attack may occur, and the secure cloud server does not need to perform further processing (that is, steps 808, 809, etc. will no longer be performed).

808. The secure cloud server verifies the legality of the application.

The secure cloud server can verify the legitimacy of the application based on the parsed application ID and application signature certificate fingerprint.

In one possible design, the secure cloud server can compare (match) the parsed application ID and application signature certificate fingerprint with the whitelist. Among them, the whitelist can be preset on the secure cloud server. The whitelist can record the application IDs and application signature certificate fingerprints of multiple legitimate applications. If the parsed application ID and application signature certificate fingerprint are present in the whitelist, the application is determined to be a legitimate application (trusted application).

809. The secure cloud server generates a device token.

It should be noted that when the UDID (for example, the first UDID) carried in the device certificate is registered for the first time, that is, when the security cloud server receives the device certificate containing the first UDID for the first time, the security cloud server can be based on the UDID. (for example, the first UDID) generates a device Token, and establishes a corresponding relationship between the device Token and the public key (the public key generated in step 804). Subsequent data requested by the application can be signed using the private key (the private key generated in step 804) corresponding to the public key (the public key generated in step 804), and the signed data and device Token can be sent to the secure cloud server. The secure cloud server can verify the device Token to ensure the legitimacy of electronic devices and applications. The secure cloud server can verify the data requested by the application based on the public key corresponding to the device Token to ensure the integrity of the message.

Among them, device Token is an example of the first token.

810. The secure cloud server issues device Token to the application.

In the embodiment of this application, the device Token can be used to verify whether the electronic device and application program are legal. If the verification passes, it means that the electronic device and application are legal.

In the embodiment of this application, the application can save the device Token in the TEE to prevent the device Token from being stolen or tampered with.

At this point, application authentication and device authentication are completed, and the secure cloud server can interact with the application for business data. That is, the method provided in this application may also include the following steps:

811. The application sends a business data request to the secure cloud server.

The service data request may include the device Token and the service data signed by the private key. The application may sign the service data of the preset highly sensitive interface based on the private key generated in step 804.

Among them, the highly sensitive interface can be pre-set by the developer of the application. The highly sensitive interface involves the processing of highly sensitive data (for example, payment information, biometric information, etc.). Highly sensitive data needs to be encrypted and signed on the end side (electronic device side), and the signature needs to be verified on the cloud side (security cloud server side) to ensure the security of highly sensitive data.

812. The secure cloud server queries the corresponding public key based on the device Token for signature verification.

After receiving the business data request, the secure cloud server parses the device Token and queries the public key corresponding to the device Token based on the correspondence between the device Token and the public key established by itself. If the public key corresponding to the device Token is queried, the business data signed by the private key is verified based on the queried public key.

813. If the signature verification is successful, a business data response is sent to the application.

If the secure cloud server verifies the signed business data and determines that the electronic device and application are legitimate, that is, it determines that the business data request is initiated by a legitimate application of a legitimate device, it can send a business data response to the application, allowing the application of the electronic device to call the highly sensitive interface to process the highly sensitive data.

814. If the signature verification fails, an interface error will be sent to the application.

If the secure cloud server fails to verify the signed business data and cannot determine whether the electronic device and application that initiated the business data request are legal, it can send an interface error to the application and do not allow the application of the electronic device to call highly sensitive interfaces. Sensitive data is processed.

For example, taking the application as the Honor® Mall, as shown in (a) in Figure 9, after the user opens the Honor® Mall on mobile phone A, he can enter the shopping cart interface 901. In response to the user entering the shopping cart interface 901 By clicking the settlement button 902, the mobile phone can send a settlement request to the secure cloud server. The settlement request can carry the device Token and business data signed according to the private key (for example, settlement product information, settlement amount, etc.). The secure cloud server can be based on the deviceToken. Query the public key corresponding to the device Toke for signature verification. If the signature verification is passed, the electronic device application is allowed to perform settlement processing. For example, as shown in (b) of FIG. 9 , the mobile phone may display the payment order interface 903 . The payment order interface 903 may include multiple payment methods and a payment confirmation button 904. The user can select the corresponding payment method and click the confirm payment button 904 to make the payment. If the signature verification fails, an interface error will be sent to the application, and the electronic device application will not be allowed to perform settlement processing. For example, as shown in (c) of Figure 9, the mobile phone can display a pop-up box 905, which is used to prompt the user that the settlement has failed. Optionally, the mobile phone can also prompt the user for the reason for settlement failure, for example, the electronic device and the current application have not passed authentication.

Based on the method provided by the embodiment of this application, the application program (first application) of the electronic device can obtain the device certificate (first digital certificate) from the TEE and send the certificate to the secure cloud server (first server). The secure cloud server can certify the device certificate and certify the application's identity and application signing certificate fingerprint. If the device certificate passes the authentication and the application signature certificate fingerprint contained in the certificate passes the authentication, the application can communicate securely with the secure cloud server. Since the device certificate is obtained directly from the TEE, it can avoid the problem of malicious programs on the terminal side (electronic device side) tampering with the application identification and application signature certificate fingerprint in the device certificate. Moreover, the device certificate carries the application's identity and application signature certificate fingerprint to the secure cloud server, allowing the security cloud server to authenticate not only the device certificate, but also the application's identity and application signature certificate fingerprint. After both are authenticated, , the application can communicate with the secure cloud server, ensuring the security of communication between the application and the secure cloud server.

As shown in FIG. 10 , an embodiment of the present application provides an authentication method, including an application authentication process.

1001. The application calls the HUKS interface to generate a pair of public and private keys.

For the specific process, please refer to step 804, which will not be described again here.

1002. The application calls the HUKS interface to generate digital certificate A.

Among them, digital certificate A (an example of the first digital certificate) may include information such as application ID, application signature certificate fingerprint, and public key.

Optionally, the embodiment of this application may also include an account authentication process. During the account authentication process, the electronic device application can receive random numbers from the cloud server. The application can also fill in random numbers into digital certificate A, that is, digital certificate A can also include random numbers.

1003. The application uploads digital certificate A to the secure cloud server.

That is, the application sends digital certificate A to the secure cloud server.

1004. The secure cloud server verifies the legality of digital certificate A.

After receiving the digital certificate A, the secure cloud server can parse the digital certificate A to extract the application ID, the fingerprint of the application signature certificate, the public key and other information. Optionally, the secure cloud server can also parse to obtain information such as random numbers.

The secure cloud server can verify the legitimacy of the device certificate based on the certificate chain. For the specific process, please refer to step 806, which will not be described again here.

If digital certificate A is valid, the secure cloud server can continue to perform step 1005. If digital certificate A is illegal, the secure cloud server may not perform further processing.

In addition, the secure cloud server can also determine the number of times the random number is triggered within a specific period of time to prevent replay attacks. For relevant instructions, please refer to step 807, which will not be described again here.

1005. The secure cloud server verifies the legitimacy of the application.

The secure cloud server can verify the legitimacy of the application program based on the parsed application ID and application signature certificate fingerprint. For related instructions, please refer to step 808, which will not be repeated here.

If the application authentication passes, the secure cloud server can save the public key carried in digital certificate A. Optionally, the application can establish a correspondence between the application ID and the public key (the public key carried in digital certificate A).

At this point, the application authentication is completed, and the secure cloud server can interact with the application for business data. That is, the method provided in this application may also include the following steps:

1006. The application sends a business data request to the secure cloud server.

The service data request may include service data signed according to the private key. Optionally, the business data request may also include the application ID. The application can sign the business data of the preset highly sensitive interface based on the private key generated in step 1001. For relevant instructions on highly sensitive interfaces, please refer to step 811 and will not be described in detail here.

1007. The secure cloud server verifies the business data signed by the private key.

After receiving the business data request, the secure cloud server parses the application ID and queries the public key corresponding to the application ID based on the corresponding relationship between the application ID and the public key established by itself. If the public key corresponding to the application ID is queried, the business data signed by the private key is verified based on the queried public key.

1008. If the signature verification passes, send a business data response to the application.

For relevant instructions, please refer to step 813, which will not be described again here.

1009. If the signature verification fails, an interface error is sent to the application.

For relevant instructions, please refer to step 814, which will not be described again here.

Based on the method provided by the embodiment of this application, the application program (first application) of the electronic device can obtain digital certificate A (first digital certificate) from the TEE and send the certificate to the secure cloud server (first server). The secure cloud server can certify digital certificate A, and certify the application's identity and application signature certificate fingerprint. When the digital certificate A passes the authentication and the application signature certificate fingerprint contained in the certificate passes the authentication, the application can communicate securely with the secure cloud server. Since digital certificate A is obtained directly from the TEE, it can avoid the problem of malicious programs on the terminal side (electronic device side) tampering with the application identification and application signature certificate fingerprint in digital certificate A. Furthermore, digital certificate A carries the application's identity and application signature certificate fingerprint to the secure cloud server, so that the security cloud server not only authenticates digital certificate A, but also authenticates the application's identity and application signature certificate fingerprint, both of which are authenticated. After passing, the application can communicate with the secure cloud server, ensuring the security of communication between the application and the secure cloud server.

As shown in Figure 11, this embodiment of the present application provides an authentication method, including a device authentication process.

1101. The application calls the HUKS interface to generate a pair of public and private keys.

1102. The application calls the HUKS interface to generate digital certificate B.

Among them, digital certificate B (an example of the first digital certificate) may include UDID, public key and other information.

1103. The application uploads digital certificate B to the secure cloud server.

That is, the application sends digital certificate B to the secure cloud server.

Optionally, this application embodiment can also include an account authentication process. During the account authentication process, random numbers can be received from the cloud server, and the application can also fill in the random numbers into digital certificate B, that is, digital certificate B can also include random numbers. .

1104. The secure cloud server verifies the legality of digital certificate B.

After receiving digital certificate B, the secure cloud server can parse digital certificate B and extract information such as UDID and public key.

The secure cloud server can verify the legitimacy of digital certificate B based on the certificate chain. For the specific process, please refer to step 806, which will not be described again here.

If digital certificate B is valid, the secure cloud server can continue to perform step 1105.

1105. The secure cloud server generates a device token.

It should be noted that when the UDID (for example, the first UDID) carried in digital certificate B is registered for the first time, that is, the secure cloud server receives the digital certificate (for example, digital certificate B) containing the first UDID for the first time. Next, the security cloud server can generate a device Token based on the UDID (for example, the first UDID), and establish a corresponding relationship between the device Token and the public key (the public key generated in step 1101). Subsequent data requested by the application can be signed using the private key (private key generated in step 1101) corresponding to the public key (public key generated in step 1101), and the signed data and device Token can be sent to the secure cloud server. The secure cloud server can verify the device Token to ensure the legitimacy of electronic devices and applications. The secure cloud server can verify the data requested by the application based on the public key corresponding to the device Token to ensure the integrity of the message.

1106. The secure cloud server issues device Token to the application.

In the embodiment of this application, the device Token can be used to verify whether the electronic device is legal.

In the embodiment of this application, the application can save the device Token in the TEE to prevent the device Token from being stolen or tampered with.

At this point, the device authentication is completed, and the secure cloud server can interact with the application for business data. That is, the method provided in this application may also include the following steps:

1107. The application sends a business data request to the secure cloud server.

Among them, the business data request may include device Token and business data signed according to the private key. The application can sign the business data of the preset highly sensitive interface based on the private key generated in step 1101. For relevant instructions on highly sensitive interfaces, please refer to step 811 and will not be described in detail here.

1108. The secure cloud server verifies the business data signed by the private key.

For relevant instructions, please refer to step 812, which will not be described again here.

1109. If the signature verification passes, send a business data response to the application.

For related instructions, please refer to step 813, which will not be repeated here.

1110. If the signature verification fails, an interface error will be sent to the application.

For relevant instructions, please refer to step 814, which will not be described again here.

Based on the method provided by the embodiment of this application, the application program (first application) of the electronic device can obtain digital certificate B (first digital certificate) from the TEE and send the certificate to the secure cloud server (first server). The secure cloud server can authenticate digital certificate B. Since digital certificate B is obtained directly from TEE, the legitimacy of digital certificate B can be guaranteed. If the digital certificate B is authenticated, the application can communicate securely with the secure cloud server.

In some embodiments, the security cloud server can also authenticate whether the electronic device is a trusted device of the trust ring. Among them, the trusted device of the trust ring refers to any electronic device among multiple electronic devices that are logged in to the same account (for example, Honor® account) and authenticated by the secure cloud server. In the case where the electronic device is a trusted device of the trust ring, the secure cloud server can send a business data response to the application, allowing the application of the electronic device to call a highly sensitive interface to process the highly sensitive data. Otherwise, the secure cloud server can send an interface error to the application program, and the application program of the electronic device is not allowed to call the highly sensitive interface to process the highly sensitive data.

In a possible design, after or before the secure cloud server completes at least one of application authentication, account authentication, and device authentication, the secure cloud server may also authenticate whether the electronic device is a trusted device in the trust ring, as shown in FIG12 . The process includes the following steps:

1201a. The application sends account login status and device information to the secure cloud server.

Among them, the account login status is used to indicate whether the account has been logged in (for example, Honor® account), and the device information includes the unique identifier of the electronic device (for example, UDID).

1201b. The security cloud server queries the account cloud server for the legality of the login status of the electronic device.

When the electronic device has logged into the account, the security cloud server can submit the login status and device information of the electronic device to the account cloud server.

1202. The account cloud server returns the query result of the electronic device to the security cloud server.

The account cloud server can query the list of trusted devices based on the login status and device information of the electronic device. If the device information (for example, UDID) of the electronic device is included in the trusted device list (i.e., the trusted device list includes the device information of the electronic device), that is, the account logged in by the electronic device passes two-factor verification (i.e., two-factor authentication), it is determined Electronic devices are trusted devices in the trust circle. If the trusted device list does not include the device information of the electronic device, that is, the account logged in by the electronic device does not pass the two-factor verification (i.e., two-factor authentication), it is determined that the electronic device is not a trusted device in the trust ring. Among them, two-factor verification can also be called two-factor verification, which refers to verification based on password and verification code.

1203. The security cloud server performs corresponding processing according to the query results of the electronic device.

If the electronic device is a device that passes two-factor verification (that is, the account used to log in to the electronic device (the account used to log in to the application) passes the two-factor verification), and the application authentication, account authentication, and device authentication performed on the electronic device or application At least one of the authentications passed (for example, application authentication, account authentication, device authentication all passed, or application authentication and device authentication passed, or application authentication passed), allowing highly sensitive interface operations, that is, allowing electronic devices Applications call highly sensitive interfaces to process highly sensitive data.

If the electronic device is a non-two-factor verification device, that is, the electronic device does not pass the two-factor verification, it can perform highly sensitive interface operations and report an error, that is, it can send an interface error report to the application program, and the application program of the electronic device is not allowed to call the highly sensitive interface pair. Highly sensitive data is processed. In this way, communication security between the first application and the first server can be ensured.

An embodiment of the present application also provides a chip system. As shown in Figure 13, the chip system includes at least one processor 1301 and at least one interface circuit 1302. The processor 1301 and the interface circuit 1302 may be interconnected by wires. For example, interface circuitry 1302 may be used to receive signals from other devices (eg, memory). As another example, interface circuit 1302 may be used to send signals to other devices (eg, processor 1301).

For example, the interface circuit 1302 can read instructions stored in the memory of the terminal device and send the instructions to the processor 1301. When the instructions are executed by the processor 1301, the electronic device (electronic device 100 as shown in Figure 4) or the cloud server (for example, the communication device 600 as shown in Figure 6) can be caused to perform various steps in the above embodiments. .

Of course, the chip system may also include other discrete devices, which are not specifically limited in the embodiments of this application.

Embodiments of the present application also provide a computer-readable storage medium that includes computer instructions. When the computer instructions are stored in an electronic device (electronic device 100 as shown in Figure 4) or a cloud server (for example, as When running on the communication device 600 shown in Figure 6), the electronic device (the electronic device 100 shown in Figure 4) or the cloud server (for example, the communication device 600 shown in Figure 6) executes the electronic device in the above method embodiment. Individual functions or steps performed by a device (e.g., mobile phone) or secure cloud server.

The embodiment of the present application also provides a computer program product. When the computer program product is run on a computer, the computer is enabled to execute each function or step executed by the electronic device in the above method embodiment.

The embodiment of the present application also provides an authentication device. The authentication device can be divided into different logical units or modules according to functions. Each unit or module performs different functions, so that the authentication device performs the electronic processing in the above method embodiment. Each function or step performed by the device or cloud server.

Through the description of the above embodiments, those skilled in the art can clearly understand that the above function allocation can be completed by different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete the above described All or part of the functionality.

In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated. The components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place, or they may be distributed to multiple different places. . Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

The above contents are only specific implementation modes of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be covered by the protection scope of the present application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

Claims (16)

1. An authentication method, characterized in that it is applied to an electronic device, a first application is installed in the electronic device, and the electronic device includes a trusted execution environment TEE; the method includes: The electronic device runs the first application and obtains a first digital certificate from the TEE, where the first digital certificate is generated in the TEE, and the first digital certificate includes an identifier of the first application, an application signature certificate fingerprint, and a unique identifier of the electronic device; The electronic device sends the first digital certificate to the first server; The electronic device receives an authentication pass message from the first server. The authentication pass message is used to indicate that the first digital certificate has passed the authentication, and that the identification of the first application and the fingerprint of the application signature certificate have passed the authentication. ; The electronic device securely communicates with the first server based on the first application. 2. The method according to claim 1, wherein the first application obtains the first digital certificate from the TEE including: The electronic device runs the first application and calls the universal keystore system HUKS interface to obtain the first digital certificate from the TEE. 3. The method according to claim 1, characterized in that, The first digital certificate also includes a public key of the electronic device. 4. The method according to claim 3, characterized in that, The authentication pass message includes a first token, the first token has a corresponding relationship with the public key, and the first token is used to verify the legality of the electronic device and the first application. 5. The method of claim 4, wherein the electronic device securely communicates with the first server based on the first application including: The electronic device signs the first service data of the first application based on the first application according to the private key corresponding to the public key to obtain signature data; The electronic device sends the signature data and the first token to the first server based on the first application. 6. The method according to any one of claims 1-5, characterized in that, The electronic device logs in to a first account based on the first application, and the first account passes two-factor verification. The two-factor verification includes password verification and verification code verification. 7. An authentication method, characterized in that it is applied to an authentication system including an electronic device and a first server, wherein a first application is installed in the electronic device, and the electronic device includes a trusted execution environment TEE, and the method comprises: The electronic device runs the first application to obtain a first digital certificate from the TEE. The first digital certificate is generated in the TEE. The first digital certificate includes the identification of the first application, Apply the signature certificate fingerprint and the unique identifier of the electronic device; The electronic device sends the first digital certificate to the first server; The first server receives the first digital certificate and authenticates the first digital certificate based on the certificate chain; After the first server passes the authentication of the first digital certificate, it authenticates the identity of the first application and the fingerprint of the application signature certificate; After the first server successfully authenticates the identity of the first application and the fingerprint of the application signature certificate, it sends an authentication pass message to the first application. The authentication pass message is used to indicate the first digital certificate authentication. Passes, and the identification of the first application and the fingerprint authentication of the application signature certificate pass; The electronic device receives the authentication pass message from the first server; The electronic device securely communicates with the first server based on the first application. 8. The method according to claim 7, wherein the electronic device running the first application to obtain the first digital certificate from the TEE includes: The electronic device runs the first application and calls the universal keystore system HUKS interface to obtain the first digital certificate from the TEE. 9. The method according to claim 7, characterized in that, The first digital certificate also includes the public key of the electronic device. 10. The method according to claim 9, characterized in that the method further comprises: The first server generates a first token based on the unique identifier of the electronic device; The first server establishes a corresponding relationship between the first token and the public key, and the first token is used to verify the legitimacy of the electronic device and the first application. 11. The method according to claim 10, characterized in that, The authentication pass message includes the first token. 12. The method of claim 11, wherein the electronic device securely communicates with the first server based on the first application including: The electronic device signs the first service data of the first application based on the first application according to the private key corresponding to the public key to obtain signature data; The electronic device sends the signature data and the first token to the first server based on the first application; The first server receives the signature data and the first token; The first server verifies the signature data based on the public key corresponding to the first token. 13. The method according to any one of claims 7-12, characterized in that, The electronic device logs in to a first account based on the first application, and the first account passes a two-factor verification, and the two-factor verification includes a password verification and a verification code verification. 14. An authentication system, characterized by comprising an electronic device and a first server, the electronic device and the first server executing the method according to any one of claims 7-13. 15. An electronic device, characterized in that the electronic device comprises a processor, and the processor is used to run a computer program stored in a memory, so that the electronic device implements the method according to any one of claims 1 to 6. 16. A computer-readable storage medium, characterized in that a computer program is stored in the computer-readable storage medium, and when the computer program is run on a processor, the method according to any one of claims 1-6 is implemented. .