Mac precomputation and incremental verification method and system

Abstract

The application discloses a MAC pre-computation and incremental verification method and system, comprising the following steps: a sending end sends a current message embedding current message verification information and subsequent message verification information to a receiving end; if the receiving end verifies the current message verification information successfully, the receiving end obtains a pre-computed MAC cache based on the subsequent message verification information; the sending end sends one or more subsequent messages to the receiving end in sequence; and when the receiving end receives one subsequent message sent by the sending end, if the MAC extracted from the subsequent message based on the pre-computed MAC cache is verified successfully, the subsequent message is verified successfully. The current message verification information and the subsequent message verification information are embedded in the current message, and when the receiving end receives the current message, the current message verification information is verified successfully, and the pre-computed MAC cache is obtained based on the subsequent message verification information, so that the receiving end verifies the subsequent message by preferentially matching the pre-computed MAC cache and skipping MAC complete computation, thereby reducing the load and delay of an HSM.

Description

Technical Field

[0001] This invention relates to the field of vehicle communication technology, specifically to a method and system for MAC pre-calculation and incremental verification. Background Technology

[0002] In modern vehicle networks, to meet the requirements of communication authenticity and integrity, communication between key ECUs typically employs the AUTOSAR SecOC (Secure Onboard Communication) mechanism to authenticate and protect communication PDUs. SecOC operates at the PDU level, forming a secure PDU by appending a freshness certificate and a message authentication code (MAC) to the data to be protected at the sending end. At the receiving end, the freshness certificate is checked for validity before the MAC is recalculated / verified to resist tampering and replay attacks.

[0003] In related technologies, AUTOSAR SecOC independently calculates the complete MAC for each security message. In high-frequency continuous message scenarios, the receiver has a high computational load and large verification latency. The model of verifying a complete MAC for each message will bring the following problems to the receiver: high-frequency short transaction concurrency, receiver verification latency and jitter amplification, and pressure from the mutual squeezing of security requirements and real-time requirements. This will lead to increased verification latency, uncontrollable jitter, and worst-case latency deterioration, which is not conducive to the problems of closed-loop vehicle control and high deterministic communication requirements. Summary of the Invention

[0004] To address the problems existing in the prior art, this invention provides a MAC pre-computation and incremental verification method and system. The current message verification information and subsequent message verification information are embedded in the current message. When the receiving end receives the current message, if the current message verification information is verified and passed, the pre-computed MAC cache is obtained based on the subsequent message verification information. This allows the receiving end to prioritize matching the pre-computed MAC cache when verifying subsequent messages, skipping the full MAC calculation, which can reduce HSM load and latency.

[0005] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0006] According to a first aspect of this application, a MAC pre-computation and incremental verification method is provided, applied at a receiving end, comprising: Receive the current message sent by the sending end, wherein the current message embeds current message verification information and subsequent message verification information; If the verification information of the current message passes, the pre-calculated MAC cache is obtained based on the verification information of subsequent messages; If the MAC address extracted from the subsequent message received from the sender is verified based on the pre-calculated MAC cache, then the subsequent message is verified.

[0007] According to a second aspect of this application, a MAC pre-computation and incremental verification method is provided, applied at the sending end, including: Generate current message verification information based on the current message, generate subsequent message verification information based on one or more consecutive subsequent messages following the current message, and send the current message containing the current message verification information and subsequent message verification information to the receiving end. The one or more subsequent messages are sent to the receiving end in sequence.

[0008] According to a third aspect of this application, a MAC pre-computation and incremental verification receiver is provided, comprising: The receiving module is used to receive the current message sent by the sending end, wherein the current message embeds current message verification information and subsequent message verification information; The first verification module is used to obtain the pre-calculated MAC cache based on the verification information of subsequent messages if the verification of the current message information passes. The second verification module is used to verify each subsequent message received from the sender. If the MAC verification of the subsequent message based on the pre-calculated MAC cache is successful, then the subsequent message is verified.

[0009] According to a fourth aspect of this application, a MAC pre-computation and incremental verification transmitter is provided, comprising: The first sending module is used to generate current message verification information based on the current message, generate subsequent message verification information based on one or more consecutive subsequent messages after the current message, and send the current message containing the current message verification information and the subsequent message verification information to the receiving end. The second sending module is used to send one or more subsequent messages to the receiving end in sequence.

[0010] According to a fourth aspect of this application, a MAC pre-computation and incremental verification system is provided, comprising: The sending end is used to generate current message verification information based on the current message, generate subsequent message verification information based on one or more consecutive subsequent messages following the current message, send the current message containing the current message verification information and the subsequent message verification information to the receiving end, and send the one or more subsequent messages to the receiving end in sequence. The receiving end is used to receive the current message sent by the sending end. The current message embeds current message verification information and subsequent message verification information. If the current message verification information is verified successfully, the pre-computed MAC cache is obtained based on the subsequent message verification information. For each subsequent message sent by the sending end, if the MAC verification extracted from the subsequent message based on the pre-computed MAC cache is successful, the subsequent message is verified successfully.

[0011] The beneficial effects of this application are as follows: The MAC pre-computation and incremental verification method and system provided in this application, after determining to enable the prediction mode based on the local configuration parameters of the sending end and the resource status information of the receiving end, the sending end obtains the freshness and MAC corresponding to the current packet, generates the verification information of the current packet, and obtains the predicted freshness and predicted MAC corresponding to multiple consecutive subsequent packets after the current packet, generates the verification information of the subsequent packets, and embeds the verification information of the current packet and the verification information of the subsequent packets into the current packet. If the verification information of the current packet is verified by the receiving end, the pre-computed MAC cache is obtained based on the verification information of the subsequent packets. For each subsequent packet sent by the sending end, if the MAC extracted from the subsequent packet based on the pre-computed MAC cache is verified, the subsequent packet is verified. The receiving end does not need to independently calculate the complete MAC for each security packet, and the verification information of the current packet and the verification information of the subsequent packets both use freshness to generate the MAC, reducing the HSM calculation load, verification latency, and overhead.

