Authentication method, electronic device, and system

Abstract

The present application relates to the technical field of terminals, and provides an authentication method, an electronic device, and a system. The present application adaptively finishes user identity authentication on the basis of a user identity authentication success event recorded in a trusted holding device, thereby improving the use convenience of the user. The method comprises: a second electronic device receiving an authentication request from a first electronic device that is in short-distance communication connection with the second electronic device, wherein an authentication trust level supported by the second electronic device satisfies a first authentication trust level requirement for a first service to be subjected to user identity authentication in the first electronic device; in the case of being in a first state, in a first list, matching a first authentication result corresponding to the authentication request, wherein the first list comprises a user identity authentication success event generated by at least one of the second electronic device or the first electronic device; and transmitting the first authentication result to the first electronic device, wherein the first authentication result is used for generating a second authentication result indicating whether the second electronic device passes trust authentication.

Description

Authentication method, electronic device and system

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on June 26, 2023, with application number 202310761765.6 and application name “A method for authentication, electronic equipment and system”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of terminal technology, and in particular to an authentication method, electronic device, and system. Background Art

[0003] To protect device security, some services of electronic devices require user identity authentication before use. User identity authentication includes password authentication, face recognition, fingerprint recognition, or trusted device authentication. Among them, in the trusted device authentication method, the electronic device can determine the user's identity based on the authenticated trusted status of the trusted device, so that the user does not have to directly operate the electronic device, thereby improving user convenience. For example, a watch is a trusted device for a mobile phone. When the watch is in an authenticated trusted state, when the user wears the watch close to the mobile phone, the watch can directly authorize the mobile phone to unlock, and the user no longer needs to unlock the mobile phone through passwords or face recognition.

[0004] Summary of the Invention

[0005] Currently, devices such as watches can be used as trusted devices. However, devices such as wristbands and headphones cannot be used as trusted devices due to their inherently weak capabilities and poor security. Furthermore, if a trusted device is in an untrusted authentication state or the distance between the trusted device and the electronic device exceeds a preset range, the electronic device cannot authenticate the user through the trusted device.

[0006] To solve the above technical problems, this application provides an authentication method, electronic device, and system. The technical solution provided by this application adaptively completes user authentication by recording user identity authentication events sent locally or by an authentication device in a trusted holding device, thereby improving user convenience.

[0007] In order to achieve the above technical objectives, this application provides the following technical solutions:

[0008] In a first aspect, an authentication method is provided, which is applied to a second electronic device. The method includes: receiving an authentication request from a first electronic device, wherein a short-distance communication connection is established between the first electronic device and the second electronic device, and the authentication trust level supported by the second electronic device meets the first authentication trust level requirement, and the first authentication trust level requirement is the minimum authentication trust level of the first service to be user authenticated in the first electronic device. When in a first state, a first authentication result corresponding to the authentication request is matched in a first list, the first list includes at least one of a first event or a second event, the first event is a local user identity authentication pass event monitored by the second electronic device, and the second event is a user identity authentication pass event from the first electronic device. The first authentication result is sent to the first electronic device, and the first authentication result is used to generate a second authentication result indicating whether the second electronic device has passed the trusted authentication.

[0009] In this way, the second electronic device in the first state monitors and records the user identity authentication success event, and then flexibly performs user identity authentication based on the recorded content to meet the user's usage needs.

[0010] Furthermore, the second electronic device records the user identity authentication pass event and returns different authentication results based on the recorded authentication event set, thereby improving the authentication flexibility while meeting the security of the user identity authentication.

[0011] Furthermore, even if the second electronic device has poor performance, resulting in a low security capability level, it can still receive user identity authentication pass events corresponding to a high authentication trust level sent by other devices. This allows the second electronic device, with poor performance, to subsequently determine the authentication result based on the recorded user identity authentication pass events. This allows the second electronic device to complete user identity authentication for the first electronic device, which requires a relatively high authentication trust level, thereby enriching authentication scenarios.

[0012] According to the first aspect, the method further includes: in the second state, performing real-time authentication to generate a third authentication result, sending the third authentication result to the first electronic device, and using the third authentication result to generate a second authentication result indicating whether the second electronic device has passed the trusted authentication.

[0013] Thus, compared to the prior art, if the second electronic device is in the second state, the user cannot use the second electronic device to trigger the user identity authentication of the first electronic device, and can only return to the first electronic device to perform user identity authentication, which is cumbersome for the user. The authentication method provided in the embodiment of the present application can also perform real-time authentication on the second electronic device when the second electronic device is in the second state. The user only needs to operate the second electronic device at hand to complete the user identity authentication of the first electronic device, thereby improving user convenience.

[0014] According to the first aspect, or any implementation of the first aspect above, the method further includes: receiving a confirmation request from the first electronic device, where the confirmation request is a request sent by the first electronic device to the second electronic device when the first electronic device determines that the second authentication trustworthiness level does not meet the first authentication trustworthiness level requirements, and the second authentication trustworthiness level is the authentication trustworthiness level determined by the first electronic device after adjusting the first authentication trustworthiness level carried in the first authentication result. In response to receiving the user confirmation request, obtaining a confirmation result based on the user operation. Sending the confirmation result to the first electronic device, where the confirmation result is used to determine the second authentication result.

[0015] In this way, when the second electronic device is not within the ranging range or the ranging security level does not meet the requirements, the second electronic device can also be confirmed by the user, and the final authentication result is determined based on the authentication result already determined by the second electronic device and the user confirmation result. The user only needs to operate the second electronic device at hand to complete the user identity authentication of the first electronic device, thereby improving the convenience of user use.

[0016] According to the first aspect, or any implementation of the first aspect above, before receiving the authentication request from the first electronic device, the method further includes: obtaining a user identity authentication success event, where the user identity authentication success event is from at least one of the second electronic device or the first electronic device. While the device is in the carried state, recording the user identity authentication success event in a first list.

[0017] According to the first aspect, or any implementation of the first aspect above, before receiving an authentication request from the first electronic device, the method further includes: upon determining that the carried state has been released, clearing the user identity authentication success event recorded in the first list; and sending a first state expiration notification to the first electronic device, the first state expiration notification indicating that the second electronic device is in the second state.

[0018] In some examples, when it is determined that the carried state has been released, the second electronic device does not record the currently obtained user identity authentication pass event, and may perform the clearing operation of the valid authentication event list again to avoid the first list storing the user identity authentication pass events recorded in the previous carried state period, which affects the authentication security.

[0019] In this way, the second electronic device subsequently executes the user identity authentication process of the first electronic device based on the user identity authentication pass event recorded in a single carried state period, thereby improving authentication security.

[0020] In addition, when the second electronic device is in a carried state, based on the recorded user identity authentication pass events corresponding to different authentication credibility levels, the user identity authentication requirements of the first electronic device at different authentication credibility levels can be met.

[0021] According to the first aspect, or any implementation of the first aspect above, before receiving the authentication request from the first electronic device, the method further includes: receiving a trusted device addition request from the first electronic device; sending device information to the first electronic device, the device information being used to add the second electronic device as a trusted device of the first electronic device; and receiving a trusted device addition response from the first electronic device, thereby determining that the second electronic device has become a trusted device of the first electronic device.

[0022] In this way, the first electronic device adds the second electronic device as a trusted holding device, so that the first electronic device can subsequently complete user identity authentication through the second electronic device.

[0023] According to the first aspect, or any implementation method of the above first aspect, the device information includes one or more of the following items: identity authentication capability information supported by the second electronic device, the ranging method supported by the second electronic device, the security capability level certificate of the second electronic device, and the device identity certificate information.

[0024] According to the first aspect, or any implementation of the first aspect above, the second electronic device is in a carried state, and the method further includes: while in the second state, receiving a first user identity authentication success event from the first electronic device, where the first user identity authentication success event is a user identity authentication success event detected by the first electronic device. Switching the second state to the first state.

[0025] In this way, the second electronic device can flexibly switch between the first state and the second state by monitoring the carried state and the local user identity authentication pass event or the user identity authentication pass event sent by the first electronic device, thereby meeting the subsequent user identity authentication requirements of the first electronic device.

[0026] According to the first aspect, or any implementation method of the first aspect above, the authentication request carries business constraints, and the business constraints include one or more of the following: first authentication trust level requirements, user identity confirmation time requirements, user identity confirmation method requirements, user identity confirmation device requirements, usable user confirmation identification, and triggerable real-time authentication identification.

[0027] In a second aspect, an authentication method is provided, which is applied to a first electronic device. The method includes: in response to a user identity authentication request of a first service in the first electronic device, sending an authentication request to a second electronic device, wherein a short-range communication connection is established between the first electronic device and the second electronic device, and the authentication trust level supported by the second electronic device meets the first authentication trust level requirement, and the first authentication trust level requirement is the minimum authentication trust level required by the first service. Receive a first authentication result from the second electronic device, the first authentication result is an authentication result matched by the second electronic device in the first state in the first list, the first list includes at least one of the first event or the second event, the first event is a local user identity authentication pass event monitored by the second electronic device, and the second event is a user identity authentication pass event from the first electronic device. Determine a second authentication result based on the first authentication result, and the second authentication result indicates whether the second electronic device has passed the trusted authentication.

[0028] According to the second aspect, the method further includes: receiving a third authentication result from the second electronic device, the third authentication result being an authentication result generated by real-time authentication when the second electronic device is in the second state, and determining the second authentication result based on the third authentication result.

[0029] According to the second aspect, or any implementation of the second aspect above, determining a second authentication result based on the first authentication result includes: detecting that the first authentication result is a non-real-time authentication result, measuring the distance of the second electronic device, and generating a ranging result. If the ranging result meets a preset distance requirement, determining a first ranging security level of the second electronic device, and adjusting the first authentication trust level carried in the first authentication result based on the first ranging security level to determine a second authentication result, where the second authentication result includes the second authentication trust level.

[0030] According to the second aspect, or any implementation of the second aspect above, when the second authentication trust level meets the first authentication trust level requirement, the second authentication result indicates that the second electronic device has passed the trusted authentication.

[0031] In this way, different authentication trust levels supported by the second electronic device are evaluated according to the different security capability levels of the second electronic device to support business operations with different risks, thereby expanding the scope of the first electronic device supported by the second electronic device and ensuring the security of the use of the authentication results.

[0032] According to the second aspect, or any implementation of the second aspect above, the method further includes: if the second authentication trust level does not meet the first authentication trust level requirement, sending a user confirmation request to the second electronic device; receiving a confirmation result from the second electronic device, where the confirmation result is a result determined by the second electronic device based on the user operation; and determining a second authentication result in response to receiving the confirmation result.

[0033] According to the second aspect, or any implementation of the second aspect above, in response to receiving the confirmation result, determining the second authentication result includes: matching the second ranging security level corresponding to the manner in which the confirmation result is received, and determining the second authentication result based on the second ranging security level.

[0034] In this way, compared to the prior art, if the second electronic device is not within the ranging range, the user cannot use the second electronic device to authorize the user identity authentication of the first electronic device, and can only return to the first electronic device to perform user identity authentication, which is cumbersome for the user. The authentication method provided in the embodiment of the present application can also confirm the second electronic device with the user when the second electronic device is not within the ranging range. The final authentication result is determined based on the authentication result already determined by the second electronic device and the user confirmation result. The user only needs to operate the second electronic device at hand to complete the user identity authentication of the first electronic device, thereby improving the convenience of user use.

[0035] According to the second aspect, or any implementation of the second aspect above, based on the first ranging security level, adjusting the first authentication trust level carried in the first authentication result includes: obtaining first information, the first information including the trust relationship security level between the first electronic device and the second electronic device, the first state maintenance security level of the second electronic device, the carried state detection security level of the second electronic device, and the first ranging security level. Based on the first information, the security capability level of the second electronic device is determined. When the security capability level is high, the second authentication trust level is equal to the first authentication trust level. When the security capability level is medium, the second authentication trust level is less than the first authentication trust level. When the security capability level is low, the second authentication trust level is level 0 or level 1.

[0036] According to the second aspect, or any implementation of the second aspect above, before sending an authentication request to the second electronic device in response to a user identity authentication request for the first service in the first electronic device, the method further includes: sending a trusted device addition request to the second electronic device. Receiving device information from the second electronic device, the device information being information determined by the second electronic device in response to receiving the trusted device addition request. Adding the second electronic device as a trusted device based on the device information.

[0037] According to the second aspect, or any implementation method of the above second aspect, the device information includes one or more of the following items: identity authentication capability information supported by the second electronic device, the ranging method supported by the second electronic device, the security capability level certificate of the second electronic device, and the device identity certificate information.

[0038] According to the second aspect, or any implementation method of the above second aspect, the authentication request carries business constraints, and the business constraints include one or more of the following: first authentication trust level requirements, user identity confirmation time requirements, user identity confirmation method requirements, user identity confirmation device requirements, usable user confirmation identification, and triggerable real-time authentication identification.

[0039] According to the second aspect, or any implementation of the second aspect above, the method further includes: detecting an event that the first user identity authentication is successful, and sending the event that the first user identity authentication is successful to the second electronic device.

[0040] The technical effects corresponding to the second aspect and any implementation method of the second aspect can be found in the technical effects corresponding to the above-mentioned first aspect and any implementation method of the first aspect, and will not be repeated here.

[0041] According to a third aspect, an electronic device is provided. The electronic device includes: a processor and a memory, the memory being coupled to the processor, the memory being used to store computer program code, the computer program code including computer instructions, and when the processor reads the computer instructions from the memory, the electronic device executes: receiving an authentication request from a first electronic device, wherein a short-range communication connection is established between the first electronic device and the second electronic device, the authentication trust level supported by the second electronic device meets a first authentication trust level requirement, and the first authentication trust level requirement is the minimum authentication trust level of a first service to be user authenticated in the first electronic device. When in a first state, matching a first authentication result corresponding to the authentication request in a first list, the first list including at least one of a first event or a second event, the first event being a local user authentication pass event monitored by the second electronic device, and the second event being a user authentication pass event from the first electronic device. Sending the first authentication result to the first electronic device, the first authentication result being used to generate a second authentication result indicating whether the second electronic device has passed the trusted authentication.

[0042] According to a third aspect, when the processor reads the computer instructions from the memory, the electronic device is further caused to perform: while in the second state, performing real-time authentication to generate a third authentication result. The third authentication result is sent to the first electronic device, and the third authentication result is used to generate a second authentication result indicating whether the second electronic device has passed the trusted authentication.

[0043] According to the third aspect, or any implementation of the third aspect above, when the processor reads computer instructions from the memory, the electronic device is further caused to execute: receiving a confirmation request from the first electronic device, where the confirmation request is a request sent by the first electronic device to the second electronic device when the first electronic device determines that the second authentication trustworthiness level does not meet the first authentication trustworthiness level requirements, and the second authentication trustworthiness level is the authentication trustworthiness level determined by the first electronic device after adjusting the first authentication trustworthiness level carried in the first authentication result. In response to receiving the user confirmation request, obtaining a confirmation result based on the user operation. Sending the confirmation result to the first electronic device, where the confirmation result is used to determine the second authentication result.

[0044] According to the third aspect, or any implementation of the third aspect, when the processor reads the computer instructions from the memory, the processor further causes the electronic device to: obtain a user identity authentication success event, where the user identity authentication success event originates from at least one of the second electronic device or the first electronic device; and, while the device is in the carried state, record the user identity authentication success event in a first list.

[0045] According to the third aspect, or any implementation of the third aspect, when the processor reads the computer instructions from the memory, the processor further causes the electronic device to: upon determining that the carried state is released, clear the user identity authentication success event recorded in the first list; and send a first state expiration notification to the first electronic device, the first state expiration notification indicating that the second electronic device is in the second state.

[0046] According to the third aspect, or any implementation of the third aspect, when the processor reads the computer instructions from the memory, the electronic device is further caused to execute the following steps: receiving a trusted device addition request from a first electronic device; sending device information to the first electronic device, the device information being used to add the second electronic device as a trusted device of the first electronic device; and receiving a trusted device addition response from the first electronic device, thereby determining that the second electronic device has become a trusted device of the first electronic device.

