Device authentication method and apparatus, electronic device, and storage medium

Abstract

Embodiments of the present application provide a device authentication method and device, electronic device and storage medium. The method comprises collecting a current first working state parameter, a first cumulative running time and a first timestamp of the device based on a preset period, and generating a current state record code based on the first working state parameter, the first cumulative running time and the first timestamp (201); updating the state record code saved in a first storage area and a second storage area based on the current state record code, the first storage area and the second storage area being in different physical hardware carriers, and there being no electrical interconnection between the first storage area and the second storage area (202); when the device is in an authentication mode, comparing the state record codes in the first storage area and the second storage area to obtain a comparison result, and determining an accessible permission authentication result of the device based on the comparison result (203).

Description

Technical Field

[0001] This application relates to the field of authentication technology, and in particular to a device authentication method, apparatus, electronic device and storage medium. Background Technology

[0002] Industrial equipment widely employs access authentication mechanisms. The system enforces identity authentication before users access the site. Through fine-grained access control and full-process operation auditing, it can effectively prevent unauthorized logins and unauthorized use, ensuring operational safety and data compliance in industrial settings.

[0003] Currently, industrial equipment authentication relies on fixed keys, but these keys are easily leaked, resulting in low security for equipment authentication. Summary of the Invention

[0004] The main purpose of this application is to provide a device authentication method, apparatus, electronic device, and storage medium to improve the security of device authentication.

[0005] To achieve the above objectives at least to some extent, this application proposes a device authentication method, comprising:

[0006] The device's current first working status parameters, first cumulative runtime, and first timestamp are collected based on a preset period, and a current status record code is generated based on the first working status parameters, first cumulative runtime, and first timestamp.

[0007] The status record codes stored in the first and second storage areas are updated based on the current status record code. The first and second storage areas are located on different physical hardware carriers and there is no electrical interconnection between the first and second storage areas.

[0008] When the device is in authentication mode, the status record codes in the first storage area and the second storage area are compared to obtain the comparison result, and the device's access permission authentication result is determined based on the comparison result.

[0009] Optionally, in one implementation, generating a current status record code based on a first working state parameter, a first cumulative runtime, and a first timestamp includes:

[0010] Obtain the second working state parameter from the previous acquisition, and calculate the working state change rate based on the difference between the first and second working state parameters and the time interval between the two acquisitions.

[0011] The current status record code is obtained by concatenating the working status change rate, the first cumulative runtime, and the first timestamp.

[0012] Optionally, in one implementation, determining the device's access permission authentication result based on the comparison result includes:

[0013] When the comparison results indicate that they match, obtain the first cumulative runtime in the status record code and the second cumulative runtime of the device.

[0014] When the second cumulative runtime is greater than or equal to the first cumulative runtime, the access permission authentication result is determined to be that the device is accessible.

[0015] Optionally, in one implementation, determining the device's access permissions based on the comparison results includes:

[0016] When the comparison results indicate that they match, obtain the first cumulative runtime and the first timestamp from the status record code, as well as the second cumulative runtime and the second timestamp accumulated by the device.

[0017] When the device has not been shut down for a long time, and the second timestamp is greater than the first timestamp relative to the preset time threshold, the cumulative difference between the second cumulative runtime and the first cumulative runtime is determined.

[0018] When the cumulative difference is less than the first preset difference threshold, the access permission authentication result is determined to be that the device is inaccessible.

[0019] Optionally, in one embodiment, the method further includes:

[0020] When the device last ended due to an abnormal power outage, obtain the first cumulative runtime in the status record code and the fourth cumulative runtime of the device.

[0021] When the difference between the fourth cumulative runtime and the first cumulative runtime is greater than the second difference threshold, the access permission authentication result is determined to be that the device is inaccessible.

[0022] Optionally, in one embodiment, the method further includes:

[0023] When the device is powered off, the third working status parameters, the third cumulative running time and the third timestamp before the device is powered off are collected, and a power off status record code is generated based on the third working status parameters, the third cumulative running time and the third timestamp.

[0024] Update the status record codes stored in the first and second storage areas based on the shutdown status record codes.

[0025] Optionally, in one embodiment, the method further includes:

[0026] When the access permission authentication result is that the device is inaccessible, the number of authentication failures is counted.

[0027] When the number of authentication failures exceeds a preset threshold, the device's operating logic is erased.

[0028] Optionally, in one implementation, generating a current status record code based on a first working state parameter, a first cumulative runtime, and a first timestamp includes:

[0029] Obtain the historical state record codes stored in the first and second storage areas, and calculate the hash value of the historical state record codes;

[0030] The current status record code is generated based on the first working status parameter, the first cumulative runtime, the first timestamp, and the hash value.

[0031] This application also provides a device authentication apparatus, comprising:

[0032] The generation unit is used to collect the current first working status parameters, first cumulative running time and first timestamp of the device based on a preset period, and generate a current status record code based on the first working status parameters, first cumulative running time and first timestamp;

[0033] The storage unit is used to update the state record code stored in the first storage area and the second storage area based on the current state record code. The first storage area and the second storage area are located on different physical hardware carriers and there is no electrical interconnection between the first storage area and the second storage area.

[0034] The comparison unit is used to compare the status record codes in the first storage area and the second storage area when the device is in authentication mode, obtain the comparison result, and determine the device's access permission authentication result based on the comparison result.

[0035] Another aspect of this application provides an electronic device, comprising:

[0036] Memory, transceiver, processor, and bus system;

[0037] The memory is used to store programs;

[0038] The processor is used to execute programs in memory, including methods for performing the aspects mentioned above;

[0039] Bus systems are used to connect memory and processor to enable communication between them.

[0040] Another aspect of this application provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the methods described above.

[0041] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0042] This method constructs a status record code by periodically collecting device operating status parameters, cumulative runtime, and corresponding timestamps. The updated record code is then stored on two independent physical carriers without electrical interconnection. During the authentication phase, the authentication result is determined by comparing the status record codes stored on the two physical carriers. The independent hardware carriers and lack of electrical interconnection prevent malicious actors from hijacking the connection or illegally replacing hardware to simultaneously tamper with the status record codes stored in both locations. Furthermore, the data source for each generated status record code is naturally generated based on the device's real-time operating conditions, preventing the status record code from being cracked and improving device authentication security. Attached Figure Description

[0043] Figure 1 This is a schematic diagram of the application architecture of the device authentication method provided in the embodiments of this application;

[0044] Figure 2 This is a flowchart illustrating the device authentication method provided in an embodiment of this application;

[0045] Figure 3 This is a schematic diagram of the device authentication apparatus provided in the embodiments of this application;

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

[0047] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0048] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0049] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0050] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0051] Furthermore, to better illustrate this application, numerous specific details are provided in the following detailed embodiments. Those skilled in the art should understand that this application can be implemented without certain specific details. In some instances, methods, means, components, and circuits well-known to those skilled in the art have not been described in detail in order to highlight the main points of this application.

