Electronic pricing scale data tamper-proofing control method and system

Abstract

The present application relates to the technical field of electronic metering data security, in particular to an electronic pricing scale data tamper-proofing control method and system, comprising: calculating the boot firmware hash of the current firmware; determining the boot state through hash value comparison processing; collecting the final metering weight, timestamp and transaction anti-replay random number; constructing a message digest to be signed; using the preset device private key through the security module, performing asymmetric signature processing on the message digest to be signed to generate a transaction signature; the cloud platform receives the message digest to be signed and the transaction signature; determining the signature trust decision through the asymmetric signature verification algorithm; determining the firmware trust decision through the hash value comparison processing; solving the tampering risk index through the preset dynamic iterative update algorithm; outputting the control instruction for the pricing scale through the preset hierarchical control strategy; the present application blocks the illegal data generated by the cheating firmware, ensures the credibility of the start state, and effectively prevents double-mode cheating.

Description

Technical Field

[0001] This invention relates to the field of electronic measurement data security technology, specifically to a method and system for preventing data tampering in electronic price-computing scales. Background Technology

[0002] Electronic price-computing scales are core measuring devices for ensuring fair transactions. The authenticity and integrity of their weighing data are of paramount importance. In the existing technology, electronic price-computing scales have defects in data security protection and are vulnerable to malicious attacks. Attackers can control the price-computing scales by physically tampering with them, stealing keys, or flashing illegal firmware.

[0003] This type of attack allows the scale to operate in a cheating state, such as by using dual-mode cheating technology, enabling it to generate and upload fraudulent data that does not match the actual physical weight, resulting in seriously inaccurate measurement results. In addition, existing regulatory methods are unable to effectively distinguish between malicious attacks caused by firmware tampering and occasional data anomalies caused by factors such as network fluctuations, leading to inaccurate risk assessments and an inability to provide timely warnings or block cheating behavior, posing serious market supervision risks and economic disputes. Summary of the Invention

[0004] The purpose of this invention is to provide a data anti-tampering control method and system for electronic price-computing scales, to solve the problem of fraudulent data generated by existing price-computing scales due to easy firmware tampering, and to effectively distinguish between malicious attacks caused by firmware tampering and occasional data anomalies, achieving dynamic and accurate assessment and hierarchical automatic handling of tampering risks. Specifically, the technical solution of this invention includes:

[0005] Methods for preventing data tampering in electronic price-computing scales include:

[0006] S1, in response to the power-on of the weighing scale, calculates the boot firmware hash of the current firmware; based on the boot firmware hash and the preset reference firmware hash in the security module, the boot status is determined by comparing the hash values.

[0007] S2, collects the final measured weight, timestamp, and transaction anti-replay random number;

[0008] S3, combine the final measured weight, timestamp, transaction anti-replay random number and boot firmware hash to construct a message digest to be signed;

[0009] S4, in response to the boot state being matched, the security module uses the preset device private key to perform asymmetric signature processing on the message digest to be signed, generating a transaction signature;

[0010] S5, the cloud platform receives the message digest to be signed and the transaction signature;

[0011] S6, based on the transaction signature and combined with the device public key obtained from the preset trusted device state database, determines the signature trust decision through an asymmetric signature verification algorithm;

[0012] S7, based on the boot firmware hash, combined with the known compliant firmware hash obtained from the trusted device state database, determines the firmware trust decision through hash value comparison processing;

[0013] S8 combines signature trust decision and firmware trust decision, and calculates the tampering risk index through a preset dynamic iterative update algorithm;

[0014] S9, based on the tampering risk index, preset early warning threshold and preset lockout threshold, outputs control commands for the pricing scale through a preset hierarchical control strategy.

[0015] Furthermore, the steps prior to the execution of S1 also include:

[0016] Physically couple the security module to the analog-to-digital conversion link;

[0017] The device private key and device public key are generated within the security module, and the device private key is set to be non-exportable;

[0018] Calculate the cryptographic hash value of the compliant firmware and write the cryptographic hash value as the reference firmware hash into the security module.

[0019] Furthermore, in S4, in response to a matching bootstrap state, the following includes:

[0020] The security module verifies the boot state and activates asymmetric signature processing only when the boot state indicates that the firmware has not been tampered with.

[0021] Furthermore, in S6 and S7, a trusted device state library is preset for:

[0022] Store the device ID of the price-computing scale;

[0023] Securely associate the device ID with the device public key;

[0024] Securely associate the device ID with a known compliant firmware hash.

[0025] Furthermore, a preset dynamic iterative update algorithm is included, comprising:

[0026] In response to a firmware trust decision that is deemed untrustworthy, a preset firmware tampering penalty weight is used to increase the tampering risk index;

[0027] In response to the firmware trust decision being trustworthy and the signature trust decision being untrustworthy, a preset signature tampering penalty weight is adopted to increase the tampering risk index, and the preset firmware tampering penalty weight is higher than the preset signature tampering penalty weight;

[0028] In response to the firmware trust decision being trusted and the signature trust decision being trusted, a preset trust decay factor is used to reduce the tampering risk index.

[0029] Furthermore, a pre-defined hierarchical control strategy is included, including:

[0030] If the tampering risk index exceeds the preset locking threshold, the control command is used to reject subsequent transaction data packets from the pricing scale and lock the device;

[0031] If the tampering risk index is greater than the preset warning threshold but not greater than the preset locking threshold, the control command is used to send an inspection work order.

[0032] If the tampering risk index is not greater than the preset warning threshold, the equipment is considered to be in normal condition.

[0033] The electronic price-computing scale data tamper-proof control system includes:

