A verification method and electronic device

Abstract

The application discloses a verification method and an electronic device. The method comprises the following steps: detecting a target event, and obtaining a random verification number; obtaining first verification information generated by a first function module based on a first hardware key, a second hardware key and the random verification number; obtaining second verification information generated by a second function module based on the first hardware key, the second hardware key and the random verification number; if the first verification information and the second verification information satisfy a target corresponding relationship, allowing the second function module to provide identity service based on stored identity configuration information; wherein the first hardware key is bound to a first hardware feature of the first function module, the second hardware key is bound to a second hardware feature of the second function module, and the random verification number is generated by a trusted execution environment; the first function module is used for providing the hardware feature of the electronic device, and the second function module is used for storing the identity configuration information.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and more specifically to a verification method and an electronic device. Background Technology

[0002] With the development of mobile communication technology, the identity verification modules integrated in terminal devices have gradually evolved from pluggable physical cards to embedded forms. Embedded identity verification modules are directly soldered or built into terminal devices and can store user subscription information for accessing operator networks. However, in practical use, there is a possibility that embedded identity verification modules can be migrated to other terminal devices, potentially leading to security risks such as identity theft and communication resource misuse. Summary of the Invention

[0003] In view of the above, this application provides the following technical solution:

[0004] A verification method, the method comprising:

[0005] The target event was detected, and a random number of verifications was obtained.

[0006] Obtain the first verification information generated by the first functional module based on the first hardware key, the second hardware key, and the random verification number;

[0007] Obtain the second verification information generated by the second functional module based on the first hardware key, the second hardware key, and the random verification number;

[0008] If the first verification information and the second verification information satisfy the target correspondence, the second functional module is allowed to provide identity services based on the stored identity configuration information;

[0009] Wherein, the first hardware key is bound to the first hardware feature of the first functional module, the second hardware key is bound to the second hardware feature of the second functional module, and the random verification number is generated by a trusted execution environment; the first functional module is used to provide the hardware features of the electronic device, and the second functional module is used to store identity configuration information.

[0010] An electronic device, comprising:

[0011] The first functional module is used to provide the hardware features of the electronic device;

[0012] The second functional module is used to store identity configuration information;

[0013] The processing module is connected to the first functional module and the second functional module respectively;

[0014] The processing module detects a target event and obtains a random verification number; it obtains first verification information generated by the first functional module based on a first hardware key, a second hardware key, and the random verification number; it obtains second verification information generated by the second functional module based on the first hardware key, the second hardware key, and the random verification number; if the first verification information and the second verification information satisfy a target correspondence, the second functional module is allowed to provide identity services based on stored identity configuration information.

[0015] Wherein, the first hardware key is bound to the first hardware feature of the first functional module, the second hardware key is bound to the second hardware feature of the second functional module, and the random verification number is generated by a trusted execution environment. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a verification method provided in an embodiment of this application;

[0018] Figure 2 A schematic diagram of a verification process for an application scenario provided in this application embodiment;

[0019] Figure 3 This application provides a schematic diagram illustrating the interaction relationships between various modules in a mobile phone and the generation and distribution of keys.

[0020] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] The terms "first" and "second," etc., used in this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units may include steps or units not listed, but may include steps or units not listed.

[0023] This application provides a verification method applicable to various electronic devices. These devices may include smartphones, tablets, wearable devices (such as smartwatches), IoT terminal devices, or vehicle-mounted communication terminals. The electronic device includes a first functional module and a second functional module. The first functional module provides hardware characteristic information for the electronic device and may specifically be a modem module, storage module, short-range communication module, or ultra-wideband (UWB) module, such as a module with immutable hardware information and communication functions. The second functional module stores identity configuration information, corresponding to an embedded subscriber identity module (eSIM). The verification method in this embodiment verifies the binding relationship between the first and second functional modules before the electronic device uses the identity service provided by the second functional module, to confirm whether the second functional module has been migrated to other unauthorized devices.

[0024] See Figure 1 The diagram illustrates a flowchart of a verification method provided in an embodiment of this application, which may include the following steps:

[0025] S101. Target event detected, obtain random verification number.

[0026] A target event refers to any scenario where an electronic device needs to activate a second functional module for communication or to provide identity services. Specifically, a target event may be the loading of a second functional module after the electronic device is powered on or restarted, the switching or activation of the configuration information of the second functional module, the updating of the configuration information of the second functional module, the receipt of configuration information related to communication access by the second functional module, or the need for the first and second functional modules to cooperate in communication access, etc.

[0027] When any of the aforementioned target events is detected, the electronic device acquires a random verification number. This random verification number is generated by the Trusted Execution Environment (TEE). The Trusted Execution Environment is an isolated and secure operating environment within the system-on-a-chip of the electronic device, with independent storage areas and computing resources, ensuring that operations performed and data generated within it are not accessed or tampered with by external ordinary execution environments.

[0028] The random verification number, as a one-time challenge value, is unpredictable, ensuring that the verification information generated in each verification process is different, thus effectively preventing replay attacks. For example, when a user powers on their phone, the system detects that an eSIM needs to be loaded and triggers the verification process, where a random number is generated by a trusted execution environment as the random verification number for this verification.

[0029] S102. Obtain the first verification information generated by the first functional module based on the first hardware key, the second hardware key, and the random verification number.

[0030] The first hardware key is bound to the first hardware feature of the first functional module, and the second hardware key is bound to the second hardware feature of the second functional module. The first hardware feature refers to a unique physical attribute of the first functional module, such as device identification information, specifically including the International Mobile Equipment Identity (IMEI), chip serial number, and Media Access Control (MAC) address. These hardware features are fixed during the module manufacturing stage and cannot be tampered with or copied. The second hardware feature refers to a unique physical attribute of the second functional module, such as the Embedded Identity Module ID (EID) or eSIM ID. Because the first hardware key is bound to the hardware feature of the first functional module, and the second hardware key is bound to the hardware feature of the second functional module, both hardware keys form an inseparable physical binding relationship with their respective hardware entities. If either module is replaced with another device, the hardware features of that module change, and the hardware key derived from the original hardware features will no longer be valid.

[0031] S103. Obtain the second functional module to generate second verification information based on the first hardware key, the second hardware key, and the random verification number.

[0032] The method by which the second functional module obtains the first and second hardware keys is related to its storage method. After initial binding is completed, the first functional module stores the second hardware key, and the second functional module stores the first hardware key; both modules hold each other's hardware keys. The first hardware key is bound to the first hardware feature of the first functional module, and the second hardware key is bound to the second hardware feature of the second functional module. Therefore, the key material used by the second functional module to generate the second verification information is also associated with the physical characteristics of the two hardware modules.

