Offline identity authentication method, electronic device and vehicle

Abstract

This application provides an offline identity authentication method, electronic device, and vehicle, relating to the field of intelligent connected vehicle technology. It includes a local control unit applied to the electronic device; the local control unit is connected to a low-frequency wake-up module, a near-field communication module, and a security chip; the method includes: responding to a wake-up signal sent by the low-frequency wake-up module, controlling the near-field communication module to read the identity identifier of the authentication device and obtain one-time random information generated for this authentication from the security chip; sending a verification request carrying the identity identifier and one-time random information to the security chip and receiving the verification result returned by the security chip; if the verification result is successful, performing the corresponding access control operation on the electronic device. This application deploys the authentication logic, random information generation, and identity verification within the local security chip, achieving reliable and secure offline identity authentication and access control in environments with no network, weak network, or no signal.

Description

Technical Field

[0001] This application relates to the field of intelligent connected vehicle technology, and more specifically, to an offline identity authentication method, electronic device, and vehicle. Background Technology

[0002] With the rapid development of smart devices (such as cars, electronic devices, and smart locks), passive keyless entry and start systems (PKES) and similar keyless authentication scenarios have become mainstream configurations. The Near Field Communication (NFC) technology they rely on has been established as a core technology for device identity authentication across various fields due to its convenient, secure, and controllable near-field interaction features. Whether it is unlocking car doors, verifying the permissions of electronic devices, or opening smart locks, NFC enables trusted interaction between user identity and devices through short-range (<10cm) wireless transmission.

[0003] Currently, existing solutions generally adopt a vehicle-cloud linkage architecture to achieve identity authentication. When a user brings an NFC card, mobile phone or other NFC device close to the target device, the terminal device (such as the vehicle terminal, electronic lock controller, smart device access module) uploads the NFC device ID (Identity) to the cloud server through 4G / 5G, Wi-Fi and other networks. The cloud server then completes the permission query, blacklist and whitelist verification and authentication decision, and then issues control commands (such as unlocking the car door, enabling device functions, unlocking the door lock) to achieve authorized access.

[0004] However, existing solutions rely on vehicle-to-cloud (or edge-to-cloud) channels for identity verification, making it impossible to achieve reliable and secure offline identity authentication and access control locally. In offline scenarios (such as underground parking garages, tunnels, remote areas, environments where electronic devices have no signal, and smart locks are offline), the terminal device cannot interact with the cloud server (e.g., unable to upload an ID or receive instructions), directly resulting in the terminal device being unable to complete authorized access (e.g., the car cannot unlock, electronic devices cannot log in, and smart locks cannot open), ultimately leading to authentication failure and a broken user experience. Summary of the Invention

[0005] The offline identity authentication method, electronic device, and vehicle provided in this application deploy authentication logic, random information generation, and identity verification all within a local security chip. The entire process does not require the electronic device to interact with the cloud server for ID uploading or command issuance. This effectively solves the technical problems of existing solutions that rely on network channels to complete identity verification and are prone to authentication failure and access interruption in network-free scenarios such as underground garages, tunnels, and remote areas. It achieves reliable and secure offline identity authentication and access control in environments with no network, weak network, or no signal, ensuring that the electronic device can still complete authorization unlocking and access normally when disconnected from the network, and avoiding user experience disruption caused by authentication failure.

[0006] In a first aspect, an offline authentication method is provided, applied to a local control unit of an electronic device; the local control unit is connected to a low-frequency wake-up module, a near-field communication module, and a security chip; the method includes: responding to a wake-up signal sent by the low-frequency wake-up module, controlling the near-field communication module to read the identity identifier of the authentication device and obtain one-time random information generated for this authentication from the security chip, wherein the wake-up signal is generated by the low-frequency wake-up module when it detects the proximity of the authentication device; sending a verification request carrying the identity identifier and one-time random information to the security chip, and receiving the verification result returned by the security chip; if the verification result is successful, performing the corresponding access control operation on the electronic device.

[0007] In the above technical solution, in response to the wake-up signal generated when the low-frequency wake-up module detects the proximity of the authentication device, the near-field communication module is controlled to read the identity identifier of the authentication device and obtain the one-time random information generated for this authentication from the security chip, without relying on vehicle-cloud or edge-cloud channels for data transmission and command interaction. Subsequently, a verification request carrying the identity identifier and one-time random information is sent to the security chip, which performs identity legality verification and anti-replay verification locally and directly returns the verification result to the electronic device. If the verification result is successful, the corresponding access control operation is performed on the electronic device locally. Thus, this application deploys the authentication logic, random information generation, and identity verification within the local security chip, eliminating the need for ID upload or command delivery interaction between the electronic device and the cloud server. This effectively solves the technical problems of existing solutions that rely on network channels to complete identity verification and are prone to authentication failure and access interruption in network-free scenarios such as underground garages, tunnels, and remote areas. It achieves reliable and secure offline identity authentication and access control in environments with no network, weak network, or no signal, ensuring that the electronic device can still complete authorization unlocking and access normally when disconnected from network support, avoiding user experience disruption caused by authentication failure.

[0008] Secondly, an offline authentication device is provided, applied to the local control unit of an electronic device; the local control unit is connected to a low-frequency wake-up module, a near-field communication module, and a security chip; the device includes: a control module, used to control the near-field communication module to read the identity identifier of the authentication device and obtain one-time random information generated for this authentication from the security chip in response to a wake-up signal sent by the low-frequency wake-up module; the wake-up signal is generated by the low-frequency wake-up module when it detects the authentication device approaching; a sending and receiving module, used to send a verification request carrying the identity identifier and one-time random information to the security chip and receive the verification result returned by the security chip; and an execution module, used to perform corresponding access control operations on the electronic device if the verification result is successful.

[0009] Thirdly, an electronic device is provided, including a memory and a processor. The memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the electronic device to perform the methods of the first aspect or any possible implementation thereof.

[0010] Fourthly, a vehicle is provided, including the electronic equipment of the third aspect.

[0011] Fifthly, a computer-readable storage medium is provided that stores a program or instructions that cause a computer to perform the methods described in the first aspect or any possible implementation thereof.

[0012] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application so as to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more easily understood, specific embodiments of this application are given below. Attached Figure Description

[0013] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a schematic diagram of an offline identity authentication system provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 3 A flowchart illustrating an offline identity authentication method provided in this application embodiment. Figure 1 ; Figure 4A flowchart illustrating an offline identity authentication method provided in this application embodiment. Figure 2 ; Figure 5 A flowchart illustrating an offline identity authentication method provided in this application embodiment. Figure 3 ; Figure 6 A flowchart illustrating an offline identity authentication method provided in this application embodiment. Figure 4 ; Figure 7 A flowchart illustrating an offline identity authentication method provided in this application embodiment. Figure 5 ; Figure 8 This is a schematic diagram of the structure of an offline identity authentication device provided in an embodiment of this application; Figure 9 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Detailed Implementation

[0014] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0015] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0016] With the widespread application of smart devices, passive keyless entry and start systems have become the mainstream keyless authentication solution. Near Field Communication (NFC), with its advantages of convenient near-field interaction and high security, is also widely used in identity authentication scenarios such as car unlocking, device permission verification, and smart lock opening. Most existing authentication solutions adopt a vehicle-cloud or edge-cloud linkage architecture, requiring the NFC device's identity identifier to be uploaded to a cloud server for permission verification and authentication decisions. Such solutions are highly dependent on network communication and cannot complete reliable and secure offline identity authentication and permission control locally. In scenarios with offline or weak network connections, such as underground parking garages, tunnels, or areas with no signal, identity authentication failures and devices failing to authorize access are highly likely to occur, severely impacting reliability and user experience. Therefore, this application provides an offline identity authentication solution. The following detailed description, in conjunction with the accompanying drawings and multiple embodiments, illustrates the offline identity authentication method, electronic device, and vehicle of this application.

[0017] Before elaborating on the technical solution, the technical terms used in this application will be explained to facilitate subsequent understanding.

[0018] SE (Secure Element) is a dedicated hardware chip compliant with ISO / IEC 7816 and EMV standards, primarily used for securely storing keys and performing cryptographic operations; TEE (Trusted Execution Environment) is an independent secure area within the main processor used to run sensitive business code; NFC (Near Field Communication) operates in the 13.56MHz band, enabling short-range wireless data transmission within 10cm, while the 125kHz low-frequency signal, with its strong penetration and low power consumption, is widely used in scenarios such as vehicle key wake-up and access control sensing; OTA (Over-The-Air) refers to remotely updating vehicle system software or security data via a wireless network; VIN (Vehicle Identification Number) is a globally unique vehicle identification code that can be used for binding local security data and identity verification.

[0019] Figure 1 This is a schematic diagram of an offline identity authentication system provided in an embodiment of this application. Figure 1 As shown, the offline identity authentication system 100 includes: a local control unit 110, a low-frequency wake-up module 120, a near-field communication module 130, and a security chip 140.