[0034] The status determination module is used to calculate the boot firmware hash of the current firmware in response to the power-on of the pricing scale; based on the boot firmware hash and the reference firmware hash preset in the security module, the boot status is determined by comparing the hash values.

[0035] The local processing module includes:

[0036] The data acquisition unit is used to collect the final measured weight, timestamp, and transaction anti-replay random number;

[0037] The digest construction unit is used to combine the final measured weight, timestamp, transaction anti-replay random number and boot firmware hash to construct a message digest to be signed;

[0038] The signature generation unit is used to generate a transaction signature by performing asymmetric signature processing on the message digest to be signed using a preset device private key through the security module in response to a matching boot state.

[0039] The cloud-based verification module includes:

[0040] The data receiving unit is used by the cloud platform to receive the message digest and transaction signature to be signed;

[0041] The signature verification unit is used to determine the signature trust decision based on the transaction signature and the device public key obtained from the preset trusted device state database, through an asymmetric signature verification algorithm.

[0042] The firmware verification unit is used to determine the firmware trust decision based on the boot firmware hash and the known compliant firmware hash obtained from the trusted device state database through hash value comparison.

[0043] The risk control module includes:

[0044] The risk quantification unit is used to combine signature trust decision and firmware trust decision, and calculate the tampering risk index through a preset dynamic iterative update algorithm;

[0045] The closed-loop control unit is used to output control commands for the price-computing scale based on the tampering risk index, preset warning threshold, and preset lockout threshold, through a preset hierarchical control strategy.

[0046] Furthermore, it also includes:

[0047] A pre-defined trusted device state library is used to store the device ID of the pricing scale; the device ID is securely associated with the device public key; and the device ID is securely associated with the known compliant firmware hash for use by the signature verification unit and the firmware verification unit.

[0048] Furthermore, the risk quantification unit is specifically used for:

[0049] In response to a firmware trust decision that is deemed untrustworthy, a preset firmware tampering penalty weight is used to increase the tampering risk index;

[0050] In response to the firmware trust decision being trustworthy and the signature trust decision being untrustworthy, a preset signature tampering penalty weight is adopted to increase the tampering risk index, and the preset firmware tampering penalty weight is higher than the preset signature tampering penalty weight;

[0051] In response to the firmware trust decision being trusted and the signature trust decision being trusted, a preset trust decay factor is used to reduce the tampering risk index.

[0052] Furthermore, the closed-loop control unit is specifically used for:

[0053] If the tampering risk index is greater than the preset locking threshold, a control command will be output to reject subsequent transaction data packets from the weighing scale and lock the device.

[0054] If the tampering risk index is greater than the preset warning threshold but not greater than the preset locking threshold, then output the control command for sending the inspection work order.

[0055] If the tampering risk index is not greater than the preset warning threshold, the equipment is considered to be in normal condition.

[0056] Compared with the prior art, the present invention has the following beneficial effects:

[0057] 1. This invention employs a hardware security module that forcibly verifies firmware integrity upon power-up. The signature function is activated only when the firmware is in a matching state that has not been tampered with, thus blocking the generation of illegal data by cheating firmware from the source and ensuring the trustworthiness of the startup state.

[0058] 2. This invention achieves a strong correlation between measurement data and device operating status by cryptographically binding and signing the final measured weight with the firmware hash value. Even if an attacker flashes cheating firmware, they will not be able to obtain a legitimate signature, effectively preventing dual-mode cheating.

[0059] 3. The cloud platform of this invention performs dual verification of signature and firmware, and adopts a dynamic risk algorithm. By setting a penalty weight for firmware tampering that is much higher than that for signature errors, it achieves accurate differentiation and quantitative assessment of malicious attacks and occasional network anomalies.

[0060] 4. Based on a dynamically calculated tampering risk index, this invention sets two levels of thresholds for early warning and locking, realizing automated hierarchical control. It can promptly lock devices confirmed to be cheating and send work orders to devices suspected of being abnormal, thus realizing a shift from passive auditing to proactive intervention. Attached Figure Description

[0061] The present invention will be further explained below with reference to the accompanying drawings and embodiments:

[0062] Figure 1 This is a flowchart of the method of the present invention;

[0063] Figure 2 This is a structural diagram of the system of the present invention. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments.

[0065] Example 1:

[0066] Please see Figure 1 Methods for preventing data tampering in electronic price-computing scales include:

[0067] S1, in response to the power-on of the weighing scale, calculates the boot firmware hash of the current firmware; based on the boot firmware hash and the preset reference firmware hash in the security module, the boot status is determined by comparing the hash values.

[0068] S2, collects the final measured weight, timestamp, and transaction anti-replay random number;

[0069] S3, combine the final measured weight, timestamp, transaction anti-replay random number and boot firmware hash to construct a message digest to be signed;

[0070] S4, in response to the boot state being matched, the security module uses the preset device private key to perform asymmetric signature processing on the message digest to be signed, generating a transaction signature;

[0071] S5, the cloud platform receives the message digest to be signed and the transaction signature;

[0072] S6, based on the transaction signature and combined with the device public key obtained from the preset trusted device state database, determines the signature trust decision through an asymmetric signature verification algorithm;

[0073] S7, based on the boot firmware hash, combined with the known compliant firmware hash obtained from the trusted device state database, determines the firmware trust decision through hash value comparison processing;

[0074] S8 combines signature trust decision and firmware trust decision, and calculates the tampering risk index through a preset dynamic iterative update algorithm;

[0075] S9, based on the tampering risk index, preset early warning threshold and preset lockout threshold, outputs control commands for the pricing scale through a preset hierarchical control strategy.