[0052] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0053] Industrial equipment widely employs access authentication mechanisms. The system enforces user authentication before access, effectively preventing unauthorized logins and unauthorized use through fine-grained permission control and end-to-end operation auditing, ensuring operational security and data compliance in industrial settings. Currently, industrial equipment access authentication relies on fixed keys, such as static key storage schemes. These schemes burn a fixed key or digital certificate into non-volatile memory before the device leaves the factory, and the device reads this static key for authentication or algorithm unlocking upon startup. The core flaw of this scheme is that the key exists as static data in the storage medium, making it vulnerable to attackers who can extract it through chip disassembly, storage retrieval, and side-channel attacks (such as differential power analysis and electromagnetic radiation analysis). Once the key is leaked, all devices in the same batch are at risk of being compromised. An alternative is an online authentication scheme based on an external server. Each time the device starts or runs, it sends its identifier to a cloud authentication server via a communication module. The server verifies the device's legitimacy and returns an authorization token. The drawbacks of this scheme include: heavy reliance on network connectivity, making authentication impossible in offline environments or during network outages; a single point of failure risk, where an attack or crash of the authentication server will render all terminals inoperable; and the communication process itself can be eavesdropped on, hijacked, or subjected to replay attacks, requiring additional transport layer security mechanisms. Software protection schemes based on fixed encryption algorithms: These schemes use encryption algorithms and store the keys in a protected area of ​​the chip. The drawback of this type of scheme is that the encryption algorithm is publicly known, and channel information such as power consumption, timing, and electromagnetic radiation during cryptographic operations can be collected and analyzed. Attackers can extract the keys through differential power analysis, correlation power analysis, and fault injection. Once the physical defenses are breached, the software protection becomes ineffective. Physically non-cloning function schemes: These schemes utilize random process deviations in chip manufacturing to map a specific excitation signal into a unique and unpredictable response, using this response as a unique device identifier or key seed. This solution achieves uniqueness at the "chip fingerprint" level, but it still has limitations: the stability of PUF response is greatly affected by factors such as temperature, voltage, and aging, requiring complex error correction and post-processing circuits; and PUF itself only provides static, one-time identity authentication, without solving the security maintenance problem of the device during continuous operation.

[0054] Based on this, the present application provides a device authentication method that can solve the above-mentioned technical problems.

[0055] System architecture and scenario description used in the embodiments of this application:

[0056] Figure 1 This is a system architecture diagram of a device authentication method according to an embodiment of this application. It includes a terminal 140, an Internet 130, a gateway 120, a server 110, etc.

[0057] Terminal 140 includes various forms of devices with display screens, such as desktop computers, laptops, PDAs (personal digital assistants), mobile phones, in-vehicle terminals, home theater terminals, dedicated terminals, intelligent voice interaction devices, smart home appliances, or aircraft. Furthermore, it can be a single device or a collection of multiple devices. Terminal 140 can communicate with the Internet 130 via wired or wireless means to exchange data.

[0058] Server 110 refers to a computer system that can provide certain services to terminal 140. Compared to ordinary terminal 140, server 110 has higher requirements in terms of stability, security, and performance. Server 110 can be a single high-performance computer in a network platform, a cluster of multiple high-performance computers, a portion of a single high-performance computer (e.g., a virtual machine), or a combination of portions of multiple high-performance computers (e.g., virtual machines).

[0059] Gateway 120, also known as an internetwork connector or protocol converter, is a computer system or device that acts as a translator, enabling network interconnection at the transport layer. It bridges the gap between two systems using different communication protocols, data formats, languages, or even completely different architectures. Gateways can also provide filtering and security functions. Messages sent from terminal 140 to server 110 are forwarded to the corresponding server 110 via gateway 120. Messages sent from server 110 to terminal 140 are also forwarded to the corresponding terminal 140 via gateway 120.

[0060] The device authentication method provided in this application embodiment can be implemented separately in terminal 140, separately in server 110, or partially in terminal 140 and partially in server 110.

[0061] When the device authentication method provided in this application embodiment is implemented alone in terminal 140, terminal 140 collects the device's current first working state parameters, first cumulative runtime, and first timestamp based on a preset period, and generates a current state record code based on the first working state parameters, first cumulative runtime, and first timestamp; terminal 140 updates the state record codes stored in the first storage area and the second storage area based on the current state record code, the first storage area and the second storage area are located on different physical hardware carriers, and there is no electrical interconnection between the first storage area and the second storage area; when the device is in authentication mode, terminal 140 compares the state record codes in the first storage area and the second storage area to obtain the comparison result, and determines the device's access permission authentication result based on the comparison result.

[0062] The device authentication method provided in the embodiments of this application will be described below with reference to the accompanying drawings. The execution subject of the device authentication method described below is a terminal device, which can be implemented by the terminal device by running the various computer programs mentioned above. Of course, based on the understanding of the following text, it is not difficult to see that the device authentication method provided in the embodiments of this application can also be implemented by the terminal device and the server in collaboration.

[0063] Please see Figure 2 ,like Figure 2 The diagram shown is a flowchart of a device authentication method provided in this embodiment. The method includes:

[0064] Step 201: Collect the device's current first working status parameters, first cumulative running time, and first timestamp based on a preset period, and generate a current status record code based on the first working status parameters, first cumulative running time, and first timestamp.

[0065] The preset period can be a fixed periodic time interval that is predefined by humans and written into the main control firmware configuration area by engineers during the equipment's factory commissioning phase.

[0066] The first operating status parameter can be a collective term for various measurable physical quantities collected by various sensors that can objectively reflect the current physical state and working environment of the equipment. It includes at least any combination of the following types: ambient temperature, operating temperature of a specific part of the equipment, power supply voltage, operating power, component operating frequency, component rotation speed, vibration amplitude, pressure, humidity, light intensity, and noise level. Unlike the static hardware characteristics that are fixed when the equipment leaves the factory, the physical characteristic parameters change continuously and dynamically with the operating status of the equipment and environmental conditions. They are unpredictable and unreproducible, reflecting the true operating state of the equipment at the moment of data acquisition.

[0067] The first cumulative runtime can be the total duration obtained by continuously accumulating the effective load-bearing operating time from the initial power-on and commissioning of the equipment, excluding downtime periods. This duration can be generated in real-time by a hardware timing chip independent of the main control program, and is a unidirectionally increasing, non-resettable, and non-rollback physical quantity. Even if the equipment is powered off, this cumulative runtime value is stored in non-volatile memory and continues to accumulate from the breakpoint upon the next power-on. The main control unit only has data read permissions and cannot modify the original timing value through software instructions.

[0068] The first timestamp can be a standardized time sequence code generated according to a unified time sequence specification, accurately marking the moment of occurrence of a single event. It contains the time sequence information of year, month, day, hour, minute, and second, that is, the acquisition time corresponding to this set of operating condition data, realizing a one-to-one correspondence between each set of parameters and the acquisition time point. It can be obtained by reading the timing data inside the real-time clock module.