[0020] The local control unit 110 serves as the control and communication hub of the offline identity authentication system. It is connected to the low-frequency wake-up module 120, the near-field communication module 130, and the security chip 140, coordinating their collaborative operation and executing the entire offline identity authentication process. The low-frequency wake-up module 120, connected to the local control unit 110, sends a wake-up signal to the local control unit 110 when an external authentication device is detected approaching. The near-field communication module 130, also connected to the local control unit 110, reads the identity identifier of the authentication device in response to the control of the local control unit 110. The security chip 140, connected to the local control unit 110 via a secure channel, securely stores encrypted authorized identity information (such as a whitelist) and, in response to verification requests from the local control unit 110, compares and verifies the received identity identifier based on this authorized identity information, and performs secure operations such as digital signature verification using relevant keys. During the digital signature verification process, the system uses a preset RSA (Rivest–Shamir–Adleman Algorithm) algorithm to complete the signature processing. First, the NFC data is combined with one-time random information and encoded into a data block to be signed according to a preset format. Then, using the public and private key pair pre-installed in the security chip, the private key is used to perform hash operations and hash value encryption operations on the data to be signed in sequence to obtain the corresponding signature result. The signature result is then appended to the original NFC data to form a complete NFC message carrying signature information. In the verification and failure handling phase for replay attack prevention, after receiving the aforementioned NFC message, the vehicle domain controller, acting as the receiver, first extracts the NFC data, one-time random information, and signature result. It then performs signature verification using a public key matching the security chip, performing the same hash operation on the NFC data and one-time random information to obtain a local hash value. Simultaneously, it decrypts the signature result using the public key to obtain the decrypted hash value and compares their consistency. During this process, the uniqueness of the one-time random information is simultaneously verified. By maintaining a cache or database of used one-time random information, it determines whether the current one-time random information has been reused. If the signature verification fails or the one-time random information already exists, it is determined that there is a risk of data tampering or replay attack. In this case, the receiver will directly reject the authentication request and related access operations such as vehicle start-up and door opening. Simultaneously, it records system logs containing information such as NFC data, one-time random information, and timestamps for subsequent source tracing analysis. It can also push authentication failure prompts to the user and, based on actual security needs, further strengthen monitoring, update security policies, and replace the security chip to improve the overall security protection capability of the system.

[0021] It should be noted that there is no direct signal connection between the low-frequency wake-up module 120, the near-field communication module 130, and the security chip 140. Furthermore, since the offline authentication system 100 is integrated into the electronic device, the local control unit 110, the low-frequency wake-up module 120, the near-field communication module 130, and the security chip 140 are arranged with physical spacing within the electronic device, further reducing mutual interference between low-frequency and NFC signals.

[0022] The local control unit 110 can be selected according to actual needs; for example, it can be selected as an in-vehicle domain controller. The low-frequency wake-up module 120 is a dedicated communication module using low-frequency wireless communication for proximity sensing of people or devices and standby wake-up. In the fields of vehicle and access control offline authentication, this type of module commonly uses a 125kHz low-frequency wake-up receiving antenna as the conventional hardware implementation. The near-field communication module 130 can be selected as a 13.56MHz NFC card reader with dual communication antennas; the security chip 140 can be selected as a security standard-compliant SE or eSE chip.

[0023] It should be noted that the hardware design and layout need to be optimized for the different characteristics of the 125kHz low-frequency signal and the 13.56MHz NFC signal to ensure performance and reduce interference. Firstly, regarding antenna type selection: a coil antenna is used for the 125kHz low-frequency wake-up antenna; a microstrip antenna or a PCB-embedded antenna is used for the 13.56MHz NFC card reader dual communication antenna. By appropriately selecting different types of antennas, their respective radiation characteristics and impedance requirements can be matched, reducing mutual interference between signals at the source.

[0024] Secondly, regarding antenna layout optimization: when arranging antennas inside electronic devices, the 125kHz low-frequency wake-up antenna and the NFC card reader dual communication antenna are physically separated to avoid them being too close together, thereby further reducing interference. Finally, regarding antenna performance tuning: performance is optimized by controlling the antenna's quality factor Q. Specifically, a lower quality factor Q value is configured for the 125kHz low-frequency wake-up antenna to obtain a wider operating bandwidth and ensure the reliability of wake-up detection; a higher quality factor Q value is configured for the 13.56MHz NFC card reader dual communication antenna to improve its frequency selectivity and effectively suppress out-of-band interference.

[0025] At the software signal processing level, the following optimization measures were adopted to improve the anti-interference capability and signal quality of the communication link: First, the modulation method was optimized, that is, a dedicated modulation method was adopted for the characteristics of different frequency band signals. For the 125kHz low-frequency wake-up signal, ASK (Amplitude Shift Keying) modulation method was used; for the 13.56MHz NFC card reader dual communication signal, PSK (Phase Shift Keying) or FSK (Frequency Shift Keying) modulation method was used. By selecting an appropriate modulation method, the anti-interference capability of the signal in complex environments can be improved. Second, in terms of signal filtering, the received signal can be filtered in real time in the software to remove out-of-band noise and interference. For the 125kHz low-frequency signal, a low-pass filter is used; for the 13.56MHz NFC signal, a band-pass filter with a center frequency around 13.56MHz is used to ensure that only signals in the effective frequency band can pass through, further improving the signal-to-noise ratio and communication reliability.

[0026] Furthermore, it should be noted that the aforementioned hardware modules (low-frequency wake-up module 120, near-field communication module 130, and security chip 140) and the optimized antenna system are integrated into the local control unit 110 or its hardware platform, and a local trusted execution environment (TEE) is built on this hardware. This TEE provides trusted execution in a general computing environment, handling business logic processing and user interaction. Upon receiving a signal triggered by the low-frequency wake-up module 120, it coordinates relevant software modules (such as controlling the near-field communication module 130) to perform data processing and flow control.

[0027] The security chip 140 primarily handles the most sensitive data, securely storing core data such as encrypted blacklists and whitelists of user NFC authentication devices and local keys. When the local trusted execution environment (TEE) needs to perform operations related to the data in the security chip (such as comparing local keys), it will send a request to the security chip 140 through a secure channel (such as the GP TEE APDU interface). After performing the corresponding critical operations, the security chip 140 will return the results to the local trusted execution environment (TEE).

[0028] Based on the above architecture, a typical offline authentication process is as follows: The low-frequency wake-up module 120 detects the proximity of the authentication device and sends a wake-up signal to the local control unit 110 (or its TEE); the Trusted Execution Environment (TEE) then controls the near-field communication module 130 to read the device's identity identifier; the TEE encapsulates this identifier and related parameters into a verification request and sends it to the security chip 140 through a secure channel; after completing local security verification, the security chip 140 returns the result to the TEE; if the verification is successful, the TEE generates a command to control the electronic device (such as a car door) to perform an unlocking operation. Both the low-frequency wake-up module 120 and the near-field communication module 130 can be installed on the vehicle's B-pillar or door handle.

[0029] The offline authentication system provided in this application consists of a local control unit, a low-frequency wake-up module, a near-field communication module, and a security chip. The local control unit establishes communication connections with the low-frequency wake-up module, the near-field communication module, and the security chip. The low-frequency wake-up module uses frequency-shift keying modulation to achieve long-distance, low-power device proximity detection. It can detect the approach of the authentication device and generate a wake-up signal with extremely low power consumption even in system standby mode, effectively reducing the overall standby power consumption of the system. The near-field communication module responds to wake-up commands, establishes a near-field communication session with the authentication device, completes identity identification reading and device legitimacy verification, and ensures the reliability of interactive data transmission. The security chip has a built-in encrypted storage unit and a cryptographic random information generator. It can locally encrypt and store a list of preset authorized identity information uniquely bound to the electronic device, and perform offline identity verification, one-time random information anti-replay checks, and signature verification to prevent the leakage of sensitive authorized data. As the core scheduling node of the system, the local control unit coordinates the collaborative work of various modules, enabling the entire system to complete the entire offline identity authentication process without relying on a wide area network or cloud server. While meeting automotive-grade security authentication requirements, it also ensures low power consumption and fast authentication response. The system can directly perform access control, unlocking, and other corresponding operations on electronic devices based on the authentication results, ensuring that electronic devices can still achieve highly secure local identity authentication and access control even when disconnected from network support.

[0030] Optionally, Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 2 As shown, the electronic device 200 may include a processor 210 and a memory 220.

[0031] The memory 220 stores machine-executable instructions that can be executed by the processor 210. When the electronic device 200 is running, these machine-executable instructions are executed. The processor 210 and the memory 220 communicate via a bus. The processor 210 can execute these machine-executable instructions to implement an offline authentication method.

[0032] The memory 220, processor 210, and bus components are electrically connected directly or indirectly to enable data transmission or interaction. For example, these components can be electrically connected via one or more communication buses or signal lines. The memory 220 includes at least one software functional module, which is stored in the memory 220 in the form of software or firmware or embedded in the operating system (OS) of the electronic device. This software functional module includes at least one executable module. The processor 210 is used to execute the executable module stored in the memory 220, such as the software functional modules and computer programs included in offline authentication methods.