[0047] According to the third aspect, or any implementation method of the above third aspect, the device information includes one or more of the following items: identity authentication capability information supported by the second electronic device, the ranging method supported by the second electronic device, the security capability level certificate of the second electronic device, and the device identity certificate information.

[0048] According to the third aspect, or any implementation of the third aspect above, the second electronic device is in a carried state, and when the processor reads computer instructions from the memory, the electronic device is further caused to execute: while in the second state, receive a first user identity authentication success event from the first electronic device, where the first user identity authentication success event is a user identity authentication success event detected by the first electronic device; and switch the second state to the first state.

[0049] According to the third aspect, or any implementation method of the above third aspect, the authentication request carries business constraints, and the business constraints include one or more of the following: first authentication trust level requirements, user identity confirmation time requirements, user identity confirmation method requirements, user identity confirmation device requirements, usable user confirmation identification, and triggerable real-time authentication identification.

[0050] The technical effects corresponding to the third aspect and any implementation method of the third aspect can be found in the technical effects corresponding to the above-mentioned first aspect and any implementation method of the first aspect, and will not be repeated here.

[0051] In a fourth aspect, an electronic device is provided. The electronic device includes: a processor and a memory, the memory being coupled to the processor. The memory is configured to store computer program code, the computer program code including computer instructions. When the processor reads the computer instructions from the memory, the electronic device is configured to execute the following: in response to a user identity authentication request for a first service in a first electronic device, send an authentication request to a second electronic device, wherein a short-range communication connection is established between the first electronic device and the second electronic device, and the authentication trust level supported by the second electronic device meets a first authentication trust level requirement, which is the minimum authentication trust level required by the first service. A first authentication result is received from the second electronic device, the first authentication result being an authentication result matched in a first list for the second electronic device in a first state, the first list including at least one of a first event and a second event, the first event being a local user identity authentication success event monitored by the second electronic device, and the second event being a user identity authentication success event from the first electronic device. A second authentication result is determined based on the first authentication result, the second authentication result indicating whether the second electronic device has passed the trusted authentication.

[0052] According to a fourth aspect, when the processor reads the computer instructions from the memory, the electronic device further causes the electronic device to: receive a third authentication result from the second electronic device, the third authentication result being an authentication result generated by real-time authentication of the second electronic device while the second electronic device is in the second state; and determine the second authentication result based on the third authentication result.

[0053] According to the fourth aspect, or any implementation of the fourth aspect above, determining a second authentication result based on the first authentication result includes: detecting that the first authentication result is a non-real-time authentication result, measuring the distance of the second electronic device, and generating a ranging result. If the ranging result meets a preset distance requirement, determining a first ranging security level of the second electronic device, and adjusting the first authentication trust level carried in the first authentication result based on the first ranging security level to determine a second authentication result, where the second authentication result includes the second authentication trust level.

[0054] According to the fourth aspect, or any implementation of the fourth aspect above, when the second authentication trust level meets the first authentication trust level requirement, the second authentication result indicates that the second electronic device has passed the trusted authentication.

[0055] According to the fourth aspect, or any implementation of the fourth aspect, when the processor reads the computer instructions from the memory, the processor further causes the electronic device to execute: if the second authentication trust level does not meet the first authentication trust level requirement, send a user confirmation request to the second electronic device; receive a confirmation result from the second electronic device, where the confirmation result is a result determined by the second electronic device based on the user operation; and determine the second authentication result in response to receiving the confirmation result.

[0056] According to the fourth aspect, or any implementation of the fourth aspect above, in response to receiving the confirmation result, determining the second authentication result includes: matching the second ranging security level corresponding to the manner in which the confirmation result is received. Determining the second authentication result based on the second ranging security level.

[0057] According to the fourth aspect, or any implementation of the fourth aspect above, based on the first ranging security level, adjusting the first authentication trust level carried in the first authentication result includes: obtaining first information, the first information including the trust relationship security level between the first electronic device and the second electronic device, the first state maintenance security level of the second electronic device, the carried state detection security level of the second electronic device, and the first ranging security level. Based on the first information, the security capability level of the second electronic device is determined. When the security capability level is high, the second authentication trust level is equal to the first authentication trust level. When the security capability level is medium, the second authentication trust level is less than the first authentication trust level. When the security capability level is low, the second authentication trust level is level 0 or level 1.

[0058] According to the fourth aspect, or any implementation of the fourth aspect, when the processor reads the computer instructions from the memory, the processor further causes the electronic device to execute: sending a trusted device addition request to a second electronic device; receiving device information from the second electronic device, where the device information is information determined by the second electronic device in response to receiving the trusted device addition request; and adding the second electronic device as a trusted device based on the device information.

[0059] According to the fourth aspect, or any implementation method of the above fourth aspect, the device information includes one or more of the following items: identity authentication capability information supported by the second electronic device, the ranging method supported by the second electronic device, the security capability level certificate of the second electronic device, and the device identity certificate information.

[0060] According to the fourth aspect, or any implementation method of the above fourth aspect, the authentication request carries business constraints, and the business constraints include one or more of the following: first authentication trust level requirements, user identity confirmation time requirements, user identity confirmation method requirements, user identity confirmation device requirements, usable user confirmation identification, and triggerable real-time authentication identification.

[0061] According to the fourth aspect, or any implementation of the fourth aspect above, the method further includes: detecting a first user identity authentication success event, and sending the first user identity authentication success event to the second electronic device.

[0062] The technical effects corresponding to the fourth aspect and any implementation method of the fourth aspect can be found in the technical effects corresponding to the above-mentioned second aspect and any implementation method of the second aspect, and will not be repeated here.

[0063] In a fifth aspect, an authentication system is provided, which includes a first electronic device and a second electronic device, and a short-range communication connection is established between the first electronic device and the second electronic device. The first electronic device is configured to: respond to a user identity authentication request of a first service in the first electronic device, send an authentication request to the second electronic device, wherein the authentication trust level supported by the second electronic device meets the first authentication trust level requirement, and the first authentication trust level requirement is the minimum authentication trust level of the first service. Receive a first authentication result from the second electronic device. Based on the first authentication result, determine a second authentication result, and the second authentication result indicates whether the second electronic device has passed the trusted authentication. The second electronic device is configured to: when the second electronic device is in a first state, match the first authentication result corresponding to the authentication request in a first list, the first list including at least one of a first event or a second event, the first event being a local user identity authentication pass event monitored by the second electronic device, and the second event being a user identity authentication pass event from the first electronic device. Send the first authentication result to the first electronic device.

[0064] According to a fifth aspect, the second electronic device is further configured to: while in the second state, perform real-time authentication to generate a third authentication result; transmit the third authentication result to the first electronic device; and receive the third authentication result from the second electronic device. Upon detecting that the third authentication result is a real-time authentication result, determine the second authentication result based on the third authentication result.

[0065] According to the fifth aspect, or any implementation of the fifth aspect above, the first electronic device is further configured to: upon detecting that the first authentication result is a non-real-time authentication result, measure the distance of the second electronic device, generate a distance measurement result, and determine a first distance measurement security level for the second electronic device. If the distance measurement result meets a preset distance requirement, based on the first distance measurement security level, adjust the first authentication trust level carried in the first authentication result to generate a second authentication result, the second authentication result including a second authentication trust level. If the second authentication trust level meets the first authentication trust level requirement, the second authentication result indicates that the second electronic device has passed the trusted authentication.

[0066] According to the fifth aspect, or any implementation of the fifth aspect above, the first electronic device is further configured to: if the second authentication trust level does not meet the first authentication trust level requirements, send a user confirmation request to the second electronic device. The second electronic device is further configured to: receive the user confirmation request from the first electronic device. In response to receiving the user confirmation request, obtain a confirmation result based on the user operation. Send the confirmation result to the first electronic device. The first electronic device is further configured to: receive the confirmation result from the second electronic device. In response to receiving the confirmation result, determine the second authentication result.

[0067] According to the fifth aspect, or any implementation of the fifth aspect, the second electronic device is further configured to: obtain a user identity authentication success event, and when in the carried state, record the user identity authentication success event in a first list, wherein the user identity authentication success event comes from at least one of the second electronic device or the first electronic device. When it is determined that the carried state is released, the user identity authentication success event recorded in the first list is cleared.

[0068] The technical effects corresponding to the fifth aspect and any implementation method of the fifth aspect can be found in the technical effects corresponding to the above-mentioned first aspect and any implementation method of the first aspect, and will not be repeated here.

[0069] In a sixth aspect, an electronic device is provided, the electronic device having the functionality to implement the authentication method described in the first aspect and any possible implementation thereof; or the electronic device having the functionality to implement the authentication method described in the second aspect and any possible implementation thereof. The functionality may be implemented in hardware, or may be implemented in hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned functionality.

[0070] The technical effects corresponding to the sixth aspect and any implementation method of the sixth aspect can be found in the technical effects corresponding to the above-mentioned first aspect and any implementation method of the first aspect, and will not be repeated here.

[0071] In a seventh aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program (also referred to as instructions or code), which, when executed by an electronic device, causes the electronic device to perform the method of the first aspect or any one of the embodiments of the first aspect; or causes the electronic device to perform the method of the second aspect or any one of the embodiments of the second aspect.

[0072] The technical effects corresponding to the seventh aspect and any implementation method of the seventh aspect can be found in the technical effects corresponding to the above-mentioned first aspect and any implementation method of the first aspect, and will not be repeated here.

[0073] In an eighth aspect, a computer program product is provided. When the computer program product is run on an electronic device, the electronic device executes the method of the first aspect or any one of the embodiments of the first aspect; or, the electronic device executes the method of the second aspect or any one of the embodiments of the second aspect.

[0074] The technical effects corresponding to the eighth aspect and any one of the implementation methods of the eighth aspect can be found in the technical effects corresponding to the above-mentioned first aspect and any one of the implementation methods of the first aspect, and will not be repeated here.

[0075] In a ninth aspect, a circuit system is provided, the circuit system including a processing circuit, the processing circuit being configured to execute the method of the first aspect or any one of the embodiments of the first aspect; or, the processing circuit being configured to execute the method of the second aspect or any one of the embodiments of the second aspect.

[0076] The technical effects corresponding to the ninth aspect and any implementation method of the ninth aspect can be found in the technical effects corresponding to the above-mentioned first aspect and any implementation method of the first aspect, and will not be repeated here.

[0077] In the tenth aspect, a chip system is provided, comprising at least one processor and at least one interface circuit, wherein the at least one interface circuit is used to perform transceiver functions and send instructions to the at least one processor. When the at least one processor executes the instructions, the at least one processor executes the method of the first aspect or any one of the embodiments of the first aspect; or, the at least one processor executes the method of the second aspect or any one of the embodiments of the second aspect.

[0078] The technical effects corresponding to the tenth aspect and any one of the implementation methods of the tenth aspect can be found in the technical effects corresponding to the above-mentioned first aspect and any one of the implementation methods of the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0079] FIG1 is a flow chart of an authentication method provided by this application;

[0080] FIG2 is a schematic diagram of a communication system for applying the authentication method provided in this application;

[0081] FIG3 is a schematic diagram of the hardware structure of a first electronic device provided in this application;

[0082] FIG4 is a schematic diagram of a software structure block diagram of a first electronic device provided by the present application;

[0083] FIG5 is a flow chart of an authentication method for adding a trusted device provided by the present application;

[0084] FIG6 is a schematic diagram of the trusted device adding interface provided by this application;

[0085] FIG7 is a schematic diagram of a scenario in which different authentication methods provided by this application trigger different authentication trust levels for the same trusted holding device;

[0086] FIG8 is a schematic diagram of a scenario in which the authentication device provided by the present application can add multiple trusted holding devices that support different authentication trust levels;

[0087] FIG9 is a flowchart of an authentication method for a trusted holding device maintenance identity authentication pass event provided by the present application;

[0088] FIG10 is a schematic diagram of a scenario in which a trusted holding device restores an authenticated trusted state provided by this application;

[0089] FIG11 is a schematic diagram of a scenario of a change in authentication trust level supported by a trusted holding device provided in this application;

[0090] FIG12 is a flow chart of an authentication method for a trusted device authentication phase provided by this application;

[0091] FIG13 is a schematic diagram of a scenario of operations that can be performed by an authentication device provided by the present application based on the authentication trust level supported by a trusted holding device;

[0092] FIG14 is a schematic diagram of a scenario for triggering real-time user authentication provided by this application;

[0093] FIG15 is a schematic diagram of a scenario of user-unaware authentication provided by this application;

[0094] FIG16 is a schematic diagram of a scenario for triggering user confirmation provided by this application;

[0095] FIG17 is a second schematic diagram of a scenario for triggering user confirmation provided by this application;

[0096] FIG18 is a flow chart of the authentication method provided by this application;

[0097] FIG19 is a schematic structural diagram of a first electronic device provided by the present application;

[0098] FIG20 is a schematic structural diagram of the second electronic device provided in this application. DETAILED DESCRIPTION

[0099] The technical solutions in the embodiments of the present application are described below in conjunction with the drawings in the embodiments of the present application. Among them, in the description of the embodiments of the present application, the terms used in the following embodiments are only for the purpose of describing specific embodiments, and are not intended to be used as limitations on the present application. As used in the specification and appended claims of the present application, the singular expressions "one", "a kind of", "said", "above", "the" and "this" are intended to include expressions such as "one or more", unless there is a clear indication to the contrary in the context. It should also be understood that in the following embodiments of the present application, "at least one", "one or more" refer to one or more (including two).

[0100] References to "one embodiment" or "some embodiments" etc. described in this specification mean that the specific features, structures or characteristics described in conjunction with the embodiment are included in one or more embodiments of the present application. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. appearing in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in another way. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in another way. The term "connected" includes direct and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated.

[0101] In the embodiments of this application, words such as "exemplarily" or "for example" are used to represent examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplarily" or "for example" is intended to present the relevant concepts in a concrete manner.

[0102] In some embodiments, with the advancement of terminal technology, some electronic devices support user identity authentication based on trusted devices. For example, a watch can be a trusted device for a mobile phone. Within a period of time after the user manually unlocks the watch, if the user wears the watch close to the phone, the watch's authenticated trusted status can directly authorize the phone to unlock. The user no longer needs to use password authentication or facial recognition to unlock the phone, improving user convenience.

[0103] Optionally, a device requiring user identity authentication may be described as an authentication device, and a device performing user identity authentication on the authentication device may be described as a trusted device. It should be understood that an authentication device may also be described as a device to be authenticated, a device requesting user identity authentication, and the trusted device may also be described as a trusted device. This is not limited in the present embodiment and will not be further described below.

[0104] For example, as shown in Figure 1, before performing user identity authentication based on a trusted device, the authentication device must first perform the trusted device addition phase. During this phase, the authentication device establishes a trusted relationship with the trusted device, enabling the trusted device to serve as a valid credential proving the identity of the authentication device owner (i.e., step 1). For example, the authentication device must log in to the same account as the trusted device to establish a trusted connection, and the trusted device must be password-protected. The authentication device then confirms that the trusted device has been added.

[0105] After the trusted holding device is added to the authentication device, the trusted holding device authentication phase can be executed. Among them, since the trusted holding device is generally an accessory that is easy to carry, such as a watch, bracelet, etc., it is easy to be lost. In order to avoid other users passing the user identity authentication of the authentication device through the trusted holding device after it is lost, the trusted holding device needs to confirm the user's identity. For example, when the user holds or wears a trusted holding object, the trusted holding device is unlocked to determine that the user holding or wearing the trusted holding device is the owner of the device (i.e., step 2). Afterwards, after the trusted holding device confirms the user's identity, the trusted holding device is in an authentication trusted state. When the trusted holding device cannot determine the user's identity, the trusted holding device is in an authentication untrusted state. When the trusted holding device is in an authentication untrusted state, the user identity confirmation of the authentication device cannot be completed.

[0106] As can be seen, since trusted devices only support two states: authenticated trusted and authenticated untrusted, the authenticated trusted state is relatively simple and can only support specific business scenarios. For example, after entering the authenticated trusted state, a trusted device can support the unlocking service of the authenticated device; after entering the unauthenticated untrusted state, this unlocking service cannot be supported.

[0107] In addition, some devices have low performance and are not configured with password authentication. Therefore, these devices cannot be used as trusted devices, affecting user usage. For example, wristbands and headphones with low performance cannot be used as trusted devices.