[0076] This embodiment provides a method for preventing data tampering in electronic price-computing scales. Its purpose is to construct a complete trust chain from hardware startup, data acquisition, data signing to cloud verification and dynamic risk control, to ensure the authenticity and integrity of the electronic price-computing scale's measurement data. The method includes the following steps:

[0077] S1, in response to the power-on of the weighing scale, calculates the boot firmware hash of the current firmware; based on the boot firmware hash and the preset reference firmware hash in the security module, the boot status is determined by comparing the hash values.

[0078] In this embodiment, the security module SE refers to an immutable hardware root of trust that is physically coupled to the analog-to-digital converter (ADC) link; the reference firmware hash Hr refers to the base value in the security module's fuse memory, which is the cryptographic hash value such as SHA-256 calculated by the compliant firmware and written into the device's fuse memory during the device production or testing phase. It represents the device's legitimate birth status.

[0079] Each time the price-computing scale is powered on, the bootloader calculates the boot firmware hash of the firmware to be run in the current flash memory. This is a physical reflection of the current operating status of the equipment;

[0080] The security module SE internally performs hash value comparisons to determine the boot state Sb. This comparison process can be implemented using the following formula:

[0081]

[0082] in, : Guidance state; in this embodiment, A matching status indicates that the firmware has not been tampered with; A mismatch status indicates that the firmware has been tampered with;

[0083] The zero-check function, a variant of KroneckerDelta, performs an exact comparison, outputting 1 only if the input is 0, and 0 otherwise.

[0084] The boot firmware hash is calculated in real time upon power-on.

[0085] Reference firmware hash, sourced from a preset within the security module;

[0086] XOR operation;

[0087] Enforce consistency between the boot firmware and compliant firmware through cryptographic operations;

[0088] S2, collects the final measured weight, timestamp, and transaction anti-replay random number;

[0089] After the weighing scale performs a weighing operation, the main processor obtains the final measured weight w from the analog-to-digital converter (ADC) link. This is the core physical data for this measurement. Simultaneously, the system generates a high-precision timestamp t derived from the internal clock and a unique transaction anti-replay random number generated by a hardware random number generator. , and Used to ensure the uniqueness and timeliness of transactions and prevent replay attacks;

[0090] S3, combine the final measured weight, timestamp, transaction anti-replay random number and boot firmware hash to construct a message digest to be signed;

[0091] In this embodiment, the message digest to be signed is constructed by taking the message digest obtained in S1. Obtained in S2 , , Perform a data concatenation operation and execute a cryptographic hash function such as SHA-256 on the concatenated data block:

[0092]

[0093] Measurement behavior With equipment status Force cryptographic binding;

[0094] S4, in response to the matching boot state, the security module uses the preset device private key to perform asymmetric signature processing on the message digest to be signed, and generates a transaction signature;

[0095] Device private key It is generated within the Security Module (SE) during the production phase and is set to be non-exportable to ensure its physical security.

[0096] The security module SE must verify the boot state determined in S1. Whether it matches 1; only under this condition will the SE be activated and its internal storage used. For those built in S3 Execute an asymmetric signature algorithm such as ECDSA to generate a transaction signature. :

[0097]

[0098] like If there is a mismatch, SE will refuse to perform the signature operation;

[0099] S5, the cloud platform receives the message digest to be signed and the transaction signature;

[0100] The pricing scale will include , , , and transaction signature The trusted data packet, along with the device ID, is uploaded to the cloud monitoring platform.

[0101] S6, based on the transaction signature and combined with the device public key obtained from the preset trusted device state database, determines the signature trust decision through an asymmetric signature verification algorithm;

[0102] The default trusted device status database is a database maintained on a cloud-based monitoring platform; device public key. Is with The paired public key is securely associated with the device ID and stored in this database during the production phase;

[0103] The cloud platform retrieves the corresponding device ID from the database based on the device ID in the data packet. ; Perform an asymmetric signature verification algorithm to determine the signature trust decision V. :

[0104]

[0105] in, : Signature trust ruling; In this embodiment, To be considered trustworthy, it means that the data packet indeed comes from the corresponding device and its content has not been tampered with; Unreliable;

[0106] S7, based on the boot firmware hash, combined with the known compliant firmware hash obtained from the trusted device state database, determines the firmware trust decision through hash value comparison processing;

[0107] The known compliant firmware hash Hg is The copy in the cloud-based trusted device status database represents the latest legal firmware status of the device as approved by the regulator. This value is only updated after a compliant firmware upgrade process.

[0108] The cloud platform is executing S1. Cloud replay to determine firmware trust decisions :

[0109]

[0110] in, Firmware trust ruling; This indicates that the firmware running on the device during weighing is consistent with the firmware recognized by the cloud. Untrusted firmware cheating;

[0111] S8 combines signature trust decision and firmware trust decision, and calculates the tampering risk index through a preset dynamic iterative update algorithm;

[0112] To differentiate between occasional network errors and malicious attacks, the system introduces a dynamic tampering risk index for each device. The preset dynamic iterative update algorithm is a state transition equation used to quantify device health; in The time, obtained from S6 and S7 and Updated risk index:

[0113]

[0114] in, Risk index at the previous moment;

[0115] The current signature and firmware trust decision is 0 or 1, originating from S6 and S7;

[0116] Firmware tampering penalty weight, a preset high-risk constant such as 100;

[0117] Signature tampering penalty weight, a preset medium-risk constant, such as 10;

[0118] Trust decay factor, a preset constant close to 1, for example, 0.99;