[0033] The memory 220 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0034] The electronic device 200 can be selected according to the actual situation. Furthermore, the electronic device 200 has software capable of executing offline authentication methods or an offline authentication system that executes offline authentication methods, etc.

[0035] It should be noted that the electronic device described in this application is a controlled device and is also the main application object of this offline identity authentication method.

[0036] The offline authentication method provided in this application embodiment can be executed by a processor in the electronic device 200. This processor corresponds to the local control unit in the aforementioned offline authentication system. The offline authentication method provided in this application embodiment will be explained further below. Figure 3 A flowchart illustrating an offline identity authentication method provided in this application embodiment. Figure 1 .like Figure 3 As shown, the method may include: S310, in response to the wake-up signal sent by the low-frequency wake-up module, controls the near-field communication module to read the identity identifier of the authentication device and obtain the one-time random information generated for this authentication from the security chip.

[0037] The random information is generated locally in real time and is only valid for the current single authentication session; it cannot be reused. Specifically, the random information can be a randomly generated random number, random characters, a random character sequence, or any combination of numbers and characters.

[0038] The wake-up signal is generated by the low-frequency wake-up module when it detects the proximity of the authentication device. For example, when the low-frequency wake-up module continuously transmits a low-frequency detection signal using frequency shift keying (FSK) modulation, and the authentication device enters the preset detection range of the low-frequency wake-up module, the corresponding low-frequency sensing unit inside the authentication device establishes a wireless coupling interaction with the low-frequency wake-up module. The low-frequency wake-up module identifies the proximity behavior of the authentication device by detecting the coupling signal strength and interaction response characteristics. After confirming that the authentication device meets the proximity triggering conditions, the low-frequency wake-up module immediately generates a corresponding wake-up signal. This wake-up signal can carry the low-frequency device feature code corresponding to the authentication device. After the wake-up signal is generated, it is transmitted to the local control unit through a preset communication interface to trigger the subsequent near-field communication module activation and identity authentication process. The entire proximity detection and wake-up signal generation process is completed in low-power mode, without requiring the main system of the electronic device to be in a high-power operation state continuously.

[0039] The preset detection range can be selected according to actual conditions; for example, it can be selected to be within 4 meters. The low-frequency device signature is physical layer feature information extracted by the low-frequency wake-up module using frequency shift keying (FSK) modulation from the low-frequency response signal fed back by the approaching authentication device. It can be generated based on signal modulation parameters, transmission characteristics, or inherent signal attributes of the device, forming a unique correspondence with the authentication device. This low-frequency device signature is only used to identify the device object actually physically detected by the low-frequency wake-up module. It completes the authentication device consistency verification before establishing a near-field communication session, ensuring that the near-field interaction object matches the physically nearby device, thereby preventing signal relay attacks and device forgery. It only serves as a basis for verifying the physical authenticity of the device and does not directly participate in identity authorization determination. It is independent of the identity identifier used for subsequent legitimate identity verification in terms of data attributes, usage scenarios, and core purposes, jointly ensuring the security and reliability of offline authentication.

[0040] In one possible implementation, upon receiving a wake-up signal from the low-frequency wake-up module, the local control unit of the electronic device confirms that the authentication device has entered the preset detection range. It then switches itself from standby to operating state and sends an activation command. Upon receiving this activation command, the near-field communication module establishes a near-field communication connection with the authentication device, initiates data interaction according to the selected preset near-field communication protocol, and reads the unique identifier pre-written in the secure storage area within the authentication device via radio frequency field coupling. Simultaneously, the local control unit sends a random information retrieval request to the security chip. Based on its internally integrated cryptographic random information generator, the security chip generates one-time random information applicable only to this authentication session. This one-time random information possesses single-authentication validity, unpredictability, and non-repeatability, used for subsequent replay attack verification. Its generation and temporary storage processes are completed within the trusted environment of the security chip, without leaking the original random information parameters. After generation, the security chip feeds back the one-time random information to the local control unit, enabling the local control unit to obtain the one-time random information for this authentication session.

[0041] S320: Send an authentication request carrying an identity identifier and one-time random information to the security chip, and receive the authentication result returned by the security chip.

[0042] In one possible implementation, the local control unit first verifies the low-frequency device signature code previously detected by the low-frequency wake-up module and obtained through FSK modulation. It confirms that the signature code matches the one returned by the authentication device, completing a physical layer consistency check with the authentication device to ensure that subsequent interactions involve legitimate devices that are physically close. Simultaneously, the near-field communication module establishes a single authentication session with the authentication device based on the low-frequency device signature code and verifies the authentication device's legitimacy, confirming that the currently interacting device and the device detected by the low-frequency wake-up module are the same object. Subsequently, it successfully reads the identity identifier stored in the authentication device. This identity identifier is a unique legitimate credential within the authorized blacklist and whitelist, forming a two-dimensional authentication basis together with the low-frequency device signature code.

[0043] At this point, the local control unit can obtain a one-time random information (Nonce) generated by the cryptographic random information generator built into the security chip through a preset encrypted secure channel established with the security chip. This one-time random information is unique to this authentication and cannot be reused, thus preventing replay attacks at the source. Subsequently, the local control unit combines and encapsulates the identity identifier and the one-time random information according to preset verification request encapsulation rules to generate verification request data that conforms to the communication specifications of the security chip. The preset verification request encapsulation rules refer to the composition specifications pre-configured by the local control unit for assembling identity verification request data, which clearly define the target data fields and data concatenation logic included in the verification request, and can be selected according to actual conditions. Finally, the local control unit sends the verification request carrying the identity identifier and the one-time random information to the security chip through the preset encrypted secure channel. The entire sending process is encrypted, ensuring the security of the verification data transmission and conforming to the design principle of this application—being entirely offline and not dependent on the network—laying the data foundation for the offline verification operation of the security chip.

[0044] After the local control unit sends a verification request, it continuously monitors the preset encrypted security channel with the security chip and waits for the verification result returned by the security chip. After receiving the verification request, the security chip first parses the identity identifier and one-time random information in the verification request data. Then, it retrieves the preset authorized identity information list that is uniquely bound to the electronic device and is stored locally. It compares the authorization legality of the identity identifier and checks the validity of the one-time random information to confirm that the one-time random information is valid and unused for this authentication. It also completes a two-parameter linkage verification by combining the low-frequency device feature code from the pre-detection low-frequency detection stage. That is, the security chip generates a verification result that the authentication is successful only when the identity identifier verification is successful, the one-time random information check is valid, and the low-frequency device feature code matches. Otherwise, it generates a verification result that the authentication is unsuccessful. After receiving the verification result returned by the security chip through a preset encrypted security channel, the local control unit first verifies the integrity and legality of the verification result to confirm that the verification result has not been tampered with and has a legitimate source. Then, it performs subsequent access control operations based on the verification result. The entire receiving and verification process ensures that the local control unit can obtain the offline verification conclusion of the security chip, providing a reliable basis for the local access control of electronic devices, while further ensuring the security and reliability of the entire offline identity authentication process.

[0045] S330. If the verification result is successful, the corresponding access control operation is performed on the electronic device.

[0046] The verification result is "passed," meaning that the security chip uses an internal encrypted storage unit to compare the legitimacy of the identity identifier read by the near-field communication module based on a unique blacklist and whitelist of authorized identities bound to the electronic device. Simultaneously, it combines one-time random information to perform anti-replay attack verification and low-frequency device signature code to perform physical consistency verification. After multiple cryptographic verifications, it is determined that the device initiating the authentication is a legitimate authorized authentication device and that there are no illegal attacks such as signal relay, data tampering, or replay in this authentication session. Then, a dedicated verification command indicating successful verification is output to the local control unit. This command transmission follows the preset secure data encapsulation format and communication specifications between the local control unit and the security chip, and the entire interaction is completed between local hardware, without involving any data interaction with wide area networks or cloud servers.

[0047] In one possible implementation, after receiving a successful verification result from the security chip, the local control unit, without relying on external network support, directly outputs corresponding control signals to the electronic device's actuators through a pre-defined hardware control interface, based on a preset local access control policy. This allows the local control unit to perform matching access control operations on the electronic device. These access control operations include at least: unlocking the electronic device, enabling functional permissions, and granting access permissions—actions adapted to the actual application scenario of the electronic device. The entire access control execution process is completed collaboratively by the local hardware module. This ensures that the electronic device can still achieve highly secure identity authentication and access control in offline scenarios without network support, while also meeting the technical requirements of automotive-grade security authentication standards, low-power operation, and rapid response. It achieves direct linkage between authentication results and electronic device access control in offline states.