[0108] Optionally, the trusted holding device monitors its own authentication trust status and notifies the authentication device when the authentication trust status changes (i.e., step 3). For example, after the trusted holding device determines that the user has released the holding or wearing status, it enters the authentication untrusted state and sends a notification to the authentication device to indicate the current authentication untrusted state of the trusted holding device.

[0109] During the user authentication phase, the authentication device queries the authentication trust status of the trusted holding device to evaluate the user authentication result (i.e., step 4). For example, if the authentication device queries that the trusted holding device is in the authentication trust status, the user authentication is passed and the corresponding business can be executed. If the unlocking function triggers the user authentication process of the authentication device, the authentication device can be unlocked after the user authentication is passed. For another example, if the authentication device determines that the trusted holding device is in the authentication untrusted state and cannot execute the corresponding business, the user can only perform user authentication operations on the authentication device, such as entering a password on the authentication device.

[0110] Optionally, after determining that the trusted device is in a trusted state, the authentication device may also determine whether the distance between the trusted device and the authentication device is within a preset range to mitigate uncontrollable risks. For example, in a user identity authentication method based on a trusted device, the distance between the trusted device and the authentication device may be within 2 meters.

[0111] It can be seen that the user needs to hold or wear and unlock the trusted holding device before the trusted holding device can enter the authenticated trusted state. Once the user releases the holding or wearing state of the trusted holding device, the trusted holding device will enter the authenticated untrusted state. The user needs to hold or wear and unlock the trusted holding device again before the trusted holding device can enter the authenticated trusted state again, which is cumbersome for the user to operate.

[0112] Furthermore, if the trusted device is in an untrusted state, or if it is trusted but outside the preset range, the authentication device cannot authenticate the user. Therefore, the user can only use the corresponding functions of the authentication device by operating the authentication device on the authentication device, which affects user usability.

[0113] In addition, some devices have low performance and are not equipped with high-precision ranging, wearing detection and other capabilities, and cannot be used as trusted holding devices.

[0114] Therefore, an authentication method provided by an embodiment of the present application adaptively completes user authentication through a user authentication pass event recorded locally in a trusted holding device or sent by an authentication device, thereby improving user convenience.

[0115] For example, Figure 2 is a schematic diagram of a communication system to which the authentication method provided in an embodiment of the present application is applied. As shown in Figure 2 , the communication system includes a first electronic device 100 and a second electronic device 200 .

[0116] Optionally, the first electronic device 100 is, for example, an authentication device that requires user identity authentication. The first electronic device 100 can be, for example, a mobile phone, a tablet computer, a laptop computer, a smart screen, a wearable device, a vehicle-mounted terminal, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), an artificial intelligence (AI) device, or other terminal device. The operating system installed on the first electronic device 100 includes but is not limited to This application does not limit the specific type of the first electronic device 100 or the installed operating system.

[0117] Optionally, the second electronic device 200 is, for example, a trusted device that performs user identity authentication on the first electronic device 100. The second electronic device 200 can be, for example, a wearable device (such as a watch, a bracelet, a headset, etc.), a mobile phone, a tablet computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), an artificial intelligence (AI) device, or other terminal device. The operating system installed on the second electronic device 200 includes but is not limited to This application does not limit the specific type of the second electronic device 200 or the installed operating system.

[0118] In some embodiments, a wireless communication connection is established between the first electronic device 100 and the second electronic device 200. The wireless communication technology used to establish the wireless communication connection includes, but is not limited to, at least one of the following: Bluetooth (BT) (e.g., traditional Bluetooth or Bluetooth low energy (BLE)), wireless local area networks (WLAN) (e.g., wireless fidelity (Wi-Fi) networks), near field communication (NFC), Zigbee, frequency modulation (FM), infrared (IR), etc.

[0119] Optionally, the first electronic device 100 and the second electronic device 200 may also establish a communication connection through a third-party device in the local area network, such as a router, a gateway, a smart device controller, a server, etc.

[0120] Optionally, the first electronic device 100 and the second electronic device 200 in the embodiment of the present application may be implemented by different devices, and the different devices may have the same, similar or somewhat different hardware structures, such as the hardware structure shown in FIG3 .

[0121] For example, taking the first electronic device 100 having the hardware structure shown in FIG. 3 as an example, the hardware structure shown in FIG. 3 is described.

[0122] As shown in Figure 3, the first 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, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0123] It should be understood that the structures illustrated in the embodiments of the present application do not constitute a specific limitation on the first electronic device 100. In other embodiments of the present application, the first electronic device 100 may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0124] The processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, or a neural-network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.

[0125] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0126] Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the same instruction or data again, it can directly retrieve it from the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

[0127] In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, or a universal serial bus (USB) interface.

[0128] The I2C interface is a bidirectional synchronous serial bus that includes a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple I2C bus lines. The processor 110 may be coupled to the touch sensor, charger, flash, camera 193, etc. via different I2C bus interfaces. For example, the processor 110 may be coupled to the touch sensor via the I2C interface, allowing the processor 110 to communicate with the touch sensor via the I2C bus interface, thereby implementing the touch function of the first electronic device 100.

[0129] The MIPI interface can be used to connect the processor 110 to peripheral devices such as the display screen 194 and the camera 193. MIPI interfaces include the camera serial interface (CSI) and the display serial interface (DSI). In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to implement the camera function of the first electronic device 100. The processor 110 and the display screen 194 communicate via the DSI interface to implement the display function of the first electronic device 100.

[0130] The USB interface 130 is an interface that complies with USB standards and specifications, and may be a Mini USB interface, a Micro USB interface, a USB Type-C interface, or the like. The USB interface 130 can be used to connect a charger to charge the first electronic device 100, or to transfer data between the first electronic device 100 and peripheral devices. It can also be used to connect headphones to play audio. This interface can also be used to connect to other first electronic devices, such as AR devices.

[0131] It is understood that the interface connection relationship between the modules illustrated in the embodiments of the present application is merely an illustrative description and does not constitute a structural limitation on the first electronic device 100. In other embodiments of the present application, the first electronic device 100 may also adopt a different interface connection method from the above embodiments, or a combination of multiple interface connection methods.

[0132] The charging management module 140 is configured to receive charging input from a charger. The charger can be either a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 can receive charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 can receive wireless charging input via the wireless charging coil of the first electronic device 100. While charging the battery 142, the charging management module 140 can also provide power to the first electronic device via the power management module 141.

[0133] 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 or the charging management module 140 and provides power to the processor 110, the internal memory 121, the display 194, the camera 193, and the wireless communication module 160. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage, impedance). In some other embodiments, the power management module 141 can also be set in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 can also be set in the same device.

[0134] The wireless communication function of the first 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.

[0135] Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in first electronic device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In other embodiments, the antennas can be used in conjunction with a tuning switch.

[0136] The mobile communication module 150 can provide solutions for wireless communications including 2G / 3G / 4G / 5G applied to the first electronic device 100. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves from the antenna 1, and filter, amplify, and process the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the same device as at least some of the modules of the processor 110.

[0137] The modem processor may include a modulator and a demodulator. The modulator is used to modulate the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After being processed by the baseband processor, the low-frequency baseband signal is passed to the application processor. The application processor outputs the sound signal through the audio device or displays an image or video through the display screen 194. In some embodiments, the modem processor may be an independent device. In other embodiments, the modem processor may be independent of the processor 110 and be provided in the same device as the mobile communication module 150 or other functional modules.

[0138] The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., applied on the first electronic device 100. The wireless communication module 160 can 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 for radiation through the antenna 2.

[0139] In some embodiments, the antenna 1 of the first 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 first electronic device 100 can communicate with the network and other devices through wireless communication technology. The wireless communication technology may include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, or IR technology. GNSS may include global positioning system (GPS), global navigation satellite system (GLONASS), Beidou navigation satellite system (BDS), quasi-zenith satellite system (QZSS) or satellite based augmentation system (SBAS).

[0140] The first electronic device 100 implements display functionality through a GPU, display screen 194, and an application processor. The GPU is a microprocessor for image processing that connects the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or modify display information.

[0141] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. The display panel can be manufactured using a liquid crystal display (LCD), for example, an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), Mini-LED, Micro-LED, Micro-OLED, quantum dot light-emitting diodes (QLED), etc. In some embodiments, the first electronic device 100 may include one or N display screens 194, where N is a positive integer greater than 1.

[0142] The camera 193 is used to capture still images or videos. The object generates an optical image through the lens and projects it 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 light signal into an electrical signal, and then passes the electrical signal to the ISP for conversion into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV or other format. In some embodiments, the first electronic device 100 may include 1 or N cameras 193, where N is a positive integer greater than 1.

[0143] 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 first electronic device 100. The external memory card communicates with the processor 110 via the external memory interface 120 to implement data storage functions. For example, files such as music and videos can be stored in the external memory card.

[0144] The internal memory 121 can be used to store computer executable program codes, and the executable program codes include instructions. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the first electronic device 100 (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various functional applications and data processing of the first electronic device 100 by running instructions stored in the internal memory 121, or instructions stored in a memory provided in the processor.

[0145] 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 audio module 170 can also be used to encode and decode audio signals. In some embodiments, the audio module 170 can be set in the processor 110, or some functional modules of the audio module 170 can be set in the processor 110. The first electronic device 100 can use the audio module 170, such as music playback and recording. The audio module 170 may include a speaker, a receiver, a microphone, a headphone jack, and an application processor to implement audio functions.

[0146] The sensor module 180 may include a pressure sensor, a gyro sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.

[0147] The buttons 190 include a power button, a volume button, etc. The buttons 190 may be mechanical buttons or touch buttons. The first electronic device 100 may receive key inputs and generate key signal inputs related to user settings and function control of the first electronic device 100.

[0148] Motor 191 can generate vibration prompts. Motor 191 can be used for incoming call vibration prompts and can also be used for touch vibration feedback.

[0149] The indicator 192 can be an indicator light, which can indicate the charging status, power changes, messages, missed calls, notifications, etc.

[0150] The SIM card interface 195 is used to connect a SIM card. The first electronic device 100 may support one or N SIM card interfaces, where N is a positive integer greater than one.

[0151] The software system of the first electronic device 100 or the second electronic device 200 can adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a microservice architecture, or a cloud architecture. The embodiment of the present application takes the Android system with a layered architecture as an example to illustrate the software structure of the first electronic device 100 or the second electronic device 200.

[0152] FIG4 is a block diagram of the software structure of the first electronic device 100 according to an embodiment of the present application. The second electronic device 200 may have the same, similar or slightly different software structure.

[0153] A layered architecture divides software into several layers, each with distinct roles and responsibilities. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0154] The application layer can include a series of application packages.

[0155] As shown in FIG4 , the application package may include lock screen, calendar, contacts, memo, clipboard, gallery, map, camera, video and other applications.

[0156] The application framework layer provides an application programming interface (API) and programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0157] As shown in FIG4 , the application framework layer may include a session management module, a device trust relationship management module, an authentication management module, a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, and the like.

[0158] The session management module is used to establish a communication channel with the peer device. In some examples, the first electronic device 100 and the second electronic device 200 establish a trusted communication channel through the session management module and perform key negotiation based on the communication channel to ensure the security of subsequent sessions.

[0159] The device trust relationship management module is used to maintain the device trust relationship between the first electronic device 100 and the second electronic device 200, and store device information of the peer device, such as the trusted device security capability level. The trusted device security capability level is described in detail below and will not be repeated here.

[0160] Optionally, an electronic device (such as the first electronic device 100 or the second electronic device 200) can serve as an authentication device or as a trusted holding device. For example, a mobile phone can be unlocked by a watch as an authentication device, and the mobile phone can also be used as a trusted holding device to unlock a laptop.

[0161] Optionally, when the electronic device (such as the first electronic device 100 or the second electronic device 200) serves as an authentication device, it stores information of one or more trusted holding devices through the device trusted relationship management module.

[0162] Optionally, when an electronic device (such as the first electronic device 100 or the second electronic device 200) acts as a trusted device, it stores information about one or more authentication devices through the device trusted relationship management module. Furthermore, during the trusted device addition phase, the electronic device sends information such as its authentication trust level to the authentication device.

[0163] The authentication management module is used to manage the authentication relationship and authentication trust status between the first electronic device 100 and the second electronic device 200 .

[0164] Optionally, after the trusted device is added, the trusted device (eg, the second electronic device 200 ) monitors a local user identity authentication success event and records the user identity authentication success event through the authentication management module.

[0165] Optionally, after the trusted device is added, the authentication device (e.g., the first electronic device 100) detects a user identity authentication success event on the local end and sends the user identity authentication success event to the trusted device (e.g., the second electronic device 200). Accordingly, the trusted device receives the user identity authentication success event sent by the authentication device and records the user identity authentication success event through the authentication management module.

[0166] Optionally, during the trusted holding device authentication phase, after the trusted holding device (e.g., the second electronic device 200) receives the authentication request sent by the authentication device (e.g., the first electronic device 100), it matches the appropriate authentication trust level based on the user identity authentication pass event recorded in the authentication management module to send the authentication result to the authentication device. For example, the authentication management module stores a user identity authentication pass event in which the user unlocks the trusted holding device with a password, and the authentication trust level corresponding to the user identity authentication pass event is ATL3. Then, when the subsequent trusted holding device responds to the authentication request, the authentication trust level matched may be ATL3. The specific matching method is described in detail below and will not be repeated here.

[0167] Optionally, during the trusted holding device authentication stage, after the authentication device (for example, the first electronic device 100) receives the authentication result sent by the trusted holding device (for example, the second electronic device 200), it can also evaluate the authentication result through the authentication management module, such as determining whether the authentication result is passed, whether the user needs to confirm again, whether ranging is required, etc.

[0168] In some examples, if the electronic device is a trusted device, it may also include a security capability level management module. The security capability level management module is used to assess its own security capability level, such as high, medium, or low. The trusted device may also send this security capability level to an authentication device, which then verifies its security capabilities.

[0169] Optionally, the security capability level management module assesses the security capability level of the trusted holding device based on, for example, one or more of the following: the security level of the trusted relationship between the authentication device and the trusted holding device, the security level of trusted state maintenance, the security level of holding state detection, and the security level of ranging. The specific assessment method is described in detail below and is not further elaborated here.

[0170] Optionally, after receiving the authentication result from the trusted device, the authentication device may determine whether to modify the authentication trust level carried in the authentication result based on the security capability level of the trusted device. For example, if the authentication trust level carried in the authentication result is ATL3, but the authentication device determines that the security capability level of the trusted device is medium, the authentication trust level of the final user identity authentication performed by the trusted device may be determined to be ATL2, i.e., downgraded, to prevent the authentication result confirmed by the trusted device with a low security capability level from affecting the reliability of the user identity authentication performed by the authentication device.

[0171] The window manager is used to manage window programs. The window manager can obtain the display size, determine whether there is a status bar, lock the screen, take screenshots, etc.

[0172] Content providers are used to store and retrieve data and make it accessible to applications. Data can include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0173] The view system includes visual controls, such as those for displaying text and images. The view system is used to build applications. A display interface can consist of one or more views. For example, a display interface containing a text notification icon might include a view for displaying text and a view for displaying images.

[0174] The phone manager is used to provide communication functions of the first electronic device 100, such as management of call status (including answering, hanging up, etc.).

[0175] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0176] The notification manager allows applications to display notification information in the status bar. It can be used to convey informational messages and can disappear automatically after a short stay without user interaction. The notification manager can also be a notification that appears in the top status bar of the system in the form of an icon or scrolling text bar.

[0177] The Android runtime includes the core library and the virtual machine. The Android runtime is responsible for scheduling and management of the Android system.

[0178] The core library consists of two parts: one is the function that needs to be called by the Java language, and the other is the Android core library.

[0179] The application layer and application framework layer run in a virtual machine. The virtual machine executes Java files in the application layer and application framework layer as binary files. The virtual machine manages object lifecycles, stack management, thread management, security and exception management, and garbage collection.

[0180] The system library can include multiple functional modules, such as surface manager, media library, 3D graphics processing library (such as OpenGL ES), 2D graphics engine (such as SGL), etc.

[0181] The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications.

