Authentication method, electronic device and system

Abstract

This application provides an authentication method, electronic device, and system, relating to the field of terminal technology. This application adaptively completes user authentication by recording user authentication success events in a trusted holding device, improving user convenience. The method includes: a second electronic device receiving an authentication request from a first electronic device with which it has a short-range communication connection, the second electronic device supporting an authentication trust level that meets the first authentication trust level requirements of a first service in the first electronic device for which user authentication is to be performed. In a first state, a first authentication result corresponding to the authentication request is matched against a first list, the first list including user authentication success events generated by the second electronic device or at least one of the first electronic devices. 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 trusted authentication.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to an authentication method, electronic device and system. Background Technology

[0002] To protect device security, some functions of electronic devices require user authentication before use. User authentication includes password authentication, facial recognition, fingerprint recognition, or trusted device authentication. Among these, trusted device authentication allows the electronic device to determine the user's identity based on the trusted status of the device, eliminating the need for direct user operation and improving convenience. For example, if a watch is a trusted device for a mobile phone and is in a trusted authentication state, the watch can directly authorize the phone to unlock when the user wears it near the phone, without requiring a password or facial recognition. Summary of the Invention

[0003] Currently, devices such as watches can be considered trusted holding devices. However, devices such as wristbands and earphones cannot be used as trusted holding devices due to their weaker capabilities and lower security. Furthermore, when the trusted holding device is in an untrusted authentication state or the distance between the trusted holding device and the electronic device exceeds a preset range, the electronic device cannot authenticate the user's identity through the trusted holding device.

[0004] To address the aforementioned technical problems, this application provides an authentication method, electronic device, and system. The technical solution provided by this application adaptively completes user authentication by utilizing user authentication pass events recorded in a trusted holding device and sent by a local or authentication device, thereby improving user convenience.

[0005] To achieve the above-mentioned technical objectives, this application provides the following technical solution:

[0006] Firstly, an authentication method is provided, applied to a second electronic device. The method includes: receiving an authentication request from a first electronic device, wherein a short-range communication connection is established between the first and second electronic devices, 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 of a first service in the first electronic device for which user authentication is to be performed. In a first state, matching a first authentication result corresponding to the authentication request to a first list, the first list including at least one of a first event or a second event, wherein the first event is a local user authentication pass event detected by the second electronic device, and the second event is 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 trusted authentication.

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

[0008] Furthermore, the second electronic device records user authentication success events and returns different authentication results based on the recorded set of authentication events, thereby improving authentication flexibility while ensuring user authentication security.

[0009] Furthermore, while the second electronic device has relatively poor performance, resulting in a lower security level, it can still receive user authentication success events from other devices that correspond to higher authentication trust levels. Based on these recorded user authentication success events, the second electronic device can then determine the authentication result, enabling it to perform user authentication for the first electronic device with relatively high authentication trust requirements, thus enriching the authentication scenarios.

[0010] According to the first aspect, the method further includes: in the second state, performing real-time authentication and generating a third authentication result. The third authentication result is sent to the first electronic device, and this third authentication result is used to generate a second authentication result indicating whether the second electronic device has passed trusted authentication.

[0011] Thus, compared to the prior art, where if the second electronic device is in a second state, the user cannot use the second electronic device to trigger user authentication on the first electronic device and must return to the first electronic device for authentication, making the user operation cumbersome, the authentication method provided in this application allows the second electronic device to authenticate in real time even when it is in a second state. The user only needs to operate the second electronic device at hand to complete the user authentication of the first electronic device, improving user convenience.

[0012] According to the first aspect, or any implementation of the first aspect above, the method further includes: receiving a confirmation request from a first electronic device, wherein the confirmation request is 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 requirements of the first authentication trust level, and the second authentication trust level is 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 a user confirmation request, obtaining a confirmation result based on the user's operation. Sending the confirmation result to the first electronic device, the confirmation result being used to determine the second authentication result.

[0013] Thus, even 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 still be authenticated by the user. Based on the authentication result already determined by the second electronic device and the user's confirmation result, the final authentication result is determined. The user only needs to operate the second electronic device at hand to complete the user identity authentication of the first electronic device, improving the convenience of user use.

[0014] 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: obtaining a user authentication success event, wherein the user authentication success event comes from at least one of the second electronic device or the first electronic device. When in a carried state, the user authentication success event is recorded in a first list.

[0015] 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: if it is determined that the carried state has been removed, clearing the user authentication pass events recorded in the first list; and sending a first state failure notification to the first electronic device, the first state failure notification indicating that the second electronic device is in a second state.

[0016] In some examples, once the carried state is determined to be lifted, the second electronic device does not record the currently acquired user authentication success event and can perform a clearing operation on the list of valid authentication events again, so as to avoid the first list containing user authentication success events recorded in the previous carried state period, which would affect authentication security.

[0017] In this way, the second electronic device can then execute the user authentication process of the first electronic device based on the user authentication success event recorded within a single carried state cycle, thereby improving authentication security.

[0018] Furthermore, when the second electronic device is in a carried state, it can meet the user identity authentication needs of the first electronic device for different authentication trust levels based on the recorded user identity authentication success events corresponding to different authentication trust levels.

[0019] 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 holding 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 holding device of the first electronic device; and receiving a trusted holding device addition response from the first electronic device, confirming that it has become a trusted holding device of the first electronic device.

[0020] 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 authentication through the second electronic device.

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

[0022] 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: in the second state, receiving a first user authentication pass event from the first electronic device, wherein the first user authentication pass event is a user authentication pass event detected by the first electronic device. Switching from the second state to the first state.

[0023] In this way, the second electronic device can flexibly switch between the first and second states by monitoring the carried state and the local user authentication pass event or the user authentication pass event sent by the first electronic device, so as to meet the user authentication needs of the first electronic device in the future.

[0024] According to the first aspect, or any implementation of the first aspect above, the authentication request carries business constraints, which include one or more of the following: first authentication trust level requirements, user identity verification time requirements, user identity verification method requirements, user identity verification device requirements, availability of user verification identifier, and triggering of real-time authentication identifier.

[0025] Secondly, an authentication method is provided, applied to a first electronic device. The method includes: in response to a user authentication request from 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 and second electronic devices, 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; 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 authentication pass event detected by the second electronic device, and the second event being a user authentication pass event from the first electronic device; and determining a second authentication result based on the first authentication result, the second authentication result indicating whether the second electronic device has passed trusted authentication.

[0026] According to the second aspect, the method further includes: receiving a third authentication result from the second electronic device, wherein the third authentication result is an authentication result generated in real time by the second electronic device while it is in a second state; and determining a second authentication result based on the third authentication result.

[0027] According to the second aspect, or any implementation of the second aspect above, determining the 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 distance measurement result. If the distance measurement result meets a preset distance requirement, determining the first distance measurement security level of the second electronic device, and adjusting the first authentication trust level carried in the first authentication result based on the first distance measurement security level, to determine the second authentication result, wherein the second authentication result includes the second authentication trust level.

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

[0029] In this way, the authentication trust level supported by different second electronic devices is assessed according to their different security capability levels, so as to support business operations with different risks, expand the scope of first electronic devices supported by second electronic devices, and ensure the security of the authentication results.

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

[0031] According to the second aspect, or any implementation of the second aspect above, in response to receiving the confirmation result, a second authentication result is determined, including: matching the corresponding second ranging security level according to the method of receiving the confirmation result; and determining the second authentication result based on the second ranging security level.

[0032] Therefore, compared to existing technologies where, if the second electronic device is not within the ranging range, the user cannot use the second electronic device to authorize the first electronic device's user identity authentication and must return to the first electronic device for authentication, making the process cumbersome, the authentication method provided in this application allows the second electronic device to still authenticate with the user even when it is not within the ranging range. Based on the authentication result already determined by the second electronic device and the user's confirmation, the final authentication result is determined. The user only needs to operate the second electronic device at hand to complete the user identity authentication of the first electronic device, improving user convenience.

[0033] According to the second aspect, or any implementation thereof, the first authentication trust level carried in the first authentication result is adjusted based on the first ranging security level, including: obtaining first information, which includes 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.

[0034] 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 authentication request from the first electronic device for the first service, the method further includes: sending a trusted holding 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 holding device addition request; and adding the second electronic device as a trusted holding device based on the device information.

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

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

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

[0038] For the technical effects of the second aspect and any of its implementation methods, please refer to the technical effects of the first aspect and any of its implementation methods mentioned above, which will not be repeated here.

[0039] Thirdly, an electronic device is provided. The electronic device includes a processor and a memory, the memory being coupled to the processor. The memory stores computer program code, which includes computer instructions. When the processor reads the computer instructions from the memory, the electronic device performs the following actions: receiving an authentication request from a first electronic device, wherein a short-range communication connection is established between the first and second electronic devices, 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 for a first service in the first electronic device where user authentication is to be performed. 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 detected 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 trusted authentication.

[0040] According to the third aspect, when the processor reads computer instructions from memory, it also causes the electronic device to perform: in the second state, real-time authentication, generating a third authentication result. The third authentication result is then sent to the first electronic device, and this third authentication result is used to generate a second authentication result indicating whether the second electronic device has passed trusted authentication.

[0041] According to the third aspect, or any implementation thereof, when the processor reads computer instructions from memory, it further causes the electronic device to perform the following: receiving an acknowledgment request from the first electronic device, wherein the acknowledgment request is a request sent by the first electronic device to the second electronic device when it determines that the second authentication trust level does not meet the requirements of the first authentication trust level, and the second authentication trust level is 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 a user acknowledgment request, obtaining an acknowledgment result based on the user's operation; and sending the acknowledgment result to the first electronic device, wherein the acknowledgment result is used to determine the second authentication result.

[0042] According to the third aspect, or any implementation of the third aspect above, when the processor reads computer instructions from memory, it also causes the electronic device to perform: acquiring a user authentication pass event, wherein the user authentication pass event comes from at least one of the second electronic device or the first electronic device. When in a carried state, the user authentication pass event is recorded in a first list.

[0043] According to the third aspect, or any implementation of the third aspect above, when the processor reads computer instructions from memory, it also causes the electronic device to: clear the user authentication pass event recorded in the first list if it is determined that the carried state has been deactivated; and send a first state failure notification to the first electronic device, the first state failure notification indicating that the second electronic device is in the second state.

[0044] According to the third aspect, or any implementation of the third aspect above, when the processor reads computer instructions from memory, it further causes the electronic device to perform the following: receiving a trusted holding 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 holding device of the first electronic device; and receiving a trusted holding device addition response from the first electronic device, thus confirming itself as a trusted holding device of the first electronic device.

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

[0046] According to the third aspect, or any implementation of the third aspect above, the second electronic device is in a carried state. When the processor reads computer instructions from memory, it also causes the electronic device to perform the following: In the second state, receiving a first user authentication pass event from the first electronic device, the first user authentication pass event being a user authentication pass event detected by the first electronic device. Switching from the second state to the first state.

[0047] According to the third aspect, or any of the above implementations of the third aspect, the authentication request carries business constraints, which include one or more of the following: first authentication trust level requirements, user identity verification time requirements, user identity verification method requirements, user identity verification device requirements, availability of user verification identifier, and triggerable real-time authentication identifier.

[0048] For the technical effects of the third aspect and any of its implementation methods, please refer to the technical effects of the first aspect and any of its implementation methods mentioned above, which will not be repeated here.