[0012] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and do not limit this application. Attached Figure Description

[0013] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and are intended to explain the invention, but do not constitute an undue limitation thereof. In the drawings: Figure 1 This is a flowchart illustrating the application of a MAC pre-computation and incremental verification method of the present invention at the receiving end; Figure 2 This is a flowchart illustrating the application of the MAC pre-computation and incremental verification method of the present invention to the transmitting end; Figure 3 This is a schematic diagram of a MAC pre-computation and incremental verification receiver according to the present invention; Figure 4 This is a schematic diagram of a MAC pre-computation and incremental verification transmitter according to the present invention; Figure 5 This is a schematic diagram of a MAC pre-computation and incremental verification system according to the present invention. Detailed Implementation

[0014] To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0015] It should be understood that the terms "comprising" and other similar expressions in the specification, claims, and accompanying drawings of this invention are intended to cover a non-exclusive inclusion, such as a process, method, system, or apparatus that includes a series of steps or units and is not limited to the listed steps or units. Furthermore, "first" and "second" are used to distinguish different objects and are not intended to describe a specific order.

[0016] The existing AUTOSAR SecOC (Security Onboard Communication) independently calculates the complete MAC (Message Authentication Code) for each security message. In high-frequency continuous message scenarios, the receiver's HSM (Hardware Security Module) has a high computational load and large verification latency.

[0017] Therefore, according to the first aspect of this application, as Figure 1 As shown, this embodiment provides a MAC pre-calculation and incremental verification method, applied to the receiving end, including: Step S101: Receive the current message sent by the sending end, wherein the current message embeds current message verification information and subsequent message verification information.

[0018] In some embodiments of this example, before receiving the current message sent by the sending end, the method further includes: The receiver receives the local configuration parameters of the sender and verifies the resource status information of the receiver based on the local configuration parameters of the sender. If the verification passes, a prediction mode information is generated based on the local configuration parameters of the sending end. The prediction mode information is the information that enables the sending end to embed the current message verification information and the subsequent message verification information into the current message. If the verification fails, information to determine whether to enable the traditional SOC mode is generated based on the local configuration parameters of the sending end. The traditional SOC mode information is used to fully verify the MAC of subsequent packets.

[0019] In this embodiment, the local configuration parameters of the sending end include a preset prediction window, a MAC cache validity period, and a preset verification failure threshold. The verification of the receiving end's resource status information based on the local configuration parameters of the sending end includes: Accept negotiation request PDU, which is constructed by the sending end based on the preset prediction window, MAC cache validity period and preset verification failure threshold; Based on the negotiation request PDU, the receiver resource status information is verified. The receiver resource status information includes the available HSM cache capacity and the current HSM load. If the available HSM cache capacity is greater than the product of the preset prediction window and the MAC length, and the current HSM load is greater than the preset HSM load threshold, the verification passes. If the available HSM cache capacity is less than or equal to the product of the preset prediction window and the MAC length, and / or the current HSM load is less than or equal to the preset HSM load threshold, the verification fails.

[0020] In one specific embodiment, the sending end reads local preset configuration parameters, specifically the preset prediction window K_prop=4, MAC cache validity period T_cache=50ms, and preset verification failure threshold F_thresh=2; then it constructs a negotiation request PDU, the format of which strictly follows the following specifications: byte 0 is fixed as 0xC0 (identifying the negotiation request), byte 1 is filled with the value of the preset prediction window K_prop 4, bytes 2-3 are little-endian byte order (0x0032, corresponding to 50ms in decimal), byte 4 is filled with the value of the MAC cache validity period T_cache 2, and bytes 5-7 are filled with 0x00 (reserved fields); after construction, it is sent to the receiving end (ECU, Electronic Control Unit) through the vehicle security communication channel (compliant with the AUTOSAR SecOC protocol specification).

[0021] In one specific embodiment, after receiving the negotiation request PDU, the receiving end (ECU) immediately performs two core verifications: first, it verifies the available cache capacity of the HSM (Hardware Security Module), which must be ≥ the preset prediction window K_prop × 16 bytes (since each pre-calculated MAC is 16 bytes, at least 64 bytes of cache are required when the preset prediction window K_prop=4); second, it verifies the current HSM load, which must be ≤80% (to avoid excessive load affecting the efficiency of subsequent verifications).

[0022] In this embodiment, generating the prediction mode information based on the local configuration parameters of the sending end includes: The system sets the first actual prediction window based on the preset prediction window, sets the actual local cache validity period based on the MAC cache validity period, sets the local verification failure threshold based on the preset verification failure threshold, and sets the prediction mode enable information. A hash table structure is used to store the first actual prediction window, the actual local cache validity period, the local verification failure threshold, and the prediction mode activation information to obtain the first receiver's local configuration parameters. The first construction response PDU is constructed based on the local configuration parameters of the first receiving end, and the first construction response PDU is sent to the sending end. The first construction response PDU is information to determine whether prediction mode is enabled.

[0023] In this embodiment, the sending end enables the prediction mode based on the determined prediction mode information, and embeds the current message verification information and subsequent message verification information into the current message.