[0048] The offline identity authentication method provided in this application responds to a wake-up signal generated when the low-frequency wake-up module detects the proximity of the authentication device. It then controls the near-field communication module to read the authentication device's identity identifier and obtains a uniquely generated one-time random information from the security chip, eliminating the need for data transmission and command interaction via vehicle-to-cloud or edge-to-cloud channels. Subsequently, a verification request carrying the identity identifier and one-time random information is sent to the security chip, which performs identity legitimacy verification and anti-replay verification locally, directly returning the verification result to the electronic device. If the verification result is successful, the corresponding access control operation is performed locally on the electronic device. Thus, this application deploys the authentication logic, random information generation, and identity verification all within the local security chip, eliminating the need for ID uploads or command transmissions between the electronic device and the cloud server. This effectively solves the technical problems of existing solutions that rely on network channels for identity verification and are prone to authentication failure and access interruption in network-free scenarios such as underground parking garages, tunnels, and remote areas. It achieves reliable and secure offline identity authentication and access control in environments with no network, weak network, or no signal, ensuring that the electronic device can still complete authorization unlocking and access normally when disconnected from the network, avoiding user experience disruptions caused by authentication failures.

[0049] Figure 4 A flowchart illustrating an offline identity authentication method provided in this application embodiment. Figure 2 .like Figure 4 As shown, the above method for controlling the near-field communication module to read the identity identifier of the authentication device includes: S410 sends radio frequency signals through the near-field communication module to wake up the authentication device.

[0050] In one possible implementation, during the offline authentication process, after confirming the low-frequency device signature verification is successful, the local control unit sends a wake-up control command to the near-field communication module. Upon receiving this command, the near-field communication module, based on preset near-field communication operating parameters, radiates a radio frequency (RF) signal conforming to the near-field communication protocol standard. This RF signal forms an effective communication excitation area within the near-field range in the form of an alternating electromagnetic field. The authentication device integrates an RF sensing unit matched to the near-field communication module. When the authentication device enters this RF excitation area, its RF sensing unit acquires the RF signal energy emitted by the near-field communication module through electromagnetic coupling, converting this energy into its own startup power and state switching trigger signal. This causes the authentication device to switch from a low-power sleep / standby state to a working state capable of normal communication and interaction, completing a passive wake-up. This wake-up method eliminates the need for the authentication device to actively emit signals; it relies solely on the unidirectional RF excitation provided by the near-field communication module to wake the device. This effectively reduces the power consumption of the authentication device while ensuring the speed and stability of device interaction startup during offline authentication, aligning with the overall system design goals of low power consumption and reliable offline authentication.

[0051] S420: Receive the response signal returned by the authentication device.

[0052] The response signal carries the authentication device's identity identifier. This identifier is pre-securely stored in the authentication device's dedicated secure storage area and is only retrieved and loaded into the valid data segment of the response signal after the authentication device initiates a device legitimacy verification via the near-field communication module. The identity identifier's encapsulation in the response signal follows the near-field communication secure data encapsulation format preset by the local control unit and the authentication device. It can also be combined with preset verification request encapsulation rules and one-time random information to ensure that the data encapsulation format conforms to the near-field communication transmission standard and effectively prevent the identity identifier from being stolen, tampered with, or forged during transmission. This identity identifier and the low-frequency device signature are independent of each other and have clearly distinguishable functions. The low-frequency device signature is used to verify the physical layer authenticity of the authentication device to prevent relay attacks, while the identity identifier serves as the basis for subsequent offline authorization verification by the security chip and comparison with the authorized identity blacklist and whitelist bound to the electronic device. It is key data for determining whether the authentication device has the authority to access and operate the electronic device.

[0053] In one possible implementation, after establishing a single dedicated near-field communication authentication session with the authentication device and verifying the consistency between the low-frequency device signature code fed back by the authentication device and the low-frequency device signature code in the wake-up signal, the near-field communication module receives the response signal generated and fed back by the authentication device based on the challenge command of this authentication session. This response signal is wirelessly transmitted through the near-field communication standard communication link. The near-field communication module demodulates, filters, and captures the radio frequency signal during transmission according to the preset near-field communication signal reception specifications, eliminating channel interference and abnormal clutter signals, and then reliably receives the valid response signal. The entire signal reception process is controlled by the unified scheduling of the local control unit, allowing only the reception of response signals that match the current single authentication session, preventing illegal signals from entering the session, and ensuring the exclusive uniqueness of the response signal reception stage.

[0054] S430, Verify the response signal.

[0055] In one possible implementation, the local control unit first parses and extracts the low-frequency device signature field carried by the authentication device from the response signal. It then compares this signature with the low-frequency device signature previously detected and reported by the low-frequency wake-up module to verify that the device currently participating in near-field communication is the same device detected by the physical layer of the low-frequency wake-up module, thus preventing relay attacks and device impersonation. Secondly, the local control unit matches and verifies the one-time random information carried in the response signal with the authentication-specific random information pre-issued and stored by the security chip to confirm that this one-time random information is unique and generated for this single authentication session, and has not been duplicated. The system verifies the response signal's message structure and data format against unauthorized tampering and replay attacks. Simultaneously, the local control unit verifies the signal's legitimacy according to the agreed-upon secure data encapsulation format and preset verification request encapsulation rules, confirming that the response signal conforms to the near-field communication protocol specifications and secure data interaction standards, preventing packet loss, tampering, or format anomalies during transmission. Furthermore, the local control unit can transmit any digital signature fields that may be present in the response signal to the security chip, which uses its built-in encryption algorithm to verify the digital signature, confirming that the response signal originates from a legitimately authorized authentication device and that the data has not been illegally tampered with. Thus, through this multi-dimensional collaborative verification process, the local control unit can complete a comprehensive verification of the response signal. Only when all verification items pass can the response signal be deemed legitimate and valid, allowing subsequent identity reading and authentication operations to proceed. This verification logic fully covers the verification requirements for device physical authenticity, session uniqueness, data legitimacy, and identity legitimacy, ensuring the security and reliability of the offline identity authentication process.

[0056] The digital signature verification process is as follows: First, in a secure environment, a unique key pair (private key and public key) is generated for each NFC tag using a specialized key generation tool or algorithm. A unique random information generator ensures the uniqueness of the key pair. The private key is securely stored inside the NFC tag, while the public key is publicly available. Second, during production, a secure writing method is used to write the generated private key into a specific storage area of ​​the NFC tag. After writing, a verification operation is performed to ensure that the private key has been correctly written and can be read and used normally, thus completing the binding between the private key and the NFC tag. Subsequently, the NFC tag's public key is associated with the corresponding device information (such as device model, serial number, etc.) and stored in a trusted database or server. Simultaneously, digital signature technologies are used to ensure the integrity of the public key. To ensure authenticity and prevent public key tampering or forgery, during the authentication phase, when the NFC tag communicates with the reader, the NFC tag sends data containing its unique identifier and related information. After receiving the data, the reader retrieves the corresponding public key by querying a trusted database or server, and then uses this public key to sign and verify the data sent by the NFC tag. If the verification is successful, it proves that the NFC tag is authentic and the data has not been tampered with. In addition, to further enhance security, a fixed key update cycle can be set to periodically generate new key pairs for the NFC tag, securely write the new private key into the NFC tag, and synchronously update the public key storage in the database. During the update process, technologies such as encrypted transmission and digital signatures are used to ensure the security of key transmission and writing, and to prevent the key from being stolen or tampered with.

[0057] S440. After the verification is successful, the identity identifier is parsed and extracted from the response signal.

[0058] In one possible implementation, after the local control unit determines that the response signal returned by the authentication device has passed the aforementioned legality verification, low-frequency device signature consistency verification, and one-time random information validity verification, the local control unit drives the near-field communication module to perform data parsing operations on the response signal. Specifically, based on the near-field communication protocol specification and the communication data encapsulation format preset by the local control unit and the authentication device, the near-field communication module performs frame structure identification, data segment splitting, and message parsing on the response signal, removing non-identity data parts such as frame headers, check bits, and random information padding segments from the response signal, and restoring the data segment carrying valid identity information in the response signal; subsequently, the local control unit locates and extracts the unique identity identifier pre-stored by the authentication device from the parsed valid identity data segment according to preset identity identifier extraction rules. The above parsing and extraction processes are all completed by the local control unit in collaboration with the near-field communication module in a local offline environment, without relying on cloud data interaction. The extracted identity identifier will serve as the core basis for subsequent authorization list comparison by the security chip. The entire process strictly follows the near-field communication interaction sequence and security data parsing specifications to ensure the accuracy and completeness of identity identifier extraction.

[0059] The offline authentication method provided in this application uses a near-field communication module to wake up the authentication device by sending an outward radio frequency signal and to receive a response signal returned by the authentication device after it is woken up. This response signal carries the identity identifier corresponding to the authentication device. Subsequently, the legality of the response signal is verified to exclude the possibility of signal tampering, forgery, or abnormal transmission, thereby ensuring the authenticity and reliability of the interactive data. After the verification is passed, the corresponding identity identifier is parsed and extracted from the legal and valid response signal, providing an accurate and reliable identity basis for subsequent offline identity verification.