[0069] The main control unit's internal timing module continuously monitors the preset period. When the timing value reaches the preset interval threshold, it automatically issues a collection trigger command. First, it collects the first working status parameters output by each sensor, then reads the first cumulative running time output by the independent hardware timing circuit, and then retrieves the first timestamp output by the clock. The field encapsulation is completed according to the factory-preset encoding and layout rules, and finally a compliant current status record code is generated.

[0070] Step 202: Update the status record codes stored in the first and second storage areas based on the current status record codes. The first and second storage areas are located on different physical hardware carriers and there is no electrical interconnection between them.

[0071] The storage area can be a hardware storage space equipped with non-volatile storage media that can retain digital data for a long time after power failure. Two independent data storage points can be referred to as the first storage area and the second storage area, respectively. The first and second storage areas are located on different physical hardware carriers; that is, the two storage units are on independent hardware carriers without sharing a PCB substrate or components. The hardware entities are separated from each other, isolating the two storage areas at the physical hardware level. It is impossible to simultaneously touch both storage chips through a single disassembly or hardware connection operation, thus cutting off the physical conditions for single-point hardware tampering with the two storage areas. There is no electrical interconnection between the first and second storage areas; that is, there are no direct power lines, communication signal lines, shared system buses, or any other electrical connections between the two storage areas. Synchronous read and write operations cannot be achieved based on the same electrical communication link. Accordingly, write commands can be issued through two independent channels.

[0072] Updating the status record code can replace the old record code stored in the previous round in both storage areas with the latest generated current status record code, ensuring that the data inside the dual storage is synchronized to the current valid version and completing the periodic update of the authentication basis.

[0073] Step 203: When the device is in authentication mode, compare the status record codes in the first storage area and the second storage area to obtain the comparison result, and determine the device's access permission authentication result based on the comparison result.

[0074] The authentication mode can be a dedicated running state for security verification that is actively entered before the device is powered on or before high-privilege operations such as high-risk debugging or parameter rewriting are required.

[0075] Status record code comparison can involve reading status record codes from two storage areas separately and performing a data verification operation to check whether the two encoded contents are completely identical, field by field and byte by byte. The binary judgment conclusion obtained after the code consistency operation can be called the comparison result, such as all codes being identical or codes being different. Combining the comparison rules and the comparison result to generate the final access control instruction can determine the device's access permission authentication result, including two output forms: permission granted or permission completely locked. If all characters of the two record codes match without difference, authentication is successful, and device access permissions are granted; if there is a data difference at any position in the two codes, authentication is deemed unsuccessful, device operation permissions are locked, and access permission function is denied.

[0076] This application embodiment dynamically generates verification credentials based on the real operating data of the device at all times. The status record code is continuously updated according to the operating conditions of the device. Unlike the traditional industrial equipment that relies on fixed key authentication, this approach avoids the security risks of fixed keys being reverse-engineered or stolen by hardware. Furthermore, the two storage units are located on independent physical hardware carriers without any electrical connection. Malicious attackers cannot use a single bus hijacking or a single hardware disassembly and burning to simultaneously modify the record codes inside the two storage units, thereby improving the security of device authentication.

[0077] In one implementation, generating a current status record code based on a first working state parameter, a first cumulative runtime, and a first timestamp includes:

[0078] Obtain the second working state parameter from the previous acquisition, and calculate the working state change rate based on the difference between the first and second working state parameters and the time interval between the two acquisitions.

[0079] The current status record code is obtained by concatenating the working status change rate, the first cumulative runtime, and the first timestamp.

[0080] In this embodiment, the second working status parameter can be physical quantitative data collected in the previous acquisition cycle to characterize the historical operating conditions of the equipment, which can be read from the historical data cache of the equipment master control.

[0081] The rate of change of working status can be the magnitude of change of the working status parameters of the equipment per unit time. It is a dynamic indicator used to reflect how fast the working condition changes. It is calculated by dividing the difference between the first working status parameter and the second working status parameter by the time interval between the two data collections.

[0082] By introducing a working state change rate into the status record code, the verification code can be dynamically changed according to the actual operating state of the equipment, further increasing the coding complexity and improving the unforgeability of each record code.

[0083] In one implementation, determining the access permission authentication result of the device based on the comparison result includes:

[0084] When the comparison results indicate that they match, obtain the first cumulative runtime in the status record code and the second cumulative runtime of the device.

[0085] When the second cumulative runtime is greater than or equal to the first cumulative runtime, the access permission authentication result is determined to be that the device is accessible.

[0086] In this embodiment, the second cumulative runtime can be the actual cumulative working time of the entire machine from the initial power-on and commissioning to the current certification time, which is continuously statistically summarized by the hardware timing component.

[0087] Relying solely on the consistency of dual storage record codes to grant access may also have security vulnerabilities. Attackers could simultaneously tamper with the two storage record codes or manually rewrite the duration field within the code to achieve dual code matching, creating a spoofing opportunity. The internal arithmetic register performs a numerical comparison of the two sets of duration data. When the condition that the second cumulative runtime is greater than or equal to the first cumulative runtime is met (wherein, the difference between the second and first cumulative runtimes must also be limited to a preset range), the device outputs an authentication result granting access permission.

[0088] The second cumulative runtime on the hardware side is generated natively by independent timing hardware and is not affected by the tampering of the record code. Even if criminals forge the first cumulative runtime field inside the record code, they cannot synchronously modify the underlying timing data of the hardware. By using the objective numerical constraints of the two sets of durations, the vulnerability of full-scale synchronous forgery is further blocked, and the authentication verification level is improved.

[0089] For example, the main control chip reads the cumulative runtime value from the authentication code and compares it with the cumulative runtime value at the current moment after the device is powered on. Since the cumulative runtime is a unidirectionally increasing and irreversible physical quantity, the current cumulative runtime value must be greater than or equal to the cumulative runtime value recorded in the authentication code. If the current cumulative runtime value is less than the cumulative runtime value recorded in the authentication code (i.e., the cumulative runtime has reversed), it is determined that time forgery has occurred, and authentication fails even if the two authentication codes are the same.

[0090] In one implementation, determining the device's access permissions based on the comparison results includes:

[0091] When the comparison results indicate that they match, obtain the first cumulative runtime and the first timestamp from the status record code, as well as the second cumulative runtime and the second timestamp accumulated by the device.

[0092] When the device has not been shut down for a long time, and the second timestamp is greater than the first timestamp relative to the preset time threshold, the cumulative difference between the second cumulative runtime and the first cumulative runtime is determined.

[0093] When the cumulative difference is less than the first preset difference threshold, the access permission authentication result is determined to be that the device is inaccessible.

[0094] In this implementation, the second timestamp can be the current system time information corresponding to the hardware clock at the time of authentication.

[0095] "Not being shut down for a long time" can mean that the equipment is in an operating state where the shutdown and resting time does not exceed the specified range.