[0049] Fourthly, an electronic device is provided. The electronic device includes: a processor and a memory, the memory being coupled to the processor. The memory stores computer program code, which includes computer instructions. When the processor reads the computer instructions from the memory, the electronic device performs the following actions: responding to a user authentication request for a first service in a first electronic device, sending an authentication request to a second electronic device, wherein a short-range communication connection is established between the first and second electronic devices, 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. Receiving a first authentication result from the second electronic device, the first authentication result being an authentication result matched in a first list by the second electronic device in a first state, 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 detected by the second electronic device, and the second event being a user authentication pass event from the first electronic device. Based on the first authentication result, determining a second authentication result, the second authentication result indicating whether the second electronic device has passed trusted authentication.

[0050] According to the fourth aspect, when the processor reads computer instructions from memory, it also causes the electronic device to perform the following: receiving a third authentication result from the second electronic device, the third authentication result being an authentication result generated in real time by the second electronic device while it is in the second state. Based on the third authentication result, a second authentication result is determined.

[0051] According to the fourth aspect, or any implementation of the fourth aspect above, the second authentication result is determined based on the first authentication result, including: detecting that the first authentication result is a non-real-time authentication result, measuring the distance of the second electronic device, and generating a distance measurement result. If the distance measurement result meets a preset distance requirement, a 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 determine the second authentication result, wherein the second authentication result includes the second authentication trust level.

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

[0053] According to the fourth aspect, or any implementation of the fourth aspect above, when the processor reads computer instructions from memory, it also causes the electronic device to perform the following: If the second authentication trust level does not meet the requirements of the first authentication trust level, send a user confirmation request to the second electronic device; receive a confirmation result from the second electronic device, the confirmation result being the result determined by the second electronic device based on the user's operation; and, in response to receiving the confirmation result, determine the second authentication result.

[0054] According to the fourth aspect, or any implementation of the fourth aspect above, in response to receiving the confirmation result, a second authentication result is determined, including: matching the corresponding second ranging security level according to the method of receiving the confirmation result; and determining the second authentication result based on the second ranging security level.

[0055] According to the fourth aspect, or any implementation thereof, the first authentication trust level carried in the first authentication result is adjusted based on the first ranging security level, including: obtaining first information, which includes 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.

[0056] According to the fourth aspect, or any implementation of the fourth aspect above, when the processor reads computer instructions from memory, it further causes the electronic device to perform the following: sending a trusted holding 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 holding device addition request; and adding the second electronic device as a trusted holding device based on the device information.

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

[0058] According to the fourth aspect, or any of the above implementations of the fourth aspect, the authentication request carries business constraints, which include one or more of the following: first authentication trust level requirements, user identity verification time requirements, user identity verification method requirements, user identity verification device requirements, availability of user verification identifier, and triggerable real-time authentication identifier.

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

[0060] For the technical effects of the fourth aspect and any of its implementation methods, please refer to the technical effects of the second aspect and any of its implementation methods mentioned above, which will not be repeated here.

[0061] Fifthly, an authentication system is provided, comprising 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 to: in response to a user authentication request for 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 a first authentication trust level requirement, which is the minimum authentication trust level of the first service; receive a first authentication result from the second electronic device; determine a second authentication result based on the first authentication result, the second authentication result indicating whether the second electronic device has passed trusted authentication; and 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 the first list, the first list including at least one of a first event or a second event, wherein the first event is a local user authentication success event detected by the second electronic device, and the second event is a user authentication success event from the first electronic device; and send the first authentication result to the first electronic device.

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

[0063] According to the fifth aspect, or any implementation of the fifth aspect above, the first electronic device is further configured to: detect that the first authentication result is a non-real-time authentication result, measure the distance to 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 includes a second authentication trust level. If the second authentication trust level meets the requirements of the first authentication trust level, the second authentication result indicates that the second electronic device has passed trusted authentication.

[0064] According to the fifth aspect, or any implementation of the fifth aspect above, the first electronic device is further configured to: send a user confirmation request to the second electronic device if the second authentication trust level does not meet the requirements of the first authentication trust level. The second electronic device is further configured to: receive the user confirmation request from the first electronic device; obtain a confirmation result based on the user's operation in response to receiving the user confirmation request; and 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; and determine the second authentication result in response to receiving the confirmation result.

[0065] According to the fifth aspect, or any implementation of the fifth aspect above, the second electronic device is further configured to: acquire a user authentication pass event; and, while in a carried state, record the user authentication pass event in a first list, wherein the user authentication pass event originates from at least one of the second electronic device or the first electronic device. Upon determining that the carried state is to be lifted, clear the user authentication pass event recorded in the first list.

[0066] The technical effects of the fifth aspect and any implementation thereof can be found in the first aspect and any implementation thereof, and will not be repeated here.

[0067] Sixthly, an electronic device is provided, which has the function of implementing the authentication method as described in the first aspect and any of its possible implementations; or, the electronic device has the function of implementing the authentication method as described in the second aspect and any of its possible implementations. This function can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described function.

[0068] The technical effects of the sixth aspect and any implementation thereof can be found in the first aspect and any implementation thereof, and will not be repeated here.

[0069] A seventh aspect provides a computer-readable storage medium. The computer-readable storage medium stores a computer program (also referred to as instructions or code) that, when executed by an electronic device, causes the electronic device to perform the method of the first aspect or any embodiment thereof; or causes the electronic device to perform the method of the second aspect or any embodiment thereof.

[0070] The technical effects of the seventh aspect and any implementation thereof can be found in the first aspect and any implementation thereof, and will not be repeated here.

[0071] Eighthly, a computer program product is provided that, when run on 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 of the eighth aspect and any implementation thereof can be found in the first aspect and any implementation thereof, and will not be repeated here.

[0073] A ninth aspect provides a circuit system including a processing circuit configured to perform the method of the first aspect or any embodiment thereof; or, the processing circuit is configured to perform the method of the second aspect or any embodiment thereof.

[0074] The technical effects of the ninth aspect and any implementation thereof can be found in the first aspect and any implementation thereof, and will not be repeated here.

[0075] In a tenth aspect, a chip system is provided, including at least one processor and at least one interface circuit, wherein the at least one interface circuit is configured to perform transceiver functions and send instructions to the at least one processor, wherein when the at least one processor executes the instructions, the at least one processor performs the method of the first aspect or any embodiment thereof; or, the at least one processor performs the method of the second aspect or any embodiment thereof.

[0076] The technical effects of the tenth aspect and any of its implementations can be found in the first aspect and any of its implementations, and will not be repeated here. Attached Figure Description

[0077] Figure 1 A schematic diagram of an authentication method provided for this application;

[0078] Figure 2 A schematic diagram of the communication system used for the authentication method provided in this application;

[0079] Figure 3 A schematic diagram of the hardware structure of the first electronic device provided in this application;

[0080] Figure 4 A schematic diagram of the software structure of the first electronic device provided in this application;

[0081] Figure 5 A schematic diagram of an authentication method for the trusted holding device addition stage provided in this application;

[0082] Figure 6 Add an interface diagram to the trusted holding device provided in this application;

[0083] Figure 7 A schematic diagram illustrating scenarios where different authentication methods provided in this application trigger different authentication trust levels for the same trusted holding device;

[0084] Figure 8 A schematic diagram illustrating a scenario where multiple trusted holding devices supporting different authentication trust levels can be added to the authentication device provided in this application;

[0085] Figure 9 A schematic diagram of the authentication method for a trusted device maintenance identity authentication success event provided in this application;

[0086] Figure 10 A schematic diagram illustrating a scenario for restoring the trusted state of authentication for a trusted holding device provided in this application;

[0087] Figure 11 A schematic diagram illustrating scenarios of changes in the authentication trust level supported by the trusted holding device provided in this application;

[0088] Figure 12 A schematic diagram of the authentication method process for the trusted holding device authentication stage provided in this application;

[0089] Figure 13 A schematic diagram illustrating a scenario in which the authentication device provided in this application can perform operations based on the authentication trust level supported by the trusted holding device;

[0090] Figure 14 A schematic diagram illustrating the scenario that triggers real-time user authentication provided in this application;

[0091] Figure 15 A schematic diagram illustrating a scenario for seamless user authentication provided in this application;

[0092] Figure 16This application provides a schematic diagram of the scenario that triggers user confirmation. Figure 1 ;

[0093] Figure 17 This application provides a schematic diagram of the scenario that triggers user confirmation. Figure 2 ;

[0094] Figure 18 A schematic diagram of the certification method process provided for this application;

[0095] Figure 19 A schematic diagram of the structure of the first electronic device provided in this application;

[0096] Figure 20 A schematic diagram of the structure of the second electronic device provided in this application. Detailed Implementation

[0097] The technical solutions of the embodiments of this application are described below with reference to the accompanying drawings. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to be a limitation of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include expressions such as “one or more,” unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, “at least one” and “one or more” refer to one or more (including two).

[0098] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized. The term "connection" includes direct connections and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated.

[0099] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0100] In some embodiments, with the development of terminal technology, some electronic devices support user authentication methods based on trusted holding devices. For example, a watch serves as a trusted holding device for a mobile phone. After a user manually unlocks the watch, for a period of time, when the user wears the watch near the phone, the watch's trusted authentication status can directly authorize the phone to unlock, eliminating the need for the user to unlock the phone through password authentication or facial recognition, thus improving user convenience.

[0101] Optionally, the device requiring user authentication can be described as an authentication device, and the device performing user authentication on the authentication device can be described as a trusted holding device. It should be understood that the authentication device can also be described as a device to be authenticated, a device requesting user authentication, etc., and the trusted holding device can also be described as a trusted device, etc. This application embodiment does not limit this, and it will not be described further below.

[0102] For example, such as Figure 1 As shown, before performing user authentication based on a trusted holding device, the authentication device needs to first perform a trusted holding device addition phase. In this phase, the authentication device establishes a trusted relationship with the trusted holding device, enabling the trusted holding device to serve as a valid credential proving the identity of the authentication device's owner (i.e., step 1). For example, the authentication device needs to log in with the same account as the trusted holding device, establish a trusted connection, and the trusted holding device needs to set a password. Afterwards, the authentication device confirms the completion of adding the trusted holding device.

[0103] After adding a trusted holder device to the authentication device, the trusted holder device authentication phase can be performed. Since trusted holder devices are generally portable accessories, such as watches and bracelets, they are easily lost. To prevent other users from using the trusted holder device to authenticate their identity through the authentication device after loss, the trusted holder device needs to verify the user's identity. For example, if the user is holding or wearing the trusted holder device, the trusted holder device is unlocked to confirm that the user holding or wearing the trusted holder device is the owner (i.e., step 2). After the trusted holder device verifies the user's identity, it is in a trusted authentication state. If the trusted holder device cannot verify the user's identity, it is in an untrusted authentication state. When the trusted holder device is in an untrusted authentication state, user identity verification by the authentication device cannot be completed.

[0104] As can be seen, because trusted holding devices only support two states—trusted authentication state and untrusted authentication state—the trusted authentication state is relatively limited and can only support specific business scenarios. For example, when a trusted holding device enters the trusted authentication state, it can support the unlocking service of the authenticated device; when it enters the untrusted authentication state, it cannot support this unlocking service.

[0105] Furthermore, some devices have lower performance and lack password authentication, making them unsuitable as trusted holding devices and impacting user experience. For example, less capable smart bracelets and earphones cannot be considered trusted holding devices.

[0106] 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 state, 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.