[0033] S104. If the first verification information and the second verification information satisfy the target correspondence, the second functional module is allowed to provide identity services based on the stored identity configuration information.

[0034] The electronic device compares the acquired first verification information with the acquired second verification information. The comparison can be performed by one functional module sending its own generated verification information to another functional module for comparison, or by two functional modules sending their own verification information to the Trusted Execution Environment for comparison, or by both parties comparing their information separately and then exchanging the comparison results.

[0035] Since the first and second verification information are generated based on the same two hardware keys and the same random verification number, they satisfy a target correspondence when neither functional module is replaced and the hardware keys match. This target correspondence includes the two being identical, satisfying a preset functional relationship, or satisfying a preset verification relationship. In other words, the first and second verification information have a deterministic mapping relationship under the same input conditions, determined by the rules used to generate them. For example, when the first and second verification information are generated using different concatenation orders, the target correspondence indicates a definite mapping relationship between the hash values ​​calculated based on the same key and random verification number under their different concatenation methods. This mapping relationship verifies whether the two verification information are generated by the same hardware key and the same random verification number, thus confirming the validity of the binding relationship between the first and second functional modules. Alternatively, when the first verification information and the second verification information are generated using the same concatenation order, the target correspondence indicates that the two verification information have the same hash value calculated based on the same key and random verification number under the same concatenation method. This same relationship can verify whether the two verification information are generated by the same hardware key and the same random verification number, thereby confirming whether the binding relationship between the first functional module and the second functional module is valid.

[0036] Identity service refers to the second functional module providing electronic devices with the authentication capabilities required to access communication networks based on stored identity configuration information, such as completing authentication and registration operations in cellular networks. If the first verification information and the second verification information do not meet the target correspondence, it indicates that the binding relationship between the two modules has been broken, for example, the second functional module has been migrated to other devices. In this case, the second functional module is prohibited from providing identity service, thereby preventing the identity configuration information from being used illegally.

[0037] This application provides a verification method that binds a first hardware key to a first hardware feature of a first functional module and a second hardware key to a second hardware feature of a second functional module. This ensures that both hardware keys are physically bound to their respective hardware entities. If either module is replaced with another device, the hardware features change, causing the hardware keys to become invalid. This physically prevents the second functional module from being migrated to unauthorized devices. By generating a random verification number as a one-time challenge value from a trusted execution environment when a target event is detected, the randomness and unpredictability of each verification are ensured, effectively preventing replay attacks. By acquiring and comparing the first and second verification information independently generated by the first and second functional modules based on the two hardware keys and the random verification number, respectively, identity services are only allowed when the two verification information matches the target correspondence. This achieves bidirectional collaborative verification between the two functional modules. Any mismatch in the hardware keys held by either module will result in the verification information not meeting the target correspondence. Therefore, even if identity configuration information is illegally obtained or copied, it cannot be used on other devices because it fails the consistency verification. Therefore, this application effectively solves the security risks such as identity recognition module migration, identity impersonation, and communication resource theft while ensuring that legitimate users can use the identity services provided by the second functional module normally.

[0038] In some embodiments of this application, the target event includes at least one of the following:

[0039] When an electronic device powers on or restarts, a second functional module is loaded. During the system startup process, a second functional module needs to be loaded. For example, after a smartphone powers on, the operating system loads an embedded subscriber identity module (eSIM) to put it in a ready state to provide identity services to the user later. At this time, the second functional module has not yet communicated with the first functional module and needs to execute a verification process to confirm the binding relationship is valid. In this scenario, the action of loading the second functional module constitutes the target event. For example, when a user presses the power button to power on the phone, the system detects the need to load the eSIM during startup and then triggers the verification process.

[0040] The configuration information of the second functional module is switched or enabled. In actual use, electronic devices may store multiple configuration information, such as multiple configuration files for embedded user identification modules. Users can switch between different configuration information or enable previously configured but inactive configuration information. When a user performs a switching or enabling operation, the second functional module needs to provide identity services with the new configuration information. At this time, a verification process should be executed first. For example, when a user switches from configuration A to configuration B, the system detects the configuration switch operation, triggers a verification process, obtains a random verification number, and then the first and second functional modules generate verification information respectively and compare them.

[0041] The second functional module updates its configuration information. The configuration information of the second functional module may need to be updated, for example, due to a new configuration file issued by the operator or updates to parameters in the existing configuration. When the second functional module receives the updated configuration information, a verification process should be executed to ensure that the updated configuration information remains bound to the first functional module of the current electronic device.

[0042] The second functional module receives configuration information related to communication access. This information may include authentication parameters issued by the operator and network access point configurations. Since this configuration information relates to the second functional module's ability to provide identity services, the validity of the binding relationship should be verified before applying this information. When the second functional module receives such configuration information, a verification process is triggered.

[0043] The first and second functional modules need to work together to access the communication network. When an electronic device needs to use the identity service provided by the second functional module to access the communication network, such as when a user initiates a voice call or data connection, the first and second functional modules need to work together to complete the communication access. At this time, before officially accessing the communication network, it should be verified whether the binding relationship between the two is still valid, so as to avoid the security risk of continuing to use the identity service even if the binding relationship has been broken.

[0044] Taking a smartphone scenario as an example. When a user powers on their phone, the operating system loads the embedded user identity verification module. This satisfies the objective event of loading a second functional module after the electronic device powers on or restarts, triggering the verification process, obtaining a random verification number, and performing the verification. After successful verification, the user can use network services normally. At some point, the user switches to a different embedded user identity verification module configuration. This satisfies the objective event of the second functional module's configuration information being switched, triggering the verification process again to ensure that the newly configured embedded user identity verification module remains bound to the phone's first functional module. After successful verification, the new configuration takes effect, and the user can use the identity service corresponding to that configuration normally.

[0045] This embodiment specifies the target events into various scenarios, such as loading the second functional module after the electronic device is powered on or restarted, the configuration information of the second functional module being switched or enabled, the configuration information of the second functional module being updated, the second functional module receiving configuration information related to communication access, and the first and second functional modules needing to coordinate communication access. This ensures that the timing of the verification process is matched with the actual usage needs of the second functional module, guaranteeing that the verification process is only triggered at critical moments when the validity of the binding relationship needs to be confirmed. This avoids the negative impact of continuous and frequent verification on the performance of the electronic device and the user experience, while also ensuring that the binding relationship is still valid at security-sensitive nodes such as switching configuration information, receiving updated configurations, and before communication access. Thus, it balances security with the working efficiency of the electronic device and the user experience.

[0046] In some embodiments of this application, the process of obtaining random verification numbers includes:

[0047] S201. In response to verifying that the current user of the electronic device is an authorized user in a trusted execution environment, a random verification number is generated.