[0060] Figure 5 A flowchart illustrating an offline identity authentication method provided in this application embodiment. Figure 3 .like Figure 5 As shown, the above method involves sending a verification request carrying an identity identifier and one-time random information to the security chip, including: S510 combines and encapsulates identity identifiers and one-time random information based on the secure data encapsulation format agreed upon with the security chip to generate verification request data.

[0061] The secure data encapsulation format refers to the dedicated secure data message format agreed upon in advance by the local control unit and the security chip. It is a communication and parsing standard exclusive to both parties. This format is not a general public format, but an encapsulation standard customized to the offline identity authentication scenario of this application and to fit the hardware parsing capabilities of the security chip. Specifically, it includes: data frame header identification, effective data segment division, encryption verification field configuration, data encoding method, message length constraints, etc. At the same time, this format is also designed in conjunction with the security chip's built-in encrypted storage unit and cryptographic operation capabilities, which can ensure the anti-tampering and anti-eavesdropping characteristics of the encapsulated data when it is transmitted between the local control unit and the security chip.

[0062] Among them, the identity identifier is a unique identity credential used to represent the legitimate identity of the device, which is read from the secure storage area of ​​the authentication device after the near-field communication module completes a single authentication session and legitimacy verification with the authentication device; the one-time random information is random information that is exclusive to a single authentication session and cannot be reused, which is generated in real time by the security chip through the built-in cryptographic random information generator, and has the core security function of preventing replay attacks.

[0063] In one possible implementation, the local control unit must strictly adhere to the agreed-upon secure data encapsulation format before performing subsequent encapsulation operations. This ensures that the security chip can correctly identify and parse the subsequently generated verification request data, avoiding communication anomalies or verification failures due to format mismatches.

[0064] The local control unit, following preset verification request encapsulation rules, sequentially concatenates and integrates the aforementioned identity identifiers and one-time random information according to the agreed field order and data bit width. Then, it applies the secure data encapsulation format agreed upon with the security chip to standardize and encapsulate the concatenated raw data. During this process, data verification bits can be added simultaneously to ensure data transmission accuracy. This combined encapsulation operation is not a simple data overlay, but rather a standardized data processing process that combines offline authentication security requirements with the communication specifications of both parties, ensuring that the encapsulated data simultaneously carries core identity verification information and anti-replay security information.

[0065] Ultimately, the generated verification request data, after being combined and encapsulated, constitutes the formal request message from the local control unit to the security chip for offline identity verification. This formal request message fully complies with the security chip's communication parsing specifications and secure data encapsulation format requirements. It comprehensively contains two core verification fields: identity identifier and one-time random information, along with format identifiers and verification information recognizable by the security chip. After generating this verification request data, the local control unit transmits it to the security chip via a dedicated communication link. The security chip retrieves a built-in encrypted blacklist and whitelist of authorized identities uniquely bound to the electronic device, and combines this with the one-time random information to perform subsequent operations such as offline identity verification, replay protection checks, and signature verification. The generation of this verification request data is a crucial link between the near-field communication identity reading stage and the security chip's offline verification stage, and it is also the core data carrier ensuring the secure and orderly execution of the entire offline identity authentication process.

[0066] S520 sends a verification request carrying verification request data to the security chip.

[0067] In one possible implementation, the local control unit pre-establishes a reliable communication connection with the security chip, and the two follow a pre-negotiated internal communication interaction mechanism to achieve data transmission. After completing the encapsulation and generation of verification request data, the local control unit loads the verification request data, which includes the authentication device identifier, one-time random information, and low-frequency device signature, into a data frame structure conforming to the security chip's communication parsing specification, forming a complete verification request message. This verification request data is processed by the local control unit according to preset verification request encapsulation rules, combining multiple fields, and is standardized using a security data encapsulation format preset by the security chip to ensure data format, encoding method, and message structure are consistent. All components can be correctly identified and parsed by the security chip. Subsequently, the local control unit synchronously sends the verification request carrying complete verification request data to the security chip through the communication link between the local control unit and the security chip. The security chip then performs subsequent offline authentication processing operations such as anti-replay verification, identity legality verification, and signature verification based on the built-in encrypted storage of authorized identity blacklists and whitelists uniquely bound to the electronic device, combined with one-time random information. The above data transmission process relies on the collaborative interaction between the local hardware modules of the electronic device and does not rely on wide area networks or cloud servers throughout the process. This ensures the security and integrity of the verification request data during transmission and meets the low latency and high reliability requirements of automotive-grade offline identity authentication.

[0068] The offline authentication method provided in this application involves the local control unit combining the authentication device's identity identifier with one-time random information specific to this authentication, based on a security data encapsulation format preset by the security chip. This encapsulates the data to generate verification request data that conforms to the security chip's parsing standards. Subsequently, the control unit sends a verification request carrying this verification request data to the security chip. This dedicated encapsulation method effectively ensures the security and format standardization of the verification request data transmission, preventing data from being tampered with, lost, or parsed abnormally during transmission. Furthermore, combined with the unique characteristic of one-time random information, it further strengthens the anti-replay attack capability of the offline authentication process, improving the overall security and reliability of identity verification.

[0069] Optionally, receiving the verification result returned by the security chip in the above method includes: The system receives verification requests via a security chip and extracts the identity identifier and one-time random information from the verification request data.

[0070] In one possible implementation, the security chip and the local control unit are collaborative components that have established a pre-existing communication connection. After the local control unit completes the combination and encapsulation of identity identifier and one-time random information according to the preset verification request encapsulation rules and generates a verification request that conforms to the communication specifications of the security chip, it transmits the verification request to the security chip through the hardware communication link between the two. The security chip obtains the verification request in real time through its own configured dedicated data receiving interface, performs preliminary reception verification and caching processing on the message data. This reception process is only implemented through the local communication link between the local control unit and the security chip, without the need to access a wide area network or cloud server. It is fully adaptable to offline identity authentication application scenarios. At the same time, the security chip only receives compliant verification requests from the local control unit, which can filter out illegal external data interference and ensure the security of subsequent data processing.

[0071] After receiving the verification request, the security chip, based on the security data encapsulation format preset by itself and the local control unit, and the verification request encapsulation rules preset by the local control unit, performs standardized parsing operations on the verification request data carried within the verification request through its built-in data parsing module. Since the verification request data is formed by the local control unit combining the identity identifier and one-time random information according to preset rules and encapsulating them in a security format agreed upon by both parties, the security chip can reverse decompose the encapsulated verification request data according to the preset data frame structure and field sorting logic, separating and extracting the identity identifier used for identity legitimacy determination and the one-time random information used to prevent replay attacks. The parsing process is completed in the trusted execution environment inside the security chip, and the parsed data will be temporarily stored in the security chip's encrypted storage unit, providing compliant raw data support for subsequent offline verification steps such as authorized identity blacklist / whitelist comparison and one-time random information validity verification.

[0072] The identity is verified using a security chip based on a one-time random information and a pre-defined list of authorized identity information stored in the security chip, and the verification result is then received.

[0073] The preset authorized identity information list is a blacklist and whitelist of authorized identities bound to the electronic device. This blacklist and whitelist are pre-written and encrypted and stored in a separate encrypted storage unit of the security chip, forming a one-to-one hardware binding relationship with the electronic device, preventing unauthorized tampering or portability. The whitelist stores the identity identifiers of legitimate authenticated devices with access and usage rights to the electronic device, while the blacklist stores the identity identifiers of unauthorized authenticated devices with restricted access. The security chip uses this authorized identity blacklist and whitelist to compare and verify the identity identifiers, providing the data basis for controlling the access rights of the electronic device in offline mode. This binding relationship is set during the initial configuration phase of the electronic device, ensuring the security of offline identity authentication and dedicated access control capabilities.

[0074] In one possible implementation, after the local control unit transmits the encapsulated verification request data to the security chip, the security chip first extracts the one-time random information contained in the verification request data. It verifies that this random information is a single valid random information generated for this offline identity authentication session, confirming that the current authentication session is a legitimate session initiated in real time, thus preventing replay attacks after the authentication data is illegally intercepted. Subsequently, the security chip retrieves a preset list of authorized identity information stored in the chip's internal encrypted storage, compares and verifies the identity identifiers obtained through the near-field communication module with the identity information in the list one by one, and combines this with the one-time random information to complete the validity verification of this authentication session. The legality of the identity identifiers is verified through dual verification logic. After the verification is completed, the security chip generates a verification result containing either verification passed or verification failed, and feeds the verification result back to the local control unit. The local control unit receives the verification result and provides data basis for subsequent access control operations of electronic devices.

[0075] The offline identity authentication method provided in this application involves the security chip receiving a verification request and then parsing the identity identifier and one-time random information from the verification request data carried in the verification request. Subsequently, the security chip uses this one-time random information in conjunction with its own built-in authorized identity blacklist and whitelist, which are uniquely bound to the electronic device, to perform offline security verification of the identity identifier. The one-time random information effectively prevents authentication data replay attacks, ensuring the uniqueness and tamper-proof nature of the verification process, and thus generating the corresponding verification result. Finally, the local control unit receives the verification result fed back by the security chip.