[0096] Assuming the encoding matches, the first cumulative runtime and first timestamp encapsulated within the status record code are extracted. Simultaneously, the second cumulative runtime and second timestamp are read in real-time from the independent timing hardware and the hardware clock. Then, assuming the device does not experience prolonged downtime, the difference between the second and first timestamps is checked to see if it exceeds a preset time threshold, i.e., if the time span exceeds the limit. Under reasonable conditions where the device operates continuously and the time span exceeds the preset threshold, the cumulative runtime will have a regular increment. Therefore, if the cumulative difference between the second and first cumulative runtimes is less than the first preset difference threshold, it indicates that the status record code is not normal, authentication fails, and the access permission authentication result is determined to be that the device is inaccessible.

[0097] In objective scenarios where equipment operates continuously and the time span across cycles is relatively large, the actual running time of the equipment should generate a reasonable increment. If the first cumulative running time in the code is tampered with, it may cause the difference between the actual hardware time and the time in the code to be too small. Based on this characteristic, the tampering anomaly can be identified, thereby filling the verification vulnerability.

[0098] For example, the main control chip reads the real-time timestamp and cumulative runtime value from the authentication code and cross-compares them with the current real-time clock time. If there is a logical contradiction between the real-time timestamp and the cumulative runtime value in the authentication code, such as the real-time timestamp showing that a long time has passed since the record time, but the increment of the cumulative runtime is very small or zero, then it is determined that there is time forgery, and the authentication will still fail even if the two authentication codes are the same.

[0099] In one embodiment, the method further includes:

[0100] When the device last ended due to an abnormal power outage, obtain the first cumulative runtime in the status record code and the fourth cumulative runtime of the device.

[0101] When the difference between the fourth cumulative runtime and the first cumulative runtime is greater than the second difference threshold, the access permission authentication result is determined to be that the device is inaccessible.

[0102] In this implementation, "last run ended due to abnormal power failure" could refer to the equipment's operational history where the previous cycle of operation did not execute the normal shutdown procedure and the equipment stopped directly under abnormal scenarios such as sudden power outages or circuit breaker trips. For example, an internal power failure flag register can automatically store a power failure type identifier based on the level signal of the power failure detection circuit, and the status can be determined by reading the identifier during verification.

[0103] After retrieving the equipment shutdown status flag and confirming that the last termination of the equipment was due to an abnormal power outage, the first cumulative runtime carried by the current status record code is extracted. Then, the fourth cumulative runtime output by the timing module is read through an independent hardware interface. The main controller calculates the numerical difference between the two runtimes in the calculation unit and compares the calculated difference with the pre-stored second difference threshold. If the difference is greater than the second difference threshold, the authorization conclusion that the equipment is inaccessible is determined.

[0104] In a scenario where the device experiences an unexpected power outage and there is no external tampering, the entire machine is not running during the power outage phase. The increment of the fourth cumulative runtime relative to the first cumulative runtime in the record code can be stably controlled within the second difference threshold. If malicious personnel take advantage of the power outage to replace the main control chip with a brand new blank one, the new hardware timing will start from zero or the duration will be tampered with. The final calculated duration difference will exceed the second difference threshold. This can efficiently identify illegal chip replacement and data tampering during the power outage window, further compressing the feasible space for attackers to carry out hardware attacks by exploiting power outage vulnerabilities.

[0105] For example, if the device's last operation ended due to an abnormal power outage, upon power-up, the main control chip compares the current cumulative runtime value with the cumulative runtime value recorded in the authentication code. Since the device was stationary during the power outage, the cumulative runtime should not increase. If the increment exceeds a preset physically reasonable threshold, it is determined that the device may have been illegally operated or replaced during the power outage.

[0106] In one embodiment, the method further includes:

[0107] When the device is powered off, the third working status parameters, the third cumulative running time and the third timestamp before the device is powered off are collected, and a power off status record code is generated based on the third working status parameters, the third cumulative running time and the third timestamp.

[0108] Update the status record codes stored in the first and second storage areas based on the shutdown status record codes.

[0109] In this embodiment, the shutdown of the device can refer to the controlled shutdown process when the device receives a normal shutdown command issued by a human and the system orderly closes its business and prepares for power outage according to a preset process.

[0110] After receiving a normal shutdown command and marking the shutdown running status, the main controller suspends the normal operation of the device, and sequentially collects the third working status parameter, the third cumulative running time, and the third timestamp corresponding to the moment of shutdown. Then, the third working status parameter, the third cumulative running time, and the third timestamp are concatenated and encapsulated according to the preset field order to generate a shutdown status record code. Finally, the shutdown status record code overwrites the original historical record code in the first and second storage areas, completing the dual storage data synchronization update.

[0111] Based on updating the record code during the controllable window period of normal shutdown, the actual operating information at the moment of shutdown before the equipment stops is solidified into the dual storage, forming two complementary archiving forms of periodic timed updates and instant updates upon shutdown, continuously ensuring that the record code in the storage is highly matched with the real-time operating status of the equipment.

[0112] In one embodiment, the method further includes:

[0113] When the access permission authentication result is that the device is inaccessible, the number of authentication failures is counted.

[0114] When the number of authentication failures exceeds a preset threshold, the device's operating logic is erased.

[0115] In this implementation, a single authentication failure may be an occasional anomaly, but multiple consecutive failures strongly suggest that the device is under malicious attack, such as brute-force attacks, repeated disassembly and tampering, or hardware replacement. Each time the device completes authentication and the result is inaccessible, the system accumulates one authentication failure count and saves the latest count in a secure non-volatile storage area. After each count, the current authentication failure count is compared with a preset threshold. When the failure count reaches the preset threshold, the device can be forcibly erased from its operating logic, firmware, and configuration data, rendering the device completely inoperable and unusable.

[0116] By setting a threshold for the number of tolerable failures, it is possible to filter out accidental triggers caused by occasional anomalies and accurately identify persistent attack behaviors. When the number of failures exceeds the limit, the operating logic is automatically erased, thereby improving the overall anti-hacking, anti-theft, and anti-reuse capabilities of the device.

[0117] For example, the main control chip maintains a consecutive authentication failure counter. When the device experiences a preset number of authentication failures (N) within a preset time period, the main control chip automatically performs an irreversible firmware self-destruct operation. The preset number N can be a positive integer from 1 to 10, and the preset time period can be from 1 minute to 24 hours. The specific values ​​are configured by the manufacturer before the device leaves the factory according to security level requirements.

[0118] The firmware self-destruct operation includes at least one of the following: erasing the core function algorithm in the program storage area, turning all core code into an unrecoverable erased state; erasing the authentication code and trust anchor in the program execution area and the dedicated algorithm storage area; physically blowing the hardware fuse used to enable the core function algorithm; and forcibly zeroing all authentication-related registers and storage areas inside the main control chip.

[0119] Understandably, when a device needs to reset its authentication system for legitimate reasons such as authorized repair or legal replacement, a factory reset operation must be performed within the device manufacturer's controlled, physically secure environment. This operation first completely erases the current authentication code and trust anchors in the program execution area and dedicated algorithm storage area, while simultaneously resetting the accumulated runtime to zero. Then, an authorized initialization device re-executes the factory initialization process for the device in a controlled environment, generating and injecting entirely new trust anchors that are unrelated to the original trust anchors.