[0119] Parameter source and basis: and It is a constant set according to the severity of the risk, and This is to ensure that the penalty for deterministic cheating in firmware is far greater than that for signature errors that may be network issues; Used to slowly reduce the risk index and restore trust when the device remains trustworthy;

[0120] S9, based on the tampering risk index, preset early warning threshold and preset lockout threshold, outputs control commands for the pricing scale through a preset hierarchical control strategy;

[0121] Preset warning threshold and preset locking threshold It is a constant pre-set based on regulatory strategy and acceptable risk level, and ;

[0122] The preset tiered control strategy is based on the latest risk index calculated by S8. The closed-loop control logic executed is as follows:

[0123] like : Confirm that the equipment is in normal condition;

[0124] like : Triggering a Level 1 warning, the cloud platform outputs control commands to automatically send inspection work orders to the regulator and operations and maintenance personnel;

[0125] like : Triggering a secondary lock, the cloud platform outputs control commands to reject subsequent transaction data packets from the pricing scale and can remotely lock the device. For example, the cloud platform uses its private key to sign the lock command, and the pricing scale's security module uses a pre-set public key to verify the signature before executing the lock, ensuring the security and authority of the downlink commands.

[0126] This embodiment constructs a complete data anti-tampering system through the complete process from S1 to S9, from hardware trust root S1 to metering behavior S2, from local encrypted signature S3 and S4 to cloud dual verification S6 and S7, and combines dynamic risk quantification S8 and closed-loop control S9. It not only ensures the non-repudiation of single transaction data, but also achieves effective identification and automatic handling of advanced tampering methods such as dual-mode cheating by forcibly binding metering behavior w with device status Hb.

[0127] Example 2:

[0128] The steps before S1 is executed also include:

[0129] Physically couple the security module to the analog-to-digital conversion link;

[0130] The device private key and device public key are generated within the security module, and the device private key is set to be non-exportable;

[0131] Calculate the cryptographic hash value of the compliant firmware and write the cryptographic hash value as the reference firmware hash into the security module.

[0132] Based on Example 1, this embodiment further specifies the hardware initialization and trust root establishment phases before S1 execution, and also includes:

[0133] Physically couple the security module to the analog-to-digital conversion link;

[0134] The security module SE is the hardware root of trust, and the analog-to-digital converter (ADC) link is the physical source of the metering signal. In this embodiment, the SE is integrated into the signal output path of the ADC chip through hardware design, or they are closely associated in the PCB layout and encapsulated with epoxy resin or other means to achieve physical coupling between the two. The purpose is to prevent attackers from bypassing the SE by physical wiring or other means and directly stealing or tampering with the original metering signal from the ADC.

[0135] The device private key and device public key are generated within the security module, and the device private key is set to be non-exportable;

[0136] During equipment manufacturing or initial testing, an asymmetric key pair is generated using the True Random Number Generator (TRNG) within the Security Module (SE). , Device private key Protected by the hardware security boundary of the security module and set to non-exportable, it means... Once generated, it will never leave the SE chip; all signature operations, such as S4, must be called and executed within the SE. Device public key. It can then be exported for cloud verification in subsequent S6 steps;

[0137] Calculate the cryptographic hash value of the compliant firmware and write it into the security module as a reference firmware hash;

[0138] During the same production or testing phase, the compliant firmware certified by the regulatory agency, i.e., the legitimate scale body program, is hashed using a cryptographic hash function such as SHA-256. This hash value, used as the reference firmware hash Hr, is written into the one-time programmable OTP fuse-breaking memory of the security module SE. Writing to the fuse-breaking memory ensures... Once set, it cannot be changed, forming the gold standard for firmware integrity verification in step S1.

[0139] This embodiment establishes the strongest root of trust required before the S1 method is executed through the above three steps, from the physical level, the key level, and the firmware benchmark level; it prevents signal tampering through physical coupling; it ensures the uniqueness and impersonability of the device identity through the non-derivative private key; and it ensures the immutability of the firmware verification benchmark by fusing the reference hash in memory. This greatly enhances the starting point strength and anti-attack capability of the entire trust chain in Embodiment 1.

[0140] Example 3:

[0141] In S4, in response to a matching bootstrap state, the following are included:

[0142] The security module verifies the boot state and activates asymmetric signature processing only when the boot state indicates that the firmware has not been tampered with.

[0143] Based on Example 1, this embodiment specifically defines the internal execution logic in step S4 in response to a matching boot state, including:

[0144] The security module verifies the boot state and activates asymmetric signature processing only when the boot state indicates that the firmware has not been tampered with.

[0145] In step S1 of Example 1, the security module SE has calculated the boot state. For matching / unaltered, Mismatch / Already altered;

[0146] When step S4 is executed, the main processor requests SE to... When signing, the internal hardware logic of SE verifies the boot state Sb;

[0147] Only when the boot status indicates that the firmware has not been tampered with Only when the SE is activated will asymmetric signature processing be initiated, calling its internal, non-exportable signature function. Generate transaction signature ;

[0148] if SE will reject the signature request, causing S4 to fail to generate the signature. The transaction data generated under the tampered firmware is inherently illegitimate and will inevitably fail in the S6 step.

[0149] This embodiment sets up a mandatory security gate for the signature operation of S4; it checks the firmware integrity verification result of S1. As an S4 signature function The enable signal; this blocks the possibility of source contamination or dual-mode cheating, i.e., a tampered firmware. Even if fraudulent weight data is generated It is also absolutely impossible to call SE to obtain a legitimate transaction signature, ensuring that data generated under any illegal state cannot enter the subsequent trust chain.

[0150] Example 4:

[0151] In S6 and S7, a trusted device state library is preset for use in:

[0152] Store the device ID of the price-computing scale;

[0153] Securely associate the device ID with the device public key;

[0154] Securely associate the device ID with a known compliant firmware hash.

[0155] Based on Example 1, this embodiment specifically defines the functions and data structures of the preset trusted device state library relied upon in steps S6 and S7. This library is used for:

[0156] Store the device ID of the price-computing scale;

[0157] Securely associate the device ID with the device public key;

[0158] Securely associate the device ID with a known compliant firmware hash;

[0159] In this embodiment, the preset trusted device status database is a security database deployed on a cloud-based monitoring platform;

[0160] The device ID is a unique identifier for each weighing scale; this database uses the device ID as the primary key and securely stores two other key data corresponding to that ID:

[0161] Device public key That is, the device private key in S4. Paired public keys; S6 signature verification unit in execution At that time, this will be queried based on the device ID. ;

[0162] Known compliant firmware hash Hg: This is the hash value of the latest legal firmware currently recognized by the regulator; the S7 firmware verification unit executes... At that time, this will be queried based on the device ID. ;

[0163] The library also supports authorized firmware upgrade processes, meaning that regulators can securely update the libraries when a new compliant firmware version is released. This ensures that S7 verification always uses the latest compliance standards;

[0164] This embodiment defines the trust anchor points for cloud verification S6 and S7; through this database, the cloud platform can match the device ID of an uploaded data packet with its corresponding... and should be in State is assigned to authoritative entities for binding and verification; this makes the verification process no longer dependent on any information local to the device. In addition, it enables centralized, flexible, and auditable management of firmware versions.

[0165] Example 5:

[0166] The preset dynamic iterative update algorithm includes:

[0167] In response to a firmware trust decision that is deemed untrustworthy, a preset firmware tampering penalty weight is used to increase the tampering risk index;

[0168] In response to the firmware trust decision being trustworthy and the signature trust decision being untrustworthy, a preset signature tampering penalty weight is adopted to increase the tampering risk index, and the preset firmware tampering penalty weight is higher than the preset signature tampering penalty weight;

[0169] In response to the firmware trust decision being trusted and the signature trust decision being trusted, a preset trust decay factor is used to reduce the tampering risk index.

[0170] Based on Example 1, this embodiment defines the specific logic of the preset dynamic iterative update algorithm in step S8, including:

[0171] In response to a firmware trust decision that is deemed untrustworthy, a preset firmware tampering penalty weight is used to increase the tampering risk index;

[0172] In response to the firmware trust decision being trustworthy and the signature trust decision being untrustworthy, a preset signature tampering penalty weight is adopted to increase the tampering risk index, and the preset firmware tampering penalty weight is higher than the preset signature tampering penalty weight;

[0173] In response to the firmware trust decision being trusted and the signature trust decision being trusted, a preset trust decay factor is used to reduce the tampering risk index.

[0174] These three features together describe the dynamic iterative formula for step S8 in Example 1:

[0175]

[0176] In response to firmware trust ruling as untrusted The formula simplifies to: ; That is, the preset firmware tampering penalty weight;

[0177] Responding to firmware trust ruling as trusted Furthermore, the signature trust ruling is deemed unreliable. The formula simplifies to: ; That is, the pre-set penalty weight for signature tampering;

[0178] The default firmware tampering penalty weight is higher than the default signature tampering penalty weight: that is... For example ;

[0179] Responding to firmware trust ruling as trusted And the signature trust ruling is credible. The formula simplifies to: ; That is, a preset trust decay factor, such as 0.99, is used to slowly reduce the risk index;

[0180] This embodiment greatly improves the accuracy of risk assessment by defining a risk accumulation model that differentiates priorities; by setting... This algorithm can intelligently distinguish deterministic firmware tampering as a form of cheating. And possible abnormal signature errors, This may include sporadic factors such as network packet loss; this makes the system more sensitive to even the highest priority firmware cheating events. It can quickly accumulate risk index, while also being effective against low-to-medium priority events. Give tolerance, and decrease trust through attenuation. This achieves automatic cooling of the risk index, thereby effectively avoiding misjudgments and overreactions caused by occasional network errors.

[0181] Example 6:

[0182] Preset hierarchical control strategies, including:

[0183] If the tampering risk index exceeds the preset locking threshold, the control command is used to reject subsequent transaction data packets from the pricing scale and lock the device;

[0184] If the tampering risk index is greater than the preset warning threshold but not greater than the preset locking threshold, the control command is used to send an inspection work order.

[0185] If the tampering risk index is not greater than the preset warning threshold, the equipment is considered to be in normal condition.

[0186] Based on Example 1, this embodiment defines the specific thresholds and response actions of the preset hierarchical control strategy in step S9, including:

[0187] If the tampering risk index exceeds the preset locking threshold, the control command is used to reject subsequent transaction data packets from the pricing scale and lock the device;

[0188] If the tampering risk index is greater than the preset warning threshold but not greater than the preset locking threshold, the control command is used to send an inspection work order.

[0189] If the tampering risk index is not greater than the preset warning threshold, the equipment is determined to be in normal condition.

[0190] In this embodiment, the risk index is tampered with. Calculation results derived from S8; preset warning threshold and preset locking threshold It is a constant preset according to the regulatory strategy, and ;

[0191] High-risk lock-in: If This indicates that the device has accumulated extremely high risks, such as multiple firmware verification failures. The cloud platform will immediately blacklist the device ID, refuse to continue all transaction data packets, and can remotely send control commands, such as locking the device screen through the SE's secure channel, displaying violation information, forcibly stopping use, and reporting to regulatory agencies for on-site inspection.