[0107] During the user authentication phase, the authentication device queries the trusted holding device's authentication trust status to evaluate the user authentication result (i.e., step 4). For example, if the authentication device finds that the trusted holding device is in an authentication trust status, the user authentication is successful, and the corresponding business can be executed. For instance, if the unlock function triggers the authentication device's user authentication process, the authentication device can be unlocked after successful user authentication. Conversely, if the authentication device determines that the trusted holding device is in an authentication untrust status and cannot execute the corresponding business, the user must perform another user authentication operation on the authentication device, such as entering a password.

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

[0109] As can be seen, users need to hold or wear and unlock the trusted holding device before it can enter the trusted authentication state. Once the user removes the trusted holding device from the holding or wearing state, the trusted holding device will enter the untrusted authentication state. Users need to hold or wear the trusted holding device again and unlock it before it can enter the trusted authentication state again, which is cumbersome for users.

[0110] Furthermore, if the trusted holding device is in an untrusted authentication state, or if the trusted holding device is in a trusted authentication state but the distance between it and the authentication device exceeds a preset range, user authentication by the authentication device cannot be supported. In this case, the user can only use the corresponding functions of the authentication device through operations on the authentication device, affecting the user's experience.

[0111] In addition, some devices have low performance and lack high-precision ranging and wear detection capabilities, making them unsuitable as trusted holding devices.

[0112] Therefore, the authentication method provided in this application embodiment adaptively completes user authentication by using the user authentication pass event recorded in the trusted holding device and sent by the local or authentication device, thereby improving the convenience of user use.

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

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

[0115] Optionally, the second electronic device 200 may be, for example, a trusted holding device that authenticates the user identity of the first electronic device 100. The second electronic device 200 may be, for example, a wearable device (such as a watch, bracelet, or earphone), a mobile phone, tablet computer, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), artificial intelligence (AI) device, or other terminal device. The operating system installed on the second electronic device 200 may include, but is not limited to, […]. Alternatively, other operating systems may be used. This application does not limit the specific type of the second electronic device 200 or the operating system installed on it.

[0116] 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 this connection includes, but is not limited to, at least one of the following: Bluetooth (BT) (e.g., classic Bluetooth or Bluetooth Low Energy (BLE) Bluetooth), wireless local area networks (WLAN) (such as Wireless Fidelity (Wi-Fi) networks), near field communication (NFC), Zigbee, frequency modulation (FM), infrared (IR), etc.

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

[0118] Optionally, the first electronic device 100 and the second electronic device 200 in the embodiments of this application can be implemented by different devices. Different devices can have the same, similar, or somewhat different hardware structures, for example... Figure 3 The hardware structure shown.

[0119] For example, the first electronic device 100 has such Figure 3 Taking the hardware structure shown as an example, for Figure 3 The hardware structure shown will be explained.

[0120] like Figure 3 As shown, 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.

[0121] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the first electronic device 100. In other embodiments of this application, the first electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0122] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0123] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0124] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0125] In some embodiments, the processor 110 may include one or more interfaces. 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, etc.

[0126] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple I2C buses. The processor 110 can couple to a touch sensor, charger, flash, camera 193, etc., through different I2C bus interfaces. For example, the processor 110 can couple to a touch sensor through the I2C interface, enabling the processor 110 and the touch sensor to communicate through the I2C bus interface, thereby realizing the touch function of the first electronic device 100.

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

[0128] USB interface 130 is a USB standard compliant interface, specifically a Mini USB interface, Micro USB interface, USB Type-C interface, etc. USB interface 130 can be used to connect a charger to charge the first electronic device 100, and can also be used for data transfer between the first electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other first electronic devices, such as AR devices.

[0129] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the first electronic device 100. In other embodiments of this application, the first electronic device 100 may also adopt different interface connection methods or a combination of multiple interface connection methods as described in the above embodiments.

[0130] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 receives 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 supply power to the first electronic device via the power management module 141.

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

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

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

[0134] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the first electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0135] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates 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 processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs a sound signal through an audio device or displays an image or video through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0136] The wireless communication module 160 can provide solutions for wireless communication applications on the first electronic device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. 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 antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0137] In some embodiments, antenna 1 of the first electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling the first electronic device 100 to communicate with networks and other devices via wireless communication technology. 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, etc. GNSS can include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), or satellite-based augmentation systems (SBAS).

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

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

[0140] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. 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, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the first electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0141] The external storage interface 120 can be used to connect an external storage card, such as a Micro SD card, to expand the storage capacity of the first electronic device 100. The external storage card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external storage card.

[0142] Internal memory 121 can be used to store executable program code, including instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of the first electronic device 100 (such as audio data, phonebook, etc.). In addition, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, 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 internal memory 121 or instructions stored in memory located in the processor.

[0143] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110. The first electronic device 100 can use the audio module 170 for functions such as music playback and recording. The audio module 170 may include a speaker, receiver, microphone, headphone jack, and application processor to implement audio functions.

[0144] The sensor module 180 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, etc.

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

[0146] Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback.

[0147] Indicator 192 can be an indicator light, which can indicate charging status, power changes, or messages, missed calls, notifications, etc.

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

[0149] The software system of the first electronic device 100 or the second electronic device 200 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses a layered Android system as an example to exemplify the software structure of the first electronic device 100 or the second electronic device 200.

[0150] Figure 4 This is a software structure block diagram of the first electronic device 100 according to an embodiment of this application. The second electronic device 200 may have the same, similar or different software structures.

[0151] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

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

[0153] like Figure 4 As shown, the application package can include applications such as lock screen, calendar, contacts, notes, clipboard, gallery, maps, camera, and video.

[0154] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0155] like Figure 4 As shown, 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, etc.

[0156] 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 this communication channel to ensure the security of subsequent sessions.

[0157] 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 to store device information of the peer device, such as the security capability level of the trusted holding device. A detailed description of the security capability level of the trusted holding device is provided below and will not be repeated here.

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

[0159] Optionally, when an electronic device (such as a first electronic device 100 or a second electronic device 200) is used as an authentication device, it stores information about one or more trusted holding devices through a device trust relationship management module.

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

[0161] 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.

[0162] Optionally, after the addition of the trusted holding device is completed, the trusted holding device (e.g., the second electronic device 200) listens for the local user authentication pass event and records the user authentication pass event through the authentication management module.

[0163] Optionally, after adding the trusted holding device, the authentication device (e.g., the first electronic device 100) sends the user authentication success event to the trusted holding device (e.g., the second electronic device 200) after detecting the user authentication success event on its own end. Correspondingly, the trusted holding device receives the user authentication success event sent by the authentication device and records the user authentication success event through the authentication management module.

[0164] Optionally, during the trusted holding device authentication phase, after receiving an authentication request from the authentication device (e.g., the first electronic device 100), the trusted holding device (e.g., the second electronic device 200) matches a suitable authentication trust level based on the user authentication success event recorded in the authentication management module, and then sends the authentication result to the authentication device. For example, the authentication management module stores user authentication success events where a user unlocks the trusted holding device with a password, and the authentication trust level corresponding to this user authentication success event is ATL3. Then, in subsequent responses to authentication requests, the trusted holding device may match an authentication trust level of ATL3. The specific matching method is described below and will not be repeated here.

[0165] Optionally, during the trusted holding device authentication phase, after the authentication device (e.g., the first electronic device 100) receives the authentication result sent by the trusted holding device (e.g., 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 successful, whether the user needs to confirm again, or whether distance measurement is required.

[0166] In some examples, where the electronic device is a trusted holder, it may also include a security capability level management module. This module assesses its own security capability level, which may be categorized as high, medium, or low. The trusted holder may also send this security capability level to an authentication device for verification.

[0167] Optionally, the security capability level management module may assess the security capability level of a trusted holding device based on one or more of the following: the security level of the trusted relationship between the certified device and the trusted holding device, the security level of trusted status maintenance, the security level of holding status detection, and the security level of ranging. Specific assessment methods are described in detail below and will not be repeated here.

[0168] Optionally, after receiving the authentication result from the trusted holding device, the authentication device can determine whether the authentication trust level carried in the authentication result needs to be corrected based on the security capability level of the trusted holding 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 holding device is medium, then the final authentication trust level of the trusted holding device for this user authentication can be determined to be ATL2, i.e., a downgrade is performed to avoid the authentication result confirmed by the trusted holding device with a low security capability level affecting the reliability of the authentication device's user authentication.

[0169] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0170] Content providers store and retrieve data, making that data accessible to applications. This data can include videos, images, audio, phone calls made and received, browsing history and bookmarks, phone books, and more.

[0171] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0172] The phone manager is used to provide communication functions for the first electronic device 100. For example, it manages call status (including connection, hang-up, etc.).

[0173] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0174] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. The notification manager can also display notifications as icons or scrolling text in the system's top status bar.

[0175] The Android runtime consists of core libraries and a virtual machine. The Android runtime is responsible for scheduling and managing the Android system.

[0176] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0177] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0178] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0179] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0180] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

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

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

[0183] The kernel layer is the layer between hardware and software. The kernel layer includes at least display drivers, camera drivers, audio drivers, sensor drivers, and connectivity drivers. Optionally, the connectivity driver is used to trigger the establishment of a communication connection with the peer device.

[0184] In some embodiments, if an authentication device needs to authenticate a user's identity through a trusted holding device, it needs to first add the electronic device as a trusted holding device. The following describes the process of adding a trusted holding device.

[0185] For example, Figure 5 This is a schematic flowchart illustrating an authentication method for adding a trusted holding device, as provided in an embodiment of this application. It should be noted that this method does not rely on... Figure 5 The specific order described below is a limitation. 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:

[0186] S501, The first electronic device establishes a communication connection with the second electronic device.

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

[0188] In some embodiments, the first electronic device and the second electronic device can establish a mutual trust relationship through various methods such as Bluetooth pairing, Wi-Fi pairing, QR code binding, and logging into the same account. Based on this mutual trust relationship, the first electronic device and the second electronic device can establish a secure communication connection.

[0189] Optionally, the communication connection established between the first electronic device and the second electronic device may be, for example, a Bluetooth connection, a Wi-Fi connection, or other similar connections.

[0190] S502, The first electronic device sends a request to the second electronic device to add the second electronic device.

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

[0192] Optionally, the second electronic device adds a request carrying device information from the first electronic device. This device information may include, for example, the device name, device identifier, device type, and device identity credentials of the first electronic device. The device identity credentials may be, for example, a public key, used to generate a secure key for subsequent communication between the first and second electronic devices.

[0193] For example, such as Figure 6 As shown in interface 601 (a), during the display of the settings interface, the first electronic device detects the user's operation on the biometric and password control 61 and displays as shown in the image. Figure 6 Interface 602 is shown in (b). On interface 602, the first electronic device detects the user's operation on the smart unlock control 62 and displays as shown in (b). Figure 6 Interface 603 is shown in (c). On interface 603, the first electronic device detects the user's operation on the smart unlock switch control 63 and determines that the user has instructed to activate the smart unlock function. When the smart unlock function is activated, the first electronic device detects the user's operation on the add unlock device control 64 and determines that the user has instructed to add a second electronic device. Then, the first electronic device searches for nearby electronic devices with established communication connections and displays as shown in (c). Figure 6 As shown in (d), interface 604 displays the searched electronic devices, such as smartwatches and Bluetooth headsets. Subsequently, if the first electronic device detects user interaction with the smartwatch control 65, it can send a request to the smartwatch corresponding to the smartwatch control 65 to add the smartwatch as a second electronic device.

[0194] S503, the second electronic device determines the device information and generates a security key.

[0195] In some embodiments, the second electronic device parses the received trusted holding 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 of the first electronic device and the security key in a file such as... Figure 4 The device trust relationship management module shown.