[0182] The media library supports playback and recording of a variety of common audio and video formats, as well as static image files. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[0183] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0184] A 2D graphics engine is a drawing engine for 2D drawings.

[0185] The kernel layer is the layer between hardware and software. It includes at least a display driver, a camera driver, an audio driver, a sensor driver, and a connection driver. Optionally, a connection driver is used to trigger a communication connection with a peer device.

[0186] In some embodiments, if the authentication device needs to perform user identity authentication through a trusted holding device, the electronic device needs to be added as a trusted holding device first. The following describes the stage of adding a trusted holding device.

[0187] For example, Figure 5 is a flowchart of an authentication method for adding a trusted device provided in an embodiment of the present application. It should be noted that the method is not limited to the specific sequence shown in Figure 5 and below. It should be understood that in other embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0188] S501: A first electronic device establishes a communication connection with a second electronic device.

[0189] The first electronic device is an electronic device to which a trusted device is to be added, and the second electronic device is an electronic device to become a trusted device of the first electronic device.

[0190] In some embodiments, a mutual trust relationship can be established between the first electronic device and the second electronic device through various methods such as Bluetooth pairing, Wi-Fi pairing, code scanning binding, logging in with the same account, etc. Based on this mutual trust relationship, the first electronic device and the second electronic device can establish a secure communication connection.

[0191] Optionally, the communication connection established between the first electronic device and the second electronic device is, for example, a Bluetooth connection, a Wi-Fi connection, or other types of connections.

[0192] S502: The first electronic device sends a trusted device adding request to the second electronic device.

[0193] In some embodiments, a first electronic device triggers a trusted device addition process in response to a user action. The first electronic device then displays multiple electronic devices with established communication connections and, based on the user action, sends a trusted device addition request to the electronic device selected by the user, adding the selected device as a trusted device. In response, the second electronic device receives the trusted device addition request sent by the first electronic device.

[0194] Optionally, the trusted device addition request carries device information of the first electronic device. The device information may include, for example, the device name, device identifier, device type, and device identity credential information of the first electronic device. The device identity credential information may be, for example, a public key used to subsequently generate a security key for communication between the first electronic device and the second electronic device.

[0195] For example, as shown in interface 601 in FIG6(a), while displaying the settings interface, the first electronic device detects a user's operation on the biometric and password control 61, displaying interface 602 as shown in FIG6(b). On interface 602, the first electronic device detects a user's operation on the smart unlock control 62, displaying interface 603 as shown in FIG6(c). On interface 603, the first electronic device detects a user's operation on the smart unlock switch control 63 and determines that the user has instructed to activate the smart unlock function. While the smart unlock function is enabled, the first electronic device detects a user's operation on the add unlock device control 64 and determines that the user has instructed to add a trusted held device. The first electronic device then searches for nearby electronic devices with which it has established a communication connection and displays interface 604 as shown in FIG6(d), displaying the searched electronic devices, such as a smartwatch and a Bluetooth headset. Subsequently, if the first electronic device detects a user's operation on the smartwatch control 65, it may send a trusted held device add request to the smartwatch corresponding to the smartwatch control 65, requesting that the smartwatch be added as a trusted held device.

[0196] S503: The second electronic device determines device information and generates a security key.

[0197] In some embodiments, the second electronic device parses the received trusted device add request, obtains the device information of the first electronic device carried therein, and generates a key for protecting communication security based on the device information. Optionally, the second electronic device stores the device information and security key of the first electronic device in a device trusted relationship management module as shown in FIG4 .

[0198] In some embodiments, the second electronic device generates device information of the second electronic device in response to the received trusted device addition request. The second electronic device then encrypts the generated device information using a security key, so that the encrypted device information can be subsequently sent to the first electronic device to ensure information security.

[0199] Optionally, the device information of the second electronic device includes, for example, one or more of the following items: identity authentication capability information of the second electronic device supported by the second electronic device, such as authentication method, authentication trust level, etc.; ranging method supported by the second electronic device, such as Bluetooth ranging, wireless carrier communication (ultra wideband, UWB) ranging, etc.; security capability level certificate of the second electronic device, such as device certificate, trusted execution environment (TEE) level key certificate, etc.; device identity credential information, such as public key, etc.

[0200] S504: The second electronic device sends device information to the first electronic device.

[0201] In some embodiments, the second electronic device sends the encrypted device information of the second electronic device to the first electronic device. Correspondingly, the first electronic device receives the device information sent by the second electronic device.

[0202] S505: The first electronic device completes adding the trusted device according to the device information.

[0203] In some embodiments, after receiving the device information of the second electronic device, the first electronic device decrypts the device information and stores the decrypted device information of the second electronic device through the device trusted relationship management module as shown in Figure 4, completing the addition of the trusted holding device, that is, the first electronic device adds the second electronic device as its own trusted holding device.

[0204] In this way, the authentication device can complete the addition of the trusted holding device through the above steps, and subsequently the trusted holding device can be used to perform trusted services, such as unlocking.

[0205] The following describes in detail the authentication method provided in the embodiment of the present application, taking the first electronic device as an authentication device serving as a client and the second electronic device as a trusted holding device serving as a server as an example.

[0206] In some embodiments, to protect device security, some services of electronic devices require user authentication before use. User authentication methods include password authentication, face recognition, fingerprint recognition, voiceprint recognition, etc. For example, a user enters a password on the lock screen of a mobile phone to unlock the phone.

[0207] Optionally, different user identity authentication methods have different accuracy in identifying user identities, different difficulty in being deceived by non-live objects, and different ease in maliciously modifying the authentication results. Therefore, the authentication results determined by different user identity authentication methods have different authentication credibility levels.

[0208] For example, Table 1 shows examples of user identity authentication methods corresponding to different authentication trust levels (ATLs) and the typical business scenarios they support. It should be understood that the content shown in Table 1 is only illustrative and does not limit the authentication trust levels. In actual scenarios, the relevant content of the authentication trust level may include more or less content than shown in Table 1.

[0209] As shown in Table 1, the authentication trust levels include ATL4, ATL3, ATL2, ATL1, and ATL0, with the authentication trust levels decreasing in order, such as ATL4>ATL3>ATL2>ATL1>ATL0.

[0210] For example, as shown in Table 1, if an electronic device can accurately identify an individual user or has strong liveness detection capabilities, and if, in a typical credit card financial operation scenario, the electronic device uses a personal identification number (PIN) authentication method on a secure keyboard to authenticate the user's identity, then after the user's identity authentication passes, the authentication trust level is ATL4.

[0211] Table 1

[0212] In some embodiments, the authentication device can add one or more trusted devices through steps S501 to S505, and different trusted devices may support the same or different highest authentication trust levels. Therefore, the authentication devices may have the same or different ranges of operations that can be performed based on the trusted devices.

[0213] For example, a trusted holding device can monitor local user identity authentication pass events, and can also obtain user identity authentication pass events sent by the authentication device. These user identity authentication pass events can be determined based on different authentication methods. Then, as shown in Table 1, the trusted holding device can obtain the same or different authentication trust levels, so that the trusted holding device can support different authentication trust levels. Therefore, the authentication device can have different executable operation ranges based on the authentication trust levels supported by the same trusted holding device, and the executable operation ranges based on the authentication trust levels supported by different trusted holding devices can be the same or different. The operation range includes operations in business scenarios corresponding to the highest authentication trust level supported by the trusted holding device and authentication trust levels below the highest authentication trust level.

[0214] For example, as shown in (a) of FIG7 , a watch is used as a trusted holding device of a mobile phone. When the watch lock screen is not set, the highest authentication trust level supported by the watch is ATL2. Based on the highest authentication trust level supported by the watch and the trusted holding status, the mobile phone can execute the business scenarios corresponding to ATL2 and ATL1 shown in Table 1, such as general personal data query. For example, when the watch is being worn, the local user identity authentication event monitored is the detection of the user's PPG signal to determine that the user currently wearing the watch is the owner of the phone, and the authentication trust level corresponding to the user identity authentication event is ATL2. Subsequently, the range of operations that can be executed by the mobile phone includes operations in business scenarios corresponding to authentication trust levels ATL2 and below.

[0215] As shown in Figure 7 (b), when the watch is locked, the highest authentication trust level supported by the watch is ATL3. Based on the highest authentication trust level and trusted holding status supported by the watch, the mobile phone can execute the business scenarios corresponding to ATL3, ATL2 and ATL1 shown in Table 1, such as screen unlocking. For example, when the watch is worn, the local user identity authentication event detected is that the user enters the correct lock screen password to unlock the watch, and the authentication trust level corresponding to the user identity authentication event is ATL3. Subsequently, the range of operations that can be executed by the mobile phone includes operations in business scenarios corresponding to authentication trust levels ATL3 and below.

[0216] As another example, as shown in Figure 8, the trusted devices added to the mobile phone include a Bluetooth headset, a wristband, and a watch. The current state of the Bluetooth headset can authorize operations in business scenarios corresponding to authentication trust levels of ATL1 and below, the current state of the wristband can authorize operations in business scenarios corresponding to authentication trust levels of ATL2 and below, and the current state of the watch can authorize operations in business scenarios corresponding to authentication trust levels of ATL3 and below. Therefore, the range of operations that can be performed by the mobile phone through the multiple trusted devices it connects to includes operations in business scenarios corresponding to authentication trust levels of ATL3 and below.

[0217] In some embodiments, after completing the addition of the trusted device, the authentication device may enter a trusted device authentication phase. In the trusted device authentication phase, the trusted device performs user identity authentication in response to an authentication request received from the authentication device.

[0218] As mentioned above, different authentication methods may correspond to the same or different authentication trust levels. Therefore, after the authentication device adds a trusted holder, the trusted holder can monitor at least one of the local user identity authentication success events or obtain the user identity authentication success events sent by the authentication device, and maintain these user identity authentication success events. This allows the trusted holder to subsequently determine whether the user's identity can be successfully confirmed based on the recorded user identity authentication success events when performing user identity authentication in response to an authentication request.

[0219] For example, the target authentication trust level corresponding to the authentication request is ATL2. The trusted holding device in the authentication trusted state determines that these user identity authentication pass events include user identity authentication pass events of ATL2 or above based on the recorded user identity authentication pass events, and can determine that the user identity authentication is passed.

[0220] The following describes the process of maintaining identity authentication pass events during the authentication phase of the trusted holding device.

[0221] For example, Figure 9 is a flowchart of an authentication method for maintaining a trusted device identity authentication pass event provided by an embodiment of the present application. It should be noted that the method is not limited to the specific sequence shown in Figure 9 and the following description. It should be understood that in other embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0222] S901a: The trusted holding device determines that the authentication device starts authentication.

[0223] S901b: The trusted device determines that it has been added as a trusted device by the authentication device.

[0224] In some embodiments, after completing the addition of the trusted device, the authentication device may send a notification to the trusted device to indicate that the trusted device has become the trusted device of the authentication device.

[0225] In some embodiments, after receiving an authentication request from an authentication device, the trusted holding device determines that it is the first time to receive an authentication request from the authentication device, and may determine to initiate authentication, trigger the authentication process, and begin monitoring for user identity authentication success events (i.e., executing step S901a). Alternatively, after determining that it has been added as a trusted holding device, the trusted holding device begins monitoring for user identity authentication success events (i.e., executing step S901b).

[0226] S902: The authentication device detects a user identity authentication success event, and sends the user identity authentication success event to a trusted holding device within a preset range.

[0227] S903: The trusted holding device monitors the user identity authentication success event.

[0228] The user identity authentication success event monitored by the trusted holding device includes at least one of a user identity authentication success event that occurs locally and a user identity authentication success event that is sent by the authentication device.

[0229] In some embodiments, after the trusted device determines that the authentication device has initiated authentication, or determines that it has become the trusted device of the authentication device, it can begin to obtain user identity authentication success events. The user identity authentication success events can be obtained by local monitoring, authentication device synchronization, etc.

[0230] In some examples, to simplify the monitoring process of user identity events, changes in the holding or wearing status of the trusted holding device will not affect the monitoring of user identity authentication events, but will affect the recording process of the user identity authentication events in the following steps S904-S907.

[0231] In other examples, the trusted holding device may also monitor the user identity authentication pass event sent by at least one of the local or authentication devices when determining that the trusted holding device is in the holding or wearing state.

[0232] Optionally, the above step S902 is an optional step, that is, the trusted holding device may not receive the user identity authentication pass event sent by the authentication device, but only monitors the user identity authentication pass event generated locally.

[0233] S904: The trusted device is in the holding or wearing state. If so, execute S905; if not, execute S907.

[0234] In some embodiments, while monitoring local user identity authentication success events, the trusted holding device also monitors its own holding or wearing status. If it determines that it is in the holding or wearing state, it records the acquired user identity authentication success event, executing step S905 below. Upon determining that it has been released from the holding or wearing state, i.e., after switching to a non-holding or non-wearing state, it may clear the recorded user identity authentication success event, executing step S907 below.

[0235] Optionally, the trusted holding device records monitored user identity authentication success events through a valid authentication event list.

[0236] Optionally, the trusted held device being in a held or worn state indicates that the trusted held device is held or worn, and the trusted held device being released from a held or worn state indicates that the trusted held device is not held or worn.

[0237] It should be understood that the embodiment of the present application takes whether the trusted holding device is in a held or worn state as an example to determine whether to record the user identity authentication pass event. When the device form of the trusted holding device is different, the user can also carry the trusted holding device in other ways. Then, when the user carries the trusted holding device in other ways, that is, the trusted holding device is in a carried state, the trusted holding device can also record the user identity authentication pass event; and when the user releases the carried state of the trusted holding device, the trusted holding device can also no longer record the user identity authentication pass event and clear the recorded user identity authentication pass event. That is, the trusted holding device determines whether it needs to record the monitored user identity authentication pass event by judging whether it is in a carried state (such as whether it is in a held state, whether it is in a worn state, etc.), which will not be elaborated below.

[0238] S905: The trusted holding device records the user identity authentication success event.

[0239] In some embodiments, when the trusted holding device determines that it is in a holding or wearing state, it can record a user identity authentication pass event sent by at least one of the local or authentication devices in a valid authentication event list.

[0240] For example, when the trusted holding device is being held or worn, it records locally monitored user authentication events. For example, in response to a user entering a password, the trusted holding device determines the password is correct and unlocks the device. As shown in Table 1, the authentication trust level corresponding to the screen unlock scenario is ATL3. As shown in Table 2, the trusted holding device records the user authentication success event in the valid authentication event list, including information such as the authentication method, authentication trust level, authentication success time, and authentication execution device.

[0241] For another example, after adding a trusted holding device, the authentication device detects a user identity authentication pass event and can send the user identity authentication pass event to the trusted holding device within the preset range. Correspondingly, the trusted holding device receives the user identity authentication pass event sent by the authentication device, and if it determines that it is in a holding or wearing state, it can record the received user identity authentication pass event. For example, as shown in Table 2, the trusted holding device can serve as a trusted holding device for one or more authentication devices, then the trusted holding device can obtain and record the user identity authentication pass event sent by one or more authentication devices. For example, after the Client1 device completes the user identity authentication through the user's fingerprint, it sends the corresponding user identity authentication pass event to the trusted holding device. For another example, after the Client2 device completes the user identity authentication through the user's voiceprint, it sends the corresponding user identity authentication pass event to the trusted holding device.

[0242] Table 2

[0243] In some embodiments, the user identity authentication pass event recorded by the trusted holding device in the valid authentication event list includes the corresponding authentication trust level. Subsequently, during the user identity authentication process of the authentication device, the trusted holding device can determine whether it can meet the authentication requirements of the authentication device based on the authentication trust level. For example, the target authentication trust level of the authentication device is ATL4, but as shown in Table 2, the highest authentication trust level of the user identity authentication pass event recorded by the trusted holding device is ATL3. That is, the highest authentication trust level supported by the trusted holding device is ATL3, which does not meet the ATL4 requirements, that is, the user identity authentication of the authentication request cannot be passed.

[0244] In this way, the trusted holding device records the user identity authentication pass events and returns different authentication results based on the recorded authentication event set, thereby improving authentication flexibility while meeting the security of user identity authentication.

[0245] S906: The trusted holding device determines that it has released the holding or wearing state.

[0246] S907: The trusted device clears the recorded user identity authentication success event.