[0048] Furthermore, in the embodiments of this application, it may also include: S202, in response to verifying in the trusted execution environment that the current user of the electronic device is not an authorized user, prohibiting the generation of random verification numbers.

[0049] A Trusted Execution Environment (TEE) is an independent, isolated, and secure operating environment within a system-on-a-chip (SoC) of an electronic device. This environment has its own independent storage area and computing resources, and is isolated from the ordinary execution environment (such as the operating system environment) within the electronic device. Code and data running in the TEE cannot be accessed or tampered with by the ordinary execution environment. The TEE pre-stores the characteristic templates of authorized users. These templates can be biometric information such as fingerprint, facial, iris, or voiceprint data pre-recorded by the user, used for comparison with subsequently collected characteristic information of the current user.

[0050] Upon detecting a target event, the Trusted Execution Environment (TEE) acquires the user characteristic information of the current user of the electronic device. The method of acquiring this user characteristic information can be determined based on the type of acquisition module configured in the electronic device; for example, it can acquire fingerprint information via a fingerprint sensor, facial image information via a camera, iris information via an iris sensor, or voiceprint information via a microphone. The TEE compares the acquired user characteristic information of the current user with pre-stored authorized user characteristic templates. If the comparison matches, it indicates that the current user is an authorized user, and the TEE generates a random verification number. If the comparison does not match, it indicates that the current user is not an authorized user, and the TEE prevents the generation of a random verification number.

[0051] It should be noted that, in the case of a match, the generated random verification number is sent by the Trusted Execution Environment (TEE) to both the first and second functional modules, enabling them to generate first and second verification information respectively. In the case of a mismatch, since the TEE prohibits the generation of random verification numbers, neither the first nor second functional modules can obtain the random verification number, thus preventing the generation of verification information. Consequently, the verification process terminates, and the second functional module is unable to provide identity services.

[0052] For example, when a user presses the power button to turn on the phone, the system detects the target event of loading the embedded user identification module during startup. The trusted execution environment then prompts the user to press their fingerprint. The user places their finger on the fingerprint sensor, which collects the user's fingerprint information and transmits it to the trusted execution environment. The trusted execution environment compares the collected fingerprint information with a pre-stored authorized user fingerprint template. If the fingerprint matches, the trusted execution environment confirms the current user is an authorized user, generates a random verification number, and sends this number to the first and second functional modules, allowing the verification process to continue. If the fingerprint does not match, the trusted execution environment confirms the current user is not an authorized user, prevents the generation of a random verification number, terminates the verification process, the embedded user identification module cannot provide identity services, and the phone cannot access the communication network.

[0053] For example, after a phone is stolen, the finder attempts to use it. Upon powering it on, the system triggers a verification process. The trusted execution environment (TEE) requires verification of the current user's authorization. Since the finder cannot provide an authorized user's fingerprint, the fingerprint comparison fails. The TEE then prevents the generation of a random verification number, the verification process terminates, and the finder is unable to use the communication services provided by the phone's embedded user identification module.

[0054] This embodiment verifies whether the current user is authorized through a trusted execution environment, and only generates a random verification number after successful verification. This ensures that the verification process depends not only on the binding relationship between the two hardware modules but also on whether the current user is authorized. Combining user authentication with hardware module binding authentication creates a dual security guarantee. Even if the binding relationship between the first and second functional modules in the electronic device remains valid, the verification process will still fail if the current operator is not an authorized user, and the second functional module will be unable to provide identity services. This effectively prevents unauthorized use of the identity recognition module after the electronic device is lost or stolen, further enhancing the security of communication services.

[0055] The first functional module generates first verification information based on a first hardware key, a second hardware key, and a random verification number. The second functional module generates second verification information based on the same first and second hardware keys and the random verification number. Further, a hash function combined with different concatenation orders can be used to generate the two verification information sets. The first verification information is generated by combining the hash value obtained by concatenating the first and second hardware keys in a first order with the hash function and then combining it with the random verification number. The second verification information is generated by combining the hash value obtained by concatenating the second and first hardware keys in a second order with the hash function and then combining it with the random verification number. The first and second orders are different.

[0056] A hash function is a mathematical function that maps input data of arbitrary length to an output value of fixed length. It is one-way, meaning the input value cannot be deduced from the output value, and it is collision-resistant, meaning it is difficult to find two different input values ​​that will produce the same output value. The hash function used in this embodiment can be any of the SHA series of secure hash algorithms, such as SHA-256.

[0057] After obtaining the first hardware key, the second hardware key, and the random verification number, the first functional module concatenates the first and second hardware keys in a first order to obtain a concatenated data sequence. This concatenated data sequence is then input into a hash function for hashing to obtain a first hash value. Here, the first order refers to the concatenation order where the first hardware key comes first, followed by the second hardware key. The first functional module then combines the first hash value with the random verification number to generate the first verification information. The combination can be achieved by concatenating the first hash value and the random verification number, that is, appending the random verification number to the end or beginning of the first hash value to form a complete verification message.

[0058] After obtaining the first hardware key, the second hardware key, and the random verification number, the second functional module concatenates the second hardware key and the first hardware key in a second order to obtain a concatenated data sequence. This concatenated data sequence is then input into the same hash function for hashing to obtain a second hash value. Here, the second order differs from the first order; it refers to the concatenation order where the second hardware key comes first, followed by the first hardware key. The second functional module then combines the second hash value with the random verification number to generate second verification information. The combination method can be the same as that used in the first verification information; for example, it can also use a concatenation method, appending the random verification number to the end or beginning of the second hash value to form a complete verification message.

[0059] Because the first and second sequences are different, even if the first and second functional modules use the same two hardware keys, the data sequences they form are different. Specifically, the first functional module concatenates the first and second hardware keys, while the second functional module concatenates the second and first hardware keys. Thus, even when both parties possess correct hardware keys, the different concatenation orders of the two functional modules result in different input data to the hash function, leading to different calculated hash values. In other words, the first and second hash values ​​are different. Since the first and second verification information are generated independently by the first and second functional modules respectively, each party knows its own concatenation order and calculation result. During subsequent comparison, after exchanging verification information, each party compares according to its known concatenation order and the one-way nature of the hash function. Because the hash values ​​in the two verification messages are calculated by the same hash function under different input orders, and the hash function has a definite input-output mapping relationship, when both hardware keys are correct, the two verification messages satisfy a preset correspondence and can therefore be compared as identical.