[0024] In one specific embodiment, if both verifications pass, the receiving end sets the following local parameters: the first actual prediction window K_used = the preset prediction window K_prop = 4 (actually enabled prediction window), the actual local cache validity period T_cache_local = 50ms (local cache validity period, consistent with the sending end), and the local verification failure threshold F_thresh_local = 2 (local verification failure threshold, consistent with the sending end). Simultaneously, P_enable = 1 (enable prediction mode). The prediction cache is initialized using a hash table structure with a maximum capacity of 2 × the first actual prediction window K_used = 8 (reserving redundant space to prevent cache overflow due to packet loss). The verification failure counter fail_cnt = 0 and the previous packet sequence number last_seq = 0xFFFFFFFF (initial invalid value, indicating that no valid packet has been received).

[0025] The receiving end constructs the first construct response PDU, with the following format: byte 0 is fixed as 0xC1 (identifying the negotiation response), byte 1 is filled with the value of the first actual prediction window K_used (4), bytes 2-3 are filled with the value of the actual local cache validity period T_cache_local (50ms corresponds to 0x0032), and byte 4 is filled with the value of the local verification failure threshold F_thresh_local (2). The first construct response PDU is returned to the sending end through the secure channel.

[0026] After receiving the first construct response PDU, the sending end determines that the first actual prediction window K_used ≥ 2 (minimum effective window), and then officially starts the prediction mode.

[0027] In this embodiment, the step of generating information to determine whether to enable the traditional SOC mode based on the local configuration parameters of the sending end includes: Information on setting a second actual forecast window and disabling forecast mode; A second construct response PDU is constructed based on the second actual prediction window and the information of not enabling prediction mode, and the second construct response PDU is sent to the sending end. The second construct response PDU is the information of determining to enable traditional SOC mode.

[0028] In this embodiment, the sending end enables the traditional SOC mode based on the second constructed response PDU.

[0029] In this embodiment, if the verification fails (insufficient cache or excessive HSM load), the first actual prediction window K_used=0 and P_enable=0 are set (prediction mode is not enabled).

[0030] The receiving end constructs a second construct response PDU, with the following format: byte 0 is fixed as 0xC1 (identifying the negotiation response), and byte 1 is filled with the value (0) of the first actual prediction window K_used. The second construct response PDU is returned to the sending end through a secure channel.

[0031] If the first actual prediction window K_used < 2, then fall back to the traditional SecOC mode (each message calculates the complete MAC independently); if the sender does not receive a response from the receiver within 100ms, it is considered a negotiation failure, and it also falls back to the traditional SecOC mode to ensure communication stability.

[0032] Step S102: If the receiving end verifies the current message verification information, it obtains the pre-calculated MAC cache based on the subsequent message verification information.

[0033] In this embodiment, after receiving the security PDU, the receiving end first parses it and extracts key fields: ① Extract the lower 3 bits of byte 0 to obtain K_recv (the number of preloaded MACs actually sent by the sending end). If K_recv is inconsistent with K_used (4), K_used shall prevail to avoid parameter mismatch leading to cache abnormality; ② Extract 2 bytes of simplified freshness TruncFV (little-endian), 4 bytes of simplified MAC TruncMAC (little-endian), and the subsequent PreloadPayload (64 bytes); ③ Obtain the current local trip count TripCnt_local (synchronized with the sending end trip count TripCnt) and local reset count ResetCnt_local (synchronized with the sending end reset count ResetCnt) from the local SecOC context of the receiving end.

[0034] In some embodiments of this example, if the receiving end verifies the current message verification information successfully, then obtaining the pre-calculated MAC cache based on the subsequent message verification information includes: Retrieve the valid portion of the current message's freshness and the sequence number of the previous message; If the sequence number of the previous message of the current message is the initial state where no valid message has been received, then the valid part of the freshness of the current message is used as the number of reconstructed messages. If the sequence number of the previous message of the current message is not the initial state where no valid message has been received, then the first difference between the valid part of the predicted freshness of the subsequent message and the valid part of the freshness of the current message is obtained. If the first difference is 0, the number of reconstructed messages is established based on the effective part of the freshness of the current message and the first difference. If the first difference is the first preset value, the number of reconstructed messages is established based on the effective part of the freshness of the current message, the first preset value and the first difference. If the first difference is the second preset value, the current message is discarded and no further verification is performed. After obtaining the number of reconstructed packets, obtain the local trip count TripCnt_local and the local reset count ResetCnt_local. Based on the local trip count TripCnt_local, the local reset count ResetCnt_local, and the number of reconstructed packets, establish the local complete freshness. Extract the first preset low digit of the local complete freshness as the local freshness of the current packet. Concatenate the packet identifier, the data segment to be authenticated, and the local freshness of the current packet to form the local complete MAC. Extract the second preset low digit of the local complete MAC as the local MAC of the current packet. If the local MAC is equal to the MAC corresponding to the current packet, the verification passes; if the local MAC is not equal to the MAC corresponding to the current packet, the verification fails. When the verification is successful, the verification information of subsequent messages is parsed, and the predicted MAC corresponding to the multiple consecutive subsequent messages after the current message is cached as the pre-calculated MAC cache.