[0120] In one implementation, generating a current status record code based on a first working state parameter, a first cumulative runtime, and a first timestamp includes:

[0121] Obtain the historical state record codes stored in the first and second storage areas, and calculate the hash value of the historical state record codes;

[0122] The current status record code is generated based on the first working status parameter, the first cumulative runtime, the first timestamp, and the hash value.

[0123] In this embodiment, the historical status record code can be a check code generated in the previous cycle or the last time the system was shut down and stored in the first storage area and the second storage area.

[0124] A hash value is a fixed-length string obtained by performing a one-way operation on the original data according to a hash algorithm. It has the characteristics of being unique and irreversible.

[0125] The main controller can read the saved historical status record codes from the first storage area and the second storage area respectively. After confirming that the two historical record codes are consistent, it performs a hash operation on them to obtain a unique hash value. Then, it combines the first working status parameter, the first cumulative runtime, and the first timestamp obtained in this collection with the calculated hash value according to fixed fields, and finally concatenates them to generate the current status record code with historical association characteristics.

[0126] By introducing the hash value of the historical record code, the current record code is no longer independent data, but forms a strongly related chain structure with the previous round of encoding. Any tampering with the historical code will cause the hash value to mismatch, making the current code directly invalid and unable to pass subsequent verification. This reduces the possibility of the record code in any storage area being forged and improves authentication security.

[0127] In one example, the logical flow of the device authentication method of this application embodiment can be described as follows.

[0128] The overall security authentication process for the device can be divided into four consecutive stages: factory initialization, iterative updates during operation, power-on authentication verification, and normal shutdown final update. The entire mechanism manages the authentication code throughout its entire lifecycle based on two physically isolated storage partitions. From factory initialization to continuous data refresh during operation, the device's legitimate operating permissions are determined by the consistency of data between the two partitions, and the last valid data is automatically retained. The complete operating logic is as follows:

[0129] First, the factory initialization process is performed. This step is limited to a secure environment, such as the manufacturer's production line or authorized service center, where physical access is strictly controlled and external eavesdropping and illegal interference can be avoided. The device completes its first controlled power-on. The main control chip sequentially reads the device's unique hardware identifier, the initial power-on timestamp output by the real-time clock module, the initial value of the cumulative runtime (preset to zero or a fixed value), and the measured data collected by the sensors at the moment of the device's initial power-on. The main control chip performs pure concatenation processing on all the data according to a pre-agreed concatenation order. The resulting original data string serves as the initial authentication code, which is the trust anchor point of the entire authentication system. Once generated, the trust anchor point is permanently locked and cannot be modified or replaced.

[0130] After the initial authentication code is generated, the main controller synchronously writes the code to the preset storage addresses corresponding to the program execution area and the dedicated algorithm storage area. The program execution area and the dedicated algorithm storage area are completely isolated at the hardware level. There are no electrical connections, no shared storage units, and no shared data buses or control lines between the two. At the same time, the program execution area is constrained by the underlying hardware logic. Only when the enable signal issued after successful authentication is received can the program counter jump to the core function algorithm storage address to perform addressing access. Once authentication fails, this area remains in an addressing locked state, and the core function algorithm can neither be read nor run.

[0131] After the equipment completes its factory initialization, it enters the normal operation phase and embarks on a continuous self-iterative process. Based on the equipment category and safety level requirements, the manufacturer pre-determines the iteration cycle before shipment, for example, configuring a fixed time interval between 1 and 10 minutes. The main control chip periodically collects real-time operating data according to this cycle. The collected data includes multiple physical characteristic parameters of the equipment and the current cumulative runtime. Physical characteristic parameters can be arbitrarily selected and combined from ambient temperature, local operating temperature of the equipment, power supply voltage, operating power consumption, component operating frequency, component rotation speed, vibration amplitude, pressure, ambient humidity, light intensity, and noise levels. The main control chip encapsulates the real-time timestamp, cumulative runtime, and absolute values ​​of each physical characteristic parameter collected in this round into a single status record code according to a preset data structure. This code is then synchronously written to two independent storage partitions: the program execution area and the dedicated algorithm storage area. The writing process uses a physical overwrite mode; the new code irreversibly overwrites the original historical record. Overwritten data is permanently destroyed, and there is no data recovery method. At any given time, only one copy of the currently effective authentication code is retained in each of the two storage partitions.

[0132] Whenever the device performs a power-on startup, it automatically enters the startup authentication comparison process. Initially, the device defaults to authentication mode. At this time, the addressing permissions of the storage area containing the core function algorithm are pre-locked, and the program counter is hardware-restricted from jumping to the algorithm entry address. The main controller independently reads the valid authentication codes stored in the physically isolated program execution area and the dedicated algorithm storage area, and then performs a full-field, item-by-item comparison of the two codes. The comparison covers the real-time timestamp, cumulative runtime, and the completeness and consistency of all physical characteristic parameters. Any situation, such as inconsistent authentication code lengths, deviations in any field values, or complete or partial loss of data on one side, is considered a discrepancy between the two authentication codes. Only when all fields of the two authentication codes completely match is the system considered to have passed authentication. The main controller outputs an enable signal, releasing the addressing restriction of the core algorithm storage area, unlocking all device functions, and enabling normal startup. If any part of the two authentication codes does not match, authentication is directly deemed to have failed, the main controller permanently stops issuing enable signals, the core function algorithm cannot be scheduled for execution, and the device is locked in an irrecoverable, permanent shutdown state.

[0133] When the device performs a normal shutdown operation, a final update step is performed before the main controller cuts off the main power supply to the entire machine. The system collects the operating status data of the device at the moment of shutdown and generates a corresponding status record code. The new code is synchronously updated to two independent storage areas through physical overwriting. The old record is synchronously and irreversibly cleared. The main power supply is officially cut off only after the main controller confirms that the writing action in both areas has been completed. If a sudden abnormal power outage or failure to comply with the shutdown procedure occurs during the operation of the device, the two storage partitions automatically retain the status record code that was successfully overwritten in the previous round, as the benchmark data for the next power-on authentication.

[0134] In one example, the status log code can also consist of a real-time timestamp, cumulative runtime value, and change rate data for various physical characteristic parameters. The main control chip continuously collects a set of physical characteristic parameters and the current cumulative runtime value of the device at preset time intervals. Based on the time series, the main control chip divides the difference between the currently collected physical characteristic parameter value and the previously collected physical characteristic parameter value by the time interval between the two collections to obtain the change rate data of each physical characteristic parameter per unit time.

[0135] Correspondingly, the comparison phase of authentication can be used to compare two authentication codes that are inconsistent in length, real-time timestamp, cumulative runtime, change rate of various physical characteristic parameters, or where one end of the data is completely missing or partially missing.

[0136] In one example, a scenario for generating state record codes based on physical feature parameters is described as follows:

[0137] Taking a distributed water source heat pump air conditioner indoor unit as an example, the hardware components of this indoor unit include a main control MCU, a compressor drive module, a variable frequency water pump, a DC fan, an ambient temperature sensor, an inlet water temperature sensor, an outlet water temperature sensor, a voltage and current sensor, a real-time clock module, an independent cumulative runtime timing circuit, a program storage area, and core function algorithms. The program storage area is divided into a physically isolated program execution area and a dedicated algorithm storage area, each mounted on two independent non-volatile memory chips. These two areas are not electrically connected and each has its own independent address bus and data bus, ensuring that read and write operations do not interfere with each other. The core function algorithms are stored in plaintext within the program storage area, but this storage area is natively set to prohibit direct addressing. Only after authorization authentication is completed and the corresponding enable signal is received can the MCU perform addressing and retrieval operations on the core function algorithms. The MCU chip integrates an independent cumulative runtime timing circuit. From the moment the device is first powered on, this circuit continuously accumulates the actual runtime of the device, and the corresponding runtime data is periodically stored in the non-volatile memory. In the event of a power outage, the data will not be lost or automatically cleared and reset.

[0138] During the factory initialization process, the first power-on operation of the equipment is limited to a controlled physical security environment within the factory. The main control MCU sequentially reads the unique serial number built into the device, the initial real-time timestamp output by the real-time clock module, the cumulative runtime data with initial values ​​set to zero, the real-time sampling values ​​from the ambient temperature sensor, the real-time sampling values ​​from the inlet water temperature sensor, and the real-time sampling values ​​from the voltage sensor. The MCU directly concatenates these multiple sets of raw data according to the factory-preset fixed sorting rules to generate a raw data string. The entire concatenation process only performs pure data continuation processing and does not introduce any data transformation processing logic such as digest operations or encryption operations. The final generated raw data string serves as the initial authentication code and is also the trust anchor point corresponding to the entire lifecycle of the air conditioner indoor unit's authentication. After generating the initial authentication code, the main control MCU synchronously writes the code to the authentication code storage address 0x0000 in the program execution area and the authentication code storage address 0x0000 in the dedicated algorithm storage area in parallel. After the writing action is completed, the access constraint rules of the program execution area are solidified through hardware logic. The program counter is only allowed to jump to the entry address corresponding to the core function algorithm to complete the addressing when it receives the enable signal output after successful authentication.

[0139] During the self-iterative update phase of the equipment's operation period after it is put into use on-site, when the indoor unit of the air conditioner is normally powered on at the user's site, the main control MCU is configured with a fixed 3-minute timed interrupt task. After each timed interrupt is triggered, the MCU automatically starts a complete set of data acquisition and encoding update work. The MCU sequentially reads the current real-time timestamp and the real-time cumulative duration output by the independent cumulative runtime timing circuit. Simultaneously, it collects multiple physical parameters, including ambient temperature, inlet water temperature, outlet water temperature, compressor real-time operating frequency, and variable frequency pump real-time speed. Then, it encapsulates and integrates all collected information according to a preset data structure to generate a standardized status record code. An example encoding format is: Real-time timestamp: 2025-09-15T14:03:00, Cumulative runtime: 1047321 seconds, Ambient temperature: 26.2, Inlet water temperature: 16.1, Outlet water temperature: 19.0, Compressor frequency: 50.0, Pump speed: 30.0. After encoding generation, the MCU uses physical overwriting to write the latest status record code to address 0x0000 in the program execution area and address 0x0000 in the dedicated algorithm storage area. The new code directly overwrites the previous record at the hardware level. The overwritten historical data is permanently deleted and cannot be recovered by any means. Only a single, valid authentication code is retained in each of the two independent storage areas at any given time.

[0140] The normal shutdown process involves the user issuing a shutdown control command via the device control panel, after which the MCU initiates the standard shutdown processing logic. The MCU first replicates all data acquisition and parameter encapsulation steps of the self-iterative process, acquiring the real-time timestamp, cumulative runtime, and absolute values ​​of various physical characteristic parameters at the moment of shutdown, and encapsulating them to generate a last state record code. This new code is then physically overwritten and stored in two isolated storage areas, while the original historical records are synchronously and irreversibly erased. After the system verifies that all write operations to the two storage areas are successful, the MCU backs up the latest cumulative runtime value to non-volatile memory, and finally disconnects the main power supply to the entire device, completing the compliant shutdown process.

[0141] The abnormal power failure handling logic is as follows: if a non-command abnormal power failure occurs during the operation of the indoor unit of the air conditioner, the built-in independent cumulative running time timing circuit will immediately stop the time accumulation work. The hardware will automatically latch and save the current timing value at the moment of power failure. Meanwhile, the program execution area and the dedicated algorithm storage area will still retain the valid status record code of the previous successful overwrite, which will serve as the benchmark for subsequent power-on authentication of the device.

[0142] After the device is powered on again, the authentication comparison process begins. After the user completes the power-on operation, the MCU bootloader prioritizes switching to the dedicated authentication mode. During the authentication mode, the storage area containing the core function algorithm is locked by default and cannot be accessed by the program. At the same time, the independent cumulative runtime timing circuit retrieves the historical values ​​saved before the power outage and continues to perform runtime accumulation statistics. The MCU independently reads the authentication codes stored in the physically isolated program execution area and the dedicated algorithm storage area. It then performs a field-by-field comparison and verification of the two authentication codes, checking the consistency of the real-time timestamp, cumulative runtime, and all physical characteristic parameters. In a normal authentication scenario where all fields of the two authentication codes match, the MCU continues to perform a two-layer enhanced verification: The first layer of verification reads the current cumulative runtime output by the independent timing circuit and compares it with the cumulative runtime embedded in the authentication code, satisfying the constraint that the current runtime is greater than or equal to the runtime recorded in the code and that the runtime increment is within a preset reasonable range; The second layer of verification retrieves the current real-time clock data and cross-verifies it with the timestamp carried by the authentication code, ensuring that the cumulative runtime increment and the difference between the two timestamps are logically consistent; After all the above verification items pass successfully, the MCU outputs a hardware enable signal to release the addressing lock restriction of the core function algorithm storage area, and the air conditioner indoor unit unlocks all control logic and starts running normally.

[0143] In the scenario where malicious actors replace the main control chip, if the device is disassembled without authorization during downtime and the original MCU is replaced with a blank new chip, when the replaced chip is powered on for the first time and enters authentication mode, it reads authentication data from its own program execution area and dedicated algorithm storage area. Since the blank chip has not undergone any factory initialization or periodic code overwrite operation, the dedicated algorithm storage area has no valid stored data. The two authentication codes to be compared naturally have missing content differences, and the field comparison is directly judged as a failure. Even if the attacker artificially fills in the data and forcibly makes the authentication code content in the two storage areas consistent, the independent timing circuit with the newly replaced chip starts timing from zero or the timing base does not match the original device's history. The chip's current cumulative running time is much less than the millions of seconds of historical running time recorded in the original device's authentication code. The duration continuity verification cannot meet the standard, and the main control MCU ultimately judges the overall authentication as a failure, permanently stops issuing enable signals, and the core function algorithm cannot be called and executed continuously. The entire machine enters an irreversible permanent locked state.