[0060] If either the first or second functional module is replaced after the initial binding phase, the hardware key derived from the replaced module will differ from the original hardware key. In this case, the key materials used by the first and second functional modules when performing hash calculations will no longer match. For example, if the second functional module is migrated to another electronic device, the first hardware key obtained by the second functional module in the new device will be the hardware key of the first functional module in the new device, not the hardware key of the first functional module in the original device. Therefore, when the second functional module generates the second verification information, the first hardware key used has changed, and the second hash value it calculates cannot satisfy the preset correspondence with the first hash value calculated by the first functional module, resulting in a comparison failure.

[0061] Taking a practical application scenario as an example, assume the first hardware key is KeyA, the second hardware key is KeyB, and the random verification number is R. The first functional module concatenates KeyA and KeyB in the order of "KeyA + KeyB," inputs the hash function SHA-256 to calculate the first hash value H1, and then concatenates H1 with R to generate the first verification information V1. The second functional module concatenates KeyB and KeyA in the order of "KeyB + KeyA," inputs the same hash function SHA-256 to calculate the second hash value H2, and then concatenates H2 with R to generate the second verification information V2. During verification, because the first verification information V1 and the second verification information V2 use different concatenation orders, the two verification information are calculated independently. Due to the different input order of the hash function, the first hash value H1 and the second hash value H2 are inherently different. However, after exchanging verification information, both parties check according to their known concatenation orders. Due to the determinism of the hash function and the matching of the two hardware keys, when both hardware keys are correct, the two verification information satisfy the preset correspondence, the comparison is consistent, and the verification passes. If the second functional module is migrated to another mobile phone, and the hardware key of the first functional module of that mobile phone is KeyC, then the second functional module uses KeyC and KeyB for calculation, that is, the concatenation order is "KeyB+KeyC". The calculated hash value is different from the hash value calculated when KeyA was used, the comparison fails, and the verification fails.

[0062] This embodiment generates two verification messages by employing a hash function combined with different concatenation orders. This results in a structural difference in the generation process of the first and second verification messages. Based on their respective key materials, the two functional modules independently generate mutually verifiable authentication credentials under the same random verification challenge. The one-way nature of the hash function ensures that the verification messages are irreversible; even if the verification messages are intercepted during communication, attackers cannot reconstruct the hardware key. The difference between the first and second sequences prevents either functional module from unilaterally forging the other's verification messages. Verification requires both parties to calculate and participate jointly based on their respective keys, forming a two-way locking mechanism that further enhances the security and reliability of the verification.

[0063] In embodiments of this application, the first hardware key is generated based on a first hardware feature of the first functional module and a first root key stored internally in the first functional module. The second hardware key is generated based on a second hardware feature of the second functional module and a second root key stored internally in the second functional module.

[0064] The first hardware feature refers to the unique physical attribute information possessed by the first functional module. This information is fixed during the functional module's manufacturing stage and cannot be tampered with or copied. The first hardware feature may include the device identifier of the first functional module, such as the International Mobile Equipment Identity (IMEI), chip serial number, or Media Access Control (MAC) address. These device identifiers are written into corresponding hardware registers or storage areas during device manufacturing and are unique. The first functional module internally stores a first root key. The first root key is written during the chip manufacturing stage of the first functional module and stored in a one-time programmable storage area or similar secure storage medium within the first functional module. This root key cannot be read or exported externally. The first functional module uses its device identifier and the internally stored first root key as input and calculates the first hardware key using a hash-based key derivation function (HKDF).

[0065] The second hardware feature refers to the unique physical attribute information possessed by the second functional module. This second hardware feature may include the device identifier of the second functional module, such as the Embedded Identity Module ID (EID, eSIM ID). This identifier is written during the manufacturing stage of the second functional module and is unique. The second functional module internally stores a second root key. This second root key is written during the chip manufacturing stage of the second functional module and stored in a secure storage area within the module; this root key cannot be read or exported externally. The second functional module uses its device identifier and the internally stored second root key as input, and calculates the second hardware key using the same hash-based key derivation function.

[0066] A hash-based key derivation function is an algorithm that expands the input raw key material into key data of the required length. Its output is pseudo-random, meaning it is statistically indistinguishable from a random number. This function is one-way; even if the output is known, the input root key or device identifier cannot be derived in reverse. In this embodiment, the device identifier and root key are combined using this function to generate a hardware key. This ensures that the hardware key is both associated with the hardware characteristics of the functional module and depends on the internally stored root key; both are indispensable. Obtaining only the device identifier without the internal root key, or only the internal root key without the device identifier, will not result in the correct generation of the hardware key.

[0067] For example, the first functional module is the modem module in the mobile phone, and the second functional module is the embedded user identity module. During the mobile phone manufacturing process, the modem module internally stores a first root key, which is written into the one-time programmable storage area inside the chip during the modem module chip manufacturing stage. The modem module obtains the International Mobile Equipment Identity (IMEI) of the mobile phone, and inputs the IMEI and the internally stored first root key into a hash-based key derivation function to calculate the first hardware key. The embedded user identity module internally stores a second key, which is written into its internal secure storage area during the embedded user identity module chip manufacturing stage. The embedded user identity module obtains its own Embedded Identity Module Identifier (EID), and inputs the EID and the internally stored second key into the same hash-based key derivation function to calculate the second hardware key. Since both the IMEI and EID are globally unique, and neither root key can be read externally, the generated first and second hardware keys are unique and cannot be copied.

[0068] For example, an attacker might attempt to obtain the hardware key of one phone and use it on another. The attacker could obtain the IMEI and EID information of the first phone, but because neither the first root key stored within the first functional module nor the second root key stored within the second functional module can be read or exported, the attacker cannot obtain the root key and therefore cannot regenerate the same hardware key as the first phone. Even if the attacker physically migrates the second functional module to another phone, because the first functional module of the new phone has a different IMEI and internal root key, the derived first hardware key will be different from the original device, and the second functional module will fail verification.

[0069] This embodiment combines the generation of the hardware key with the hardware characteristics of the functional module and the internally stored root key, thus establishing a strong physical-level binding relationship between the hardware key and the hardware entity. Because the device identifier is unique and the root key is written during chip manufacturing and cannot be exported, the generated hardware key is unique and cannot be copied. When the second functional module is migrated to another electronic device, the device identifier and internal root key of the first functional module in the new device are different from those in the original device, resulting in a different first hardware key. This causes a mismatch between the original first hardware key stored in the second functional module and the first hardware key in the new device, thus failing verification. This prevents the hardware key from being copied or migrated, cutting off the technical path for illegal migration at its source.

[0070] This application embodiment also provides a processing flow for the initialization binding phase. This initialization binding phase is executed once when the electronic device is first powered on or when the second functional module is first activated, and does not need to be executed repeatedly during subsequent use. This initialization binding phase aims to establish a binding relationship between the first and second functional modules, whereby they mutually hold each other's hardware keys. Once established, this binding relationship remains valid until the electronic device is restored to factory settings or the second functional module is actively unbound. The process may include the following steps:

[0071] S301. Generate an asymmetric key pair and send the public key of the asymmetric key pair to the first functional module and the second functional module respectively.

[0072] An asymmetric key pair is a set of keys containing a public key and a private key. The public key can be publicly distributed and used to encrypt data, while the private key is kept secret by the entity that generated the key pair and used to decrypt data encrypted using the corresponding public key. In this embodiment, the asymmetric key pair is generated by the trusted execution environment (TEE). The private key is securely stored within the TEE and can never be exported, while the public key can be distributed to other modules. The purpose of using asymmetric encryption is to ensure that even if the transmission channel is intercepted during the transmission of the hardware key from the first functional module and the second functional module to the TEE, an attacker cannot decrypt and obtain the hardware key because they do not have the private key. The TEE sends the generated public key to both the first and second functional modules.

[0073] S302, Receive a first hardware key encrypted from the first functional module, and receive a first hardware key encrypted from the second functional module. The key used for encryption is a public key.

[0074] The first functional module obtains a first hardware key, encrypts it using the received public key, and sends the encrypted first hardware key to the trusted execution environment. The second functional module obtains a second hardware key, similarly encrypts it using the received public key, and sends the encrypted second hardware key to the trusted execution environment. The generation methods of the first and second hardware keys can be found in the description of the foregoing embodiments, i.e., they are generated based on the hardware characteristics of their respective functional modules and the root key stored internally.

[0075] S303. Use the private key in the asymmetric key pair to decrypt and obtain the first hardware key and the second hardware key.

[0076] The Trusted Execution Environment (TEE) receives a first hardware key encrypted from a first functional module and a second hardware key encrypted from a second functional module. Since these two hardware keys are encrypted using a public key, the TEE uses its stored private key to decrypt them respectively, obtaining the plaintext of the first hardware key and the plaintext of the second hardware key.

[0077] S304. Send the second hardware key to the first functional module through a secure channel, and send the first hardware key to the second functional module, so that the first functional module stores the second hardware key and the second functional module stores the first hardware key.

[0078] The Trusted Execution Environment (TEE) sends the second hardware key to the first functional module and then to the second functional module via a secure channel. The secure channel refers to a secure transmission path established between the first and second functional modules, ensuring the confidentiality and integrity of data during transmission and preventing eavesdropping or tampering. Upon receiving the second hardware key, the first functional module stores it in a local non-volatile storage partition. This partition retains data even after power failure and is protected by hardware-level access control, preventing arbitrary reading or modification of the data by ordinary software. Upon receiving the first hardware key, the second functional module stores it in a local internal secure storage area. This storage area is isolated from the external interface of the second functional module, providing physical-level protection against reading and tampering.

[0079] After the above initialization and binding phase, the first functional module stores the second hardware key (i.e., the hardware key of the other party's module), and the second functional module stores the first hardware key (i.e., the hardware key of the other party's module). Both parties hold each other's hardware key instead of their own hardware key.

[0080] Taking a smartphone scenario as an example. When a user purchases a new phone and activates it for the first time, the phone undergoes an initialization and binding phase. The Trusted Execution Environment (TEE) generates an asymmetric key pair, and the public key is distributed to the modem module and the embedded user identity module. The modem module generates a first hardware key based on the IMEI and internal root key, encrypts it with the public key, and sends it to the TEE. The embedded user identity module generates a second hardware key based on the EID and internal root key, encrypts it with the public key, and sends it to the TEE. The TEE decrypts the second and third hardware keys using its private key, then sends the second hardware key to the modem module and the first hardware key to the embedded user identity module via a secure channel. The modem module stores the second hardware key in its non-volatile storage partition, and the embedded user identity module stores the first hardware key in its internal secure storage area. Subsequently, each time the phone is powered on or the embedded user identity module is loaded, the stored hardware key is used directly to execute the verification process, and the initialization and binding phase is not repeated.

[0081] If the user restores the phone to factory settings, the second hardware key stored in the non-volatile storage partition of the modem module and the first hardware key stored in the secure storage area inside the embedded user identity module are cleared. The next time the phone is powered on, the initialization binding phase will be executed again, a new asymmetric key pair will be generated, the new hardware keys will be exchanged and stored again, and a new binding relationship will be established.

[0082] This embodiment transmits hardware keys using asymmetric encryption, ensuring the confidentiality of the hardware keys during transmission from each functional module to the trusted execution environment. Even if the transmission channel is intercepted, attackers cannot decrypt and obtain the hardware keys without the private keys. Exchanging keys through a secure channel further prevents man-in-the-middle attacks, guaranteeing the integrity and authenticity of the key exchange process. After initial binding, the first functional module stores the second hardware key, and the second functional module stores the first hardware key. Both modules hold each other's hardware keys instead of their own, achieving a mutually binding and constraining relationship. This provides a hardware-level trust anchor for subsequent two-way verification. If any functional module is replaced, verification will fail because the hardware key held by the other module will not match the new hardware.

[0083] Furthermore, the secure channel is established based on a key exchange protocol, which is used to establish a shared key between the first functional module and the second functional module.

[0084] A key exchange protocol is a protocol that allows two communicating parties to negotiate a shared key over an insecure communication channel. The protocol primarily involves each party generating a temporary public-private key pair, exchanging the public key, and combining it with their own private key to calculate a shared key known only to the two communicating parties. Even if an attacker intercepts the exchanged public key, they cannot calculate the shared key without the private key of either party.

[0085] In this embodiment, a secure channel is established between the trusted execution environment (TEE) and the first functional module via a key exchange protocol. The TEE generates a temporary public-private key pair and sends the temporary public key to the first functional module. Upon receiving the public key, the first functional module generates its own temporary public-private key pair and sends the temporary public key to the TEE. The TEE calculates a shared key using its own temporary private key and the first functional module's temporary public key. The first functional module calculates the same shared key using its own temporary private key and the TEE's temporary public key. The TEE uses this shared key to encrypt a second hardware key and sends it to the first functional module. The first functional module uses the same shared key to decrypt the second hardware key. Similarly, the TEE and the second functional module establish a secure channel through the same key exchange protocol and use the shared key to encrypt the transmission of the first hardware key.

[0086] This embodiment establishes a secure channel through a key exchange protocol, ensuring the confidentiality and integrity of the hardware key during transmission, effectively preventing eavesdropping and man-in-the-middle attacks during the key exchange process, and ensuring the secure transmission of the hardware key exchanged during the initialization and binding phase.