[0035] In this embodiment, rcv_low (the effective part of simplified freshness) is extracted from the lower 10 bits of the simplified freshness TruncFV. Based on the current value of the previous message sequence number last_seq, the message count MsgCnt (denoted as the rebuilt message count MsgCnt_rebuilt) is reconstructed in different cases to ensure the sequence number is accurate: ① If the previous message sequence number last_seq = 0xFFFFFFFF (initial state, no valid message has been received), then rcv_low is directly used as the rebuilt message count MsgCnt_rebuilt (at this time, the message count Msg... ① If Cnt is small, the lower 10 bits are sufficient to represent it completely; ② If the sequence number of the previous message last_seq ≠ 0xFFFFFFFF, first calculate expected_low = (last_seq + 1) & 0x3FF (the lower 10 bits of the expected simplified freshness TruncFV for subsequent messages), then calculate the first difference diff = (rcv_low - expected_low) & 0x3FF (the first difference between the actual and expected values, retaining only the lower 10 bits); ③ If the first difference diff = 0, it means that the lower 10 bits of the simplified freshness TruncFV are different from the expected values. ④ If the first difference diff = 1, it means the number of packets MsgCnt is 1 more than expected, so the number of rebuilt packets MsgCnt_rebuilt = ((last_seq + 1) & 0xFFFFFC00) | rcv_low (retain the high 22 bits of the previous packet sequence number last_seq, and replace the low 10 bits with rcv_low); ⑤ If the first difference diff = 2 or 3, it means there is a slight packet delay, and an attempt is made. Offset = first difference diff, i.e. offset is 2 to 3. Construct candidate message count MsgCnt = ((last_seq + offset) & 0xFFFFFC00) | rcv_low. Select the candidate message count MsgCnt_rebuilt whose candidate value is greater than the previous message sequence number last_seq and whose lower 10 bits match rcv_low. ⑥ If the first difference diff > 3, it means that the message has serious synchronization loss. The message is directly discarded without further verification to avoid error propagation.

[0036] In this embodiment, the current packet MAC verification is as follows: ① Assemble local freshness: FV=((uint64_t)TripCnt_local<<48)|((uint64_t)ResetCnt_local<<32)|MsgCnt_rebuilt (consistent with the FV calculation logic of the sender); ② Calculate local MAC: Use the same AES-128-CMAC algorithm as the sender, with the input being "DataID||AuthenticPDU||FV", to calculate the local complete MAC (MAC_calc); ③ Compare and verify: Extract the lower 32 bytes of the local MAC MAC_calc. The local MAC address is compared with the received simplified MACTruncMAC. Result processing: If the local MAC address is not equal to the MAC address corresponding to the current packet, the verification fails, and the failure counter `fail_cnt` is automatically incremented by 1. If the failure counter `fail_cnt` is greater than or equal to the preset verification failure threshold `F_thresh` = 2 (reaching the failure threshold), the abnormal rollback mechanism is immediately triggered. If the local MAC address is equal to the MAC address corresponding to the current packet, the verification passes, the sequence number of the previous packet `last_seq` is updated to `MsgCnt_rebuilt` (recording the current valid packet sequence number), and the failure counter `fail_cnt` is reset to 0 (clearing failure records).

[0037] In this embodiment, the MAC cache is pre-calculated: After verification, the PreloadPayload is parsed, and the predicted MAC is split into K_recv = 4 16-byte bytes in sequence (corresponding to MAC_full(N+1) to MAC_full(N+4) of the subsequent 4 packets); for each i = 1 to 4, the expiration time of the MAC is calculated as expire_ms = current system time (unit: ms) + actual local cache validity period T_cache_local = 50ms (to ensure that the cached MAC is used within the valid time); the three sets of data "(number of rebuilt packets MsgCnt_rebuilt+i, MAC, expire_ms)" are stored as a cache entry in the prediction cache (hash table), with the key being the number of rebuilt packets MsgCnt_rebuilt+i (the sequence number of the subsequent packets), and the value being the corresponding MAC and expiration time, which facilitates quick querying later.

[0038] Step S103: For each subsequent message received from the sender, if the MAC verification of the subsequent message based on the pre-calculated MAC cache is successful, then the subsequent message verification is successful.

[0039] In some embodiments of this example, step S103 specifically includes: Extract the valid value of the MAC address corresponding to the subsequent message. If the valid value of the MAC address corresponding to the subsequent message is equal to the pre-calculated MAC cache, the subsequent message verification is successful. If the valid value of the MAC address corresponding to the subsequent message is not equal to the pre-calculated MAC cache, the subsequent message verification is unsuccessful. If the verification passes, the second difference between the valid value of the MAC address corresponding to the subsequent message and the sequence number of the previous valid message is obtained. If the second difference is within the valid range, the sequence number of the previous valid message is updated to the valid value of the MAC address corresponding to the subsequent message, and the valid value of the MAC address corresponding to the subsequent message is deleted. If the verification fails, the subsequent message is discarded.

[0040] In this embodiment, message sequence number reconstruction: After the receiving end receives the next security message, it reconstructs the sequence number and subsequent message number MsgCnt_M of the message according to the message number MsgCnt reconstruction logic in step S102, ensuring that the sequence number is accurate and providing a basis for cache query.

[0041] Cache query: Using the subsequent packet number MsgCnt_M as the key, query the pre-computed MAC cache to determine if a corresponding cache entry exists. At the same time, check if the expire_ms (expiration time) of the entry is greater than the current system time to ensure that the cache has not expired.

[0042] Quick verification process: ① If the cache hits and the cache is not expired, retrieve the pre-calculated MAC cache (MAC_pre), extract its lower 32 bits, and compare it with the simplified MACTruncMAC extracted from the current packet; ② If the comparison is equal, the packet verification is successful, and there is no need to perform the complete AES-128-CMAC calculation (skip the complete MAC calculation step), directly proceed to freshness continuity verification; ③ Freshness continuity check: Calculate gap = number of subsequent packets MsgCnt_M - sequence number of the previous packet last_seq (the first difference between the current packet sequence number and the sequence number of the previous valid packet), and determine whether gap is within the legal range 1≤gap≤G_max=5 (G_max is the maximum allowed sequence number interval to avoid packet loss). (Excessive loss leads to security risks); ④ Valid processing: If the gap is within the valid range, accept the message, update the sequence number of the previous message last_seq = the number of subsequent messages MsgCnt_M (record the current valid sequence number), delete the cache entry corresponding to the number of subsequent messages MsgCnt_M from the cache (to avoid reuse), and at the same time parse the PreloadPayload of the current message (the pre-calculated MAC of the next 4 messages), and store the new pre-calculated MAC into the prediction cache according to the caching rules in step S102 to maintain the validity of the cache; ⑤ Valid processing: If gap<1 (sequence number duplication) or gap>5 (sequence number interval is too large), discard the message, and at the same time, the failure counter fail_cnt is automatically incremented by 1 to record the verification failure.

[0043] In this embodiment, the rollback process is as follows: ① If the cache misses (there is no cache entry corresponding to the subsequent packet number MsgCnt_M), or the cache hits but the MAC comparison fails, it indicates that fast verification cannot be performed, and the process immediately rolls back to the complete MAC verification process (consistent with the current packet MAC verification logic in step S102); ② After complete verification, the failure counter fail_cnt is updated according to the result: if the verification is successful, the failure counter fail_cnt is reset to 0, the sequence number of the previous packet last_seq is updated to the number of subsequent packets MsgCnt_M, and the PreloadPayload is parsed and stored in the cache; if the verification fails, the failure counter fail_cnt is incremented by 1; ③ If the failure counter fail_cnt ≥ the preset verification failure threshold F_thresh = 2, the abnormal rollback mechanism is immediately triggered to ensure communication security.

[0044] In some implementations of this embodiment, the following are also included: Abnormal rollback triggering and execution: When the receiver's failure counter fail_cnt reaches 2 (the preset verification failure threshold F_thresh threshold), the following operations are immediately performed: ① Clear all entries in the prediction buffer to avoid invalid MACs in the buffer causing subsequent verification errors; ② Construct a rollback notification PDU, with byte 0 fixed at 0xC2 (identifying the rollback notification), and send it to the sender through the secure channel; ③ The receiver sets P_enable=0 to disable the prediction mode and rolls back to the traditional SecOC mode (each packet independently calculates the complete MAC).

[0045] Sender rollback processing: After receiving the receiver's rollback notification PDU, the sender immediately sets P_enable=0, disables prediction mode, stops attaching subsequent message verification information PreloadPayload to subsequent messages (no longer pre-calculates subsequent message MAC), and synchronously rolls back to the traditional SecOC mode to ensure that the verification modes of both parties are consistent and to avoid communication anomalies.

[0046] Resumption of negotiation process: ① After the receiving end rolls back, it immediately starts a recovery timer with an initial waiting time of 10,000 ms (10 seconds); ② After the timer expires, the receiving end resends the parameter negotiation request PDU (with the same negotiation request format as in step one) to try to re-enable the prediction mode; ③ If the negotiation fails again (the receiving end fails the verification or the sending end does not receive a response), the recovery waiting time is doubled to 60,000 ms (60 seconds), and a 60-second waiting time is maintained for each subsequent failure until the negotiation is successful.

[0047] The sending end dynamically adjusts the prediction window K_prop: To adapt to different HSM load scenarios, the sending end dynamically adjusts the prediction window K_prop based on the load situation every 100 packets of HSM load (real-time calculation of HSM computational utilization). The adjustment rules are as follows: ① If Load > 70% (HSM load is too high) and the current prediction window K_prop < 8 (maximum allowed window), then the prediction window K_prop += 2 (increase the window size and reduce the number of HSM calculations); ② If Load < 30% (HSM load is too low) and the current prediction window K_prop > 2, then the prediction window K_prop -= 1 (decrease the window size to avoid wasting cache resources); ③ After the new prediction window K_prop is determined, the sending end sends a notification through the extended field of the synchronization message. The byte 0 of the extended field is fixed at 0xD0 (indicating that the prediction window K_prop value has been updated), and subsequent bytes are filled with the new prediction window K_prop value. After receiving the notification, the receiving end updates its local first actual prediction window K_used to ensure that the prediction window K_prop values ​​of both parties are consistent, thus achieving adaptive load adjustment.

[0048] According to the second aspect of this application, such as Figure 2 As shown, a MAC pre-computation and incremental verification method, applied to the sending end, includes: Step S201: Generate current message verification information based on the current message, generate subsequent message verification information based on one or more consecutive subsequent messages following the current message, and send the current message containing the current message verification information and the subsequent message verification information to the receiving end; Step S202: Send one or more subsequent messages to the receiving end in sequence.

[0049] In some embodiments of this example, the method for obtaining the current message verification information and the subsequent message verification information includes: The sending end establishes a trip counter to obtain the trip count, resets the counter to obtain the reset count, and establishes a message counter to obtain the message count. For the current message, the number of trips, the number of resets, and the number of messages in the current message are concatenated to form the complete freshness. The first preset low number of digits of the complete freshness is extracted to form the simplified freshness. The simplified freshness is the freshness of the current message. The message identifier, the data segment to be authenticated, and the freshness of the current message are concatenated to form the complete MAC. The second preset low number of digits of the complete MAC is extracted to form the simplified MAC. The simplified MAC is the MAC corresponding to the current message. For multiple consecutive subsequent messages following the current message, the number of trips, the number of resets, and the number of messages in the subsequent messages are concatenated to form the predicted freshness of the subsequent messages, and the message identifier, the data segment to be authenticated, and the predicted freshness of the subsequent messages are concatenated to form the predicted MAC of the subsequent messages. Verification information for the current message is generated based on its freshness and the MAC address corresponding to the current message. Verification information for subsequent messages is generated based on the predicted MAC address of subsequent messages.

[0050] Specifically, the sending end continuously maintains three core counters to generate message freshness, with the following specifications: ① 16-bit TripCnt (trip counter): Initial value is 1, automatically incremented by 1 after each re-authentication between the sending and receiving ends, and automatically wraps back to 1 when the value reaches 65535 (maximum value of a 16-bit unsigned integer); ② 16-bit ResetCnt (reset counter): Initial value is 0, automatically incremented by 1 after every 10 successful security messages are sent, and automatically wraps back to 0 when the value reaches 65535; ③ 32-bit Message Count MsgCnt (message counter): Initial value is 0, automatically incremented by 1 after each security message is sent, and automatically wraps back to 0 when the value reaches 4294967295 (maximum value of a 32-bit unsigned integer).

[0051] In some embodiments of this example, the method for obtaining the freshness of the current message is as follows: The complete freshness is obtained by concatenating the number of trips, resets, and messages of the current message. The first preset low digit of the complete freshness is extracted as the simplified freshness, which is the freshness of the current message.

[0052] In this embodiment, since the trip counter is a 16-bit TripCnt, the reset counter is a 16-bit ResetCnt, and the message counter is a 32-bit message count MsgCnt, the trip count is shifted left by 48 bits, the reset count is shifted left by 32 bits, and then the left-shifted trip count, the left-shifted reset count, and the message count are concatenated to form the complete freshness.

[0053] For the current message (sequence number N, i.e., the real-time value of the current message number MsgCnt), calculate the complete freshness FV(N) using the following formula: FV(N) = ((uint64_t)TripCnt<<48)|((uint64_t)ResetCnt<<32)|Message number MsgCnt, which is to left-shift the trip number TripCnt by 48 bits, left-shift the reset number ResetCnt by 32 bits, and concatenate it with the message number MsgCnt to form a 64-bit unsigned integer; Then, the lower 10 bits of the complete freshness FV(N) are extracted as the simplified freshness TruncFV, and the calculation formula is TruncFV=FV(N)&0x3FF (0x3FF corresponds to 10 bits of all 1s in binary, ensuring that only the lower 10 bits of valid data are retained).

[0054] In some embodiments of this example, the method for obtaining the MAC address corresponding to the current packet is as follows: The message identifier, the data segment to be authenticated, and the freshness of the current message are concatenated to form a complete MAC. The second preset low-order bits of the complete MAC are extracted to form a simplified MAC, which is the MAC corresponding to the current message.

[0055] In this embodiment, the MAC corresponding to the current packet is calculated using the AES-128-CMAC algorithm. The input is “DataID||AuthenticPDU(N)||Freshness of Completeness (FV(N))”, where N is the sequence number of the current packet, DataID is a 2-byte packet identifier (used to distinguish different types of security packets), and AuthenticPDU(N) is the data segment to be authenticated in the current packet. The 128-bit complete MAC is calculated and denoted as MAC_full(N). Then, the lower 32 bits of MAC_full(N) are truncated as the MAC corresponding to the current packet (simplified MAC), and the calculation formula is TruncMAC=(uint32_t)MAC_full(N), which is used to reduce packet transmission overhead.

[0056] In some embodiments of this example, the method for obtaining the predicted freshness of subsequent messages is as follows: For multiple consecutive subsequent messages following the current message, the number of trips, resets, and messages of each subsequent message are concatenated to form the predicted freshness of the subsequent message.

[0057] In some embodiments of this example, the method for obtaining the predicted MAC of subsequent messages is as follows: The message identifier, the data segment to be authenticated, and the predicted freshness of the subsequent message are concatenated to form the predicted MAC of the subsequent message.

[0058] In this embodiment, for the subsequent K=4 messages (sequence numbers N+1 to N+4), a pre-calculation operation is performed sequentially to obtain the predicted freshness of the subsequent messages. The calculation formula is as follows: FV(N+i)=((uint64_t)TripCnt<<48)|((uint64_t)ResetCnt<<32)|(Number of packets MsgCnt+i) (i=1 to 4), that is, keep TripCnt and ResetCnt unchanged, and only increment the number of packets MsgCnt by 1 in turn; Data to be authenticated: Prefetch AuthenticPDU(N+i) from the message sending queue of the sender (applicable to batch request sequences, ensuring that the pre-calculated data is consistent with the actual sent data).

[0059] In this embodiment, the same AES-128-CMAC algorithm as the current message is used. The predicted MAC of subsequent messages is input as “DataID||AuthenticPDU(N+i)||FV(N+i)”, and the 128-bit predicted MAC (MAC_full(N+i)) pre-calculated for each subsequent message is obtained; ④ Concatenate the predicted MAC: Concatenate K=4 complete MACs of 16 bytes (MAC_full(N+1) to MAC_full(N+4)) in sequence to form the verification information PreloadPayload of the subsequent message (total length is 4×16=64 bytes), which is used as an additional field of the current message.

[0060] In some implementations of this embodiment, current message verification information is generated based on the freshness of the current message and the MAC corresponding to the current message, and subsequent message verification information is generated based on the predicted MAC of subsequent messages. The current message verification information and subsequent message verification information are encapsulated into a secure PDU: the secure PDU is encapsulated in the following format to ensure that the receiving end can correctly parse it: Byte 0 = 0x80 | (K & 0x07) (0x80 indicates that the preloading function is enabled, the lower 3 bits store the K value, K=4 corresponds to 0x04, so byte 0 is 0x84); bytes 1-2 are 2-byte DataID (consistent with the DataID when calculating MAC); bytes 3 and the following bytes are AuthenticPDU(N) in Len_auth bytes (Len_auth is the length of AuthenticPDU(N), determined by the message type); followed by 2-byte little-endian simplified freshness TruncFV (only the lower 10 bits are valid, the higher 6 bits are filled with 0); then 4-byte little-endian simplified MAC TruncMAC; finally, PreloadPayload (64 bytes) is appended. After encapsulation, the PDU is sent through a secure channel. Upon successful transmission, the message count MsgCnt is automatically incremented by 1 and updated to the sequence number of subsequent messages.

[0061] According to the third aspect of this application, such as Figure 3 As shown, this embodiment provides a MAC pre-computation and incremental verification receiver, including: The receiving module is used to receive the current message sent by the sending end, wherein the current message embeds current message verification information and subsequent message verification information; The first verification module is used to obtain the pre-calculated MAC cache based on the verification information of subsequent messages if the verification of the current message information passes. The second verification module is used to verify each subsequent message received from the sender. If the MAC verification of the subsequent message based on the pre-calculated MAC cache is successful, then the subsequent message is verified.

[0062] According to the fourth aspect of this application, such as Figure 4 As shown, this embodiment provides a MAC pre-calculation and incremental verification transmitter, including: The first sending module is used to generate current message verification information based on the current message, generate subsequent message verification information based on one or more consecutive subsequent messages after the current message, and send the current message containing the current message verification information and the subsequent message verification information to the receiving end. The second sending module is used to send one or more subsequent messages to the receiving end in sequence.

[0063] According to the fifth aspect of this application, such as Figure 5 As shown, this embodiment provides a MAC pre-computation and incremental verification system, including: The sending end is used to generate current message verification information based on the current message, generate subsequent message verification information based on one or more consecutive subsequent messages following the current message, send the current message containing the current message verification information and the subsequent message verification information to the receiving end, and send the one or more subsequent messages to the receiving end in sequence. The receiving end is used to receive the current message sent by the sending end. The current message embeds current message verification information and subsequent message verification information. If the current message verification information is verified successfully, the pre-computed MAC cache is obtained based on the subsequent message verification information. For each subsequent message sent by the sending end, if the MAC verification extracted from the subsequent message based on the pre-computed MAC cache is successful, the subsequent message is verified successfully.

[0064] Specifically, this embodiment corresponds one-to-one with the above method embodiments. The functions of each module have been described in detail in the corresponding method embodiments, so they will not be repeated here.

[0065] According to a fifth aspect of this application, this embodiment provides a computer-readable storage medium having a computer program stored thereon, the computer program including executable instructions that, when executed by a processor, implement the method described above.

[0066] The present invention can implement all or part of the processes in the above methods, or it can be accomplished by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when the computer program is executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium can include: any entity or system capable of carrying computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0067] According to a sixth aspect of this application, an electronic device is provided, comprising: One or more processors; Memory is used to store executable instructions for the processor, which, when executed by one or more processors, cause one or more processors to implement the methods described above.