[0192] Medium-risk warning: If This indicates that the device is malfunctioning, such as occasional signature failures. The cloud platform marks the device as pending observation, outputs control commands, and automatically sends inspection work orders to the operation and maintenance party and the regulatory party, prompting them to conduct remote diagnosis or on-site inspection, but does not interrupt its transaction function.

[0193] Low risk normal: if Confirm that the device is in normal condition and that the transaction data packets are being received normally;

[0194] This embodiment transforms the quantified risk index in S8 into specific, tiered regulatory actions; it provides an automated closed-loop control method, realizing the transformation from passive auditing to proactive intervention; by setting two levels of thresholds, it achieves precise responses to different levels of risk: high-risk devices, such as those confirmed to be cheating, are immediately blocked, while medium-risk devices, such as those suspected of being abnormal, are given warnings and investigated; this tiered strategy ensures regulatory strength while also taking into account operational efficiency, avoiding a one-size-fits-all, extensive management approach.

[0195] Furthermore, to ensure the robustness of the risk model under extreme conditions, this strategy may also include an authorized reset mechanism when the device is affected by the risk index. Accumulated exceeding the lock threshold Once locked, if the device is inspected and confirmed to be repaired by the regulatory or maintenance personnel on-site—for example, through recalibration or secure firmware flashing—the cloud platform can respond to authorization requests and adjust the device's tamper risk index. Manually reset it to a preset safe value, such as 0, to restore normal service capabilities and avoid issues caused by... The problem of permanent locking caused by slow decay.

[0196] Example 7:

[0197] Please see Figure 2 The electronic price-computing scale data tamper-proof control system includes:

[0198] The status determination module is used to calculate the boot firmware hash of the current firmware in response to the power-on of the pricing scale; based on the boot firmware hash and the reference firmware hash preset in the security module, the boot status is determined by comparing the hash values.

[0199] The local processing module includes:

[0200] The data acquisition unit is used to collect the final measured weight, timestamp, and transaction anti-replay random number;

[0201] The digest construction unit is used to combine the final measured weight, timestamp, transaction anti-replay random number and boot firmware hash to construct a message digest to be signed;

[0202] The signature generation unit is used to generate a transaction signature by performing asymmetric signature processing on the message digest to be signed using a preset device private key through the security module in response to a matching boot state.

[0203] The cloud-based verification module includes:

[0204] The data receiving unit is used by the cloud platform to receive the message digest and transaction signature to be signed;

[0205] The signature verification unit is used to determine the signature trust decision based on the transaction signature and the device public key obtained from the preset trusted device state database, through an asymmetric signature verification algorithm.

[0206] The firmware verification unit is used to determine the firmware trust decision based on the boot firmware hash and the known compliant firmware hash obtained from the trusted device state database through hash value comparison.

[0207] The risk control module includes:

[0208] The risk quantification unit is used to combine signature trust decision and firmware trust decision, and calculate the tampering risk index through a preset dynamic iterative update algorithm.

[0209] The closed-loop control unit is used to output control commands for the price-computing scale based on the tampering risk index, preset warning threshold, and preset lockout threshold, through a preset hierarchical control strategy.

[0210] This embodiment provides a data anti-tampering control system for electronic price-computing scales, including:

[0211] State determination module: This module is implemented in step S1 of embodiment 1; it is configured to calculate the boot firmware hash Hb of the current firmware in response to the power-on of the weighing scale; and based on The reference firmware hash Hr is pre-set within the security module SE. The comparison process determines whether the boot state Sb matches or does not match.

[0212] Local processing module: This module is implemented in steps S2, S3, and S4 of Example 1 and is deployed locally on the pricing scale; it includes:

[0213] Data acquisition unit: used to implement S2, collect the final measured weight w, timestamp t, and transaction anti-replay random number n;

[0214] Abstract building block: used to implement S3, combined with , , and Construct a message digest to be signed ;

[0215] Signature generation unit: Used to implement S4, responding to the bootstrap state output by the state determination module as a match. At that time, by calling the security module SE and using the preset device private key Kp, it can access... Perform asymmetric signing to generate transaction signatures. ;

[0216] Cloud verification module: This module is implemented in steps S5, S6, and S7 of Example 1 and is deployed on the cloud monitoring platform; it includes:

[0217] Data receiving unit: Used to implement S5, receiving data uploaded by the price-computing scale, including... or its original data and Data packets;

[0218] Signature verification unit: used to implement S6, based on and Combined with the device public key Ku obtained from the preset trusted device state database, through Algorithm, determining signature trust ruling V ;

[0219] Firmware verification unit: used to implement S7, based on the data packet Combined with the known compliant firmware hash Hg obtained from the trusted device state database, through The comparison process determines the firmware trust decision Vh.

[0220] Risk control module: This module is implemented in steps S8 and S9 of Example 1 and is deployed on a cloud-based monitoring platform; it includes:

[0221] Risk quantification unit: Used to implement S8, combined with the output of the cloud verification module. and Through a preset dynamic iterative update algorithm, such as The tampering risk index was calculated. ;

[0222] Closed-loop control unit: used to implement S9, according to Preset warning threshold and preset locking threshold By using a preset hierarchical control strategy, control commands for the price-computing scale are output: normal, warning, and lock.

[0223] This embodiment provides a complete system architecture, clearly mapping the process described in Embodiment 1 to functional modules. The system builds a hardware-based root of trust and trusted data generation capability on the device side through a state determination module and a local processing module. It also builds centralized verification and intelligent response capabilities in the cloud through a cloud verification module and a risk control module. This distributed architecture combining the edge and cloud ensures the security and controllability of the entire chain from data generation to data consumption.