[0076] Figure 6 A flowchart illustrating an offline identity authentication method provided in this application embodiment. Figure 4 .like Figure 6 As shown, the access control operation in the above method includes an unlocking operation. If the verification result is successful, the corresponding access control operation is performed on the electronic device, including: S610. If the verification result is successful, the corresponding device control command is generated.

[0077] The verification result being "passed" means that the security chip has completed the joint verification of the identity identifier, low-frequency device signature, and one-time random information, confirming that the identity identifier falls within the authorized identity whitelist that is uniquely bound to the electronic device, the one-time random information has not been reused to resist replay attacks, and the consistency verification of the low-frequency device signature has passed. All of the above multiple verification conditions are met.

[0078] In one possible implementation, after the local control unit determines that the verification result is successful, it automatically generates device control commands matching the current authentication scenario based on preset device control strategies and command generation rules. This command generation process does not rely on cloud server interaction or network data transmission; it is completed independently within the local control unit. The generated device control commands are used to perform corresponding access control and execution operations on the electronic device. For example, in a scenario where the electronic device is a vehicle, the device control commands could specifically be vehicle unlocking commands, door opening commands, or in-vehicle device access authorization commands. The command format conforms to the electronic device's own vehicle control bus communication specifications and can be directly sent to the vehicle's actuators to complete the corresponding control actions. This enables secure local control of the electronic device based on the legitimate identity authentication result in offline scenarios without network support.

[0079] S620: Execute device control commands to drive the actuator of the electronic device to perform an unlocking operation.

[0080] In one possible implementation, after receiving a successful authentication result from the security chip, the local control unit generates a device control command corresponding to the unlocking operation based on preset device control logic. The generation rules and format of this device control command are adapted to the actuator of the electronic device and follow established communication and interaction specifications between the local control unit and the actuator. The local control unit then transmits the generated device control command to the corresponding actuator of the electronic device. This actuator is a hardware execution component on the electronic device used to implement access control actions. In the scenario where the electronic device is a vehicle, it may specifically include a door lock actuator, a central locking drive mechanism, or a body controller drive module. Upon receiving the device control command from the local control unit, the actuator completes the mechanical or electronic drive action according to the action logic specified in the command, thereby unlocking the electronic device and completing the full-process access control after offline authentication. The entire unlocking control process is completed locally, without relying on a cloud server or external network interaction. Closed-loop control is achieved through the direct communication connection between the local control unit and the actuator, ensuring the real-time performance and reliability of electronic device access control operations in network-free scenarios.

[0081] The offline identity authentication method provided in this application, if the identity authentication result is successful, the local control unit generates the corresponding device control command based on the verification result and executes the device control command to drive the actuator of the electronic device to complete the unlocking operation; the entire control process is completed independently locally without relying on network interaction, and under the premise of ensuring authentication security and reliability, it realizes the rapid issuance and execution of unlocking commands, improving the response efficiency and ease of use of electronic devices in offline scenarios.

[0082] Optionally, the above method further includes: If the verification result is unsuccessful, an access denial command is generated, and a security audit log is recorded.

[0083] The security audit log records standardized authentication behavior information stored locally on the electronic device. Its log fields are configured and populated by the local control unit according to preset log specifications. This security audit log records the timestamp of the authentication event, the authentication device identifier that triggered the event, and the reason code for authentication failure. The timestamp is obtained and written by the local real-time clock module of the electronic device, identifying the specific moment the illegal authentication behavior occurred and ensuring the traceability of the event sequence. The authentication device identifier is derived from the identity information read from the authentication device by the near-field communication module, used to identify the device entity that initiated the illegal authentication request. The reason code is fed back to the local control unit by the security chip when verification fails, used to standardize the specific type of authentication failure, including but not limited to inconsistencies in low-frequency device signature verification, identity identifiers not on the authorized blacklist or whitelist, and failure of one-time random information verification. The standardized reason code enables clear differentiation and recording of authentication failure types, providing data support for subsequent offline security event investigation and device access management.

[0084] Taking a vehicle as an example, the security audit log records at least the following: authentication-related information, vehicle status information, network connection information, and other relevant information. Authentication-related information includes at least: authentication time, authentication location, authentication device information, and authentication result. The authentication time is the specific time of each NFC authentication, accurate to the second. The authentication location is the vehicle's current location information obtained through the vehicle positioning system, including latitude, longitude, and specific address. The authentication device information is device information related to the NFC function, such as the NFC chip model and serial number, to determine which NFC device performed the authentication operation. The authentication result clearly records whether each authentication was successful or failed; if it failed, it records the specific failure reason code (e.g., incorrect password, invalid card, communication failure, etc.). Vehicle status information includes at least: vehicle driving status, vehicle door lock status, and vehicle power status. Vehicle driving status records whether the vehicle was moving or stationary during authentication, and related data such as vehicle speed and acceleration. Vehicle door lock status displays whether the vehicle doors, trunk, etc., are locked or unlocked. Vehicle power status includes different power modes such as vehicle start, engine off, and standby. Network connection information includes at least: network type, network signal strength, and whether the vehicle is connected to the network. Network type records the type of network the vehicle is currently connected to, such as 4G, 5G, or Wi-Fi. Network signal strength displays the network signal strength value to indicate network connection quality. Whether the vehicle is connected to the network indicates whether it is connected during authentication; if not, relevant information should be recorded in the log. Other relevant information includes at least: vehicle VIN code, user account information, and system version information; the vehicle VIN code is the vehicle's unique identifier. User account information, if the vehicle system is associated with a user account, records the user account ID or other identifying information used for authentication; system version information records the vehicle's operating system version, NFC-related software version, etc., to facilitate version compatibility checks in case of problems.

[0085] In one possible implementation, if the offline identity authentication fails, it indicates that the authentication device initiating the authentication has failed the comprehensive verification conducted by the security chip based on authorized identity blacklists and whitelists, one-time random information anti-replay verification, and low-frequency device signature consistency verification. This indicates an authentication request from an illegal or unauthorized device. In response to this failure, the local control unit of the electronic device automatically generates an access denial command to prohibit unauthorized access operations. This command directly acts on the electronic device's permission execution module, blocking requests for unlocking, accessing, and other related operations. Simultaneously, the local control unit triggers a security audit log generation process. Based on the system's built-in logging rules, it automatically creates corresponding security audit log records. This log generation operation is coordinated and scheduled by the local control unit, without relying on cloud servers or network environments, and is executed entirely offline on the electronic device, enabling real-time recording and tracing of unauthorized authentication activities.

[0086] The offline authentication method provided in this application will generate an access denial command if the authentication result fails, in order to block unauthorized access and ensure the security of electronic devices. At the same time, it will generate a corresponding security audit log record, which will be used to record the timestamp of the authentication event, the device identifier that initiated the authentication, and the authentication failure reason code. This will enable traceable management of abnormal authentication behavior, provide reliable data support for subsequent security investigation, fault location and risk audit, and further improve the security control and traceability capabilities of the offline authentication system.

[0087] Optionally, the above method further includes: If the verification results are all unsuccessful after a preset number of consecutive attempts, the authentication function of the near-field communication module will be locked for a preset duration.

[0088] Both the preset number of attempts and the preset duration can be configured and adjusted locally according to actual security needs.

[0089] In one possible implementation, during the offline authentication process, after each successful authentication of an authentication device, the security chip sends the verification result back to the local control unit in real time. The local control unit simultaneously counts and tracks the number of failed authentication attempts, monitoring whether the number of failures reaches a pre-set limit. When the local control unit determines that the count of consecutive failed authentication attempts matches the preset limit (i.e., the preset number of consecutive failures are all unsuccessful), it immediately sends an authentication function lock control command to the near-field communication module. Upon receiving this lock command, the near-field communication module immediately suspends and disables all authentication-related functions, including near-field authentication session establishment, identity verification, and device legitimacy checks, and ceases to respond to any near-field interaction requests from external authentication devices. This locked state will be maintained for a preset duration set by the local control unit. During the preset duration, the authentication function of the near-field communication module will always be disabled and locked. After the local control unit reaches the preset duration, it will automatically send an unlock command to the near-field communication module to unlock the authentication function of the near-field communication module. The near-field communication module will then resume normal offline identity authentication functions and can re-establish an authentication session with the external authentication device and execute the identity verification process.

[0090] The aforementioned continuous failure locking mechanism achieves a fully localized closed-loop operation through the counting and judgment of the local control unit, the issuance of instructions, and the start and stop execution of the near-field communication module. It does not rely on cloud server interaction and can effectively prevent illegal attacks such as brute-force attacks and malicious attempts against offline identity authentication systems, further improving the identity authentication security of electronic devices in offline scenarios.

[0091] Within a preset time period, new identity authentication cannot be initiated through the near-field communication module.