[0196] In some embodiments, in response to a received trusted device addition request, the second electronic device generates device information. The second electronic device then encrypts the generated device information using a security key, enabling the encrypted device information to be sent to the first electronic device subsequently, thus ensuring information security.

[0197] Optionally, the device information of the second electronic device may include one or more of the following: the authentication capability information of the second electronic device supported by the second electronic device, such as authentication method and authentication trust level; the ranging method supported by the second electronic device, such as Bluetooth ranging and ultra-wideband (UWB) ranging; the security capability level credentials of the second electronic device, such as device certificate and trusted execution environment (TEE) level key certificate; and device identity credential information, such as public key.

[0198] S504, The second electronic device sends device information to the first electronic device.

[0199] In some embodiments, the second electronic device sends 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.

[0200] S505, the first electronic device completes the addition of the trusted holding device based on the device information.

[0201] In some embodiments, after receiving device information from the second electronic device, the first electronic device decrypts the device information and then, through methods such as... Figure 4 The device trust relationship management module shown stores the decrypted device information of the second electronic device and completes the addition of the trusted holding device, that is, the first electronic device adds the second electronic device as its trusted holding device.

[0202] In this way, by authenticating the device through the above steps, a trusted holding device can be added. Subsequently, trusted services, such as unlocking, can be performed through the trusted holding device.

[0203] The following section uses the example of a first electronic device as an authentication device serving as a client and a second electronic device as a trusted holding device serving as a server to provide a detailed description of the authentication method provided in this application.

[0204] In some embodiments, to protect device security, certain services of electronic devices require user authentication before use. User authentication methods include password authentication, facial recognition, fingerprint recognition, and voiceprint recognition. For example, a user enters a password on the phone's lock screen to unlock the phone.

[0205] Optionally, different user authentication methods differ in their accuracy in identifying users, the difficulty of the algorithm being fooled by non-human entities, and the ease with which the provided authentication results can be maliciously modified. Therefore, the authentication credibility levels of the authentication results determined by different user authentication methods differ.

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

[0207] As shown in Table 1, the authentication trust levels include five levels: ATL4, ATL3, ATL2, ATL1, and ATL0, with the trust levels decreasing sequentially. For example, ATL4 > ATL3 > ATL2 > ATL1 > ATL0.

[0208] For example, as shown in Table 1, electronic devices can accurately identify individual users with 100% accuracy, or have strong liveness detection capabilities. For instance, in typical financial transaction scenarios, electronic devices use a secure keyboard with a personal identification number (PIN) for authentication. After successful user authentication, the authentication trust level is ATL4.

[0209] Table 1

[0210]

[0211] In some embodiments, the authentication device can add one or more trusted holding devices through steps S501-S505 described above. Different trusted holding devices may support the same or different maximum authentication trust levels. Therefore, the scope of operations that the authentication device can perform based on the trusted holding devices may be the same or different.

[0212] For example, a trusted holding device can listen for local user authentication success events and also acquire user authentication success events sent by the authentication device. These user authentication success events can be determined based on different authentication methods. As shown in Table 1, the trusted holding device can acquire the same or different authentication trust levels, enabling it to support different authentication trust levels. Therefore, the scope of operations that an authentication device can perform based on the same trusted holding device's supported authentication trust level can differ, and the scope of operations that can be performed based on different trusted holding devices' supported authentication trust levels can be the same or different. This scope includes the highest authentication trust level supported by the trusted holding device and operations in business scenarios corresponding to authentication trust levels below that highest level.