[0144] In one example, a scenario for generating state record codes based on the rate of change of physical characteristics is illustrated below:

[0145] Taking the embedded industrial controller used for production line control as an example, the hardware composition of the controller includes a main control MCU, an ambient temperature sensor, a power supply voltage sensor, a motor drive frequency sensor, a real-time clock module, an independent cumulative running time timing circuit, a program storage area, and core function algorithms. The program storage area is divided into two storage units: a program execution area and a dedicated algorithm storage area. The two areas are physically isolated from each other and there are no shared electrical lines or data interaction paths between them.

[0146] The entire authentication process begins with the device initialization operation completed in a controlled physical security environment at the factory. During the initialization phase, an initial authentication code is generated, which contains the initial value of the built-in cumulative runtime and real-time timestamp information. The main controller then writes this initial authentication code into two physically isolated independent storage areas.

[0147] After the equipment is deployed on the production line and put into normal operation, the controller activates a dynamic authentication operation mechanism based on the parameter change rate. The main control MCU is set to a fixed acquisition cycle of five minutes. At each cycle node, the MCU synchronously acquires the current real-time timestamp, the cumulative running time output by the independent timing circuit, the measured value of the ambient temperature, the measured value of the power supply voltage, and the measured value of the motor drive frequency. In addition to retaining the absolute acquisition values ​​of each parameter in this cycle, the MCU retrieves the historical acquisition data retained in the previous cycle and calculates the unit time change rate of each type of sensor parameter. The formula for calculating the parameter change rate is the difference between two adjacent parameters divided by the interval between the two acquisitions. Taking the temperature parameter as an example, if the previous acquisition temperature was 42.5℃ and the current acquisition temperature is 42.8℃, with an acquisition interval of 300 seconds, the corresponding temperature change rate calculation result is (42.8-42.5) / 300=0.001℃ / second. The same calculation logic is used to complete the change rate calculation for the power supply voltage and motor drive frequency parameters.

[0148] After all data and change rate calculations are completed, the MCU encapsulates the real-time timestamp, cumulative runtime, temperature change rate, voltage change rate, and frequency change rate into a unified status record code according to a predetermined format. Example encoding content: Real-time timestamp: 2025-10-20T08:15:00, Cumulative runtime: 5273841 seconds, Temperature change rate: 0.001, Voltage change rate: -0.002, Frequency change rate: 0.000. After encoding generation, the main controller synchronously writes the latest status record code to the corresponding authentication code storage address in the program execution area and the dedicated algorithm storage area through physical overwriting. The new data directly overwrites the original historical records at the hardware level, and the replaced previous version of the record is permanently lost and cannot be recovered. Only the currently valid authentication data is retained in both storage areas at any given time.

[0149] If the equipment is attacked by unauthorized disassembly and replacement of the main control MCU during normal operation and maintenance downtime, the new MCU will experience multiple verification failures during the power-on authentication process. First, the two independent storage areas of the new main control MCU will either be blank with no data or contain different pre-set data, causing inconsistencies in the initial dual-storage authentication code comparison. Even if malicious actors forcibly make the authentication code content in the two storage areas consistent by manually filling in data, subsequent deep verification can still identify the anomaly. The independent timing circuit of the new MCU starts counting the runtime from zero, which has an objective numerical gap with the historical runtime accumulated to millions of seconds in the authentication code. At the same time, the new main control MCU lacks parameter acquisition records for the entire equipment cycle and cannot replicate the complete set of parameter change rate sequences that match the actual production line operation trajectory of the equipment. Both the cumulative duration verification and the physical parameter change rate verification will fail. After verification fails, the controller directly locks the startup permission and enters an unrecoverable permanent lock state. To unlock the device and restore normal function, the only way is for authorized technicians from the original manufacturer to re-execute the entire factory initialization process in a controlled physical security environment using dedicated initialization equipment. This process involves regenerating a new trust anchor point and resetting the accumulated runtime parameters before the device can be restored.

[0150] In one example, the self-destruct scheme for an onboard electronic control unit scenario is as follows:

[0151] Taking the Engine Control Unit (ECU) for commercial vehicles as an example, this hardware device includes a main control MCU, an intake air temperature sensor, a coolant temperature sensor, a power supply voltage monitoring circuit, a real-time clock module, an independent cumulative running time timing circuit, a program storage area, and the core functional algorithm as the engine control firmware. The whole machine is set to the highest security protection level, and the threshold N for the number of consecutive authentication failures is fixed at 1.

[0152] The ECU completes the initialization process uniformly during the factory stage. After the equipment is installed in the vehicle and put into operation, the ECU periodically collects various physical characteristic parameters and calculates the corresponding rate of change according to the established operating logic. It also synchronously records real-time timestamps and cumulative running time data that can characterize the total running time of the engine. Based on the above information, the ECU continuously generates and iteratively updates the equipment authentication code.

[0153] If unauthorized personnel disassemble the vehicle during maintenance and use a counterfeit ECU to replace original parts, the counterfeit part will immediately enter the authentication comparison process upon power-on. The initial cumulative runtime value inside the counterfeit ECU is zero, and the relevant parameters cannot match the original vehicle's actual operating history. Furthermore, it cannot generate cumulative runtime data or physical parameter change rate trajectories consistent with the original vehicle's historical operating patterns, causing all verification steps to fail and directly resulting in authentication failure. Constrained by a preset threshold N=1, the MCU immediately initiates a firmware physical self-destruction process after the first authentication failure. The MCU drives an internal charge pump to generate high-voltage electrical energy, which then blows the hardware fuse used to control the enable path of the core function algorithm Flash storage area. After the fuse blows, the hardware address link of the corresponding Flash partition is permanently severed, and the engine control firmware stored in that area completely loses the condition for being read and run by the circuitry at the physical level. Even if unscrupulous individuals subsequently obtain a valid initial authentication code, the damaged ECU cannot be restored to its original function. To restore the vehicle's control capabilities, the entire ECU hardware must be replaced with a brand new one. Then, authorized personnel from the original manufacturer must perform the initialization configuration of the new device and reset the accumulated runtime parameters in a controlled physical safety environment using specialized tooling and equipment.

[0154] The device authentication method has been described above; the device that performs the method is described below.

[0155] Please see Figure 3 ,like Figure 3 The diagram shown is a structural schematic of a device authentication apparatus provided in an embodiment of this application. The apparatus 300 includes:

[0156] The generation unit 301 is used to collect the current first working status parameters, first cumulative running time and first timestamp of the device based on a preset period, and generate a current status record code based on the first working status parameters, first cumulative running time and first timestamp;

[0157] The storage unit 302 is used to update the state record code stored in the first storage area and the second storage area based on the current state record code. The first storage area and the second storage area are located on different physical hardware carriers and there is no electrical interconnection between the first storage area and the second storage area.

[0158] The comparison unit 303 is used to compare the status record codes in the first storage area and the second storage area when the device is in authentication mode, obtain the comparison result, and determine the access permission authentication result of the device based on the comparison result.

[0159] Optionally, in one embodiment, the generation unit 301 is specifically used for:

[0160] Obtain the second working state parameter from the previous acquisition, and calculate the working state change rate based on the difference between the first and second working state parameters and the time interval between the two acquisitions.

[0161] The current status record code is obtained by concatenating the working status change rate, the first cumulative runtime, and the first timestamp.

[0162] Optionally, in one embodiment, the comparison unit 303 is specifically used for:

[0163] When the comparison results indicate that they match, obtain the first cumulative runtime in the status record code and the second cumulative runtime of the device.

[0164] When the second cumulative runtime is greater than or equal to the first cumulative runtime, the access permission authentication result is determined to be that the device is accessible.

[0165] Optionally, in one embodiment, the comparison unit 303 is specifically used for:

[0166] When the comparison results indicate that they match, obtain the first cumulative runtime and the first timestamp from the status record code, as well as the second cumulative runtime and the second timestamp accumulated by the device.

[0167] When the device has not been shut down for a long time, and the second timestamp is greater than the first timestamp relative to the preset time threshold, the cumulative difference between the second cumulative runtime and the first cumulative runtime is determined.

[0168] When the cumulative difference is less than the first preset difference threshold, the access permission authentication result is determined to be that the device is inaccessible.

[0169] Optionally, in one embodiment, the comparison unit 303 is further configured to:

[0170] When the device last ended due to an abnormal power outage, obtain the first cumulative runtime in the status record code and the fourth cumulative runtime of the device.

[0171] When the difference between the fourth cumulative runtime and the first cumulative runtime is greater than the second difference threshold, the access permission authentication result is determined to be that the device is inaccessible.

[0172] Optionally, in one embodiment, the generating unit 301 is further configured to:

[0173] When the device is powered off, the third working status parameters, the third cumulative running time and the third timestamp before the device is powered off are collected, and a power off status record code is generated based on the third working status parameters, the third cumulative running time and the third timestamp.

[0174] Storage unit 302 is also used for:

[0175] Update the status record codes stored in the first and second storage areas based on the shutdown status record codes.

[0176] Optionally, in one embodiment, the comparison unit 303 is further configured to:

[0177] When the access permission authentication result is that the device is inaccessible, the number of authentication failures is counted.

[0178] When the number of authentication failures exceeds a preset threshold, the device's operating logic is erased.

[0179] Optionally, in one embodiment, the generation unit 301 is specifically used for:

[0180] Obtain the historical state record codes stored in the first and second storage areas, and calculate the hash value of the historical state record codes;

[0181] The current status record code is generated based on the first working status parameter, the first cumulative runtime, the first timestamp, and the hash value.

[0182] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned device authentication method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0183] Please see Figure 4 , Figure 4 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes:

[0184] The processor 401 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0185] The memory 402 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 402 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 402 and is called and executed by the processor 401 using the device authentication method of the embodiments of this application.

[0186] Input / output interface 403 is used to implement information input and output;

[0187] The communication interface 404 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0188] Bus 405 transmits information between various components of the device (e.g., processor 401, memory 402, input / output interface 403, and communication interface 404);

[0189] The processor 401, memory 402, input / output interface 403 and communication interface 404 are connected to each other within the device via bus 405.

[0190] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described device authentication method.

[0191] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0192] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0193] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0194] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0195] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0196] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0197] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0198] 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 the units described above 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 coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0199] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

[0201] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0202] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A device authentication method, comprising: The device's current first working status parameters, first cumulative runtime, and first timestamp are collected based on a preset period, and a current status record code is generated based on the first working status parameters, first cumulative runtime, and first timestamp. The status record codes stored in the first storage area and the second storage area are updated based on the current status record code. The first storage area and the second storage area are located on different physical hardware carriers and there is no electrical interconnection between the first storage area and the second storage area. When the device is in authentication mode, the status record codes in the first storage area and the second storage area are compared to obtain the comparison result, and the access permission authentication result of the device is determined based on the comparison result.

2. The method according to claim 1, wherein, The step of generating the current status record code based on the first working status parameter, the first cumulative runtime, and the first timestamp includes: Obtain the second working state parameter from the previous acquisition, and calculate the working state change rate based on the difference between the first working state parameter and the second working state parameter, and the time interval between the two acquisitions. The current status record code is obtained by concatenating the working status change rate, the first cumulative running time, and the first timestamp.

3. The method according to claim 1, wherein, The step of determining the access permission authentication result of the device based on the comparison result includes: When the comparison results indicate a match, the first cumulative runtime in the status record code and the second cumulative runtime of the device are obtained. When the second cumulative runtime is greater than or equal to the first cumulative runtime, the access permission authentication result is determined to be that the device is accessible.

4. The method according to claim 1, wherein, Determining the access permissions of the device based on the comparison results includes: When the comparison results indicate a match, the first cumulative runtime and first timestamp in the status record code, as well as the second cumulative runtime and second timestamp accumulated by the device, are obtained. When the device has not been shut down for a long time, and the second timestamp is greater than the first timestamp relative to the first timestamp, the cumulative difference between the second cumulative runtime and the first cumulative runtime is determined. When the cumulative difference is less than the first preset difference threshold, the access permission authentication result is determined to be that the device is inaccessible.

5. The method according to claim 1, wherein, The method further includes: When the device last ended due to an abnormal power outage, the first cumulative runtime in the status record code and the fourth cumulative runtime of the device are obtained. When the difference between the fourth cumulative runtime and the first cumulative runtime is greater than the second difference threshold, the access permission authentication result is determined to be that the device is inaccessible.

6. The method according to claim 1, wherein, The method further includes: When the device is powered off, the third working status parameters, the third cumulative running time and the third timestamp before the device is powered off are collected, and a power off status record code is generated based on the third working status parameters, the third cumulative running time and the third timestamp. Update the status record codes stored in the first and second storage areas based on the shutdown status record codes.

7. The method according to claim 1, wherein, The method further includes: When the access permission authentication result is that the device is inaccessible, the number of authentication failures is counted. When the number of authentication failures exceeds a preset threshold, the device's operating logic is erased.

8. A device authentication apparatus, wherein, include: The generation unit is used to collect the current first working status parameter, first cumulative running time and first timestamp of the device based on a preset period, and generate a current status record code based on the first working status parameter, first cumulative running time and first timestamp; A storage unit is used to update the state record code stored in the first storage area and the second storage area based on the current state record code. The first storage area and the second storage area are located on different physical hardware carriers and there is no electrical interconnection between the first storage area and the second storage area. The comparison unit is used to compare the status record codes in the first storage area and the second storage area when the device is in authentication mode, obtain the comparison result, and determine the access permission authentication result of the device based on the comparison result.

9. An electronic device, comprising: Memory, transceiver, processor, and bus system; The memory is used to store programs; The processor is configured to execute a program in the memory, including performing the method as described in any one of claims 1 to 7; The bus system is used to connect the memory and the processor to enable communication between the memory and the processor.

10. A computer-readable storage medium comprising instructions, when executed on a computer, causing the computer to perform the method as claimed in any one of claims 1 to 7.

Images