[0224] Example 8:

[0225] This system also includes:

[0226] A pre-defined trusted device state library is used to store the device ID of the pricing scale; the device ID is securely associated with the device public key; and the device ID is securely associated with the known compliant firmware hash for use by the signature verification unit and the firmware verification unit.

[0227] This embodiment supplements the components of the system described in Embodiment 7, and also includes:

[0228] Preset trusted device status database: This database is deployed on a cloud platform and implements the functions described in Example 4;

[0229] This pre-defined trusted device state library is designed for:

[0230] Store the device ID of the price-computing scale;

[0231] Securely associate the device ID with the device public key Ku so that it can be called by the signature verification unit, i.e., used by step S6;

[0232] Securely associate the device ID with the known compliant firmware hash Hg so that it can be called by the firmware verification unit, i.e., used by the S7 step.

[0233] This embodiment introduces the preset trusted device state library, providing authoritative and centralized data support for the cloud verification module. The signature verification unit and firmware verification unit no longer rely on static or local configuration, but dynamically obtain the public key and compliant firmware standard required for verification from the library, ensuring the accuracy, real-time performance and flexibility of cloud verification for firmware version upgrades.

[0234] Example 9:

[0235] The risk quantification unit is specifically used for:

[0236] In response to a firmware trust decision that is deemed untrustworthy, a preset firmware tampering penalty weight is used to increase the tampering risk index;

[0237] In response to the firmware trust decision being trustworthy and the signature trust decision being untrustworthy, a preset signature tampering penalty weight is adopted to increase the tampering risk index, and the preset firmware tampering penalty weight is higher than the preset signature tampering penalty weight;

[0238] In response to the firmware trust decision being trusted and the signature trust decision being trusted, a preset trust decay factor is used to reduce the tampering risk index.

[0239] This embodiment, based on the system described in Embodiment 7, specifies the concrete implementation of the risk quantification unit in the risk control module. This unit is specifically used for:

[0240] In response to a firmware trust decision that is deemed untrustworthy, a preset firmware tampering penalty weight is used to increase the tampering risk index;

[0241] In response to the firmware trust decision being trustworthy and the signature trust decision being untrustworthy, a preset signature tampering penalty weight is adopted to increase the tampering risk index, and the preset firmware tampering penalty weight is higher than the preset signature tampering penalty weight;

[0242] In response to the firmware trust decision being trusted and the signature trust decision being trusted, a preset trust decay factor is used to reduce the tampering risk index.

[0243] These three features describe the algorithmic logic executed by the risk quantification unit, namely the preset dynamic iterative update algorithm; the unit receives... and As input, maintain each device The state, and based on the above three logics, that is... Shijia ; Shijia ; Time Travel To calculate the output ;

[0244] This embodiment configures the risk quantification unit with the aforementioned dynamic iterative algorithm, particularly... The differential weighting logic enables this unit to intelligently distinguish risk levels; it is no longer a simple counter, but a state machine that can simulate the accumulation and decay process of trust and doubt; this upgrades the decision-making basis of the system, especially the subsequent closed-loop control unit, from a simple yes / no decision to a refined risk score, which greatly improves the accuracy and robustness of the control strategy.

[0245] Example 10:

[0246] Closed-loop control unit, specifically used for:

[0247] If the tampering risk index is greater than the preset locking threshold, a control command will be output to reject subsequent transaction data packets from the weighing scale and lock the device.

[0248] If the tampering risk index is greater than the preset warning threshold but not greater than the preset locking threshold, then output the control command for sending the inspection work order.

[0249] If the tampering risk index is not greater than the preset warning threshold, the equipment is considered to be in normal condition.

[0250] This embodiment, based on the system described in Embodiment 7, specifies the concrete implementation of the closed-loop control unit in the risk control module. This unit is specifically used for:

[0251] If the tampering risk index is greater than the preset locking threshold, a control command will be output to reject subsequent transaction data packets from the weighing scale and lock the device.

[0252] If the tampering risk index is greater than the preset warning threshold but not greater than the preset locking threshold, then output the control command for sending the inspection work order.

[0253] If the tampering risk index is not greater than the preset warning threshold, the equipment is determined to be in normal condition.

[0254] These three features describe the strategy logic executed by the closed-loop control unit, namely the preset hierarchical control strategy described in Example 6; this unit receives the tampering risk index output by the risk quantification unit. As input, it is compared with the internally configured preset warning threshold. and preset locking threshold The system compares the results and selectively outputs one of three control commands: lock, warning, or normal.

[0255] This embodiment configures the closed-loop control unit with the aforementioned hierarchical control strategy, making it the execution terminal and control closed loop of the entire system; it calculates the abstract risk score from the risk quantification unit. This has been successfully transformed into specific, automated regulatory actions with varying degrees of intensity; this ensures that any discovered tampering risks, whether high or medium risk, can be handled automatically, promptly, and proportionally by the system, achieving a seamless connection from risk perception to risk handling.