[0213] For example, such as Figure 7As shown in (a), the watch, as a trusted holding device of the mobile phone, supports a maximum authentication trust level of ATL2 when the watch screen is not locked. Based on the highest authentication trust level and trusted holding status supported by the watch, the mobile phone can perform business scenarios corresponding to ATL2 and ATL1 as shown in Table 1, such as general personal data queries. For example, when the watch is being worn, if a local user authentication pass event is detected (e.g., the user's PPG signal is detected, confirming that the user currently wearing the watch is the owner), the authentication trust level corresponding to this user authentication pass event is obtained as ATL2. Therefore, the subsequent operations that the mobile phone can perform include operations in business scenarios corresponding to authentication trust levels of ATL2 and below.

[0214] like Figure 7 As shown in (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 possession status supported by the watch, the mobile phone can perform business scenarios corresponding to ATL3, ATL2, and ATL1 as shown in Table 1, such as screen unlocking. For example, when the watch is being worn, if the monitored local user authentication event allows the user to enter the correct lock screen password to unlock the watch, the authentication trust level corresponding to this user authentication event is determined to be ATL3. Therefore, the subsequent operations that the mobile phone can perform include those corresponding to ATL3 and lower authentication trust levels in business scenarios.

[0215] For example, such as Figure 8 As shown, the trusted holding devices added to the mobile phone include Bluetooth headsets, wristbands, and watches. Specifically, the Bluetooth headset currently authorizes operations in business scenarios corresponding to authentication trust levels of ATL1 and below; the wristband currently authorizes operations in business scenarios corresponding to authentication trust levels of ATL2 and below; and the watch currently authorizes operations in business scenarios corresponding to authentication trust levels of ATL3 and below. Therefore, the mobile phone, through its connected trusted holding devices, can perform operations within the scope of business scenarios corresponding to authentication trust levels of ATL3 and below.

[0216] In some embodiments, after adding a trusted holder device, the authentication device may enter the trusted holder device authentication phase. During the trusted holder device authentication phase, the trusted holder device performs user authentication in response to an authentication request received from the authentication device.

[0217] As mentioned above, the authentication trust levels corresponding to different authentication methods may be the same or different. Therefore, after adding a trusted holder device to the authentication device, the trusted holder device can listen for at least one of the following: a user authentication success event is passed locally, or a user authentication success event is passed sent by the authentication device. It can maintain these user authentication success events. Thus, when the trusted holder device responds to an authentication request and performs user authentication, it can determine whether the user's identity can be successfully verified based on the recorded user authentication success events.

[0218] For example, if the target authentication trust level corresponding to the authentication request is ATL2, the trusted holding device in the authentication trust state can determine that the user authentication is successful by determining that the user authentication is successful if the recorded user authentication success events include user authentication success events of ATL2 or higher.

[0219] The following describes the process by which the trusted holding device maintains identity authentication through events during the authentication phase of the trusted holding device.

[0220] For example, Figure 9 This is a schematic flowchart illustrating an authentication method for a trusted holding device maintenance identity authentication success event, provided in an embodiment of this application. It should be noted that this method does not rely on... Figure 9 The specific order described below is a limitation. 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:

[0221] S901a, Trusted Holding Device determines the authentication device and initiates authentication.

[0222] S901b, The trusted holding device determines that it has been added as a trusted holding device by an already certified device.

[0223] In some embodiments, after the authentication device completes the addition of the trusted holder device, it may send a notification to the trusted holder device to indicate that it has become a trusted holder device of the authentication device.

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

[0225] S902. The authentication device detects a user authentication success event and sends the user authentication success event to trusted holding devices within a preset range.

[0226] S903, Trusted Holding Device listens for user authentication success events.

[0227] Among them, the user authentication pass event listened to by the trusted holding device includes at least one of the following: a user authentication pass event that occurs locally or a user authentication pass event sent by the authentication device.

[0228] In some embodiments, after determining that the authentication device has initiated authentication, or after determining that it has become the trusted holder of the authentication device, the trusted holder device may begin to acquire user authentication success events. These user authentication success events can be acquired through methods such as local monitoring or authentication device synchronization.

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

[0230] In other examples, a trusted holding device may also listen for user authentication pass events sent by at least one of the local or certified devices, once it has determined that it is in a holding or wearing state.

[0231] Optionally, step S902 above is optional, meaning the trusted holding device may not receive the user authentication pass event sent by the authentication device, but only listen for the user authentication pass event generated locally.

[0232] S904. The trusted holding device is in a holding or wearing state. If yes, proceed to S905; otherwise, proceed to S907.

[0233] In some embodiments, while listening to local user authentication success events, the trusted holding device also listens to its own holding or wearing status. If it determines that it is in a holding or wearing state, it records the acquired user authentication success event, i.e., executes step S905 below. After determining that it has released its holding or wearing state, i.e., switched to a non-holding or non-wearing state, it can clear the recorded user authentication success events, i.e., execute step S907 below.

[0234] Optionally, the trusted holding device records the user authentication success events it has listened to through a list of valid authentication events.

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

[0236] It should be understood that this application embodiment uses the presence or absence of a trusted holding device in a held or worn state as an example to determine whether to record a user authentication success event. However, when the form of the trusted holding device differs, the user may also carry the trusted holding device in other ways. Therefore, when the user carries the trusted holding device in other ways, the trusted holding device is in a carried state, and the trusted holding device can also record a user authentication success event; conversely, when the user releases the trusted holding device from the carried state, the trusted holding device may no longer record user authentication success events and clear the already recorded user authentication success events. That is, the trusted holding device determines whether it needs to record the monitored user authentication success event by judging whether it is in a carried state (such as whether it is held or worn), which will not be elaborated further below.

[0237] S905, Trusted Holding Device records user identity authentication success events.

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

[0239] For example, when a trusted holding device is held or worn, it records user authentication events that occur locally. For instance, in response to a user entering a password, the trusted holding device verifies the password and unlocks the device. As shown in Table 1, the authentication trust level corresponding to the screen unlock scenario is ATL3. Then, as shown in Table 2, the trusted holding device records this successful user authentication event in the list of valid authentication events, including information such as the authentication method, authentication trust level, authentication success time, and authentication execution device.

[0240] For example, after adding a trusted holder device, the authentication device can detect a successful user authentication event and send the event to trusted holder devices within a preset range. Correspondingly, the trusted holder device receives the successful user authentication event sent by the authentication device and records it if it determines that it is in a holding or wearing state. For instance, as shown in Table 2, a trusted holder device can act as a trusted holder device for one or more authentication devices. Therefore, the trusted holder device can obtain and record successful user authentication events sent by one or more authentication devices. For example, after Client1 completes user authentication via fingerprint, it sends the corresponding successful user authentication event to the trusted holder device. Similarly, after Client2 completes user authentication via voiceprint, it sends the corresponding successful user authentication event to the trusted holder device.

[0241] Table 2

[0242] 1 Password authentication ATL3 8:00 local 2 PPG Certification ATL1 16:20 local 3 Fingerprint authentication ATL3 16:00 Client1 device 4 Voiceprint authentication ATL2 15:30 Client2 device 5 … … … …

[0243] In some embodiments, the user authentication success events recorded by the trusted holding device in the list of valid authentication events include the corresponding authentication trust level. Subsequently, during the user authentication process of the authentication device, the trusted holding device can determine whether its authentication requirements are met based on this authentication trust level. For example, if the target authentication trust level of the authentication device is ATL4, but as shown in Table 2, the highest authentication trust level recorded by the trusted holding device for user authentication success events is ATL3, then the highest authentication trust level supported by the trusted holding device is ATL3, which does not meet the ATL4 requirement, meaning the user authentication request cannot be passed.

[0244] In this way, trusted holding devices can record user authentication success events and return different authentication results based on the set of recorded authentication events, thereby improving authentication flexibility while ensuring user authentication security.

[0245] S906. Trusted holding devices determine whether they are released from holding or wearing status.

[0246] S907, Trusted Holding Device clears recorded user authentication pass events.

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

[0248] In some embodiments, after the trusted holding device determines that it has released itself from the holding or wearing state, it clears the recorded user authentication success events. Subsequently, the trusted holding device determines that it is in the holding or wearing state again before recording user authentication success events. That is, in response to a change in the holding or wearing state of the trusted holding device, the trusted holding device clears user authentication success events or triggers the start of recording user authentication success events.

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

[0250] In this way, the trusted holding device can then execute the user authentication process based on the user authentication success event recorded within a single holding or wearing state cycle, thereby improving authentication security.

[0251] S908. The trusted holder device sends an indication of a change in the trusted status of authentication to the authentication device.

[0252] In some embodiments, the authentication trust status changes accordingly after the trusted holding device changes its holding or wearing state. For example, the trusted holding device is in an authentication trust state when it is in a holding or wearing state and the list of valid authentication events is not empty. The trusted holding device is in an authentication untrust state when it is de-holding or wearing or when the list of valid authentication events is empty. After determining that it has changed from an authentication trust state to an authentication untrust state, or from an authentication untrust state to an authentication trust state, the trusted holding device sends an authentication trust status change indication to the authentication device to indicate the change in its authentication status. Correspondingly, after receiving the status change indication, the authentication device saves the authentication status 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 trust state based on the saved authentication status of one or more trusted holding devices.

[0253] Optionally, the authentication trust status change indication includes an authentication trust status failure indication that indicates the trusted holding device to switch to an authentication untrusted state, and an authentication trust status validity indication that indicates the trusted holding device to switch to an authentication trust state.

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

[0255] In this way, a trusted holding device in a trusted authentication state listens for and records user authentication success events sent by at least one of the local or authentication devices. Subsequently, based on the recorded content, user authentication is flexibly performed to meet the user's needs.

[0256] Furthermore, while the trusted holding device itself has relatively poor performance, resulting in a lower level of security, it can still receive user authentication success events from other devices that correspond to higher authentication trust levels. Subsequently, based on the recorded user authentication success events, the trusted holding device determines the authentication result, enabling a trusted holding device with poor performance to complete user authentication for devices with relatively high authentication trust levels, thereby enriching authentication scenarios.

[0257] In some embodiments, steps S904-S908 are cyclical steps. The trusted holding device determines whether it needs to record user authentication success events 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 can return to step S904. If it determines that it has switched back to the holding or wearing state, it can start recording the acquired user authentication success events. After confirming again that it has released the holding or wearing state, it clears the user authentication success events recorded in the current holding or wearing state cycle.

[0258] For example, such as Figure 10 As shown in (a), after the user removes the watch, the watch determines that it has been released from holding or wearing and is in an untrusted authentication state. As a trusted holding device, the watch can send an authentication trust status failure indication to the corresponding authentication device (such as a mobile phone) to instruct the trusted holding device to switch to an untrusted authentication state.

[0259] After that, as Figure 10 As shown in (b), after the user puts the watch back on and unlocks it, and the watch confirms that it is back in a trusted authentication state, it can send a valid trusted authentication state indication to the mobile phone to indicate that the trusted holding device has switched to a trusted authentication state.

[0260] Or, such as Figure 10 As shown in (c), after the user puts the watch back on, if the mobile phone detects the user's operation and confirms that the user's identity authentication is successful, the watch can obtain the user identity authentication successful event sent by the mobile phone. After the watch determines that it is back in the authentication trusted state, it can send an authentication trusted state valid indication to the mobile phone to indicate that the trusted holding device switches to the authentication trusted state.

[0261] Once the watch is switched to a held or worn state, it can continuously monitor at least one user authentication pass event sent by a local or authenticated device, switch from an untrusted authentication state to a trusted authentication state based on the obtained user authentication pass event, and record the obtained user authentication pass event.

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

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

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

[0265] In this way, when the trusted holding device is in a holding or wearing state, the user identity authentication pass event corresponding to different authentication trust levels can meet the user identity authentication needs of different authentication trust levels of the authentication device.

[0266] The following describes the authentication process of a trusted holding device, which is based on the identity authentication maintained by the trusted holding device and executes the authentication process through events during the authentication phase of the trusted holding device.

[0267] For example, Figure 12 This is a schematic flowchart illustrating a trusted holding device authentication method during the authentication phase, as provided in an embodiment of this application. It should be noted that this method does not rely on... Figure 12 The specific order described below is a limitation. 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 holder device.

[0269] In some embodiments, in response to a user action, after determining that user authentication has been triggered, the authentication device may send an authentication request to a paired trusted holding device to determine the 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 unlocking function in the authentication device detects a user's unlocking operation and determines that user authentication is triggered, and the authentication trust level requirement for the unlocking function is ATL3, then the authentication device will iterate through the authentication trust levels supported by its paired trusted holding devices and send authentication requests to trusted holding devices with a highest supported authentication trust level of ATL3 or higher.

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

[0273] After that, as Figure 13 As shown in (b), the mobile phone determines that the watch is in an untrusted authentication state in response to a received authentication trust status invalidation indication from the watch, or the mobile phone determines to disconnect from the watch. Therefore, the mobile phone can perform operations at a risk level that matches the authentication trust level ATL2.

[0274] In the above Figure 13 In the scenario shown, the mobile phone can determine the target authentication trust level based on 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 authentication requires a trusted holding device, the service can generate service constraints that indicate the requirements for the service currently requiring user authentication. These constraints may include one or more of the following: authentication trust level requirements, user authentication time requirements, user authentication method requirements, user authentication device requirements, availability of user verification identifiers, and the ability to trigger real-time authentication identifiers.

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

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

[0278] The user identity verification time requirement indicates the time required for a valid user identity authentication success event to occur. For example, by using the user identity verification time requirement, the authentication device instructs the trusted holder device to determine the authentication result based on user identity authentication success events recorded in the list of valid authentication events that occurred within the past 4 hours.

[0279] The user identity verification method requirement indicates the method required for verifying user identity for a user authentication success event that matches the current user authentication result. For example, the user identity verification method could include biometric authentication or non-biometric authentication. For instance, by specifying the user identity verification method requirement, the authentication device instructs the trusted holding device to determine the authentication result based on a user authentication success event generated through non-biometric authentication recorded in the list of valid authentication events.

[0280] The device requirement for verifying user identity indicates the requirements for the device that generated the user authentication success event. For example, the user authentication success event recorded in the list of valid authentication events may be a user authentication success event generated locally by the trusted holding device or a user authentication success event notified by other devices. For instance, the authentication device, by verifying the user identity, instructs the trusted holding device to determine the authentication result based on the user authentication success event generated locally by the trusted holding device recorded in the list of valid authentication events.

[0281] A user confirmation identifier can be used to indicate whether user confirmation is required. For example, if a service determines that the authentication result requires user confirmation to ensure security, a user confirmation identifier can be added to the generated service constraints. Subsequently, during the user authentication process, the authentication device sends a user confirmation request to the trusted holder device based on this user confirmation identifier.

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

[0283] S1202. The trusted holding device is in an authenticated trusted state. If yes, proceed to step S1204; otherwise, proceed to step S1203.

[0284] In some embodiments, when a trusted holding device receives an authentication request from an authentication device, it indicates that the trusted holding device is within the communication range of the authentication device. The trusted holding device being in an authenticated trusted state indicates that the trusted holding device is held or worn by a user. Therefore, after receiving the authentication request and determining that it is in an authenticated trusted state, the trusted holding device can determine that its owner is within the communication distance range between the authentication device and the trusted holding device. This ensures the security of the authentication result determined by the trusted holding device. The trusted holding device can then execute the following step S1204 to determine the authentication result.

[0285] Conversely, 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 can trigger real-time authentication, i.e., execute the following step S1203.

[0286] S1203, Trusted holding device triggers real-time authentication.

[0287] In some embodiments, upon receiving an authentication request, the trusted holding device determines that it is in an untrusted authentication state. Then, the trusted holding device can determine whether to trigger real-time authentication for the user based on a real-time authentication trigger identifier carried in the authentication request. If the trusted holding device determines that the authentication request carries a real-time authentication trigger identifier, then real-time authentication for the user can be triggered, and the trusted holding device can execute the real-time authentication process. Optionally, before triggering real-time authentication for the user, the trusted holding device first determines whether it supports real-time authentication. If it supports real-time authentication, the trusted holding device can execute the real-time authentication process.

[0288] Optionally, real-time authentication methods include prompting the user to enter a password, facial recognition, fingerprint recognition, voiceprint recognition, and other methods. The trusted device can determine the authentication method used during real-time authentication based on its supported authentication methods and the target authentication trust level. For example, the trusted device displays an authentication interface, receives the password entered by the user, and then determines the real-time authentication result.

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

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

[0291] In some embodiments, after a trusted holding device triggers and successfully completes real-time authentication, it switches to an authenticated trusted state. If the trusted holding device is currently in a held or worn state, it can record the successful user authentication event for this real-time authentication through a list of valid authentication events.

[0292] Therefore, compared to existing technologies where, if the trusted holding device is in an untrusted authentication state, the user cannot trigger user authentication using the trusted holding device and must return to the authentication device for authentication, resulting in cumbersome user operations, the authentication method provided in this application allows the trusted holding device to trigger real-time user authentication even when it is in an untrusted authentication state. The user only needs to operate the trusted holding device at hand to complete user authentication, improving user convenience.

[0293] S1204. The trusted holding device matches the corresponding authentication result in the list of valid authentication events. If yes, proceed to step S1205; otherwise, proceed to step S1203.

[0294] In some embodiments, in response to an authentication request sent by an authentication device, a trusted holding device in a trusted authentication state obtains a stored list of valid authentication events. Then, the trusted holding device can match user authentication success events that meet the business constraints carried in the authentication request, such as authentication trust level requirements, user identity verification time requirements, user identity verification method requirements, and user identity verification device requirements, from the list of valid authentication events to determine the authentication result. If a user authentication event that meets the business constraints is matched, the authentication trust level corresponding to that user authentication can be determined, and the authentication result is authentication success, carrying that authentication trust level.

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

[0296] Scenario 1: The unlocking function of the authentication device triggers the authentication process. The authentication request carries the following requirements: authentication trust level requirement is ATL3, user identity verification time requirement is within 4 hours (e.g., current time is 16:30), user identity verification method is unrestricted, and the device used for user identity verification is unrestricted. Accordingly, the trusted holding device responds to the received authentication request by matching a user identity verification success event that meets the requirements from the list of valid authentication events shown in Table 2. For example, the trusted holding device matches the user identity verification events that meet the authentication trust level requirements as the user identity verification events in records 1 and 3. The authentication success time in the user identity verification event in record 1 does not meet the user identity verification time requirement. Therefore, the trusted holding device determines that the matched user identity verification success event is the user identity verification success event in record 3, generates the corresponding authentication result as "authentication successful," and carries the authentication trust level as ATL3.

[0297] Scenario 2: The unlocking function of the app store application in the authentication device triggers the authentication process. The authentication request carries the following requirements: authentication trust level requirement is ATL2, user identity verification time requirement is within 10 minutes (e.g., current time is 16:30), user identity verification method is unrestricted, and user identity verification device requirement is unrestricted. Accordingly, the trusted holding device responds to the received authentication request by matching a user identity verification success event that meets the requirements in the list of valid authentication events shown in Table 2. For example, if the trusted holding device fails to match a user identity verification success event that meets the user identity verification time requirement, the authentication result is determined to be unsuccessful.

[0298] In some embodiments, if the trusted holding device determines that no corresponding authentication pass event is matched in the list of valid authentication events, it may determine to trigger real-time authentication, i.e., perform the above step S1203. Optionally, the trusted holding device may determine whether real-time authentication can be triggered based on a real-time authentication trigger 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 means of table lookup (as described in step S1204 above) or real-time authentication (as described in step S1203 above), the trusted holding device may send the determined authentication result to the authentication device.

[0301] Optionally, the trusted holding device can be accessed via, for example... Figure 5 The security key determined in step S503 is used to encrypt the authentication result and then sent to the authentication device.

[0302] For example, in steps S1201-S1205 above, as follows Figure 14As shown, the target authentication trust level of the authentication device is ATL3, as indicated by the authentication request (i.e., step S1201). Correspondingly, after receiving the authentication request from the authentication device, if the trusted holding device determines that it is in an untrusted authentication state (i.e., step S1202), or if the authentication trust level indicated by the determined user 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, such as password authentication, based on the target authentication trust level ATL3. The trusted holding device displays the authentication interface, showing a password input window and receiving the password entered by the user. If the trusted holding device determines the password is correct, it can determine the authentication result as successful and carry the corresponding authentication trust level as ATL3. Alternatively, if the trusted holding device determines the password is incorrect, it can determine the authentication result as unsuccessful. Afterwards, the trusted holding device can send the authentication result encrypted with a security key to the authentication device (i.e., step S1205).

[0303] S1206. The authentication device determines that the authentication result is a real-time authentication result. If yes, proceed to S1207; otherwise, proceed to S1208.

[0304] In some embodiments, after receiving the authentication result, the authentication device can 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 holding device are within a nearby communicable range, the user can know and control this authentication process, and the reliability of the authentication result is high. Therefore, the authentication device can directly determine the final authentication result, i.e., execute the following step S1207. If the authentication result is a non-real-time authentication result, such as the authentication result being determined by the trusted holding device through a lookup table, then to ensure the reliability of the authentication result, the authentication device can further verify the distance measurement of the trusted holding device to determine whether the distance measurement result and the distance measurement security level of the trusted holding device meet the requirements, i.e., execute the following step S1208.

[0305] S1207. The certification device determines the final certification result based on the obtained certification results.

[0306] In some embodiments, after receiving an authentication result, the authentication device determines whether the authentication result is successful. If the authentication result is unsuccessful, the authentication device may prompt the user to use other methods for user authentication. If the authentication result is successful, the authentication device may obtain the authentication trust level carried therein and further evaluate and confirm the authentication trust level.

[0307] For example, if a trusted holding device records user authentication success events that also include those sent by other devices, then some trusted holding devices with lower security capabilities might return authentication results with higher authentication trust levels. Therefore, the authentication device needs to re-evaluate the authentication results to ensure the reliability of the final authentication outcome.

[0308] In some embodiments, different trusted holding devices have different security capability levels, and the security capability level of a trusted holding device affects the authentication trust level determined by that trusted holding device. Optionally, the security capability level of a trusted holding device is divided into three levels: high, medium, and low. For example, when the security capability level of a trusted holding device is low, it may cause the determined authentication trust level to be downgraded, thereby further ensuring the reliability of the final authentication result.

[0309] In some examples, when the authentication result is not real-time, 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 is equal to 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 is equal to 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 lower than medium (such as low or even lower), the authentication trust level in the final authentication result determined by the authentication device is equal to ATL0 to 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 is equal to 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 is equal to 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 lower than medium (such as low or even lower), the authentication trust level in the final authentication result determined by the authentication device is equal to ATL0 to 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 one in step S1204 above, the authentication trust level carried in the authentication result sent by the trusted holding device received by the authentication device is ATL3. In this scenario one, the authentication trust level requirement carried in the authentication request is ATL3, that is, the target authentication trust level of the authentication device is ATL3.

[0312] For example, if the authentication device determines that the trusted holder device has a high security capability level, then the authentication device determines the final authentication trust level in the authentication result to be ATL3. If the authentication device determines that this authentication trust level meets the target authentication trust level requirements, it can trigger unlocking.

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

[0314] In some embodiments, the authentication device may verify the security capability level of the trusted holder device based on the following: the security level of the trusted relationship between the authentication device and the trusted holder device, the security level of maintaining the trusted authentication status, the security level of detecting the holding or wearing status, and the ranging security level. Optionally, the specific requirements for each item can be found in Table 3. It should be understood that the content shown in Table 3 is only illustrative and may include more or fewer items than those shown in Table 3 in actual application scenarios.

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

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

[0317] The authentication trusted state maintenance security level indicates the trusted holding device's ability to maintain a list of valid authentication events. A higher authentication trusted state maintenance security level for the trusted holding device indicates better application isolation, which reduces the likelihood of malicious modification of user authentication pass events in the list of valid authentication events maintained by the trusted holding device, thus enhancing its ability to maintain the list of valid authentication events.

[0318] The security level of possession or wearing status detection indicates the trusted holding device's ability to detect whether it is being held or worn. The more accurately the trusted holding device detects its own possession or wearing status, the lower the likelihood that the holding user entity will be switched without the trusted holding device's knowledge after user identity verification. When the owner is present, the risks of business operations performed based on the trusted device's definitive authentication result are more controllable.

[0319] The distance measurement security level indicates the capability to detect the distance between the authentication device and the trusted holding device. The more accurate the distance detection between the authentication device and the trusted holding device, the more controllable the risk of business operations performed based on the authentication results determined by the trusted holding device when the owner is present.

[0320] Optionally, ranging is used to ensure that when the authentication device uses the authentication result from the trusted holding device, the user is within the authentication device's vicinity, and the corresponding business operations are as transparent and controllable as possible. Prompting the user to manually confirm on the trusted holding device side achieves this purpose more reliably. Therefore, the user's manual confirmation can replace the requirement for a ranging security level. For example, as shown in Table 4, if 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., steps S1208-S1211 below) to obtain the user confirmation result. Afterwards, the authentication device matches the corresponding ranging security level according to the user's manual confirmation requirements shown in Table 4, and reconfirms the final authentication result. The specific user confirmation method is detailed in steps S1208-S1211 below and will not be repeated here.

[0321] Table 3

[0322]

[0323] Table 4

[0324]

[0325] In this way, the authentication trust level supported by different trusted holding devices is assessed according to the different security capability levels of trusted holding devices, so as to support business operations with different risks, expand the scope of authentication devices supported by trusted holding devices, and ensure the security of the authentication results.

[0326] Furthermore, the methods for trusted holding devices to enter the authenticated trusted state have been expanded. Based on the authentication method used by the trusted holding device to enter the authenticated trusted state and the corresponding authentication trust level, the final authentication result and authentication trust level of the trusted holding device are evaluated in conjunction with the authentication requirements indicated in the authentication request and the security capability level of the trusted holding device. This simplifies the user experience by eliminating the need for manual user intervention to allow the trusted holding device to enter the authenticated trusted state. Moreover, the ability to provide authentication results with different authentication trust levels according to business needs expands the supported business scope.

[0327] In other embodiments, after determining the authentication result, the trusted holding device can directly evaluate the authentication result based on its own security capability level, determine the final authentication result, and then directly send the final authentication result to the authentication device. In this case, the authentication device does not need to evaluate the obtained authentication result based on the trusted holding device's security capability level again. Specifically, during the authentication result evaluation process, the trusted holding device can determine the ranging security level based on the ranging capabilities of both the authentication device and the trusted holding device. Alternatively, the trusted holding device can directly send its own security capability level to the authentication device, and the authentication device can directly evaluate the authentication result based on the obtained security capability level without needing to reconfirm the trusted holding device's security capability level.

[0328] S1208. The certification equipment confirms that the ranging results and ranging safety level meet the requirements. If yes, proceed to S1207; otherwise, proceed to S1209.

[0329] In some embodiments, after determining that the authentication result sent by the trusted holding device is a non-real-time authentication result, the authentication device may trigger ranging to obtain the ranging result in order to further reduce the risk of the operator being unaware of or unable to control the process. For example, based on the ranging result, the authentication device can determine that the trusted holding device is within a preset distance range, and thus determine that the ranging result meets the requirements.

[0330] In some examples, the ranging results meet the requirements, but the ranging security level of the trusted holding device does not, which may also prevent the user authentication from passing. Therefore, the authentication device can reconfirm the ranging security level of the trusted holding device to determine whether the authentication trust level corresponding to the ranging security level meets the target authentication trust level requirements.

[0331] 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 holding device based on the ranging security level, and consequently 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 holding 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. That is, if the requirements are met, the final authentication result can be obtained, i.e., step S1207 above is executed; if the requirements are not met, user confirmation can be triggered, i.e., step S1209 below is executed.

[0332] For example, such as Figure 15 As shown, in response to a user's action, the authentication device triggers user authentication by sending an authentication request to a trusted holding device. The trusted holding device, in a trusted authentication state, can directly match the corresponding authentication result against the list of valid authentication events and send that result to the authentication device. Subsequently, the authentication device performs ranging based on this result and determines that the ranging result and the authentication trust level corresponding to the ranging security level meet the target authentication trust level requirements, thus confirming successful user authentication. Therefore, in this process, user authentication is completed without the user's awareness, thereby improving user convenience while meeting security requirements.

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

[0334] S1209. The authentication device sends a user confirmation request to the trusted holder device.

[0335] 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 may send a user confirmation request to the trusted holding device to obtain a user confirmation result. Correspondingly, the trusted holding device receives the user confirmation request sent by the authentication device.

[0336] Optionally, the authentication device may determine whether to send a user confirmation request to the trusted holding device based on whether the service constraints include a usable user confirmation identifier. For example, the authentication device may send a user confirmation request to the trusted holding device based on whether the service constraints include a usable user confirmation identifier.

[0337] Optionally, if the business constraints do not include the availability of a user confirmation identifier, or if the availability of a user confirmation identifier indicates that user confirmation cannot be triggered, then the user authentication fails.

[0338] S1210, The trusted holding device displays a confirmation interface and obtains the confirmation result.

[0339] In some embodiments, the trusted holding device responds to a received user confirmation request by displaying a confirmation interface to obtain the user confirmation result.

[0340] Optionally, the trusted holding device displays a prompt message to allow the user to confirm the authentication result determined by the authentication device. Optionally, the trusted holding device detects user actions such as clicking a confirmation control or double-clicking the display screen on the display interface to confirm the received user confirmation result.

[0341] S1211. The trusted holding device sends an acknowledgment result to the certified device.

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

[0343] For example, such as Figure 16 As shown, the authentication device sends an authentication request to the trusted holder device, requesting a target authentication trust level of ATL2 (i.e., step ①). The trusted holder device determines the authentication trust level as ATL2 based on the list of valid authentication events and sends the corresponding authentication result back to the authentication device (i.e., step ②). 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, if the authentication device determines the security capability level of the authentication device based on the ranging security level to be medium, then... Figure 16As shown, the ranging level determined by the authentication device makes the authentication trust level 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 ③). Therefore, the authentication device can send a user confirmation request to the trusted holding device (i.e., step ④). Correspondingly, the trusted holding device, in response to the received user confirmation request, can display a confirmation interface. After detecting the user clicking the "Yes" control on the confirmation interface, it can send the corresponding confirmation result to the authentication device (i.e., step ⑤). The trusted holding device sends the authentication result through an encrypted channel established based on the device mutual trust relationship authentication established by the user operation. As shown in Table 4, the authentication device can replace the ranging security level with this user manual confirmation result, and then determine the corresponding trusted holding device security capability level as high based on the user manual confirmation result. Therefore, the authentication device can determine the authentication trust level in the final authentication result as ATL2 based on the authentication trust level ATL2 sent by the trusted holding device obtained in step ②, and thus determine that the authentication trust level in the final authentication result meets the target authentication trust level requirement, triggering the execution of the corresponding business.