[0087] In the foregoing embodiments, a binding relationship is established between the second functional module and the first functional module through an initialization binding phase, and this binding relationship remains valid once established. However, in some application scenarios, the second functional module is not fixedly soldered or permanently built into the electronic device, but is set in a detachable manner. For example, in some terminal device designs, the embedded user identification module can be designed as a pluggable card, allowing the user to remove the module from one electronic device and install it in another. In this case, when the second functional module is removed from the original electronic device and installed in the target electronic device, its binding relationship with the first functional module in the original electronic device no longer applies, and a new binding relationship needs to be established with the functional module in the target electronic device. Corresponding to this application scenario, this application embodiment also provides a rebinding process, which may include the following steps:

[0088] S401. In response to the removal of the second functional module from the electronic device and its installation in the target device, obtain the third hardware key of the third functional module in the target device.

[0089] After the second functional module is removed from the original electronic device, it is installed in the target electronic device. The target electronic device includes a third functional module, which has the same function as the first functional module and is used to provide hardware characteristic information of the target electronic device. After detecting the installation of the second functional module, the target electronic device obtains the third hardware key of the third functional module. This third hardware key is bound to the hardware characteristics of the third functional module, and its generation method is the same as that of the first hardware key, that is, it is generated based on the hardware characteristics of the third functional module and the root key stored internally.

[0090] S402. In response to the detection of a target event, perform a verification process based on the second hardware key and the third hardware key.

[0091] After detecting a target event, the target electronic device executes a verification process based on a second hardware key and a third hardware key. This verification process is similar to the one using a first and second hardware key, but the difference lies in the involvement of a second and a third functional module, and the use of a second hardware key (bound to the second functional module) and a third hardware key (bound to the third functional module). Specifically, the third functional module generates third verification information based on the third hardware key, the second hardware key, and a random verification number; the second functional module generates second verification information based on the second hardware key, the third hardware key, and the random verification number; and the two are compared. If they match, the verification passes.

[0092] S403. In response to successful verification, bind the second functional module to the third functional module.

[0093] After successful verification, the second functional module is bound to the third functional module to establish a communication association between them. Once the communication association is established, the second functional module can provide identity services normally in the target electronic device based on its stored identity configuration information.

[0094] It should be noted that verification during the binding process can be achieved in several ways. One method is user-in-person verification. For example, the user completes biometric authentication on the target electronic device using fingerprint or facial recognition. After successful authentication, the target electronic device confirms the user as an authorized user and then executes the binding of the second and third functional modules. Another method is authorization unbinding from the original device. For example, the user actively initiates an unbinding operation on the original electronic device, which sends an unbinding authorization command to the second functional module. Upon receiving this command, the second functional module clears the stored original first hardware key, enters a bindable state, and is then installed on the target electronic device to perform the binding change. Yet another method is authorization from the manufacturer's backend service. For example, the manufacturer's backend server holds the root authorization key. When a user needs to bind, they initiate a binding request to the backend through the application provided by the manufacturer. After verifying the user's identity, the backend issues an authorization token to the target electronic device, which then executes the binding of the second and third functional modules based on this authorization token. The above methods can be selected and combined according to specific application scenarios and security requirements.

[0095] Take the scenario of rebinding a detachable embedded user identity module as an example. A user purchases a new mobile phone and wants to remove the embedded user identity module from the old phone and install it in the new phone. The user removes the embedded user identity module from the old phone and installs it into the SIM card slot of the new phone. After the new phone powers on, it detects the installation of the embedded user identity module and obtains the third hardware key of the modem module (as the specific implementation of the third functional module) in the new phone. The new phone prompts the user for fingerprint verification. After the user presses their fingerprint and passes the verification, the new phone generates a random verification number. The modem module generates third verification information based on the third hardware key, the second hardware key, and the random verification number. The embedded user identity module generates second verification information based on the second hardware key, the third hardware key, and the random verification number. The two verifications match, and the verification is successful. The new phone binds the embedded user identity module to the modem module. The embedded user identity module provides normal identity services in the new phone, and the user can use the communication functions of the new phone normally.