[0068] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and a bus connecting different system components (including memory and processor).

[0069] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of a computer system, connecting all parts of the computer system through various interfaces and lines.

[0070] Memory can be used to store computer programs and / or modules. The processor implements various functions of the computer system by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system and at least one application program required for a function (e.g., sound playback, image playback, etc.); the data storage area can store data created based on the use of the mobile phone (e.g., audio data, video data, etc.). Furthermore, memory can include high-speed random access memory, and can also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, SmartMedia Cards (SMC), Secure Digital (SD) cards, Flash Cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0071] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, servers, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and memory) containing computer-usable program code.

[0072] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), servers, and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A system that specifies functions in one or more boxes.

[0073] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including an instruction set implemented in a process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0074] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0075] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0076] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0077] 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 the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A MAC pre-computation and incremental verification method, applied at the receiving end, characterized in that, include: Receive the current message sent by the sending end, wherein the current message embeds current message verification information and subsequent message verification information; If the verification information of the current message passes, the pre-calculated MAC cache is obtained based on the verification information of subsequent messages; If the MAC address extracted from the subsequent message received from the sender is verified based on the pre-calculated MAC cache, then the subsequent message is verified.

2. The method according to claim 1, characterized in that, Before receiving the current message sent by the sending end, the process also includes: The receiver receives the local configuration parameters of the sender and verifies the resource status information of the receiver based on the local configuration parameters of the sender. If the verification passes, a prediction mode information is generated based on the local configuration parameters of the sending end. The prediction mode information is the information that enables the sending end to embed the current message verification information and the subsequent message verification information into the current message.