[0256] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method for preventing data tampering in electronic price-computing scales, characterized in that: include: S1, in response to the power-on of the weighing scale, calculates the boot firmware hash of the current firmware; based on the boot firmware hash and the preset reference firmware hash in the security module, the boot status is determined by comparing the hash values. S2, collects the final measured weight, timestamp, and transaction anti-replay random number; S3, combine the final measured weight, timestamp, transaction anti-replay random number and boot firmware hash to construct a message digest to be signed; S4, in response to the matching boot state, the security module uses the preset device private key to perform asymmetric signature processing on the message digest to be signed, and generates a transaction signature; S5, the cloud platform receives the message digest to be signed and the transaction signature; S6, based on the transaction signature and combined with the device public key obtained from the preset trusted device state database, determines the signature trust decision through an asymmetric signature verification algorithm; S7, based on the boot firmware hash, combined with the known compliant firmware hash obtained from the trusted device state database, determines the firmware trust decision through hash value comparison processing; S8 combines signature trust decision and firmware trust decision, and calculates the tampering risk index through a preset dynamic iterative update algorithm; S9, based on the tampering risk index, preset early warning threshold and preset lockout threshold, outputs control commands for the pricing scale through a preset hierarchical control strategy; The preset dynamic iterative update algorithm includes: In response to a firmware trust decision that is deemed untrustworthy, a preset firmware tampering penalty weight is used to increase the tampering risk index; In response to the firmware trust decision being trustworthy and the signature trust decision being untrustworthy, a preset signature tampering penalty weight is adopted to increase the tampering risk index, and the preset firmware tampering penalty weight is higher than the preset signature tampering penalty weight; In response to the firmware trust decision being trusted and the signature trust decision being trusted, a preset trust decay factor is used to reduce the tampering risk index.

2. The method for preventing data tampering in electronic price-computing scales according to claim 1, characterized in that, The steps before S1 is executed also include: Physically couple the security module to the analog-to-digital conversion link; The device private key and device public key are generated within the security module, and the device private key is set to be non-exportable; Calculate the cryptographic hash value of the compliant firmware and write the cryptographic hash value as the reference firmware hash into the security module.

3. The method for preventing data tampering in electronic price-computing scales according to claim 1, characterized in that, In S4, in response to a matching bootstrap state, the following are included: The security module verifies the boot state and activates asymmetric signature processing only when the boot state indicates that the firmware has not been tampered with.

4. The method for preventing data tampering in electronic price-computing scales according to claim 1, characterized in that, In S6 and S7, a trusted device state library is preset for use in: Store the device ID of the price-computing scale; Securely associate the device ID with the device public key; Securely associate the device ID with a known compliant firmware hash.

5. The method for preventing data tampering in electronic price-computing scales according to claim 1, characterized in that, Preset hierarchical control strategies, including: If the tampering risk index exceeds the preset locking threshold, the control command is used to reject subsequent transaction data packets from the pricing scale and lock the device; If the tampering risk index is greater than the preset warning threshold but not greater than the preset locking threshold, the control command is used to send an inspection work order. If the tampering risk index is not greater than the preset warning threshold, the equipment is considered to be in normal condition.

6. A data anti-tampering control system for electronic price-computing scales, applied to the data anti-tampering control method for electronic price-computing scales as described in any one of claims 1-5, characterized in that, include: The status determination module is used to calculate the boot firmware hash of the current firmware in response to the power-on of the pricing scale; based on the boot firmware hash and the reference firmware hash preset in the security module, the boot status is determined by comparing the hash values. The local processing module includes: The data acquisition unit is used to collect the final measured weight, timestamp, and transaction anti-replay random number; The digest construction unit is used to combine the final measured weight, timestamp, transaction anti-replay random number and boot firmware hash to construct a message digest to be signed; The signature generation unit is used to generate a transaction signature by performing asymmetric signature processing on the message digest to be signed using a preset device private key through the security module in response to a matching boot state. The cloud-based verification module includes: The data receiving unit is used by the cloud platform to receive the message digest and transaction signature to be signed; The signature verification unit is used to determine the signature trust decision based on the transaction signature and the device public key obtained from the preset trusted device state database, through an asymmetric signature verification algorithm. The firmware verification unit is used to determine the firmware trust decision based on the boot firmware hash and the known compliant firmware hash obtained from the trusted device state database through hash value comparison. The risk control module includes: The risk quantification unit is used to combine signature trust decision and firmware trust decision, and calculate the tampering risk index through a preset dynamic iterative update algorithm; The closed-loop control unit is used to output control commands for the price-computing scale based on the tampering risk index, preset warning threshold, and preset lockout threshold, through a preset hierarchical control strategy.

7. The electronic price-computing scale data anti-tampering control system according to claim 6, characterized in that, Also includes: A pre-defined trusted device state library is used to store the device ID of the pricing scale; the device ID is securely associated with the device public key; and the device ID is securely associated with the known compliant firmware hash for use by the signature verification unit and the firmware verification unit.

8. The electronic price-computing scale data anti-tampering control system according to claim 6, characterized in that, The risk quantification unit is specifically used for: In response to a firmware trust decision that is deemed untrustworthy, a preset firmware tampering penalty weight is used to increase the tampering risk index; In response to the firmware trust decision being trustworthy and the signature trust decision being untrustworthy, a preset signature tampering penalty weight is adopted to increase the tampering risk index, and the preset firmware tampering penalty weight is higher than the preset signature tampering penalty weight; In response to the firmware trust decision being trusted and the signature trust decision being trusted, a preset trust decay factor is used to reduce the tampering risk index.

9. The electronic price-computing scale data anti-tampering control system according to claim 6, characterized in that, Closed-loop control unit, specifically used for: If the tampering risk index is greater than the preset locking threshold, a control command will be output to reject subsequent transaction data packets from the weighing scale and lock the device. If the tampering risk index is greater than the preset warning threshold but not greater than the preset locking threshold, then output the control command for sending the inspection work order. If the tampering risk index is not greater than the preset warning threshold, the equipment is considered to be in normal condition.

Images