[0096] This embodiment provides a rebinding scheme for a second functional module that is detachably configured. This allows the second functional module to re-establish its binding relationship with the functional module in the new device after the electronic device is replaced, ensuring the normal use of the second functional module. By setting verification conditions (such as user presence verification, authorization unbinding from the original device, authorization from the manufacturer's backend service, etc.), it ensures that the rebinding process is only conducted by legitimate users or with legitimate authorization, preventing the second functional module from being illegally migrated to other devices. This maintains security while ensuring user convenience.

[0097] In practical applications, the verification process can adopt different levels of complexity to adapt to different triggering scenarios.

[0098] For transient scenarios with low security risks, simplified verification processes can be adopted to improve user experience. For example, when a user rides an elevator, electronic devices experience a rapid switching process from network coverage to no network coverage and back again. During this process, the brief interruption of network signal is temporary, predictable, and short-lived; users typically only need to wait a few seconds to restore network connectivity. In this situation, if the complete verification process is executed every time the network is restored, including all steps such as verifying the current user's authorization, obtaining a random verification number, and generating verification information from the first and second functional modules and performing a two-way comparison, users may perceive an increased delay in network recovery, thus affecting the user experience. Therefore, for such transient scenarios, a simplified verification process can be adopted. For example, skipping the trusted execution environment's verification of the current user's authorization, directly generating a random verification number and performing two-way hardware verification. Since the hardware binding relationship itself is not broken, the simplified verification process can still effectively confirm the validity of the binding relationship between the two functional modules, while significantly shortening the verification time and reducing the perceived delay.

[0099] For scenarios with high security risks, such as when electronic devices are powered on or restarted, when switching from cellular to mobile networks after prolonged inactivity, or when users manually switch or enable configuration information, a complete verification process should be executed because these scenarios involve the complete activation of the second functional module or changes to configuration information, posing a potential risk of the binding relationship being broken or tampered with. A complete verification process includes all steps such as verifying whether the current user is an authorized user, obtaining a random verification number, and the first and second functional modules generating verification information and performing a two-way comparison. Although the complete verification process takes slightly longer (usually several hundred milliseconds), users have already anticipated the waiting time for device startup or configuration switching in these scenarios, and the additional delay of several hundred milliseconds will not have a significant impact on the user experience.

[0100] By employing verification processes of varying complexity across different target event scenarios, a reasonable balance between security and user experience can be achieved, ensuring security in high-risk scenarios while optimizing user experience in transient scenarios. Furthermore, for scenarios involving switching from cellular to mobile networks after prolonged periods of inactivity, the binding relationship may become uncertain due to the lack of verification over time. Executing a complete verification process helps to promptly confirm the validity of the binding relationship and avoid potential security risks.

[0101] See Figure 2This document illustrates a verification process for an application scenario provided by an embodiment of this application. In this application scenario, the electronic device is a mobile phone, the first functional module is a modem module, and the second functional module is an embedded user identity verification (eSIM) module. The process includes the following steps:

[0102] S501. Generate a public-private key pair in the Trusted Execution Environment (TEE) and distribute the public key to the modem module and the embedded user identity recognition module.

[0103] This step corresponds to the beginning of the aforementioned initialization and binding phase. The trusted execution environment generates an asymmetric key pair. The public key in this key pair is used to encrypt the hardware key for subsequent transmissions, while the private key is stored within the trusted execution environment itself and is never exported. The public key is then sent to both the modem module and the embedded user identification module.

[0104] S502, The modem module generates the first hardware key and submits it to the trusted execution environment.

[0105] The modulation and demodulation module generates a first hardware key based on its own hardware feature information (such as the International Mobile Equipment Identity) and the first root key stored internally. After encrypting the key with the received public key, it sends the key to the trusted execution environment.

[0106] S503, the embedded user identification module generates a second hardware key and submits it to the trusted execution environment.

[0107] The embedded user identification module generates a second hardware key based on its own hardware feature information (such as the embedded identification module identifier) ​​and the second root key stored internally. After encrypting the key with the received public key, it sends the key to the trusted execution environment.

[0108] S504. The trusted execution environment establishes a key exchange channel with the modem module and sends the second hardware key to the modem module.

[0109] After receiving the encrypted first and second hardware keys, the Trusted Execution Environment (TEE) decrypts them using its stored private key to obtain the first and second hardware keys. A secure channel is established between the TEE and the modem module via a key exchange protocol. This secure channel ensures the confidentiality and integrity of data during transmission. The TEE then sends the second hardware key to the modem module through this secure channel.

[0110] S505: The trusted execution environment establishes a key exchange channel with the embedded user identity recognition module and sends the first hardware key to the embedded user identity recognition module.

[0111] The trusted execution environment and the embedded user identity module also establish a secure channel through a key exchange protocol, and send the first hardware key to the embedded user identity module through this secure channel.

[0112] S506, the modem module, and the embedded user identification module each store the other's hardware key.

[0113] The modem module stores the received second hardware key in its non-volatile storage partition, while the embedded user identification module stores the received first hardware key in its internal secure storage area. At this point, the initialization binding phase is complete. The modem module and the embedded user identification module each hold the other's hardware key, forming a mutual binding relationship.

[0114] S507: The embedded user identification module has been activated.

[0115] During the use of a mobile phone, when the embedded user identity recognition module needs to be activated for communication, such as when the phone boots up and loads the embedded user identity recognition module, when the user switches configuration information, when the embedded user identity recognition module receives new configuration information, or when the modem module and the embedded user identity recognition module need to communicate and access each other, the mobile phone will detect that the embedded user identity recognition module has been activated, thereby triggering the subsequent verification process.

[0116] S508, Trusted Execution Environment requires fingerprint unlocking and random number generation.

[0117] After detecting the activation of the embedded user identification module, the trusted execution environment prompts the user to press their fingerprint. The mobile phone collects the current user's fingerprint information through the fingerprint sensor, and the trusted execution environment compares the collected fingerprint information with the pre-stored authorized user fingerprint template. If the comparison matches, the current user is confirmed as an authorized user, and the trusted execution environment generates a random number, which is then sent to both the modem module and the embedded user identification module. If the comparison does not match, random number generation is prohibited, the verification process terminates, and the mobile phone does not provide communication services.

[0118] S509. The modem module performs a hash operation to obtain the first verification information.

[0119] The modulation and demodulation module obtains the second hardware key stored in its own memory and the first hardware key provided by the embedded user identity recognition module. It concatenates the first hardware key and the second hardware key in a first order and inputs them into a hash function to perform a hash operation to obtain a first hash value. Then, it combines the first hash value with a random number sent by the trusted execution environment to generate the first verification information.

[0120] The S510 embedded user identity recognition module performs a hash operation to obtain the second verification information.

[0121] The embedded user identification module obtains the first hardware key stored in its own memory and the second hardware key provided by the modem module. It concatenates the second hardware key and the first hardware key in a second order and inputs them into the same hash function to perform a hash operation to obtain a second hash value. Then, it combines the second hash value with a random number sent by the trusted execution environment to generate the second verification information.

[0122] S511. Determine whether the first verification information matches the second verification information.

[0123] The modem module and the embedded user identification module exchange their generated verification information and compare it. If the first verification information matches the second verification information, then S512 is executed; otherwise, S513 is executed.

[0124] S512 allows the embedded user identification module and modem module to work together.

[0125] When the first verification information matches the second verification information, it indicates that the binding relationship between the modem module and the embedded user identity recognition module is valid, the embedded user identity recognition module has not been migrated to other mobile phones, the current user is an authorized user, and at this time the embedded user identity recognition module is allowed to provide identity services based on the stored identity configuration information, and the mobile phone can access the communication network normally.

[0126] S513, refusing to provide identity services.

[0127] When the first verification information does not match the second verification information, it indicates that the binding relationship between the modem module and the embedded user identity recognition module has been broken. For example, the embedded user identity recognition module may have been migrated to another mobile phone, or the current user may not be an authorized user. In this case, identity services will be refused and the mobile phone will not be able to access the communication network, thereby preventing the identity configuration information from being used illegally.

[0128] pass Figure 2 The verification process shown demonstrates that every time the mobile phone needs to activate the embedded user identity module for communication, it verifies the binding relationship between the modem module and the embedded user identity module, and confirms whether the current user is an authorized user. Communication service is only provided if both verifications are successful. This process effectively prevents the embedded user identity module from being migrated to other mobile phones. Even if the identity configuration information of the embedded user identity module is illegally obtained, it cannot pass verification on other mobile phones, thus solving the risks of identity impersonation and communication resource theft, and ensuring user communication security.

[0129] See Figure 3 This illustration shows the interaction relationships between various modules in a mobile phone and a schematic diagram of key generation and distribution provided in an embodiment of this application. In this application scenario, the mobile phone, as a specific implementation of an electronic device, includes a modem module, a trusted execution environment (TEE), and an embedded user identity (eSIM) module. The modem module generates a first hardware key (Kmd) based on the International Mobile Equipment Identity (IMEI) and its internally stored first hardware root key by performing a hash-based key derivation function (HKDF) operation through a hardware cryptographic engine (HW Crypto Engine). The embedded user identity module generates a second hardware key (Kesim) based on the embedded identity module identifier (EID) and its internally stored second hardware root key by performing the same hash-based key derivation function operation through a hardware cryptographic engine. The trusted execution environment caches the first and second hardware keys.

[0130] A secure channel can be established between the Trusted Execution Environment (TEE) and the modem module via the Diffie-Hellman Key Exchange Protocol (DH) to send the second hardware key (Kesim) to the modem module. Similarly, a secure channel can be established between the TEE and the embedded user identity module via the Diffie-Hellman Key Exchange Protocol to send the first hardware key (Kmd) to the embedded user identity module. Furthermore, the TEE communicates with both the modem module and the embedded user identity module via the Serial Peripheral Interface (SPI) and generates a random number (RND) during the verification process, which is then sent to both modules.

[0131] based on Figure 3 The illustrated process demonstrates that the modem module and embedded user identity module in the mobile phone can generate and exchange hardware keys during the initialization binding phase. The trusted execution environment, acting as a trusted third party, provides security during key distribution and random number generation, laying a hardware-level trust foundation for bidirectional verification in subsequent uses. Through this process, the mobile phone ensures that the embedded user identity module only functions correctly in the device where its bound modem module resides. When the embedded user identity module is migrated to another device, verification fails because the hardware characteristics of the modem module in the new device differ from the original device, effectively preventing the unauthorized migration or copying of identity configuration information.

[0132] See Figure 4 In this application embodiment, an electronic device is also provided, the electronic device comprising:

[0133] The first functional module 11 is used to provide the hardware features of the electronic device;

[0134] The second functional module 12 is used to store identity configuration information;

[0135] Processing module 13 is connected to the first functional module and the second functional module respectively;

[0136] The processing module detects a target event and obtains a random verification number; it obtains first verification information generated by the first functional module based on a first hardware key, a second hardware key, and the random verification number; it obtains second verification information generated by the second functional module based on the first hardware key, the second hardware key, and the random verification number; if the first verification information and the second verification information satisfy a target correspondence, the second functional module is allowed to provide identity services based on stored identity configuration information.

[0137] Wherein, the first hardware key is bound to the first hardware feature of the first functional module, the second hardware key is bound to the second hardware feature of the second functional module, and the random verification number is generated by a trusted execution environment.

[0138] In one embodiment, the second functional module is disposed in the electronic device in a detachable or non-detachable manner;

[0139] When the second functional module is set in a detachable manner, the second functional module has a unique hardware identifier, which is used to re-establish a binding relationship with the third functional module in the target electronic device after the second functional module is installed in the target electronic device.

[0140] When the second functional module is configured in a non-removable manner, the binding relationship between the second functional module and the first functional module is permanent.

[0141] It should be noted that the specific implementation of the first functional module, the second functional module, and the processing module in this embodiment can be referred to the corresponding content above, and will not be described in detail here.

[0142] In another embodiment of this application, a readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the verification method as described above.

[0143] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0144] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0145] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0146] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A verification method, the method comprising: The target event was detected; a random number of verifications was obtained. Obtain the first verification information generated by the first functional module based on the first hardware key, the second hardware key, and the random verification number; Obtain the second verification information generated by the second functional module based on the first hardware key, the second hardware key, and the random verification number; If the first verification information and the second verification information satisfy the target correspondence, the second functional module is allowed to provide identity services based on the stored identity configuration information; Wherein, the first hardware key is bound to the first hardware feature of the first functional module, the second hardware key is bound to the second hardware feature of the second functional module, and the random verification number is generated by a trusted execution environment; the first functional module is used to provide the hardware features of the electronic device, and the second functional module is used to store identity configuration information.