3. The method according to claim 2, characterized in that, The local configuration parameters at the sending end include a preset prediction window, a MAC cache expiration period, and a preset verification failure threshold. The verification of receiver resource status information based on these local configuration parameters includes: Accept negotiation request PDU, which is constructed by the sending end based on the preset prediction window, MAC cache validity period and preset verification failure threshold; Based on the negotiation request PDU, the receiver resource status information is verified. The receiver resource status information includes the available HSM cache capacity and the current HSM load. If the available HSM cache capacity is greater than the product of the preset prediction window and the MAC length, and the current HSM load is greater than the preset HSM load threshold, then the verification is successful.

4. The method according to claim 1, characterized in that, The step of obtaining the pre-calculated MAC cache based on subsequent message verification information includes: Retrieve the valid portion of the current message's freshness and the sequence number of the previous message; If the sequence number of the previous message of the current message is the initial state where no valid message has been received, then the valid part of the freshness of the current message is used as the number of reconstructed messages. If the sequence number of the previous message of the current message is not the initial state where no valid message has been received, then the first difference between the valid part of the expected freshness of the subsequent message and the valid part of the freshness of the current message is obtained. If the first difference is 0, the number of reconstructed messages is established based on the effective part of the freshness of the current message and the first difference. If the first difference is the first preset value, the number of reconstructed messages is established based on the effective part of the freshness of the current message, the first preset value and the first difference. If the first difference is the second preset value, the current message is discarded and no further verification is performed. After obtaining the number of reconstructed messages, obtain the number of local trips and the number of local resets. Establish the local complete freshness based on the number of local trips, the number of local resets, and the number of reconstructed messages. Extract the first preset low digit of the local complete freshness as the local freshness of the current message. Concatenate the message identifier, the data segment to be authenticated, and the local freshness of the current message to form the local complete MAC. Extract the second preset low digit of the local complete MAC as the local MAC of the current message. If the local MAC is equal to the MAC corresponding to the current message, the verification is successful. When the verification is successful, the verification information of subsequent messages is parsed, and the predicted MAC corresponding to the multiple consecutive subsequent messages after the current message is cached as the pre-calculated MAC cache.