[0092] In one possible implementation, upon detecting security risks such as authentication session anomalies, device legitimacy verification failures, mismatches between identity identifiers and authorized identity blacklists / whitelists, or failure of one-time random information verification, the local control unit retrieves its own preset stored risk control duration parameters or the security lock duration configuration issued by the security chip, using these as the benchmark for the preset duration. During the duration of this preset duration, the local control unit will implement permission locking control for the identity authentication of the near-field communication module, suspend the issuance of authentication session establishment commands to the near-field communication module, cease responding to authentication start requests triggered by the low-frequency wake-up module, and simultaneously prohibit the near-field communication module from establishing single authentication sessions with the authentication device and performing device legitimacy verification. During the verification, reading of identity identifiers, and encapsulation of verification request data, the security chip simultaneously suspends authentication-related processing flows such as random information generation, signature verification, and list comparison, retaining only the basic operating state. Through the above hardware collaborative control method, frequent probing, brute-force attacks, and repeated replay attacks launched by malicious devices against the offline identity authentication system can be effectively prevented, improving the identity authentication security protection capability of electronic devices in offline scenarios. This locking mechanism does not rely on cloud network commands, but is entirely implemented by the local control unit and the local scheduling logic of the security chip. After the preset time expires, the local control unit automatically releases the authentication permission lock on the near-field communication module, and the system resumes the normal offline identity authentication process.

[0093] Generate and record authentication circuit breaker event logs.

[0094] The authentication circuit breaker event log serves as the security audit data carrier for the offline identity authentication system, recording two types of information: continuous authentication failure events and triggered locking operation information. Regarding the recording of continuous authentication failure events, the log fully records the cumulative number of consecutive authentication failures, the timestamp of each failure, the identity identifier fragment of the authentication device involved, and the specific type of failure (e.g., signature verification failure, identity identifier comparison failure, random information signature verification failure, etc.). Regarding the recording of triggered locking operations, the log synchronously records the circuit breaker locking strategy triggered when continuous authentication failures reach a threshold, including at least: the electronic device's locking level, locking duration, locking activation time, unlocking requirements, and the trigger threshold for the locking operation. By fully recording these two types of information, the system achieves end-to-end retention of abnormal authentication behavior, facilitating security auditing, anomaly investigation, and access control strategy optimization in offline scenarios, thus ensuring the security of identity authentication for vehicles and other electronic devices.

[0095] In one possible implementation, when the number of consecutive failed authentication operations initiated by the authentication device reaches a preset circuit breaker threshold, the local control unit immediately initiates the generation process of the authentication circuit breaker event log. The security chip provides trusted log storage space based on its internal encrypted storage unit. The local control unit, according to a preset log encapsulation specification, structures and organizes the behavioral data related to this circuit breaker trigger, forming a standardized authentication circuit breaker event log. This log is then written to the encrypted storage area of ​​the security chip or the local trusted storage partition of the electronic device to complete the recording operation. The entire generation and recording process is completed independently in an offline environment, without relying on cloud servers or external networks. Furthermore, the log data is stored in an encrypted manner to prevent unauthorized tampering, deletion, or theft, providing trusted data support for subsequent identity authentication behavior traceability and security control. The preset circuit breaker threshold can be selected according to actual conditions.

[0096] The offline authentication method provided in this application will lock the authentication function of the near-field communication module for a preset duration if the authentication results fail for a preset number of consecutive times. During the locked period, any new authentication process will be prohibited from being initiated through the near-field communication module. At the same time, an authentication circuit breaker event log will be generated and retained to fully record the consecutive authentication failure events and the locked operations triggered, thereby effectively resisting illegal attacks such as brute-force attacks and malicious probing, improving the system's security protection capabilities in offline authentication scenarios, and providing a traceable basis for subsequent security audits and abnormal behavior tracing.

[0097] Figure 7 A flowchart illustrating an offline identity authentication method provided in this application embodiment. Figure 5 .like Figure 7 As shown, the above method also includes: S710: When the low-frequency wake-up module detects that the authenticated device has entered the preset detection range of the low-frequency wake-up module, a wake-up signal is generated.

[0098] The preset detection range formed by the low-frequency wake-up module is not a fixed spatial area. Its actual effective coverage radius, coverage angle, and detection boundary are directly determined by antenna layout parameters such as the number of antennas, installation position, radiation direction, antenna gain, and signal transmission power of the low-frequency wake-up module. The configuration of antenna layout parameters directly relates to and limits the size and shape of the preset detection range. Meanwhile, to avoid electromagnetic interference, signal crosstalk, and inter-antenna coupling interference between the low-frequency signals of the low-frequency wake-up module and the high-frequency near-field communication signals of the near-field communication module, and to ensure that both modules can operate independently and stably, the antennas of the low-frequency wake-up module and the near-field communication module are physically spaced apart within the electronic device. They are installed independently in separate areas according to a preset spacing, thereby eliminating signal interference between different communication modules and ensuring the synchronous reliability of low-frequency wake-up detection and near-field authentication.

[0099] In one possible implementation, when the authentication device approaches the electronic device, the low-frequency wake-up module radiates a frequency-shift keyed low-frequency detection signal through its own antenna, forming a stable signal coverage area. When the authentication device enters the preset detection range corresponding to this signal coverage, it generates a corresponding low-frequency signal interaction response with the low-frequency wake-up module. After detecting this valid interaction signal, the low-frequency wake-up module determines that the authentication device has entered the preset detection area, and then generates and outputs a high-level wake-up signal to the local control unit to trigger the subsequent near-field communication authentication process. The entire process does not require network involvement and can be completed solely through low-frequency signal triggering in standby mode, featuring low power consumption and high trigger reliability.

[0100] S720 receives the wake-up signal generated by the low-frequency wake-up module.

[0101] In one possible implementation, the local control unit is a processor built into the electronic device, which maintains a communication connection with the low-frequency wake-up module. When the electronic device is in standby or sleep mode, the low-frequency wake-up module uses Frequency Shift Keying (FSK) modulation to continuously detect proximity to the external environment with preset low-power parameters. When the authenticated device enters the preset sensing area of ​​the low-frequency wake-up module, the module obtains the low-frequency device signature code corresponding to the authenticated device through FSK signal interaction, and generates a wake-up signal carrying the low-frequency device signature code. The local control unit receives the wake-up signal in real time through the local communication link with the low-frequency wake-up module, thereby sensing the approach of the authenticated device and simultaneously acquiring feature information for subsequent device consistency verification. The generation, transmission, and reception of the wake-up signal are all completed locally on the electronic device, without relying on any wide area network or cloud server. This achieves low-power triggering in the system standby state and provides reliable triggering conditions and pre-verification data for the activation of the near-field communication module and the establishment of the authentication session.

[0102] The offline authentication method provided in this application generates and outputs a wake-up signal when the low-frequency wake-up module detects an authentication device entering its preset detection range. The preset detection range is adapted to the antenna layout of the low-frequency wake-up module to ensure the accuracy and sensitivity of device proximity detection. Simultaneously, the antennas of the low-frequency wake-up module and the near-field communication module are arranged with physical spacing, effectively avoiding signal crosstalk and mutual interference between the two types of antennas, thus ensuring the stability of low-frequency wake-up detection and subsequent near-field communication. The local control unit receives the wake-up signal generated by the low-frequency wake-up module to trigger the subsequent near-field authentication process.

[0103] Optionally, after verifying the results, the method further includes: It has a comprehensive offline update and local whitelist management mechanism.

[0104] Among them, the offline update mechanism synchronizes the cloud blacklist to the local device through secure OTA (over-the-air) technology, building a complete security closed loop of "cloud management and local execution", which ensures authentication security in offline mode while realizing dynamic updates of the blacklist.

[0105] In addition, for the local entry and synchronization of new whitelist entries in offline mode, the specific method is as follows: First, two preparatory steps are required: 1) Prepare a secure entry device with specific permissions (such as an authorization management terminal, smart device, etc.). This device must establish a secure data transmission channel with the vehicle's local storage system (such as USB interface, Bluetooth connection, etc.) and be securely authenticated. 2) Determine the unique identification information of the NFC tag (such as serial number, UID, etc.) and ensure its uniqueness throughout the entire system to avoid authorization confusion and errors. After preparation, follow these steps for entry: First, connect the entry device to the vehicle's local system using a secure connection method such as USB or Bluetooth, ensuring a stable and secure connection to prevent data interruption or tampering. Then, open the dedicated whitelist entry interface on the entry device and obtain the unique identification information of the NFC tag to be added through manual input, scanning a QR code, or NFC reading. Depending on actual needs, corresponding operation permissions (such as unlocking the car door, starting the vehicle, etc.) and permission validity period (fixed time period or permanent validity) can be optionally set for the tag. After verifying the entered information, the operator confirms and saves it. Before information is sent to the vehicle's local storage system, the legitimacy of the data entry device, the identity of the operator, and the completeness and accuracy of the information must be verified. After successful verification, the information is encrypted using an encryption algorithm and stored in the vehicle's secure storage area. Finally, the data entry device sends the entry result back to the operator; if the entry fails, an error message is displayed for troubleshooting and re-entry.