[0247] In some embodiments, when the trusted holding device is in a held or worn state, the trusted holding device may enter an authenticated trusted state after determining the identity of the user holding or wearing the device. For example, the trusted holding device may enter an authenticated trusted state after determining that the user has unlocked the current lock screen in response to the user entering a password. Subsequently, if the user removes the trusted holding device and the trusted holding device determines that it is no longer held or worn, the trusted holding device will be unable to obtain the relative distance between the user and the authentication device, and thus cannot ensure that the user currently operating the authentication device is the owner holding or wearing the device. In this case, the trusted holding device immediately enters an authenticated untrusted state. In other words, the trusted holding device enters an authenticated untrusted state in response to being released from the held or worn state.

[0248] In some embodiments, after the trusted holding device determines that it has been released from the holding or wearing state, it clears the recorded user identity authentication pass event. Subsequently, after the trusted holding device determines that it is again in the holding or wearing state, it resumes recording the user identity authentication pass event. In other words, in response to a change in the holding or wearing state of the trusted holding device, the trusted holding device clears the user identity authentication pass event or triggers the start of recording the user identity authentication pass event.

[0249] In some embodiments, in step S904 above, if the trusted holding device determines that it is not currently in the holding or wearing state after obtaining the user identity authentication pass event, then step S907 may be executed, i.e., the currently obtained user identity authentication pass event is not recorded, and the valid authentication event list may be cleared again to avoid the valid authentication event list from storing user identity authentication pass events recorded in the previous holding or wearing state period, which would affect authentication security.

[0250] In this way, subsequent trusted holding devices execute the user identity authentication process of the authentication device based on the user identity authentication pass events recorded within a single holding or wearing state cycle, thereby improving authentication security.

[0251] S908: The trusted holding device sends an authentication trusted state change indication to the authentication device.

[0252] In some embodiments, after the holding or wearing state of the trusted holding device changes, the authentication trusted state changes accordingly. For example, when the trusted holding device is in the holding or wearing state and the valid authentication event list is not empty, it is in the authentication trusted state. When the trusted holding device releases the holding or wearing state or the valid authentication event list is empty, it is in the authentication untrusted state. After the trusted holding device determines that it has changed from the authentication trusted state to the authentication untrusted state, or from the authentication untrusted state to the authentication trusted state, it sends an authentication trusted state change indication to the authentication device to indicate the change in its own authentication state. Accordingly, after receiving the state change indication, the authentication device saves the authentication state of the trusted holding device. Subsequently, the authentication device can determine whether to send an authentication request to the trusted holding device that is in the authentication trusted state based on the saved authentication state of one or more trusted holding devices.

[0253] Optionally, the authentication trusted state change indication includes an authentication trusted state invalidation indication indicating that the trusted holding device switches to an authentication untrusted state, and an authentication trusted state valid indication indicating that the trusted holding device switches to an authentication trusted state.

[0254] Optionally, step S908 is optional; the trusted device may not notify the authentication device after its authentication status changes. The authentication device may then query the corresponding trusted device for its authentication status when it needs to authenticate the user. Alternatively, the authentication device may directly send an authentication request to a trusted device that meets the authentication trust level requirements. The trusted device will then trigger the corresponding authentication process based on its own authentication trust status.

[0255] In this way, the trusted holding device in the authenticated trusted state monitors and records the user identity authentication pass event sent by at least one of the local or authentication devices, and then flexibly performs user identity authentication based on the recorded content to meet the user's usage needs.

[0256] Furthermore, even if a trusted device has poor performance, resulting in a low security capability level, it can still receive user identity authentication pass events from other devices corresponding to a high authentication trust level. This allows the trusted device to subsequently determine the authentication result based on the recorded user identity authentication pass events. This allows a trusted device with poor performance to complete user identity authentication on an authentication device with a relatively high authentication trust level, thus enriching authentication scenarios.

[0257] In some embodiments, steps S904 to S908 are looped, and the trusted holding device determines whether to record a user identity authentication pass event or clear the list of valid authentication events based on changes in its holding or wearing state. For example, after step S906, the trusted holding device may return to step S904 and, if it determines that it has switched back to the holding or wearing state, may begin recording the acquired user identity authentication pass events. After reconfirming that it has released the holding or wearing state, it may clear the user identity authentication pass events recorded during the current holding or wearing state period.

[0258] For example, as shown in (a) in Figure 10, after the user takes off the watch, the watch determines that it has released the holding or wearing status and is in an authentication untrustworthy state. Then, the watch, as a trusted holding device, can send an authentication trusted state invalidation indication to the corresponding authentication device (such as a mobile phone) to instruct the trusted holding device to switch to an authentication untrustworthy state.

[0259] Afterwards, as shown in (b) of Figure 10, the user puts on the watch again and unlocks the watch. After the watch determines that it is in the authenticated trusted state again, the watch can send an authenticated trusted state valid indication to the mobile phone to instruct the trusted holding device to switch to the authenticated trusted state.

[0260] Alternatively, as shown in (c) in Figure 10, after the user puts on the watch again, if the mobile phone detects the user operation to confirm the user identity authentication is passed, the watch can obtain the user identity authentication passed event sent by the mobile phone. After the watch determines that it is in the authentication trusted state again, the watch can send an authentication trusted state valid indication to the mobile phone to instruct the trusted holding device to switch to the authentication trusted state.

[0261] Among them, after the watch is switched to the holding or wearing state, it can continuously monitor the user identity authentication pass event sent by at least one local or authentication device, switch from the authentication untrusted state to the authentication trusted state based on the obtained user identity authentication pass event, and record the obtained user identity authentication pass event.

[0262] In this way, the trusted holding device can flexibly switch from an untrusted authentication state to a trusted authentication state by monitoring the holding or wearing status and the local user authentication pass event or the user authentication pass event sent by the authentication device, thereby meeting the user authentication requirements of subsequent authentication devices.

[0263] In some embodiments, after the trusted holding device enters the authentication trusted state through different authentication methods, it can provide different authentication trust levels.

[0264] For example, as shown in Figure 11, a mobile phone serves as the authentication device, and its corresponding trusted device is a watch. After the user wears the watch and performs password authentication, the watch enters the authenticated trusted state with an authentication trust level of ALT3. The authentication trust level that the watch can provide to the mobile phone is ALT3. Subsequently, if the user removes and puts the watch back on, and fails password authentication, the watch enters the authenticated untrusted state. The watch can then send an authentication trust state invalidation indication to the mobile phone, and the mobile phone can determine that the watch is currently in the authenticated untrusted state. Subsequently, the watch automatically collects the user's heart rate characteristics to identify the owner, entering the authenticated trusted state with an authentication trust level of ALT1. The authentication trust level that the watch can provide to the mobile phone is ALT1. Furthermore, the watch can send a trusted state valid indication to the mobile phone. Subsequently, if the user unlocks the watch's trusted device (e.g., a mobile phone or other electronic device), the watch receives the corresponding user identity authentication pass event, enters the authenticated trusted state with an authentication trust level of ALT2, and the highest authentication trust level that the watch can provide to the mobile phone is ALT2.

[0265] In this way, when the trusted holding device is in the holding or wearing state, based on the recorded user identity authentication pass events corresponding to different authentication trust levels, the user identity authentication requirements of the authentication device with different authentication trust levels can be met.

[0266] The following describes the authentication process of the trusted holding device in the authentication phase, in which the trusted holding device performs the authentication of the device through events based on the identity authentication maintained.

[0267] For example, Figure 12 is a flowchart of an authentication method for a trusted device authentication phase provided by an embodiment of the present application. It should be noted that the method is not limited to the specific sequence shown in Figure 12 and below. It should be understood that in other embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0268] S1201: The authentication device sends an authentication request to the trusted holding device.

[0269] In some embodiments, after the authentication device determines that user identity authentication is triggered in response to a user operation, it may send an authentication request to a paired trusted holding device to determine an authentication result.

[0270] Optionally, after determining the authentication trust level requirement corresponding to the currently triggered user identity authentication, the authentication device may send an authentication request to a trusted holding device that meets the authentication trust level requirement.

[0271] For example, if the unlock function in the authentication device detects a user unlocking operation and determines that user identity authentication is triggered, and the authentication trust level requirement for the unlock function is ATL3, the authentication device will then iterate through the authentication trust levels supported by its paired trusted devices and send an authentication request to the trusted device whose highest supported authentication trust level is ATL3 or higher.

[0272] For example, if the same authentication device is connected to multiple trusted devices, and all of them are in an authenticated trusted state, the operating range of the authentication device depends on the trusted device with the highest authenticated trusted level. For example, as shown in Figure 13 (a), a mobile phone is connected to three trusted devices, and all of them are in an authenticated trusted state. These three trusted devices include a Bluetooth headset with a maximum authenticated trusted level of ATL1, a wristband with a maximum authenticated trusted level of ATL2, and a watch with a maximum authenticated trusted level of ATL3. Therefore, the mobile phone can only perform operations with a risk level that matches the authenticated trusted level of ATL3.

[0273] Afterwards, as shown in Figure 13(b), the phone determines that the watch is in an untrusted authentication state in response to the authentication trust state failure indication received from the watch, or the phone determines to disconnect from the watch. In this case, the phone can only perform operations with a risk level that matches the authentication trust level ATL2.

[0274] In the scenario shown in FIG13 , the mobile phone can determine the target authentication trust level according to the risk level corresponding to the user authentication operation to be performed, and send an authentication request to a trusted holding device that meets the requirements.

[0275] Optionally, after determining that user identity authentication is required through a trusted device, the service may generate service constraints that indicate the requirements of the service requiring user identity authentication. These service constraints may include one or more of the following: authentication trust level requirements, user identity confirmation time requirements, user identity confirmation method requirements, user identity confirmation device requirements, usable user confirmation identifiers, and triggerable real-time authentication identifiers.

[0276] Optionally, the authentication request may carry one or more of the above service constraints.

[0277] Among them, the authentication trust level requirement indicates the target authentication trust level of the authentication device.

[0278] The user identity confirmation time requirement specifies the time requirement for the occurrence of a valid user identity authentication event. For example, the authentication device uses the user identity confirmation time requirement to instruct the trusted holder to determine the authentication result based on a user identity authentication event that occurs within 4 hours of the valid authentication event list.

[0279] The user identity confirmation method requirement indicates the user identity confirmation method requirement for the user identity authentication pass event that matches the current user identity authentication result. For example, the user identity confirmation method may include biometric authentication or non-biometric authentication. For example, the authentication device instructs the trusted holder to determine the authentication result based on the user identity authentication pass event generated by non-biometric authentication and recorded in the valid authentication event list, by passing the user identity confirmation method requirement.

[0280] The device requirements for confirming user identity indicate requirements for the device that generated the user identity authentication pass event. For example, the user identity authentication pass event recorded in the valid authentication event list may be a user identity authentication pass event generated locally by the trusted device or a user identity authentication pass event notified by another device. For example, if the authentication device meets the device requirements for confirming user identity, it instructs the trusted device to determine the authentication result based on the user identity authentication pass event generated locally by the trusted device and recorded in the valid authentication event list.

[0281] A user confirmation flag can be used to indicate whether user confirmation is required. For example, if the business determines that the authentication result requires user confirmation to ensure security, the user confirmation flag can be added to the generated business constraint. Later in the user identity authentication process, the authentication device sends a user confirmation request to the trusted holding device based on the user confirmation flag.

[0282] The triggerable real-time authentication flag indicates whether real-time user authentication is permitted. For example, if a trusted device receives an authentication request while in an untrusted authentication state, or if a trusted device is in a trusted authentication state but no corresponding authentication result is found in the valid authentication event list, the triggerable real-time authentication flag can be used to determine whether to trigger real-time user authentication. If the trusted device determines to trigger real-time user authentication based on the triggerable real-time authentication flag, it can display the authentication interface, receive the password entered by the user, and obtain the authentication result.

[0283] S1202: The trusted device is in an authenticated trusted state. If so, proceed to step S1204; if not, proceed to step S1203.

[0284] In some embodiments, the trusted device receives an authentication request from the authentication device, indicating that the trusted device is within the communication range of the authentication device. The trusted device is in an authenticated and trusted state, indicating that the trusted device is held or worn by the user. After receiving the authentication request and determining that it is in an authenticated and trusted state, the trusted device can determine that the owner of the trusted device is within the communication range between the authentication device and the trusted device, thereby ensuring the security of the authentication result determined by the trusted device. The trusted device can then execute step S1204 below to determine the authentication result.

[0285] On the contrary, if the trusted holding device determines that it is in an untrusted authentication state and cannot guarantee the security of the authentication result determined by the trusted holding device, then the trusted holding device may trigger real-time authentication, ie, execute the following step S1203.

[0286] S1203: The trusted device triggers real-time authentication.

[0287] In some embodiments, after receiving an authentication request, the trusted device determines that it is in an untrusted authentication state. The trusted device may then determine whether to trigger real-time authentication for the user based on a triggerable real-time authentication flag included in the authentication request. If the trusted device determines that the authentication request includes a triggerable real-time authentication flag, real-time authentication for the user may be triggered, and the trusted device may execute the real-time authentication process. Optionally, before triggering real-time authentication for the user, the trusted device may first determine whether it supports real-time authentication. If so, the trusted device may execute the real-time authentication process.

[0288] Optionally, real-time authentication methods include instructing the user to enter a password, facial recognition, fingerprint recognition, voiceprint recognition, and other methods. The trusted holding device may determine the authentication method to be used during the real-time authentication process based on its supported authentication methods and the target authentication trust level. For example, the trusted holding device may display an authentication interface and receive a password entered by the user to determine the real-time authentication result.

[0289] Optionally, if the authentication request does not carry a triggerable real-time authentication flag, or the triggerable real-time authentication flag indicates that user real-time authentication cannot be triggered, then this user identity authentication fails.

[0290] In some embodiments, after triggering the real-time authentication, the trusted holding device may obtain an authentication result. If the authentication result is passed, the authentication result carries the authentication trust level corresponding to the corresponding real-time authentication method.

[0291] In some embodiments, after real-time authentication is triggered and passed, the trusted device switches to a trusted authentication state. If the trusted device is currently held or worn, the trusted device can record the user identity authentication pass event for this real-time authentication in a valid authentication event list.

[0292] Thus, compared to the prior art, if the trusted device is in an untrusted authentication state, the user cannot use the trusted device to trigger user identity authentication on the authentication device and can only return to the authentication device to perform user identity authentication, which is cumbersome for the user. The authentication method provided in the embodiment of the present application can also trigger real-time user authentication on the trusted device when the trusted device is in an untrusted authentication state. The user only needs to operate the trusted device at hand to complete the user identity authentication on the authentication device, thereby improving user convenience.

[0293] S1204: The trusted device matches the corresponding authentication result in the valid authentication event list. If so, execute step S1205; if not, execute step S1203.

[0294] In some embodiments, in response to an authentication request sent by an authentication device, a trusted holding device in an authentication trusted state retrieves a stored list of valid authentication events. The trusted holding device can then, based on the business constraints carried in the authentication request, such as authentication trust level requirements, user identity confirmation time requirements, user identity confirmation method requirements, and user identity confirmation device requirements, match the valid authentication event list with a user identity authentication pass event that meets the business constraints to determine the authentication result. If a user identity authentication event that meets the business constraints is matched, the authentication trust level corresponding to the user identity authentication can be determined. The authentication result is then an authentication pass, carrying the authentication trust level.

[0295] For example, the following examples illustrate several scenarios to illustrate the matching process of authentication results.

[0296] Scenario 1: The unlocking function of the authentication device triggers the authentication process. The authentication trust level requirement carried in the authentication request is ATL3, the time requirement for confirming the user identity is within 4 hours (such as the current time is 16:30), the method requirement for confirming the user identity is not limited, and the device requirement for confirming the user identity is not limited. Accordingly, the trusted holding device responds to the received authentication request and matches the user identity authentication pass event that meets the requirements in the valid authentication event list shown in Table 2. For example, the user identity authentication events that meet the authentication trust level requirements matched by the trusted holding device are the user identity authentication event of the first record and the user identity authentication event of the third record, wherein the authentication pass time in the user identity authentication event of the first record does not meet the user identity confirmation time requirement. Then, the trusted holding device determines that the matched user identity authentication pass event is the user identity authentication pass event of the third record, generates the corresponding authentication result as authentication pass, and carries the authentication trust level of ATL3.