5. The method according to claim 1, characterized in that, If the MAC verification of the subsequent message received from the sender is successful based on the pre-calculated MAC cache, then the subsequent message verification is successful, including: Extract the valid value of the MAC address corresponding to the subsequent message, compare the valid value of the MAC address corresponding to the subsequent message with the pre-calculated MAC cache, and if they are equal, the subsequent message verification is successful. If the verification passes, the second difference between the valid value of the MAC address corresponding to the subsequent message and the sequence number of the previous valid message is obtained. If the second difference is within the valid range, the sequence number of the previous valid message is updated to the valid value of the MAC address corresponding to the subsequent message, and the valid value of the MAC address corresponding to the subsequent message is deleted.

6. A MAC pre-calculation and incremental verification method, applied at the sending end, characterized in that, include: Generate current message verification information based on the current message, generate subsequent message verification information based on one or more consecutive subsequent messages following the current message, and send the current message containing the current message verification information and subsequent message verification information to the receiving end. The one or more subsequent messages are sent to the receiving end in sequence.

7. The method according to claim 7, characterized in that, The step of generating current message verification information based on the current message, and generating subsequent message verification information based on one or more consecutive subsequent messages following the current message, includes: Establish a trip counter to obtain the trip count, reset the counter to obtain the reset count, and establish a message counter to obtain the message count. For the current message, the number of trips, the number of resets, and the number of messages in the current message are concatenated to form the complete freshness. The first preset low number of digits of the complete freshness is extracted to form the simplified freshness. The simplified freshness is the freshness of the current message. The message identifier, the data segment to be authenticated, and the freshness of the current message are concatenated to form the complete MAC. The second preset low number of digits of the complete MAC is extracted to form the simplified MAC. The simplified MAC is the MAC corresponding to the current message. For one or more consecutive subsequent messages following the current message, the number of trips, the number of resets, and the number of messages in the subsequent messages are concatenated to form the predicted freshness of the subsequent messages, and the message identifier, the data segment to be authenticated, and the predicted freshness of the subsequent messages are concatenated to form the predicted MAC of the subsequent messages. The current message verification information is generated based on the freshness of the current message and the MAC corresponding to the current message, and the subsequent message verification information is generated based on the predicted MAC of the subsequent messages. The current message is embedded with the current message verification information and the subsequent message verification information before being sent to the receiving end.