2. The method according to claim 1, wherein the target event includes at least one of the following: The second functional module is loaded after the electronic device is powered on or restarted; The configuration information of the second functional module is switched or enabled; The second functional module updates the configuration information; The second functional module receives configuration information related to communication access; The first functional module and the second functional module need to communicate and access each other in coordination.

3. The method according to claim 1, wherein obtaining the random verification number comprises: In response to verifying that the current user of the electronic device is an authorized user in the trusted execution environment, the random verification number is generated.

4. The method according to claim 1, wherein the first verification information is generated by combining the hash value obtained by concatenating the first hardware key and the second hardware key in a first order and inputting it into a hash function with the random verification number; The second verification information is generated by combining the hash value obtained by concatenating the second hardware key and the first hardware key in a second order and inputting it into the hash function with the random verification number; in, The first order is different from the second order.

5. The method according to claim 1, wherein the first hardware key is generated based on the first hardware feature of the first functional module and the first root key stored internally in the first functional module; and the second hardware key is generated based on the second hardware feature of the second functional module and the second root key stored internally in the second functional module.

6. The method according to claim 1, further comprising, before detecting the target event and obtaining the random verification number: Generate an asymmetric key pair, and send the public key of the asymmetric key pair to the first functional module and the second functional module respectively; The system receives the first hardware key encrypted from the first functional module and the second hardware key encrypted from the second functional module, wherein the key used for encryption is the public key. Decrypt using the private key in the asymmetric key pair to obtain the first hardware key and the second hardware key; The second hardware key is sent to the first functional module through a secure channel, and the first hardware key is sent to the second functional module, so that the first functional module stores the second hardware key and the second functional module stores the first hardware key.

7. The method according to claim 6, wherein the secure channel is established based on a key exchange protocol, the key exchange protocol being used to establish a shared key between the first functional module and the second functional module.

8. The method according to claim 1, wherein the second functional module is detachably disposed in the electronic device, and the method further comprises: In response to the removal of the second functional module from the electronic device and its installation in the target device, a third hardware key of the third functional module in the target device is obtained, and the third hardware key is bound to the hardware characteristics of the third functional module; In response to the detection of a target event, a verification process is executed based on the second hardware key and the third hardware key; Upon successful verification, the second functional module is bound to the third functional module.

9. An electronic device, comprising: The first functional module is used to provide the hardware features of the electronic device; The second functional module is used to store identity configuration information; The processing module is connected to the first functional module and the second functional module respectively; The processing module detects a target event and obtains a random verification number; it obtains first verification information generated by the first functional module based on a first hardware key, a second hardware key, and the random verification number; it obtains second verification information generated by the second functional module based on the first hardware key, the second hardware key, and the random verification number; if the first verification information and the second verification information satisfy a target correspondence, the second functional module is allowed to provide identity services based on stored identity configuration information. Wherein, the first hardware key is bound to the first hardware feature of the first functional module, the second hardware key is bound to the second hardware feature of the second functional module, and the random verification number is generated by a trusted execution environment.

10. The electronic device according to claim 9, wherein the second functional module is disposed in the electronic device in a detachable or non-detachable manner; When the second functional module is set in a detachable manner, the second functional module has a unique hardware identifier, which is used to re-establish a binding relationship with the third functional module in the target electronic device after the second functional module is installed in the target electronic device. When the second functional module is configured in a non-removable manner, the binding relationship between the second functional module and the first functional module is permanent.

Images