[0297] Scenario 2: The unlocking function corresponding to the application store application in the authentication device triggers the authentication process. The authentication trust level requirement carried in the authentication request is ATL2, the time requirement for confirming the user identity is within 10 minutes (such as the current time is 16:30), the method requirement for confirming the user identity is not limited, and the device requirement for confirming the user identity is not limited. Accordingly, in response to the received authentication request, the trusted holding device matches the user identity authentication pass event that meets the requirements in the valid authentication event list shown in Table 2. For example, if the trusted holding device fails to match the user identity authentication pass event that meets the user identity confirmation time requirement, it can be determined that the authentication result is unsuccessful.

[0298] In some embodiments, the trusted device determines that no corresponding identity authentication event is matched in the valid authentication event list, and may determine to trigger real-time authentication, i.e., execute the above step S1203. Optionally, the trusted device may determine whether to trigger real-time authentication based on the triggerable real-time authentication flag.

[0299] S1205: The trusted holding device sends the authentication result to the authentication device.

[0300] In some embodiments, after determining the authentication result by table lookup (such as step S1204 above) or real-time authentication (such as step S1203 above), the trusted holding device may send the determined authentication result to the authentication device.

[0301] Optionally, the trusted holding device encrypts the authentication result using the security key determined in step S503 as shown in FIG5 , and sends the encrypted result to the authentication device.

[0302] For example, in the above steps S1201 to S1205, as shown in Figure 14, the target authentication trust level of the authentication device is ATL3, such as the authentication trust level requirement carried in the authentication request is ATL3 (i.e., step S1201). Accordingly, after receiving the authentication request sent by the authentication device, the trusted holding device determines that it is in an authentication untrustworthy state (i.e., step S1202), or the authentication trust level indicated by the determined user identity authentication event is less than ATL3 (i.e., step S1204), then the trusted holding device can trigger real-time authentication (i.e., step S1203). For example, the trusted holding device triggers real-time authentication of the corresponding authentication method based on the target authentication trust level ATL3, such as password authentication. The trusted holding device displays an authentication interface, displays a password input window on the authentication interface, and receives the password entered by the user. If the trusted holding device determines that the password is correct, it can determine that the authentication result is authentication passed and carry the corresponding authentication trust level of ATL3. Alternatively, if the trusted holding device determines that the password is incorrect, it can determine that the authentication result is authentication failed. Afterwards, the trusted holding device may send the authentication result encrypted by the security key to the authentication device (ie, step S1205 ).

[0303] S1206: The authentication device determines that the authentication result is a real-time authentication result. If so, execute S1207; if not, execute S1208.

[0304] In some embodiments, after receiving the authentication result, the authentication device may determine whether the authentication result is a real-time authentication result. If the authentication result is a real-time authentication result, it can be determined that the owner and the trusted device are within a nearby communication range, the user can know and control the authentication process, and the authentication result is highly reliable. Therefore, the authentication device can directly determine the final authentication result, that is, execute the following step S1207. If the authentication result is a non-real-time authentication result, such as the authentication result determined by the trusted device through a table lookup, then to ensure the reliability of the authentication result, the authentication device may further perform distance measurement on the trusted device to determine whether the distance measurement result and the trusted device's distance measurement security level meet the requirements, that is, execute the following step S1208.

[0305] S1207: The authentication device determines the final authentication result based on the acquired authentication result.

[0306] In some embodiments, after receiving the authentication result, the authentication device determines whether the authentication result is a pass. If the authentication result is a fail, the authentication device may prompt the user to use another method to authenticate their identity. If the authentication result is a pass, the authentication device may obtain the authentication confidence level carried in the result and further evaluate and confirm the authentication confidence level.

[0307] For example, if a user identity authentication success event recorded by a trusted device includes user identity authentication success events sent by other devices, then authentication results returned by some trusted devices with lower security capabilities may also carry a higher authentication trust level. Therefore, the authentication device needs to re-evaluate the authentication results to ensure that the final authentication result is reliable.

[0308] In some embodiments, different trusted devices have different security capability levels, which influence the authentication trust level determined by the trusted device. Optionally, the security capability levels of trusted devices are categorized as high, medium, and low. For example, a low security capability level of a trusted device may downgrade its authentication trust level, thereby further ensuring the reliability of the final authentication result.

[0309] In some examples, when the authentication result is a non-real-time authentication result, if the security capability level of the trusted holding device is high, the authentication trust level in the final authentication result determined by the authentication device = the authentication trust level in the authentication result determined by the trusted holding device; if the security capability level of the trusted holding device is medium, the authentication trust level in the final authentication result determined by the authentication device = the authentication trust level in the authentication result determined by the trusted holding device - 1; if the security capability level of the trusted holding device is less than medium (such as low or lower), the authentication trust level in the final authentication result determined by the authentication device = ATL0~ATL1, that is, no matter how high the authentication trust level in the authentication result determined by the trusted holding device is, if the security capability level of the trusted holding device is low, the authentication trust level that the trusted holding device can provide will be relatively low.

[0310] In other examples, when the authentication result is a real-time authentication result, if the security capability level of the trusted holding device is high, the authentication trust level in the final authentication result determined by the authentication device = the authentication trust level in the authentication result determined by the trusted holding device; if the security capability level of the trusted holding device is medium, the authentication trust level in the final authentication result determined by the authentication device = the authentication trust level in the authentication result determined by the trusted holding device - 1; if the security capability level of the trusted holding device is less than medium (such as low or lower), the authentication trust level in the final authentication result determined by the authentication device = ATL0~ATL1, that is, no matter how high the authentication trust level in the authentication result determined by the trusted holding device is, if the security capability level of the trusted holding device is low, the authentication trust level that the trusted holding device can provide will be relatively low.

[0311] For example, corresponding to scenario 1 in step S1204 above, the authentication result received by the authentication device from the trusted holding device carries an authentication trust level of ATL 3. In this scenario 1, the authentication trust level requirement carried in the authentication request is ATL 3, that is, the target authentication trust level of the authentication device is ATL 3.

[0312] For example, if the authentication device determines that the security capability level of the trusted device is advanced, then the authentication device determines that the authentication trust level in the final authentication result is ATL3. The authentication device determines that the authentication trust level meets the target authentication trust level requirements and can trigger unlocking.

[0313] For another example, if the authentication device determines that the security capability level of the trusted device is intermediate, then the authentication device determines that the authentication trust level in the final authentication result is ATL3-1=ATL2 (i.e., authentication trust level 3 minus 1 equals authentication trust level 2). If the authentication device determines that the authentication trust level does not meet the target authentication trust level requirement, it may trigger an unlock failure. Optionally, after the unlock fails, the authentication device may prompt the user to use other methods to unlock the device.

[0314] In some embodiments, the authentication device may confirm the security capability level of the trusted holding device based on the following: the security level of the trusted relationship between the authentication device and the trusted holding device, the security level of maintaining the authentication trust status, the security level of detecting the holding or wearing state, and the security level of ranging. Specific requirements for each of these elements can be found in Table 3. It should be understood that the content shown in Table 3 is merely illustrative; in actual application scenarios, more or fewer elements may be included.

[0315] For example, if all the items shown in Table 3 meet the corresponding requirements for the advanced level, the authentication device may determine that the security capability level of the trusted holding device is advanced. For another example, if the security level of the trusted relationship between the authentication device and the trusted holding device, the security level for maintaining the authentication trusted state, and the security level for detecting the holding or wearing state shown in Table 3 all meet the advanced requirements, but the ranging security level only meets the intermediate requirements, the authentication device may determine that the security capability level of the trusted holding device is intermediate.

[0316] The security level of the trusted relationship between the authentication device and the trusted device indicates the security of the channel established after the trusted relationship is confirmed. The higher the security level of the trusted relationship between the two devices, the more difficult it is to crack the session security key negotiated after the trusted relationship is confirmed, the higher the communication security, and the less likely the trusted device authentication parameters and results will be maliciously modified during transmission.

[0317] The authentication trust state maintenance security level indicates the ability of the trusted device to maintain a list of valid authentication events. A higher authentication trust state maintenance security level and a better application isolation level reduce the likelihood of malicious modification of user authentication events in the list of valid authentication events maintained by the trusted device, and the device's ability to maintain the list of valid authentication events is enhanced.

[0318] The holding or wearing status detection security level indicates the trusted holding device's ability to detect its own holding or wearing status. The more accurately the trusted holding device detects its own holding or wearing status, the less likely it is that the holding user entity will be switched without the trusted holding device noticing after the user's identity is confirmed. In the presence of the device owner, the risk of executing business operations based on the authentication results confirmed by the trusted device is more manageable.

[0319] The distance measurement security level indicates the supported distance detection capabilities between the authentication device and the trusted device. The more accurate the distance detection between the authentication device and the trusted device, the more manageable the risk of executing business operations based on the authentication results determined by the trusted device in the presence of the device owner.

[0320] Optionally, the purpose of ranging is to ensure that when the authentication device uses the authentication result of the trusted holding device, the user is around the authentication device, and the business operations corresponding to the authentication result can be known and controlled by the user to the greatest extent. Prompting the user to manually confirm on the trusted holding device side can achieve this purpose more reliably. Therefore, the user's manual confirmation result can replace the requirement for the ranging security level. For example, as shown in Table 4, when the authentication trust level in the final authentication result is downgraded due to the ranging security level and does not meet the target authentication trust level requirement, the authentication device can trigger user confirmation (i.e., the following steps S1208-S1211) to obtain the user confirmation result. Afterwards, the authentication device matches the corresponding ranging security level according to the user manual confirmation requirements shown in Table 4, and reconfirms the final authentication result. Among them, the specific user confirmation method is detailed in the following steps S1208-S1211, which will not be repeated here.

[0321] Table 3

[0322] Table 4

[0323] In this way, the authentication trust levels supported by different trusted holding devices are evaluated according to their different security capability levels to support business operations with different risks, thereby expanding the range of authentication devices supported by trusted holding devices and ensuring the security of the use of authentication results.

[0324] Furthermore, the methods for trusted devices to enter the authenticated trusted state have been expanded. The final trusted device authentication result and authentication trust level are evaluated based on the authentication method used to enter the authenticated trusted state, combined with the authentication requirements indicated in the authentication request and the security capability level of the trusted device. This eliminates the need for manual user operation for trusted devices to enter the authenticated trusted state, facilitating user operation. Furthermore, by providing authentication results at different authentication trust levels based on business needs, the scope of supported businesses has been expanded.

[0325] In other embodiments, after determining the authentication result, the trusted holding device may also directly evaluate the authentication result based on its own security capability level. After determining the final authentication result, the final authentication result is directly sent to the authentication device. Then, the authentication device does not need to evaluate the obtained authentication result based on the security capability level of the trusted holding device. In the authentication result evaluation process, the trusted holding device can determine the ranging security level based on the ranging capabilities of the authentication device and the trusted holding device. Alternatively, the trusted holding device directly sends its own security capability level to the authentication device, and the authentication device directly evaluates the authentication result based on the obtained security capability level without having to reconfirm the security capability level of the trusted holding device.

[0326] S1208: The authentication device determines that the distance measurement result and the distance measurement security level meet the requirements. If so, execute S1207; if not, execute S1209.

[0327] In some embodiments, after determining that the authentication result sent by the trusted device is a non-real-time authentication result, the authentication device may trigger a distance measurement to obtain a distance measurement result to further reduce the risk of the operator being unaware and uncontrollable. For example, if the authentication device determines based on the distance measurement result that the trusted device is within a preset distance range, the authentication device may determine that the distance measurement result meets the requirements.

[0328] In some cases, the ranging result meets the requirements, but the ranging security level of the trusted device does not meet the requirements, and the user identity authentication may fail. Therefore, the authentication device can reconfirm the ranging security level of the trusted device to determine whether the authentication trust level corresponding to the ranging security level meets the target authentication trust level requirements.

[0329] For example, as shown in Table 3, different ranging processes correspond to different ranging security levels. The authentication device can then determine the security capability level of the trusted device based on the ranging security level, and thus determine whether the authentication trust level in the final authentication result meets the target authentication trust level requirements based on the security capability level of the trusted device. Therefore, when the authentication device determines that both the ranging result and the ranging security level meet the requirements, it can obtain the final authentication result. Specifically, if the requirements are met, the final authentication result can be obtained, executing step S1207 above. If the requirements are not met, user confirmation can be triggered, executing step S1209 below.

[0330] For example, as shown in Figure 15, the authentication device triggers user authentication in response to a user action and sends an authentication request to the trusted device. The trusted device, now in a trusted authentication state, can directly match the corresponding authentication result against a list of valid authentication events and send the result to the authentication device. The authentication device then performs ranging based on the authentication result and determines that the authentication trust level corresponding to the ranging result and the ranging security level meets the target authentication trust level requirements, thus confirming that the user authentication has passed. This process allows user authentication to be completed without the user's knowledge, thereby improving user convenience while meeting security requirements.

[0331] It should be understood that, as shown in Table 3, in step S1208, the authentication device may determine the ranging security level through real-time ranging, or may determine the ranging security level based on the ranging capabilities supported by the authentication device and the trusted holding device.

[0332] S1209: The authentication device sends a user confirmation request to the trusted holding device.

[0333] In some embodiments, if the authentication device determines that the authentication trust level corresponding to the ranging security level does not meet the requirements, or determines that the trusted holding device is not within the ranging range, it can send a user confirmation request to the trusted holding device to obtain a user confirmation result. In response, the trusted holding device receives the user confirmation request sent by the authentication device.

[0334] Optionally, the authentication device may determine whether to send a user confirmation request to the trusted device based on whether the service constraint contains an acceptable user confirmation identifier. For example, the authentication device may send a user confirmation request to the trusted device based on whether the service constraint contains an acceptable user confirmation identifier.

[0335] Optionally, if the service constraint does not include an available user confirmation identifier, or the available user confirmation identifier indicates that user confirmation cannot be triggered, then this user identity authentication fails.

[0336] S1210: The trusted device displays a confirmation interface and obtains a confirmation result.

[0337] In some embodiments, the trusted holding device displays a confirmation interface in response to the received user confirmation request to obtain a user confirmation result.

[0338] Optionally, the trusted device displays a prompt message to facilitate the user to confirm the authentication result determined by the authentication device. Optionally, the trusted device detects the user clicking a confirmation control on the display interface or double-clicking the display screen to determine the received user confirmation result.

[0339] S1211. The trusted holding device sends a confirmation result to the authentication device.

[0340] In some embodiments, after determining the user confirmation result, the trusted device may send the confirmation result to the authentication device. Accordingly, the trusted device receives the confirmation result. If the confirmation result is a manual user confirmation result, as shown in Table 4, the authentication device matches the corresponding trusted device security capability level based on the manual user confirmation result.

[0341] For example, as shown in FIG16 , the authentication device sends an authentication request to the trusted holding device, requiring a target authentication trust level of ATL2 (i.e., step 1). The trusted holding device determines the authentication trust level to be ATL2 based on the valid authentication event list and feeds back the corresponding authentication result to the authentication device (i.e., step 2). Afterwards, the authentication device determines that the obtained authentication result is a non-real-time authentication result and triggers ranging. For example, the authentication device determines that the ranging result meets the requirements. As shown in Table 3, the authentication device determines that the security capability level of the authentication device is intermediate based on the ranging security level. Then, as shown in FIG16 , the ranging level determined by the authentication device causes the authentication trust level to become ATL2-1=ATL1 (i.e., authentication trust level 2 minus 1 equals authentication trust level 1), which does not meet the target authentication trust level requirement (i.e., step 3). Then, the authentication device can send a user confirmation request to the trusted holding device (i.e., step 4). Accordingly, in response to the received user confirmation request, the trusted holding device can display a confirmation interface. After detecting that the user clicks the "Yes" control on the confirmation interface, it can send the corresponding confirmation result to the authentication device (i.e., step 5). The trusted device sends the authentication result by sending the user confirmation result through an encrypted channel established based on the mutual trust relationship between devices established by the user operation. As shown in Table 4, the authentication device can replace the ranging security level with the manual user confirmation result and then determine the corresponding trusted device security capability level as high based on the manual user confirmation result. Based on the authentication trust level ATL2 sent by the trusted device in step ②, the authentication device can determine that the authentication trust level in the final authentication result is ATL2. The authentication device then determines that the authentication trust level in the final authentication result meets the target authentication trust level requirements and triggers the execution of the corresponding service.