8. A MAC pre-computation and incremental verification receiver, characterized in that, include: The receiving module is used to receive the current message sent by the sending end, wherein the current message embeds current message verification information and subsequent message verification information; The first verification module is used to obtain the pre-calculated MAC cache based on the verification information of subsequent messages if the verification of the current message information passes. The second verification module is used to verify each subsequent message received from the sender. If the MAC verification of the subsequent message based on the pre-calculated MAC cache is successful, then the subsequent message is verified.

9. A MAC pre-computation and incremental verification transmitter, characterized in that, include: The first sending module is used to generate current message verification information based on the current message, generate subsequent message verification information based on one or more consecutive subsequent messages after the current message, and send the current message containing the current message verification information and the subsequent message verification information to the receiving end. The second sending module is used to send one or more subsequent messages to the receiving end in sequence.

10. A MAC pre-computation and incremental verification system, characterized in that, include: The sending end is used to generate current message verification information based on the current message, generate subsequent message verification information based on one or more consecutive subsequent messages following the current message, send the current message containing the current message verification information and the subsequent message verification information to the receiving end, and send the one or more subsequent messages to the receiving end in sequence. The receiving end is used to receive the current message sent by the sending end, wherein the current message embeds current message verification information and subsequent message verification information; If the verification information of the current message passes, the pre-calculated MAC cache is obtained based on the verification information of subsequent messages; If the MAC address extracted from the subsequent message received from the sender is verified based on the pre-calculated MAC cache, then the subsequent message is verified.

Images