[0106] It is important to note that local whitelist entry requires strict management of operator permissions, ensuring that only authorized personnel can perform related operations. Regular backups of local whitelist data are necessary (storage on external devices or in the cloud), and a recovery strategy must be established. Security audits and monitoring of entry operations are required, along with recording relevant information to ensure device compatibility and timely software updates. Furthermore, when the vehicle is connected to the network, newly added local whitelist entries must be synchronized to the cloud to ensure data consistency. Additionally, this application features a dedicated offline authentication protocol stack. When a legitimate device is detected by a low-frequency signal, the NFC module is automatically activated, reading the unique device ID from the NFC tag. Hash comparison and signature verification are then performed in the local security chip, without initiating any network requests, achieving fast and secure authentication in a purely offline state.

[0107] Based on the same inventive concept, this application also provides an offline identity authentication device. Since the principle of the device in this application is similar to the offline identity authentication method described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0108] Figure 8 This is a schematic diagram of an offline identity authentication device provided in an embodiment of this application. Figure 8 As shown, the offline authentication device 800 is applied to the local control unit of an electronic device; the local control unit is connected to a low-frequency wake-up module, a near-field communication module, and a security chip; the device includes: The control module 801 is used to respond to the wake-up signal sent by the low-frequency wake-up module, control the near-field communication module to read the identity identifier of the authentication device, and obtain the one-time random information generated for this authentication from the security chip. The wake-up signal is generated by the low-frequency wake-up module when it detects that the authentication device is close. The transmitting and receiving module 802 is used to send a verification request carrying an identity identifier and one-time random information to the security chip, and to receive the verification result returned by the security chip; The execution module 803 is used to perform the corresponding access control operation on the electronic device if the verification result is successful.

[0109] In one optional implementation, the control module 801 is specifically configured to: send a radio frequency signal through a near-field communication module to wake up the authentication device; receive a response signal returned by the authentication device, the response signal carrying the identity identifier of the authentication device; verify the response signal; and after the verification is successful, parse and extract the identity identifier from the response signal.

[0110] In one optional implementation, the sending and receiving module 802 is specifically used to: combine and encapsulate the identity identifier and one-time random information based on the security data encapsulation format agreed upon with the security chip to generate verification request data; and send a verification request carrying the verification request data to the security chip.

[0111] In one optional implementation, the sending and receiving module 802 is specifically configured to: receive a verification request through a security chip, and parse the identity identifier and one-time random information from the verification request data in the verification request; verify the identity identifier through the security chip based on the one-time random information and a preset authorized identity information list in the security chip to obtain a verification result; the preset authorized identity information list is a blacklist and whitelist of authorized identities bound to the electronic device; and receive the verification result.

[0112] In one optional implementation, the access control operation includes an unlocking operation. The execution module 803 is specifically used to: generate a corresponding device control instruction if the verification result is successful; and execute the device control instruction to drive the actuator of the electronic device to perform the unlocking operation.

[0113] In an optional implementation, the execution module 803 is further configured to: generate an access denial instruction and generate a security audit log record if the verification result is unsuccessful; wherein the security audit log record is used to record the timestamp of the authentication event, the authentication device identifier that triggered the authentication event, and the reason code for the authentication failure.

[0114] In an optional implementation, the execution module 803 is further configured to: if the verification results are all unsuccessful for a preset number of consecutive times, lock the authentication function of the near-field communication module for a preset duration. Within a preset time period, new identity authentication is prohibited through the near-field communication module; Generate and record authentication circuit breaker event logs, which are used to record consecutive authentication failure events and the locking operations triggered.

[0115] In an optional implementation, the control module 801 is further configured to: generate a wake-up signal when the low-frequency wake-up module detects that the authentication device has entered the preset detection range of the low-frequency wake-up module; wherein the preset detection range is associated with the antenna layout of the low-frequency wake-up module, and the antenna of the low-frequency wake-up module is physically spaced apart from the antenna of the near-field communication module; and receive the wake-up signal sent by the low-frequency wake-up module.

[0116] It should be noted that for details not disclosed in the offline identity authentication device of this application embodiment, please refer to the details disclosed in the offline identity authentication method of this application embodiment, which will not be repeated here.

[0117] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more microprocessors, or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).

[0118] Optionally, Figure 9 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. Figure 9 As shown, the vehicle 900 may include at least: electronic equipment 200.

[0119] It should be noted that the aforementioned offline identity authentication system is the hardware functional architecture for implementing the offline identity authentication method. Through the coordinated operation of a local control unit, a low-frequency wake-up module, a near-field communication module, and a security chip, it completes the entire authentication process, including external authentication device proximity detection, session establishment, legitimacy verification, and offline security verification. The aforementioned electronic device (i.e., the controlled device) serves as the device carrier for the aforementioned offline identity authentication system. The electronic device uses its internal processor to call and execute program code stored in the memory, driving the operation of each functional module of the offline identity authentication system, thereby implementing any of the aforementioned offline identity authentication methods of this application. Furthermore, by equipping the vehicle with the aforementioned electronic device and integrating the corresponding offline identity authentication system functions, the vehicle possesses high-security identity authentication and access control capabilities in a purely offline environment. It can complete device legitimacy verification and permission management without relying on a cloud network, effectively improving the security, reliability, and scenario adaptability of vehicle identity authentication.

[0120] Optionally, embodiments of this application also provide a computer-readable storage medium storing a computer program. When the computer program is run by a processor, the processor executes the steps of the offline authentication method described in the above embodiments. The specific implementation and technical effects are similar and will not be repeated here.

[0121] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the functional units in the various embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The integrated unit described above can be implemented in hardware or in the form of hardware plus software functional units.

[0122] Optionally, this embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement an offline identity authentication method provided in the above embodiment.

[0123] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0124] From the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is 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.

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

[0126] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology 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 offline identity authentication method, characterized in that, A local control unit for use in electronic devices; the local control unit is connected to a low-frequency wake-up module, a near-field communication module, and a security chip, respectively; The method includes: In response to the wake-up signal sent by the low-frequency wake-up module, the near-field communication module is controlled to read the identity identifier of the authentication device and obtain the one-time random information generated for this authentication from the security chip. The wake-up signal is generated by the low-frequency wake-up module when it detects that the authentication device is close. Send a verification request carrying the identity identifier and the one-time random information to the security chip, and receive the verification result returned by the security chip; If the verification result is successful, then the corresponding access control operation is performed on the electronic device.

2. The method according to claim 1, characterized in that, The control of the near-field communication module to read the identity identifier of the authentication device includes: The near-field communication module sends radio frequency signals to wake up the authentication device; Receive a response signal returned by the authentication device, the response signal carrying the identity identifier of the authentication device; The response signal is verified; After successful verification, the identity identifier is parsed and extracted from the response signal.

3. The method of claim 1, wherein, Sending a verification request carrying the identity identifier and the one-time random information to the security chip includes: Based on the security data encapsulation format preset with the security chip, the identity identifier and the one-time random information are combined and encapsulated to generate verification request data; Send a verification request carrying the verification request data to the security chip.

4. The method of claim 3, wherein, The receipt of the verification result returned by the security chip includes: The security chip receives the verification request and parses the identity identifier and the one-time random information from the verification request data in the verification request. The security chip verifies the identity identifier based on the one-time random information and a preset list of authorized identity information in the security chip to obtain the verification result; the preset list of authorized identity information is a blacklist and whitelist of authorized identities bound to the electronic device. Receive the verification result.

5. The method of claim 1, wherein, The access control operation includes an unlocking operation. If the verification result is successful, the corresponding access control operation is performed on the electronic device, including: If the verification result is successful, then the corresponding device control command is generated; The device control command is executed to drive the actuator of the electronic device to perform an unlocking operation.

6. The method of claim 1, wherein, The method further includes: If the verification result is unsuccessful, an access denial instruction is generated, and a security audit log is generated; wherein, the security audit log is used to record the timestamp of the authentication event, the authentication device identifier that triggered the authentication event, and the reason code for the authentication failure.

7. The method of claim 6, wherein, The method further includes: If the verification results are all unsuccessful for a preset number of consecutive times, the authentication function of the near-field communication module will be locked for a preset duration. During the preset time period, new identity authentication is prohibited through the near-field communication module; Generate and record an authentication circuit breaker event log, which is used to record consecutive authentication failure events and the locking operations triggered.

8. The method according to claim 1, characterized in that, The method further includes: When the low-frequency wake-up module detects that the authentication device has entered the preset detection range of the low-frequency wake-up module, the wake-up signal is generated; wherein, the preset detection range is associated with the antenna layout of the low-frequency wake-up module, and the antenna of the low-frequency wake-up module is physically spaced from the antenna of the near-field communication module. Receive the wake-up signal sent by the low-frequency wake-up module.

9. An electronic device, characterized in that, The electronic device includes: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the electronic device to perform the method as described in any one of claims 1 to 8.

10. A vehicle characterized by comprising: include: The electronic device as described in claim 9.

Images