[0344] For example, such as Figure 17 As shown, if the authentication device determines that the trusted holding device is not within the ranging range or cannot be rangingd (i.e., the ranging result does not meet the requirements), it can send a user confirmation request to the trusted holding device. Correspondingly, the trusted holding device, in response to the received user confirmation request, can display a confirmation interface. After detecting a user clicking the "Yes" control on the confirmation interface, it can send the corresponding confirmation result to the authentication device. The authentication device can determine the security capability level of the trusted holding device based on the method and result of the authentication, and thus determine the final authentication result.

[0345] Therefore, compared to existing technologies where, if the trusted holding device is not within the ranging range, the user cannot trigger user authentication using the trusted holding device and must return to the authentication device for authentication, resulting in cumbersome user operations, the authentication method provided in this application allows the trusted holding device to trigger user confirmation even when it is not within the ranging range. Based on the authentication result already determined by the trusted holding device and the user confirmation result, the final authentication result is determined. The user only needs to operate the trusted holding device at hand to complete user authentication with the authentication device, improving user convenience.

[0346] Figure 18 This is a schematic flowchart illustrating an authentication method provided in an embodiment of this application. It should be noted that this method does not rely on... Figure 18The specific order described below is a limitation. 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:

[0347] S1801. In response to the user authentication request of the first service in the first electronic device, the first electronic device sends an authentication request to the second electronic device.