[0342] As another example, as shown in Figure 17, if the authentication device determines that the trusted device is not within the ranging range or cannot measure the distance, that is, the ranging result does not meet the requirements, it may send a user confirmation request to the trusted device. Accordingly, the trusted device may display a confirmation interface in response to the received user confirmation request. After detecting that the user has clicked the "Yes" control on the confirmation interface, it may send the corresponding confirmation result to the authentication device. Based on the method in which the trusted device transmits the authentication result and the authentication result, the authentication device may determine the security capability level of the trusted device and further determine the final authentication result.

[0343] In this way, compared to the prior art, if the trusted device is not within the range, the user cannot use the trusted device to trigger the user identity authentication of the authentication device, and can only return to the authentication device to perform user identity authentication, which is cumbersome for the user. The authentication method provided in the embodiment of the present application can also trigger user confirmation when the trusted device is not within the range. The final authentication result is determined based on the authentication result determined by the trusted device and the user confirmation result. The user only needs to operate the trusted device at hand to complete the user identity authentication of the authentication device, thereby improving the convenience of user use.

[0344] Figure 18 is a flow chart of an authentication method provided in an embodiment of the present application. It should be noted that the method is not limited to the specific sequence shown in Figure 18 and described below. It should be understood that in other embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0345] S1801: In response to a user identity authentication request for a first service in a first electronic device, the first electronic device sends an authentication request to a second electronic device.

[0346] The authentication trust level supported by the second electronic device meets the first authentication trust level requirement, which is the minimum authentication trust level for the first service. A short-range communication connection is established between the first electronic device and the second electronic device to ensure the security of user identity authentication.

[0347] Optionally, the first service may be a function or application in the first electronic device. For example, the first service may be an unlock function that controls the unlocking or locking of the screen of the first electronic device. In response to a user operation, the unlock function determines that user identity authentication is required and may send an authentication request to the second electronic device. For another example, the first service may be a preset application, such as an app store. The preset application detects a user startup operation, determines that user identity authentication is required, and may send an authentication request to the second electronic device.

[0348] Optionally, after determining the first authentication trust level requirement required by the first service currently to perform user identity authentication, the first electronic device may send an authentication request to a second electronic device that meets the first authentication trust level requirement.

[0349] For example, if the unlock function in a first electronic device detects a user's unlock operation and determines that user identity authentication is triggered, and the corresponding authentication trust level requirement for the unlock function is ATL3, that is, the minimum authentication trust level requirement for the unlock function is ATL3, then the first electronic device will traverse the authentication trust levels supported by its paired second electronic device and send an authentication request to the trusted holding device whose highest authentication trust level supported by the second electronic device is ATL3 or above.

[0350] In some embodiments, the authentication request carries business constraints, which include one or more of the following: first authentication trust level requirements, user identity confirmation time requirements, user identity confirmation method requirements, user identity confirmation device requirements, usable user confirmation identification, and triggerable real-time authentication identification.

[0351] Optionally, the first service generates the above service constraint when determining to perform user identity authentication. The first electronic device generates an authentication request according to the request of the first service, and carries one or more of the service constraint conditions in the authentication request.

[0352] Among them, the authentication trust level requirement indicates the target authentication trust level of the first business. The user identity confirmation time requirement indicates the time requirement for the occurrence of the available user identity authentication pass event. The user identity confirmation method requirement indicates the requirement for the user identity confirmation method for the user identity authentication pass event that matches the current user identity authentication result. The user identity confirmation device requirement indicates the requirement for the device that generates the user identity authentication pass event. The available user confirmation identifier is used to indicate whether user confirmation is required, and the first electronic device determines whether to trigger user confirmation on the second electronic device side based on the available user confirmation identifier. The triggerable real-time authentication identifier indicates whether user real-time authentication is allowed. The first electronic device determines whether to trigger user real-time authentication on the second electronic device side based on the triggerable real-time authentication identifier.

[0353] In some embodiments, before the second electronic device receives the authentication request from the first electronic device, the first electronic device needs to add the second electronic device as a trusted holding device. For example, after the second electronic device receives the trusted holding device addition request from the first electronic device, it sends device information to the first electronic device. Afterwards, the first electronic device adds the second electronic device as a trusted holding device of the first electronic device based on the device information. After the trusted holding device is added successfully, the first electronic device sends a trusted holding device response to the second electronic device. Correspondingly, the second electronic device receives the trusted holding device response from the first electronic device and determines that it has become a trusted holding device of the first electronic device. Then, subsequently, the second electronic device can receive the authentication request from the first electronic device and start user identity authentication.

[0354] The device information includes one or more of the following: identity authentication capability information supported by the second electronic device, ranging methods supported by the second electronic device, security capability level certificate of the second electronic device, and device identity certificate information.

[0355] For example, the identity authentication capability information supported by the second electronic device includes the authentication method and authentication trust level. The ranging methods supported by the second electronic device include Bluetooth ranging and UWB ranging. The security capability level certificate of the second electronic device includes the device certificate and TEE-level key certificate. The device identity credential information includes the public key, etc.

[0356] S1802: When in the first state, the second electronic device matches a first authentication result corresponding to the authentication request in the first list.

[0357] The first list includes at least one of a first event or a second event. The first event is a local user identity authentication success event monitored by the second electronic device, and the second event is a user identity authentication success event from the first electronic device. The user identity authentication success event includes information such as the authentication method, authentication trust level, authentication success time, and authentication execution device. Optionally, the first list is, for example, a list of valid authentication events.

[0358] In some embodiments, after detecting the first user identity authentication success event, the first electronic device sends the first user identity authentication success event to the second electronic device.

[0359] For example, after determining that the second electronic device has been added as a trusted device by the first electronic device, the second electronic device may start to monitor user identity authentication success events generated by at least one of the local electronic device and the first electronic device.

[0360] For another example, after the second electronic device receives the authentication request from the first electronic device for the first time, that is, after the authentication is started for the first time, it starts to monitor the user identity authentication success event generated by at least one of the local electronic device and the first electronic device.

[0361] In some examples, different authentication methods may correspond to the same or different authentication trust levels. The second electronic device can then monitor user identity authentication success events and record user identity authentication success events corresponding to different authentication trust levels. This allows the second electronic device to subsequently meet the authentication requirements of the first electronic device at different authentication trust levels.

[0362] In some embodiments, the second electronic device may obtain a user identity authentication success event generated by at least one of the local electronic device and the first electronic device. Furthermore, when the second electronic device is in a carried state, the second electronic device records the obtained user identity authentication success event in a first list, so that the second electronic device can subsequently perform user identity authentication based on the user identity authentication success event recorded in the first list.

[0363] In some examples, when the second electronic device determines that the carried state has been released, it clears the user identity authentication pass events recorded in the first list to avoid the first list storing the user identity authentication pass events recorded in the previous carried state period, which affects the authentication security.

[0364] Optionally, the second electronic device further sends a first state failure indication to the first electronic device, where the first state failure indication may indicate that the second electronic device is in a second state. Optionally, the first state may be, for example, a trusted authentication state, and the second state may be, for example, an untrusted authentication state.

[0365] In this way, the second electronic device determines whether to record the acquired user identity authentication pass event in response to the change in the carrying status, so that in the subsequent user identity authentication process, the second electronic device can execute the user identity authentication process of the first electronic device based on the user identity authentication pass event recorded within a single carried status period, thereby improving authentication security.

[0366] In some embodiments, after the second electronic device is released from the carried state, it is in the second state. Thereafter, while in the second state, the second electronic device determines that it is again in the carried state and, in response to a first user identity authentication success event received from the first electronic device, switches from the second state to the first state. The first user identity authentication success event is a user identity authentication success event detected by the first electronic device.

[0367] In this way, the second electronic device can flexibly switch between the first state and the second state by monitoring the carried state and the user identity authentication pass event, thereby meeting the subsequent user identity authentication requirements of the first electronic device.

[0368] S1803: The second electronic device sends the first authentication result to the first electronic device.

[0369] In some embodiments, after the second electronic device matches the corresponding first authentication result according to the recorded user identity authentication pass event, it can send the first authentication result to the first electronic device. Correspondingly, the first electronic device receives the first authentication result from the second electronic device.

[0370] S1804: The second electronic device determines a second authentication result based on the first authentication result, where the second authentication result indicates whether the second electronic device passes the trusted authentication.

[0371] In some embodiments, after receiving the first authentication result, the first electronic device determines that the first authentication result is a non-real-time authentication result determined by the second electronic device based on a recorded user identity authentication success event. To ensure the reliability of the authentication result, the first electronic device may perform a distance measurement on the second electronic device to confirm the authentication result.

[0372] For example, in response to the first authentication result being a non-real-time authentication result, the first electronic device performs a distance measurement on the second electronic device to generate a distance measurement result. If the distance measurement result meets a preset distance requirement, the first distance measurement security level of the second electronic device is determined, and based on the first distance measurement security level, the first authentication trust level carried in the first authentication result is adjusted to generate a second authentication trust level.

[0373] For example, different second electronic devices have different security capability levels, which can affect the authentication trust level determined by the second electronic device. Optionally, as shown in Table 3, the security capability levels of the second electronic device are divided into three levels: high, medium, and low. For example, a low security capability level of the second electronic device may downgrade its authentication trust level, thereby further ensuring the reliability of the final authentication result.

[0374] Optionally, first information is obtained, the first information including the security level of the trusted relationship between the first electronic device and the second electronic device, the first state maintenance security level of the second electronic device, the carried state detection security level of the second electronic device, and the first ranging security level. Based on the first information, the security capability level of the second electronic device is determined. When the security capability level is high, the second authentication trust level is equal to the first authentication trust level. When the security capability level is medium, the second authentication trust level is less than the first authentication trust level. When the security capability level is low, the second authentication trust level is level 0 or level 1.

[0375] For example, the authentication trust level requirement carried in the authentication request is ATL3, that is, the target authentication trust level of the first electronic device is ATL3. The authentication trust level carried in the authentication result received by the first electronic device from the second electronic device is ATL3.

[0376] For example, if the first electronic device determines that the second electronic device's security capability level is high, then the first electronic device determines that the authentication trust level in the final authentication result is ATL 3. The first electronic device determines that the authentication trust level meets the target authentication trust level requirement and can trigger unlocking.

[0377] For another example, if the first electronic device determines that the security capability level of the second electronic device is intermediate, then the first electronic device determines that the authentication trust level in the final authentication result is ATL3-1=ATL2 (i.e., authentication trust level 3 minus 1 equals authentication trust level 2). If the first electronic device determines that the authentication trust level does not meet the target authentication trust level requirement, it may trigger an unlock failure. Optionally, after the unlock fails, the first electronic device may prompt the user to use other methods to unlock.

[0378] In this way, different authentication trust levels supported by the second electronic device are evaluated according to the different security capability levels of the second electronic device to support business operations with different risks, thereby expanding the scope of the first electronic device supported by the second electronic device and ensuring the security of the use of the authentication results.

[0379] In some examples, when the second authentication trust level meets the first authentication trust level requirements, the first electronic device determines that the second authentication result indicates that the second electronic device has passed the trusted authentication.

[0380] In other examples, if the second authentication trust level does not meet the first authentication trust level requirements, the first electronic device sends a user confirmation request to the second electronic device. The first electronic device then receives a confirmation result from the second electronic device, where the confirmation result is a result determined by the second electronic device based on the user operation. In response to receiving the confirmation result, the first electronic device determines a second authentication result.

[0381] For example, the first electronic device matches the corresponding second ranging security level based on the method of receiving the confirmation result. Subsequently, the first electronic device determines the second authentication result based on the second ranging security level. For example, as shown in Table 4, the first electronic device matches the corresponding ranging security level based on the confirmation method of the user's manual confirmation result, and then determines the security capability level of the second electronic device.

[0382] In this way, when the second electronic device is not within the ranging range or the ranging security level does not meet the requirements, the second electronic device can also be confirmed by the user, and the final authentication result is determined based on the authentication result already determined by the second electronic device and the user confirmation result. The user only needs to operate the second electronic device at hand to complete the user identity authentication of the first electronic device, thereby improving the convenience of user use.

[0383] For example, as shown in FIG16 , a first electronic device sends an authentication request to a second electronic device, requesting a target authentication trust level of ATL2 (i.e., step 1). The second electronic device determines an authentication trust level of ATL2 based on the first list and feeds back the corresponding authentication result to the first electronic device (i.e., step 2). Subsequently, the first electronic device determines that the obtained authentication result is a non-real-time authentication result and triggers ranging. For example, the first electronic device determines that the ranging result meets the requirements. As shown in Table 3, the security capability level of the first electronic device determined by the first electronic device based on the ranging security level is intermediate. Then, as shown in FIG16 , the ranging level determined by the first electronic device causes the authentication trust level to become ATL2-1=ATL1 (i.e., authentication trust level 2 minus 1 equals authentication trust level 1), which does not meet the target authentication trust level requirement (i.e., step 3). Then, the first electronic device may send a user confirmation request to the second electronic device (i.e., step 4). Accordingly, in response to the received user confirmation request, the second electronic device may display a confirmation interface. After detecting that the user has clicked the "Yes" control on the confirmation interface, it may send the corresponding confirmation result to the first electronic device (i.e., step 5). Among them, the second electronic device sends the authentication result by sending the user confirmation result through an encrypted channel established based on the mutual trust relationship between devices established by the user operation. As shown in Table 4, the first electronic device can replace the ranging security level with the manual user confirmation result, and then determine that the corresponding second electronic device security capability level is high based on the manual user confirmation result. Then, the first electronic device can determine that the authentication trust level in the final authentication result is ATL2 based on the authentication trust level ATL2 sent by the second electronic device obtained in the previous step ②. Then, the first electronic device determines that the authentication trust level in the final authentication result meets the requirements of the target authentication trust level and can trigger the execution of the corresponding business.

[0384] In other embodiments, when the second electronic device is in the second state, it triggers real-time authentication in response to the authentication request and generates a third authentication result. The second electronic device then sends the third authentication result to the first electronic device, and the third authentication result is used to generate a second authentication result indicating whether the second electronic device has passed the trusted authentication.

[0385] In this way, compared to the prior art, if the second electronic device is in an authentication-untrusted state, the user cannot use the second electronic device to trigger user identity authentication on the first electronic device and can only return to the first electronic device to perform user identity authentication, which is cumbersome for the user. The authentication method provided in the embodiment of the present application can also trigger real-time user authentication on the second electronic device when the second electronic device is in an authentication-untrusted state. The user only needs to operate the second electronic device at hand to complete the user identity authentication of the authentication device, thereby improving user convenience.

[0386] Optionally, the first electronic device may also execute the steps and functions executed by the authentication device in the above embodiment, and the second electronic device may also execute the steps and functions executed by the trusted holding device in the above embodiment, thereby implementing the authentication method provided by the above embodiment.

[0387] The authentication method provided in the embodiment of the present application is described in detail above with reference to Figures 14 to 18. The first electronic device and the second electronic device provided in the embodiment of the present application are described in detail below with reference to Figures 19 and 20.

[0388] In one possible design, Figure 19 is a schematic diagram of the structure of a first electronic device provided in an embodiment of the present application. As shown in Figure 19, the first electronic device 1900 may include: a transceiver unit 1901 and a processing unit 1902. The first electronic device 1900 may be used to implement the functions of the authentication device involved in the above method embodiment.

[0389] Optionally, the transceiver unit 1901 is used to support the first electronic device 1900 to execute S501, S502 and S504 in Figure 5; or to support the first electronic device 1900 to execute S901a, S902 and S908 in Figure 9; or to support the first electronic device 1900 to execute S1201, S1205, S1209 and S1211 in Figure 12.

[0390] Optionally, the processing unit 1902 is used to support the first electronic device 1900 to execute S505 in Figure 5; or to support the first electronic device 1900 to execute S1206, S1208 and S1207 in Figure 12.