[0348] The second electronic device supports an authentication trust level that meets the requirements of the first authentication trust level, which is the minimum authentication trust level for the first service. A short-range communication connection is established between the first and second electronic devices to ensure the security of user authentication.

[0349] Optionally, the first service can be a function or application within a first electronic device. For example, the first service could be an unlock function that controls the screen unlocking or locking of the first electronic device. The unlock function, responding to a user operation, determines that user authentication is required and may send an authentication request to a second electronic device. Another example is a pre-installed application, such as an app store. The pre-installed application detects the user's activation operation, determines that user authentication is required, and may send an authentication request to the second electronic device.

[0350] Optionally, after determining the first authentication trust level requirement required by the first service to be authenticated, the first electronic device may send an authentication request to a second electronic device that meets the first authentication trust level requirement.

[0351] For example, the unlocking function in the first electronic device detects the user's unlocking operation and determines that user authentication is triggered. The authentication trust level requirement for the unlocking function is ATL3, meaning that the minimum authentication trust level requirement for the unlocking function is ATL3. Then, the first electronic device iterates through the authentication trust levels supported by its paired second electronic device and sends authentication requests to trusted holding devices with the highest authentication trust level supported by the second electronic device, which is ATL3 or higher.

[0352] In some embodiments, the authentication request carries business constraints, which include one or more of the following: a first authentication trust level requirement, a user identity verification time requirement, a user identity verification method requirement, a user identity verification device requirement, a user verification identifier that can be used, and a real-time authentication identifier that can be triggered.

[0353] Optionally, when the first service determines to perform user authentication, it generates the aforementioned service constraints. The first electronic device generates an authentication request based on the request from the first service, and includes one or more of the service constraints in the authentication request.

[0354] The authentication trust level requirement indicates the target authentication trust level of the first service. The user identity verification time requirement indicates the time requirement for a usable user identity verification success event to occur. The user identity verification method requirement indicates the requirement for the method of verifying user identity for a user identity verification success event matching this user identity verification result. The user identity verification device requirement indicates the requirements for the device that generated the user identity verification success event. A usable user verification identifier is used to indicate whether user verification is required; the first electronic device determines whether to trigger user verification on the second electronic device side based on this usable user verification identifier. A triggerable real-time authentication identifier indicates whether real-time user authentication is allowed; the first electronic device determines whether to trigger real-time user authentication on the second electronic device side based on this triggerable real-time authentication identifier.

[0355] In some embodiments, before the second electronic device receives an 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 receiving a trusted holding device addition request from the first electronic device, the second electronic device sends device information to the first electronic device. Then, based on this device information, the first electronic device adds the second electronic device as a trusted holding device. After successful addition, the first electronic device sends a trusted holding device response to the second electronic device. Accordingly, the second electronic device receives the trusted holding device response from the first electronic device, confirming that it has become a trusted holding device of the first electronic device. Then, the second electronic device can subsequently receive authentication requests from the first electronic device and begin user authentication.

[0356] The device information includes one or more of the following: the 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.

[0357] For example, the authentication capabilities supported by the second electronic device include authentication methods and authentication trust levels. The ranging methods supported by the second electronic device include Bluetooth ranging and UWB ranging. The security capability level credentials of the second electronic device include device certificates and TEE-level key certificates. Device identity credentials include public keys.

[0358] S1802. In the first state, the second electronic device matches the first authentication result corresponding to the authentication request in the first list.

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

[0360] In some embodiments, after detecting a first user authentication successful event, the first electronic device sends the first user authentication successful event to the second electronic device.

[0361] For example, after determining that it has been added as a trusted holding device by the first electronic device, the second electronic device can begin to listen for at least one user authentication pass event generated locally or in the first electronic device.

[0362] For 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 initiated for the first time, it begins to listen for at least one generated user authentication success event on the local device or the first electronic device.

[0363] In some examples, different authentication methods correspond to the same or different authentication trust levels. Therefore, the second electronic device can monitor user authentication success events and record the user 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 for different authentication trust levels.

[0364] In some embodiments, the second electronic device may acquire at least one user authentication pass event generated locally or in the first electronic device. Furthermore, when in a carried state, the second electronic device records the acquired user authentication pass events in a first list, so that the second electronic device can subsequently perform user authentication based on the user authentication pass events recorded in the first list.

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

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

[0367] In this way, the second electronic device responds to the change in carrying state and determines whether to record the acquired user authentication success event. Thus, in the subsequent user authentication process, the second electronic device can execute the user authentication process of the first electronic device based on the user authentication success event recorded in a single carrying state cycle, thereby improving authentication security.

[0368] In some embodiments, after being de-carried out of the carrying state, the second electronic device is in a second state. Then, while in the second state, if the second electronic device determines that it is again in the carrying state, it switches from the second state back to the first state in response to a first user authentication pass event received from the first electronic device. The first user authentication pass event is a user authentication pass event detected by the first electronic device.

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

[0370] S1803, The second electronic device sends the first authentication result to the first electronic device.

[0371] In some embodiments, after the second electronic device matches the corresponding first authentication result based on the recorded user authentication success event, it may 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.

[0372] S1804. The second electronic device determines a second authentication result based on the first authentication result, which indicates whether the second electronic device has passed trusted authentication.

[0373] 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 previously recorded user identity authentication success event. Therefore, to ensure the reliability of the authentication result, the first electronic device may further verify the second electronic device by measuring its distance.

[0374] For example, in response to a non-real-time authentication result, the first electronic device measures the distance to the second electronic device and generates a distance measurement result. If the distance measurement result meets a preset distance requirement, a first distance measurement security level is determined for the second electronic device, 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.

[0375] For example, different second electronic devices have different security capability levels, and these security capability levels 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 devices are divided into three levels: high, medium, and low. For example, when the security capability level of the second electronic device is low, it may cause its determined authentication trust level to be downgraded, thereby further ensuring the reliability of the final authentication result.

[0376] Optionally, first information is obtained, including the security level of the trusted relationship between the first and second electronic devices, the security level of the first state maintenance of the second electronic device, the security level of the carried state detection of the second electronic device, and the security level of the first ranging. 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 trusted level is equal to the first authentication trusted level. When the security capability level is medium, the second authentication trusted level is less than the first authentication trusted level. When the security capability level is low, the second authentication trusted level is level 0 or level 1.

[0377] 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 is ATL3.

[0378] For example, if the first electronic device determines that the second electronic device has a high security capability level, then the first electronic device determines the authentication trust level in the final authentication result to be ATL3. The first electronic device determines that this authentication trust level meets the target authentication trust level requirements and can trigger unlocking.

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

[0380] In this way, the authentication trust level supported by different second electronic devices is assessed according to their different security capability levels, so as to support business operations with different risks, expand the scope of first electronic devices supported by second electronic devices, and ensure the security of the authentication results.

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

[0382] In other examples, if the second authentication trust level does not meet the requirements of the first authentication trust level, the first electronic device sends a user confirmation request to the second electronic device. Subsequently, the first electronic device receives a confirmation result from the second electronic device, which is the result determined by the second electronic device based on the user's action. In response to receiving the confirmation result, the first electronic device determines the second authentication result.

[0383] For example, the first electronic device matches the corresponding second ranging security level based on the method of receiving the confirmation result. Then, 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.

[0384] Thus, even 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 still be authenticated by the user. Based on the authentication result already determined by the second electronic device and the user's confirmation result, the final authentication result is determined. The user only needs to operate the second electronic device at hand to complete the user identity authentication of the first electronic device, improving the convenience of user use.

[0385] For example, such as Figure 16 As shown, the first electronic device sends an authentication request to the second electronic device, requesting a target authentication trust level of ATL2 (i.e., step ①). The second electronic device determines the authentication trust level as ATL2 based on the first list and sends the corresponding authentication result back to the first electronic device (i.e., step ②). Afterwards, 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 medium. Then, if... Figure 16As shown, the ranging level determined by the first electronic device makes the authentication trust level 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 ③). Therefore, the first electronic device can send a user confirmation request to the second electronic device (i.e., step ④). Correspondingly, the second electronic device, in response to the received user confirmation request, can display a confirmation interface. After detecting the user's click on the "Yes" control on the confirmation interface, it can send the corresponding confirmation result to the first electronic device (i.e., step ⑤). The second electronic device sends the authentication result through an encrypted channel established based on the device mutual trust relationship authentication established by the user operation, as shown in Table 4. The first electronic device can replace the ranging security level with this user manual confirmation result, and then determine the corresponding security capability level of the second electronic device as high based on the user manual confirmation result. Therefore, the first electronic device can determine the authentication trust level in the final authentication result as ATL2 based on the authentication trust level ATL2 obtained in step ②, and thus determine that the authentication trust level in the final authentication result meets the target authentication trust level requirement, triggering the execution of the corresponding service.

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

[0387] Therefore, compared to existing technologies where, if the second electronic device is in an untrusted authentication state, the user cannot trigger user authentication on the first electronic device and must return to the first electronic device for authentication, making the process cumbersome, the authentication method provided in this application allows the second electronic device to trigger real-time user authentication even when it is in an untrusted authentication state. The user only needs to operate the second electronic device at hand to complete the authentication process, improving user convenience.

[0388] Optionally, the first electronic device may also perform the steps and functions performed by the authentication device in the above embodiments, and the second electronic device may also perform the steps and functions performed by the trusted holding device in the above embodiments, thereby realizing the authentication method provided in the above embodiments.

[0389] The above combination Figures 14-18 The authentication method provided in the embodiments of this application is described in detail below. Figure 19 and Figure 20 This application provides a detailed description of the first electronic device and the second electronic device provided in the embodiments.

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

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

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

[0393] The transceiver unit may include a receiving unit and a transmitting unit, and may be implemented by a transceiver or transceiver-related circuit components, and may be a transceiver or transceiver module. The operation or function of each unit in the first electronic device 1900 is to implement the corresponding process of the authentication method in the above method embodiments. All relevant content of each step involved in the above method embodiments can be referred to the functional description of the corresponding functional unit, and for the sake of brevity, it will not be repeated here.

[0394] Optionally, Figure 19 The first electronic device 1900 shown may also include a storage unit ( Figure 19 (not shown in the image), this storage unit stores a program or instruction. When the transceiver unit 1901 and the processing unit 1902 execute the program or instruction, it causes... Figure 19 The first electronic device 1900 shown can perform the authentication method in the above method embodiments.

[0395] Figure 19 The technical effects of the first electronic device 1900 shown can be referred to the technical effects of the authentication method in the above method embodiments, and will not be repeated here.

[0396] In addition to being in the form of a first electronic device 1900, the technical solutions provided in this application may also be functional units or chips in the first electronic device, or devices used in conjunction with the first electronic device.

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

[0398] Optionally, the transceiver unit 2001 is used to support the second electronic device 2000 in performing [operations]. Figure 5 S501, S502, and S504; or, used to support the execution of the second electronic device 2000. Figure 9 S901a, S902, and S908; or, for supporting the execution of the second electronic device 2000. Figure 12 S1201, S1205, S1209, and S1211.

[0399] Optionally, the processing unit 2002 is configured to support the second electronic device 2000 in performing [operations]. Figure 5 S503 in; or, used to support the execution of the second electronic device 2000. Figure 9 S901b, S903, S904, S905, S906, and S907; or, for supporting the execution of the second electronic device 2000. Figure 12 S1202, S1203, S1204 and S1210.

[0400] The transceiver unit may include a receiving unit and a transmitting unit, and may be implemented by a transceiver or transceiver-related circuit components, and may be a transceiver or transceiver module. The operation or function of each unit in the second electronic device 2000 is to implement the corresponding process of the authentication method described in the above method embodiments. All relevant content of each step involved in the above method embodiments can be referred to the functional description of the corresponding functional unit, and for the sake of brevity, it will not be repeated here.

[0401] Optionally, Figure 20 The second electronic device 2000 shown may also include a storage unit ( Figure 20 (not shown in the image), this storage unit stores a program or instruction. When the transceiver unit 2001 and the processing unit 2002 execute the program or instruction, it causes... Figure 20 The second electronic device 2000 shown can perform the authentication method described in the above method embodiments.

[0402] Figure 20 The technical effects of the second electronic device 2000 shown can be referred to the technical effects of the authentication method described in the above method embodiments, and will not be repeated here.

[0403] In addition to being in the form of a second electronic device 2000, the technical solutions provided in this application may also be functional units or chips in a second electronic device, or devices used in conjunction with a second electronic device.

[0404] This application also provides a chip system, including: a processor coupled to a memory, the memory being used to store programs or instructions, wherein when the program or instructions are executed by the processor, the chip system implements the methods in any of the above method embodiments.

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

[0406] Optionally, the chip system may contain one or more memories. The memory may be integrated with the processor or disposed separately from it; this application embodiment does not limit this. 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 disposed separately on different chips. This application embodiment does not specifically limit the type of memory or the arrangement of the memory and processor.

[0407] For example, 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 micro controller unit (MCU), a programmable logic device (PLD), or other integrated chips.

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

[0409] This application also provides a computer-readable storage medium storing a computer program. When the computer program is run on a computer, it causes the computer to perform the aforementioned steps to implement the authentication method in the above embodiments.

[0410] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement the authentication method described in the above embodiments.

[0411] Additionally, this application also provides an apparatus. Specifically, the apparatus may be a component or module, and may include one or more processors and a memory connected together. The memory stores a computer program. When the computer program is executed by one or more processors, the apparatus performs the authentication methods described in the above-described method embodiments.

[0412] The apparatus, computer-readable storage medium, computer program product, or chip provided in the embodiments of this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0413] The steps of the methods or algorithms described in conjunction with the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and 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 reside in an application-specific integrated circuit (ASIC).

[0414] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, the division of the above functional modules is only used as an example. In practical applications, the above 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 process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0415] 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 modules or units is only a logical functional division, and there may be other division methods in actual implementation; for example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of modules or units may be electrical, mechanical or other forms.

[0416] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0417] Computer-readable storage media include, but are not limited to, any of the following: USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, and other media capable of storing program code.

[0418] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An authentication system, characterized in that, The system 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 as follows: In response to a user authentication request for a first service in the first electronic device, an authentication request is sent to a 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 the first authentication result from the second electronic device; Based on the first authentication result, a second authentication result is determined, wherein the second authentication result indicates whether the second electronic device has passed trusted authentication; The second electronic device is configured as follows: When the second electronic device is in the first state, a first authentication result corresponding to the authentication request is matched in the first list, wherein the first list includes a second event, or the first list includes a first event and a second event, wherein the first event is a local user authentication pass event listened to by the second electronic device, the second event is a user authentication pass event from the first electronic device, the authentication trust level corresponding to the second event is higher than the authentication trust level corresponding to the first event, and the authentication trust level supported by the second electronic device is determined by the first list; Send the first authentication result to the first electronic device.

2. The system according to claim 1, characterized in that, The second electronic device is also configured to: In the second state, real-time authentication is performed, generating a third authentication result; Send the third authentication result to the first electronic device; The first electronic device is also configured to: Receive the third authentication result from the second electronic device; If the third authentication result is detected as a real-time authentication result, the second authentication result is determined based on the third authentication result.

3. The system according to claim 1 or 2, characterized in that, The first electronic device is also configured to: If the first authentication result is detected to be a non-real-time authentication result, the distance to the second electronic device is measured, the distance measurement result is generated, and the first distance measurement security level of the second electronic device is determined; If the ranging result meets the preset distance requirement, the first authentication trust level carried in the first authentication result is adjusted based on the first ranging security level to generate the second authentication result. The second authentication result includes the 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.

4. The system according to claim 3, characterized in that, The first electronic device is also configured to: If the second authentication trust level does not meet the requirements of the first authentication trust level, a user confirmation request is sent to the second electronic device; The second electronic device is also configured to: Receive a user confirmation request from the first electronic device; In response to receiving the user confirmation request, obtain a confirmation result based on the user's operation; Send the confirmation result to the first electronic device; The first electronic device is also configured to: Receive 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-4, characterized in that, The second electronic device is also configured to: Obtain a user authentication pass event. When the device is in a carried state, record the user authentication pass event in the first list. The user authentication pass event comes from at least one of the second electronic device or the first electronic device. If the carried status is determined to be removed, clear the user authentication pass events recorded in the first list.

6. An authentication method, characterized in that, Applied to a first electronic device, the method includes: In response to a user authentication request for a first service in the first electronic device, an authentication request is sent 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, which is the minimum authentication trust level required by the first service. The device receives a first authentication result from the second electronic device. The first authentication result is the authentication result matched by the second electronic device in the first state in the first list. The first list includes a second event, or the first list includes a first event and a second event. The first event is a local user identity authentication pass event listened to by the second electronic device. The second event is a user identity authentication pass event from the first electronic device. The authentication trust level corresponding to the second event is higher than the authentication trust level corresponding to the first event. The authentication trust level supported by the second electronic device is determined by the first list. Based on the first authentication result, a second authentication result is determined, which indicates whether the second electronic device has passed trusted authentication.

7. The method according to claim 6, characterized in that, The method further includes: Receive a third authentication result from the second electronic device, wherein the third authentication result is an authentication result generated in real time by the second electronic device when it is in the second state; The second authentication result is determined based on the third authentication result.

8. The method according to claim 6 or 7, characterized in that, Based on the first authentication result, a second authentication result is determined, including: If the first authentication result is detected to be a non-real-time authentication result, the distance to the second electronic device is measured, and a distance measurement result is generated. If 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, If the second authentication trust level meets the requirements of the first authentication trust level, 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 includes: If the second authentication trust level does not meet the requirements of the first authentication trust level, a user confirmation request is sent to the second electronic device; Receive a confirmation result from the second electronic device, the confirmation result being a result determined by the second electronic device based on 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, the second authentication result is determined, including: Based on the method of receiving the confirmation result, match the corresponding second ranging security level; The second authentication result is determined based on the second ranging security level.

12. The method according to any one of claims 8-11, characterized in that, Based on the first ranging security level, the first authentication trust level carried in the first authentication result is adjusted, including: Obtain first information, which includes the security level of the trusted relationship between the first electronic device and the second electronic device, the security level of the first state maintenance of the second electronic device, the security level of the carried state detection of the second electronic device, and the security level of the first ranging. Based on the first information, determine the security capability level of the second electronic device; 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-12, characterized in that, Before sending an authentication request to the second electronic device in response to a user authentication request for a first service in the first electronic device, the method further includes: Send a trusted holding device add request to the second electronic device; Receive device information from the second electronic device, the device information being information determined by the second electronic device in response to receiving the trusted holding device add request; Based on 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: the 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.

15. The method according to any one of claims 6-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 user identity confirmation time requirement, the user identity confirmation method requirement, the user identity confirmation device requirement, the ability to use a user confirmation identifier, and the ability to trigger a real-time authentication identifier.

16. The method according to any one of claims 6-15, characterized in that, The method further includes: The first user's authentication success event was detected; Send the first user authentication successful event to the second electronic device.

17. An authentication method, characterized in that, Applied to a second electronic device, the method includes: Receive 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, and the authentication trust level supported by the second electronic device meets the first authentication trust level requirement, wherein the first authentication trust level requirement is the minimum authentication trust level of the first service to be authenticated for user identity in the first electronic device; In the first state, a first authentication result corresponding to the authentication request is matched in a first list. The first list includes a second event, or the first list includes a first event and a second event. The first event is a local user authentication pass event listened to by the second electronic device, and the second event is a user authentication pass event from the first electronic device. The authentication trust level corresponding to the second event is higher than the authentication trust level corresponding to the first event. The authentication trust level supported by the second electronic device is determined by the first list. 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.

18. The method according to claim 17, characterized in that, The method further includes: In the second state, real-time authentication is performed, generating 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.

19. The method according to claim 17 or 18, characterized in that, The method further includes: Receive a confirmation request from the first electronic device. The confirmation request is 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 requirements of the first authentication trust level. The second authentication trust level is the 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, obtain a confirmation result based on the user's operation; The confirmation result is sent to the first electronic device, and the confirmation result is used to determine the second authentication result.

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

21. The method according to any one of claims 17-20, characterized in that, Before receiving an authentication request from the first electronic device, the method further includes: If it is determined that the carried state has been removed, clear the user authentication pass events recorded in the first list; A first state failure notification is sent to the first electronic device, indicating that the second electronic device is in a second state.

22. The method according to any one of claims 17-21, characterized in that, Before receiving an authentication request from the first electronic device, the method further includes: Receive a trusted holding device addition request from the first electronic device; Send device information to the first electronic device, wherein the device information is used to add the second electronic device as a trusted holding device of the first electronic device; Receive a trusted holding device add response from the first electronic device and determine that it is a trusted holding 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: the 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.

24. The method according to any one of claims 17-23, characterized in that, The second electronic device is in a carried state, and the method further includes: In the second state, a first user authentication pass event is received from the first electronic device, wherein the first user authentication pass event is a user authentication pass 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-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 user identity confirmation time requirement, the user identity confirmation method requirement, the user identity confirmation device requirement, the ability to use a user confirmation identifier, and the ability to trigger a real-time authentication identifier.

26. An electronic device, characterized in that, include: 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, which, when the processor reads the computer instructions from the memory, cause the electronic device to perform the method as described in any one of claims 6-16; or cause the electronic device to perform the method as described in any one of claims 17-25.

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

28. A computer program product, characterized in that, The computer program product includes a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 6-25.

Images