[0391] The transceiver unit may include a receiving unit and a transmitting unit, and may be implemented by a transceiver or a transceiver-related circuit component, and may be a transceiver or a transceiver module. The operations or functions of each unit in the first electronic device 1900 are respectively to implement the corresponding process of the authentication method in the above method embodiment. All relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional unit. For the sake of brevity, they are not repeated here.

[0392] Optionally, the first electronic device 1900 shown in Figure 19 may further include a storage unit (not shown in Figure 19 ) having a program or instruction stored therein. When the transceiver unit 1901 and the processing unit 1902 execute the program or instruction, the first electronic device 1900 shown in Figure 19 may perform the authentication method in the above-described method embodiment.

[0393] The technical effects of the first electronic device 1900 shown in FIG19 may refer to the technical effects of the authentication method in the above method embodiment, and will not be repeated here.

[0394] In addition to being in the form of the first electronic device 1900, the technical solution provided in this application may also be a functional unit or chip in the first electronic device, or a device used in conjunction with the first electronic device.

[0395] In one possible design, Figure 20 is a schematic diagram of the structure of a second electronic device provided in an embodiment of the present application. As shown in Figure 20, the second electronic device 2000 may include: a transceiver unit 2001 and a processing unit 2002. The second electronic device 2000 may be used to implement the functions of the trusted holding device involved in the above method embodiment.

[0396] Optionally, the transceiver unit 2001 is used to support the second electronic device 2000 to execute S501, S502 and S504 in Figure 5; or to support the second electronic device 2000 to execute S901a, S902 and S908 in Figure 9; or to support the second electronic device 2000 to execute S1201, S1205, S1209 and S1211 in Figure 12.

[0397] Optionally, the processing unit 2002 is used to support the second electronic device 2000 to execute S503 in Figure 5; or to support the second electronic device 2000 to execute S901b, S903, S904, S905, S906 and S907 in Figure 9; or to support the second electronic device 2000 to execute S1202, S1203, S1204 and S1210 in Figure 12.

[0398] The transceiver unit may include a receiving unit and a transmitting unit, and may be implemented by a transceiver or a transceiver-related circuit component, and may be a transceiver or a transceiver module. The operations or functions of each unit in the second electronic device 2000 are respectively to implement the corresponding process of the authentication method described in the above method embodiment. All relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional unit. For the sake of brevity, they are not repeated here.

[0399] Optionally, the second electronic device 2000 shown in Figure 20 may further include a storage unit (not shown in Figure 20) having a program or instruction stored therein. When the transceiver unit 2001 and the processing unit 2002 execute the program or instruction, the second electronic device 2000 shown in Figure 20 may execute the authentication method described in the above method embodiment.

[0400] The technical effects of the second electronic device 2000 shown in FIG. 20 may refer to the technical effects of the authentication method described in the above method embodiment, and will not be repeated here.

[0401] In addition to being in the form of the second electronic device 2000, the technical solution provided in this application may also be a functional unit or chip in the second electronic device, or a device used in conjunction with the second electronic device.

[0402] An embodiment of the present application also provides a chip system, including: a processor, the processor is coupled to a memory, the memory is used to store programs or instructions, when the program or instructions are executed by the processor, the chip system implements the method in any of the above method embodiments.

[0403] Optionally, there may be one or more processors in the chip system. The processor may be implemented in hardware or software. When implemented in hardware, the processor may be a logic circuit, an integrated circuit, etc. When implemented in software, the processor may be a general-purpose processor implemented by reading software code stored in a memory.

[0404] Optionally, the memory in the chip system may be one or more. The memory may be integrated with the processor or may be provided separately from the processor, which is not limited in the embodiments of the present application. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or provided on different chips. The embodiments of the present application do not specifically limit the type of memory or the configuration of the memory and the processor.

[0405] Exemplarily, the chip system may be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a microcontroller unit (MCU), a programmable logic device (PLD) or other integrated chips.

[0406] It should be understood that each step in the above method embodiment can be completed by hardware integrated logic circuits in a processor or by software instructions. The method steps disclosed in the embodiments of the present application can be directly embodied as being executed by a hardware processor, or by a combination of hardware and software modules in a processor.

[0407] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a computer, the computer executes the above-mentioned related steps to implement the authentication method in the above-mentioned embodiment.

[0408] An embodiment of the present application further provides a computer program product. When the computer program product is run on a computer, the computer is caused to execute the above-mentioned related steps to implement the authentication method in the above-mentioned embodiment.

[0409] In addition, embodiments of the present application further provide a device. Specifically, the device may be a component or module, and may include one or more processors and a memory connected to each other. The memory is used to store a computer program. When the computer program is executed by one or more processors, the device performs the authentication method described in each of the above method embodiments.

[0410] The apparatus, computer-readable storage medium, computer program product, or chip provided in the embodiments of the present application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0411] The steps of the method or algorithm described in conjunction with the disclosure of the embodiments of the present application can be implemented in a hardware manner or can be implemented by a processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in a random access memory (RAM), a flash memory, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a register, a hard disk, a mobile hard disk, a read-only compact disc (CD-ROM) or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and can write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an application specific integrated circuit (ASIC).

[0412] Through the description of the above embodiments, those skilled in the art will clearly understand that for the sake of convenience and brevity, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed; that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working processes of the above-mentioned systems, devices, and units can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0413] In the several embodiments provided in this application, it should be understood that the disclosed methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of the modules or units is only a logical function division, and there may be other division methods in actual implementation; for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of modules or units, which can be electrical, mechanical or other forms.

[0414] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0415] Computer-readable storage media include, but are not limited to, any of the following: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and other media that can store program code.

[0416] The above is only a specific embodiment of the present application, but the scope of protection of this application is not limited to this. Any changes or substitutions within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. An authentication system, characterized in that: The system includes a first electronic device and a second electronic device, wherein a short-range communication connection is established between the first electronic device and the second electronic device; The first electronic device is configured as follows: In response to a user identity authentication request of a first service in the first electronic device, sending an authentication request to a second electronic device, wherein an authentication trust level supported by the second electronic device meets a first authentication trust level requirement, and the first authentication trust level requirement is a minimum authentication trust level of the first service; receiving a first authentication result from the second electronic device; Determine a second authentication result according to the first authentication result, wherein the second authentication result indicates whether the second electronic device passes the trusted authentication; The second electronic device is configured as follows: When the second electronic device is in the first state, matching a first authentication result corresponding to the authentication request in a first list, wherein the first list includes at least one of a first event or a second event, the first event is a local user identity authentication pass event monitored by the second electronic device, and the second event is a user identity authentication pass event from the first electronic device; The first authentication result is sent to the first electronic device.

2. The system according to claim 1, characterized in that The second electronic device is further configured to: When in the second state, perform real-time authentication to generate a third authentication result; Sending the third authentication result to the first electronic device; The first electronic device is further configured to: receiving the third authentication result from the second electronic device; It is detected that the third authentication result is a real-time authentication result, and the second authentication result is determined according to the third authentication result.

3. The system according to claim 1 or 2, characterized in that: The first electronic device is further configured to: detecting that the first authentication result is a non-real-time authentication result, measuring the distance of the second electronic device, generating a distance measurement result, and determining a first distance measurement security level of the second electronic device; When the ranging result meets the preset distance requirement, based on the first ranging security level, the first authentication trust level carried in the first authentication result is adjusted to generate the second authentication result, the second authentication result includes a second authentication trust level, and when the second authentication trust level meets the first authentication trust level requirement, the second authentication result indicates that the second electronic device has passed the trusted authentication.

4. The system according to claim 3, characterized in that The first electronic device is further configured to: If the second authentication trust level does not meet the first authentication trust level requirement, sending a user confirmation request to the second electronic device; The second electronic device is further configured to: receiving a user confirmation request from the first electronic device; In response to receiving the user confirmation request, obtaining a confirmation result according to the user operation; Sending the confirmation result to the first electronic device; The first electronic device is further configured to: receiving the confirmation result from the second electronic device; In response to receiving the confirmation result, the second authentication result is determined.

5. The system according to any one of claims 1 to 4, characterized in that: The second electronic device is further configured to: Obtain a user identity authentication pass event, and in the case of being in the carried state, record the user identity authentication pass event through the first list, wherein the user identity authentication pass event comes from the second electronic device or the first electronic device at least one of the devices; When it is determined that the carried state is released, the user identity authentication pass events recorded in the first list are cleared.

6. An authentication method, characterized in that: Applied to a first electronic device, the method includes: In response to a user identity authentication request of a first service in the first electronic device, sending an authentication request to a second electronic device, wherein a short-distance communication connection is established between the first electronic device and the second electronic device, and an authentication trust level supported by the second electronic device meets a first authentication trust level requirement, and the first authentication trust level requirement is a minimum authentication trust level required by the first service; Receiving a first authentication result from the second electronic device, the first authentication result being an authentication result matched by the second electronic device in a first state in a first list, the first list including at least one of a first event or a second event, the first event being a local user identity authentication pass event monitored by the second electronic device, and the second event being a user identity authentication pass event from the first electronic device; A second authentication result is determined based on the first authentication result, wherein the second authentication result indicates whether the second electronic device has passed the trusted authentication.

7. The method according to claim 6, characterized in that The method further comprises: receiving a third authentication result from the second electronic device, where the third authentication result is an authentication result generated by real-time authentication when the second electronic device is in the second state; The second authentication result is determined according to the third authentication result.

8. The method according to claim 6 or 7, characterized in that: Determining a second authentication result according to the first authentication result includes: detecting that the first authentication result is a non-real-time authentication result, measuring the distance of the second electronic device to generate a distance measurement result; When the ranging result meets the preset distance requirement, a first ranging security level of the second electronic device is determined, and based on the first ranging security level, a first authentication trust level carried in the first authentication result is adjusted to determine the second authentication result, wherein the second authentication result includes a second authentication trust level.

9. The method according to claim 8, characterized in that In the case where the second authentication trust level meets the first authentication trust level requirement, the second authentication result indicates that the second electronic device has passed the trusted authentication.

10. The method according to claim 8 or 9, characterized in that: The method further comprises: If the second authentication trust level does not meet the first authentication trust level requirement, sending a user confirmation request to the second electronic device; receiving a confirmation result from the second electronic device, where the confirmation result is a result determined by the second electronic device according to a user operation; In response to receiving the confirmation result, the second authentication result is determined.

11. The method according to claim 10, characterized in that In response to receiving the confirmation result, determining the second authentication result includes: According to the manner of receiving the confirmation result, matching a corresponding second ranging security level; Based on the second ranging security level, the second authentication result is determined.

12. The method according to any one of claims 8 to 11, characterized in that: Adjusting the first authentication trust level carried in the first authentication result based on the first ranging security level includes: Acquire first information, the first information including a security level of a trusted relationship between the first electronic device and the second electronic device, a first state maintenance security level of the second electronic device, a carried state detection security level of the second electronic device, and the first ranging security level; determining a security capability level of the second electronic device according to the first information; When the security capability level is high, the second authentication trust level is equal to the first authentication trust level; When the security capability level is medium, the second authentication trust level is lower than the first authentication trust level; When the security capability level is low, the second authentication trust level is level 0 or level 1.

13. The method according to any one of claims 6 to 12, characterized in that: Before sending an authentication request to the second electronic device in response to the user identity authentication request of the first service in the first electronic device, the method further includes: Sending a trusted holding device adding request to the second electronic device; receiving device information from the second electronic device, the device information being information determined by the second electronic device in response to receiving the trusted device adding request; According to the device information, the second electronic device is added as a trusted holding device.

14. The method according to claim 13, characterized in that The device information includes one or more of the following: identity authentication capability information supported by the second electronic device, ranging methods supported by the second electronic device, security capability level credentials of the second electronic device, and device identity credential information.

15. The method according to any one of claims 6 to 14, characterized in that: The authentication request carries business constraints, which include one or more of the following: the first authentication trust level requirement, the time requirement for confirming user identity, the method requirement for confirming user identity, the device requirement for confirming user identity, an available user confirmation identifier, and a triggerable real-time authentication identifier.

16. The method according to any one of claims 6 to 15, characterized in that: The method further comprises: An event of first user identity authentication passing is detected; Sending the first user identity authentication success event to the second electronic device.

17. An authentication method, characterized in that: Applied to a second electronic device, the method includes: Receiving an authentication request from a first electronic device, wherein a short-distance communication connection is established between the first electronic device and a second electronic device, and an authentication trust level supported by the second electronic device meets a first authentication trust level requirement, and the first authentication trust level requirement is a minimum authentication trust level of a first service to be authenticated by a user in the first electronic device; In the case of being in the first state, a first authentication result corresponding to the authentication request is matched in a first list, the first list includes at least one of a first event or a second event, the first event is a local user identity authentication pass event monitored by the second electronic device, and the second event is a user identity authentication pass event from the first electronic device; The first authentication result is sent to the first electronic device, where the first authentication result is used to generate a second authentication result indicating whether the second electronic device has passed the trusted authentication.

18. The method according to claim 17, characterized in that The method further comprises: When in the second state, perform real-time authentication to generate a third authentication result; The third authentication result is sent to the first electronic device, where the third authentication result is used to generate a second authentication result indicating whether the second electronic device has passed the trusted authentication.

19. The method according to claim 17 or 18, characterized in that The method further comprises: receiving a confirmation request from the first electronic device, the confirmation request being a request sent by the first electronic device to the second electronic device when it is determined that the second authentication trust level does not meet the first authentication trust level requirement, the second authentication trust level being an authentication trust level determined by the first electronic device after adjusting the first authentication trust level carried in the first authentication result; In response to receiving the user confirmation request, obtaining a confirmation result according to the user operation; The confirmation result is sent to the first electronic device, where the confirmation result is used to determine the second authentication result.

20. The method according to any one of claims 17 to 19, characterized in that: Before receiving the authentication request from the first electronic device, the method further includes: Acquire a user identity authentication success event, wherein the user identity authentication success event comes from at least one of the second electronic device or the first electronic device; When in the carried state, the user identity authentication success event is recorded through the first list.

21. The method according to any one of claims 17 to 20, characterized in that: Before receiving the authentication request from the first electronic device, the method further includes: When it is determined that the carried state is released, clearing the user identity authentication passing events recorded in the first list; A first state invalidation notification is sent to the first electronic device, wherein the first state invalidation notification indicates that the second electronic device is in a second state.

22. The method according to any one of claims 17 to 21, characterized in that: Before receiving the authentication request from the first electronic device, the method further includes: receiving a trusted holding device adding request from the first electronic device; Send device information to the first electronic device, where the device information is used to add the second electronic device as a member of the first electronic device. Trusted holding device of the child device; A trusted device adding response is received from the first electronic device, and the device becomes a trusted device of the first electronic device.

23. The method according to claim 22, characterized in that The device information includes one or more of the following: identity authentication capability information supported by the second electronic device, ranging methods supported by the second electronic device, security capability level credentials of the second electronic device, and device identity credential information.

24. The method according to any one of claims 17 to 23, characterized in that: The second electronic device is in a carried state, and the method further includes: In the case of being in the second state, receiving a first user identity authentication success event from the first electronic device, where the first user identity authentication success event is a user identity authentication success event detected by the first electronic device; Switch the second state to the first state.

25. The method according to any one of claims 17 to 24, characterized in that: The authentication request carries business constraints, which include one or more of the following: the first authentication trust level requirement, the time requirement for confirming user identity, the method requirement for confirming user identity, the device requirement for confirming user identity, an available user confirmation identifier, and a triggerable real-time authentication identifier.

26. An electronic device, characterized in that: include: A processor and a memory, wherein the memory is coupled to the processor, the memory is used to store computer program code, the computer program code includes computer instructions, and when the processor reads the computer instructions from the memory, the electronic device executes the method as described in any one of claims 6 to 16; or, the electronic device executes the method as described in any one of claims 17 to 25.

27. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a computer program, and when the computer program is executed on an electronic device, the electronic device executes the method as claimed in any one of claims 6 to 16; or, the electronic device executes the method as claimed in any one of claims 17 to 25.

28. A computer program product, characterized in that When the computer program product is run on a computer, the computer is caused to execute the method according to any one of claims 6 to 25.

Images