Trust anchor rotation method and system for vehicle-mounted SOA service communication

Abstract

The application discloses a kind of trust anchor rotation method and system of vehicle-mounted SOA service communication.The service publisher registers to obtain trust anchor, and carries the key version number that is increased with each rotation of trust anchor in the announcement message in service discovery stage.The service subscriber rejects the announcement message when the key version number is not higher than local key version number;update local key version number when it is higher than local key version number and the difference between them does not exceed version difference threshold;reject the announcement message and report to trust anchor management center when it is higher than local key version number and the difference between them exceeds threshold, then reset local key version number and re-register according to the key version number benchmark issued by trust anchor management center after being unbound;then verify the signature carried in service communication message with the public key corresponding to local key version number.The application makes key version be subjected to the dual constraints of monotonicity and span, and realizes message-level dynamic identity authentication.

Description

Technical Field

[0001] This invention relates to the field of vehicle communication security technology, specifically to a method and system for rotating trust anchors in vehicle SOA service communication. In this invention, SOA refers to Service Oriented Architecture (SOA), and the term "service-oriented architecture" in the following text refers to the same thing as SOA. Background Technology

[0002] With the development of software-defined vehicles, the in-vehicle electronic and electrical architecture is evolving towards a service-oriented architecture. Service-oriented communication protocols have become the main protocols for service communication between electronic control units within the vehicle. These protocols typically do not contain native security mechanisms; their security capabilities are provided by the transport layer, i.e., implemented by network layer security protocols or transport layer security protocols.

[0003] Network layer security protocols are application-independent protocols, and their authentication and encryption are implemented on a per-network layer data packet basis. Transport layer security protocols involve multiple interactions in their handshake process and establish sessions for point-to-point connections. In multicast scenarios where in-vehicle control flows are widely used, sessions need to be established separately for each receiver.

[0004] During the service discovery phase, existing solutions employ Domain Name System Security Extensions (DNS) and Named Entity-based authentication combined with a challenge-and-response approach to authenticate the service discovery process. Service subscribers are verified through a challenge-and-response process, while service publishers undergo one-time authentication using a long-term certificate. This long-term certificate remains unchanged throughout its validity period; however, if leaked, attackers can use it to impersonate the service and broadcast announcements.

[0005] Regarding message authentication, existing frameworks provide data integrity authentication for service communication messages. They calculate a message authentication code for each message using the same key, which remains consistent across all messages throughout its lifecycle. If this key is leaked, an attacker can calculate a verifiable message authentication code for any message.

[0006] Regarding key updates, the announcement message carries key version information in plaintext fields. When an attacker replays an announcement message carrying an old version key, the service subscriber reverts to the previous old key based on the announcement message. When an attacker pushes a version number that is much higher than the actual value, the key version number of the real service no longer matches the local record of the service subscriber, and the service subscriber continues to reject the announcement messages of the real service, thus the service cannot be subscribed to.

[0007] Regarding service restart, after the service publisher restarts, its message counter is reset to zero, while the service subscriber retains the random number record and message counter record from before the restart. Legitimate messages sent after the restart are judged as replay messages and rejected because their message counter value is not greater than the service subscriber's record and their random number is in the service subscriber's cache.

[0008] Regarding security policy configuration, existing solutions configure a fixed security level for each service based on its security level, and this security level and its key update cycle remain unchanged during operation.

[0009] In the prior art, patent document CN107846395B discloses a method and system for ensuring the security of vehicle bus communication, which uses a counter to resist replay and provides a session key update process; patent document CN118802139A discloses a distributed key update and recovery mechanism, which integrates time-triggered and event-driven update strategies and can be linked with an intrusion detection system to trigger updates. Both of these patent documents address bus signal-based communication and its general key management process.

[0010] In summary, in vehicular service-oriented communication, the long-term certificate and message authentication key of the service publisher remain unchanged throughout their lifecycle. The key version information in the announcement message can be replayed or forged into an excessively large value. After the service restarts, the value of its message counter no longer matches the local record of the service subscriber. The security configuration of the service remains fixed during operation. Summary of the Invention

[0011] In view of this, the present invention provides a method and system for rotating trust anchors in vehicle-mounted SOA service communication, in order to solve the technical problems in existing vehicle-mounted SOA service communication, such as the service publisher's service being impersonated after long-term certificate leakage, the full message being forged after the message authentication key is static, the key version number in the announcement message being replayed and rolled back or forged into an excessively large value, making it impossible for the real service to be subscribed, the legitimate message being judged as a replay message after the service restarts, and the service's security configuration remaining unchanged during operation.

[0012] The first aspect of this invention proposes a method for rotating trust anchors in in-vehicle SOA service communication for service subscribers, comprising: Service subscribers register with the trust anchor management center and establish a binding relationship with the service publisher. They receive announcement messages broadcast by the service publisher during the service discovery phase. These announcement messages carry a key version number, which comes from the trust anchor obtained by the service publisher through registration with the trust anchor management center and increments with each rotation of the trust anchor. Service subscribers learn the current key status of the service as soon as they discover the service, providing a basis for subsequent key version verification and signature verification.

[0013] When the key version number carried in the notification message is not higher than the local key version number, the notification message is rejected; when the key version number carried in the notification message is higher than the local key version number and the difference between the two does not exceed the version difference threshold, the local key version number is updated with the key version number carried in the notification message, and the public key corresponding to the updated local key version number is obtained; when the key version number carried in the notification message is higher than the local key version number and the difference between the two exceeds the version difference threshold, the notification message is rejected and reported to the trust anchor management center; this verification uses monotonicity and leap range as two conditions to constrain the evolution of the local key version number. Replayed old version notification messages and notification messages carrying excessively large version numbers are both rejected. The local key version number neither reverts to the leaked old value nor jumps to a value that the real service cannot reach.

[0014] Following the report, the service subscriber receives the key version number baseline issued by the Trust Anchor Management Center after unbinding the service subscriber from the service publisher, resets the local key version number to the key version number baseline, and re-registers with the Trust Anchor Management Center; the corrupted local version state is thus cleared, and the service subscriber and the real service return to the same version baseline.

[0015] The service subscriber receives a service communication message sent by the service publisher. The service communication message carries a signature, and the signature is verified using the public key corresponding to the local key version number. The verification result of the key version number directly affects the signature verification process. The service subscriber always completes message-level authentication with the public key of the currently valid version.

[0016] Furthermore, the service communication message also carries a session round identifier, a random number, and a message counter. The session round identifier increments each time the service publisher registers with the trust anchor management center, and the message counter increments within the same session round identifier. The service subscriber locally maintains a random number cache, a local message counter, and a local session round identifier. Before verifying the signature, if the session round identifier carried in the service communication message is higher than the local session round identifier, it is determined that the service publisher has restarted, the random number cache and the local message counter are cleared, and the session round identifier carried in the service communication message is used as the basis for verification. The local session round identifier is updated using the next identifier. When the session round identifier carried by the service communication message is equal to the local session round identifier, it is verified that the random number carried by the service communication message does not appear in the random number cache, and the message counter carried by the service communication message is greater than the local message counter. When the session round identifier carried by the service communication message is lower than the local session round identifier, the service communication message is rejected. After the signature verification is passed, the random number carried by the service communication message is recorded in the random number cache, and the local message counter is updated with the message counter carried by the service communication message. The random number and message counter left over before the restart no longer participate in the judgment after the restart, and the misjudgment caused by the message counter returning to zero after the service restart but the cache still containing the old random number is avoided. The random number cache and the local message counter are updated synchronously after each successful verification, and the judgment criteria for preventing replay and out-of-order delivery remain valid throughout the entire service lifecycle.

[0017] Furthermore, the trust anchor also includes an expiration period, the service communication message also carries a timestamp, and the signature input includes a service identifier, instance identifier, session round identifier, timestamp, random number, message counter, and payload hash. The payload hash is obtained by hashing the payload of the service communication message. Before verifying the signature, it is also verified that the difference between the timestamp and the current time is within the timestamp tolerance threshold, and that the current time is within the expiration period of the trust anchor. The combination of multiple dynamic factors makes the signature of each message unique. The time freshness and credential validity checks reject late messages and messages using expired credentials before the signature calculation, reducing the overhead of invalid signature calculations.

[0018] Furthermore, the random number cache includes a sliding window and a Bloom filter. The sliding window retains random numbers within a time window and discards timed-out random numbers, while the Bloom filter records the existence status of random numbers. Adding a random number to the random number cache includes simultaneously adding the random number to both the sliding window and the Bloom filter. The sliding window limits replay identification to a finite time range, and the Bloom filter completes the existence determination with fixed memory, thus achieving a balance between query efficiency and storage overhead.

[0019] Furthermore, a key update request carrying the local key version number and service identifier is sent to the trust anchor management center. The center verifies the request and returns the public key corresponding to the new trust anchor, whose version number is higher than the local key version number. The locally stored public key is then updated with this new public key, and the local key version number is updated with the key version number of the new trust anchor. The service subscriber's proactive retrieval and the trust anchor management center's on-demand distribution work together to complete the key version evolution without interrupting service communication.

[0020] Furthermore, the service is divided into multiple trust domains based on functional security levels. Each trust domain corresponds to a trust anchor rotation frequency and a signature algorithm. Trust domains with higher functional security levels have trust anchor rotation frequencies and signature algorithm security strengths that are no lower than those of trust domains with lower functional security levels. Service subscribers verify the signature using the signature algorithm corresponding to the trust domain to which the service publisher belongs. After the core domain controller detects an attack against the service publisher and upgrades the level of the service publisher's trust domain, it receives an announcement message broadcast by the service publisher due to the trust anchor rotation triggered by the upgrade, carrying a higher key version number, and then verifies the signature using the signature algorithm corresponding to the upgraded trust domain. After the attack is eliminated, the signature verification reverts to using the signature algorithm corresponding to the original trust domain to which the service publisher belongs. Security resources are thus allocated according to the service's functional security level, and the protection strength is adjusted according to changes in the threat landscape.

[0021] A second aspect of this invention proposes a method for rotating trust anchors in in-vehicle SOA service communication applied to service publishers, comprising: Register with the Trust Anchor Management Center to obtain a Trust Anchor, which includes a service identifier, signing key, key version number, and validity period; the service obtains initial trusted credentials for external communication and provides a data source for key version announcements during the service discovery phase.

[0022] The key version number is carried in the announcement message broadcast during the service discovery phase. The key version number increments with each rotation of the trust anchor, so that service subscribers reject the announcement message when the key version number is not higher than their local key version number, update their local key version number when the key version number is higher than their local key version number and the difference between the two does not exceed the version difference threshold, and reject the announcement message and report to the trust anchor management center when the key version number is higher than their local key version number and the difference between the two exceeds the version difference threshold. The key version number is propagated to each service subscriber during the service discovery process, thereby ensuring the monotonicity check and version difference threshold check on the subscription side.

[0023] After the Trust Anchor Management Center responds to the report and unbinds the service subscriber, the service subscriber re-registers with the Trust Anchor Management Center to bring the local key version number of the service subscriber back to a consistent benchmark with the key version number of the service publisher; the real service thus resumes communication with the service subscriber on a consistent benchmark after the exception handling.

[0024] A signature is generated for the service communication message using the signature key, the signature is appended to the service communication message and sent to the service subscriber; each service communication message can thus be verified one by one on the subscriber side.

[0025] Furthermore, each time the service publisher registers with the trust anchor management center, it obtains an incrementing session round identifier. The signature input includes a service identifier, instance identifier, session round identifier, timestamp, random number, message counter, and payload hash. The random number is generated separately by the service publisher for each service communication message. The message counter increments within the same session round identifier, so that when the session round identifier is higher than its local session round identifier, the service subscriber determines that the service publisher has restarted and clears its random number cache and local message counter. The restart event on the publisher side can thus be unambiguously identified by the subscriber side, and the subscriber's local cache is correctly reset accordingly.

[0026] Furthermore, after the trusted anchor is leaked or the service publisher becomes abnormal, a new trusted anchor with a key version number higher than the current key version number is obtained, and an announcement message carrying the new key version number is rebroadcast after recovery. The key version number of the new trusted anchor is higher than the current value, which just satisfies the monotonicity check on the subscription side, and any potentially leaked old credentials become invalid.

[0027] Thirdly, this invention also proposes a trust anchor rotation system for in-vehicle SOA service communication, including a trust anchor management module, a service publishing module, and a service subscription module. The trust anchor management module issues trust anchors containing a service identifier, a signing key, a key version number that increments with each rotation, and a validity period to registered service publishing modules. Upon receiving a report from a service subscription module, the module unbinds the service subscription module and issues a key version number base consistent with the service publishing module to the service subscription module. The service publishing module carries the key version number in the announcement message broadcast during the service discovery phase and generates a signature for the service communication message using the signing key. The service subscription module processes the announcement message according to the aforementioned monotonicity and version difference threshold rules and stores the public key corresponding to the local key version number. It then resets the local key version number to the key version number base and verifies the signature using the public key corresponding to the local key version number. The above method flow is thus solidified at the device level, forming a deployable and executable in-vehicle service communication security architecture.

[0028] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention increments the key version number as the trust anchor rotates and spreads during the service discovery process. Service subscribers apply both monotonicity and version difference threshold checks to the key version number in the announcement message, and verify the signature of the service communication message with the public key corresponding to the verified local key version number. This ensures that the local key version number does not regress to the leaked old value due to replaying old version announcement messages, nor does it jump to a value that the real service cannot reach due to announcement messages carrying excessively large version numbers. The evolution of the key version is constrained in the service discovery phase, and service discovery and message verification are connected by the same key version number.

[0029] 2. In this invention, when the difference between key version numbers exceeds the version difference threshold, the service subscriber reports to the trust anchor management center. After unbinding, the trust anchor management center issues a key version number benchmark. The service subscriber then resets its local key version number and re-registers. The corrupted local version state is cleared, and the real service and the service subscriber are restored to the same version benchmark. The real service will not be continuously unable to be subscribed due to abnormal local version state.

[0030] 3. This invention distinguishes sessions before and after a service restart by using session round identifiers. When the session round identifier increases, the service subscriber clears the random number cache and the local message counter. After each signature verification is successful, the random number of the message is recorded in the cache and the local record is updated with the message counter of the message. This avoids misjudgments caused by the message counter returning to zero after a service restart but the cache still containing the old random number. The judgment criteria for preventing replay and out-of-order delivery remain effective throughout the entire service lifecycle.

[0031] 4. This invention divides services into multiple trust domains according to functional safety levels and configures different trust anchor rotation frequencies and signature algorithms for each trust domain. When an attack against a service is detected, the level of the trust domain to which the service belongs is increased and trust anchor rotation is triggered. After the attack is eliminated, the original level is restored, so that the security overhead and protection strength change with the functional safety level of the service and the real-time threat situation. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 This is an overall architecture diagram of the trust anchor rotation system for vehicle SOA service communication according to an embodiment of the present invention; Figure 2 This is a schematic diagram illustrating the dynamic rotation of trust anchors and the prevention of key version number rollback in an embodiment of the present invention. Figure 3 This is a schematic diagram illustrating the process of generating and verifying service communication message-level signatures in an embodiment of the present invention. Figure 4 This is a schematic diagram illustrating the linkage between the hierarchical trust domain and the in-vehicle intrusion detection system according to an embodiment of the present invention; Figure 5 This is a structural block diagram of the trust anchor rotation system for vehicle-mounted SOA service communication according to an embodiment of the present invention. Detailed Implementation

[0034] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of the invention. However, those skilled in the art will understand that the invention can be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of the invention with unnecessary detail.

[0035] The trust anchor rotation method and system for in-vehicle SOA service communication provided in this invention are particularly suitable for security protection scenarios of in-vehicle diagnostic and control service communication in service-oriented architecture, and can be extended to related fields with security requirements for service discovery and message-level authentication in in-vehicle electronic and electrical architectures that adopt service-oriented communication protocols.

[0036] In a service-oriented architecture for vehicles, service publishers and subscribers communicate via service discovery to announce and subscribe to services, and exchange diagnostic or control data through service communication messages. To achieve message-level dynamic authentication without altering the existing service-oriented communication protocol structure, this invention introduces dynamic rotation of trust anchors during the service discovery phase and generates a one-time signature for each service communication message. Furthermore, it uses monotonicity verification of the key version number and version difference threshold verification to defend against rollback and version inflation attacks, and uses session round identifiers to resolve replay misjudgments caused by service restarts.

[0037] The technical solution provided by the present invention will be described in detail below with reference to specific embodiments. Embodiment 1 describes the method from the perspective of the service subscriber, Embodiment 2 describes the method from the perspective of the service publisher, and Embodiment 3 describes a system corresponding to the above method.

[0038] Example 1 This embodiment provides a method for rotating trust anchors in in-vehicle SOA service communication applied to service subscribers, such as... Figure 1 and Figure 2 As shown.

[0039] In applications, a service publisher refers to a software entity in a service-oriented architecture (FOA) that provides diagnostic or control services to the outside world. A service subscriber refers to a software entity within the vehicle that needs to call a specific service. The trust anchor management center refers to a security entity deployed within the vehicle responsible for issuing and managing trust credentials. Registration refers to the process by which a service publisher or service subscriber registers its identity with the trust anchor management center and obtains corresponding trust credentials before providing or calling a service: After registration, the service publisher obtains an initial trust anchor; after registration, the trust anchor management center establishes a binding relationship between the service subscriber and the corresponding service publisher, and issues the public key corresponding to the current key version number of the service publisher and the validity period of the trust anchor. During the binding period, the service subscriber accepts and verifies messages from the service publisher. The initial trust anchor contains a service identifier, used to uniquely identify a service; a signing key, used to digitally sign service communication messages; a key version number, an integer that increments with each rotation to indicate the key's age; and a validity period, used to limit the time range within which the set of credentials is valid.

[0040] In the application, the session round identifier is issued by the trust anchor management center during service publisher registration. The initial value is 1 for the first registration, and it increments by 1 with each subsequent re-registration, used to distinguish sessions before and after service restarts. In this embodiment, after the service publisher starts, it first completes registration, simultaneously obtaining a trust anchor with an initial key version number and a session round identifier with a value of 1. Thereafter, it communicates externally using the signing key within that anchor.

[0041] In the application, an announcement message refers to a message broadcast by a service publisher to the vehicle during the service discovery phase to announce that it is available for subscription. The service publisher writes the current key version number each time it broadcasts an announcement message, so that the key version number naturally spreads to each service subscriber during the service discovery process.

[0042] In the application, service subscribers maintain a set of records locally for each known service, including the most recently accepted key version number of the service, the corresponding public key and expiration date, the most recent session round identifier and message counter, and a cache for recording recent random numbers for the service. These are referred to as the local key version number, locally stored public key, local session round identifier, local message counter, and random number cache, respectively. Monotonicity verification refers to the service subscriber comparing the key version number in the notification message with its local key version number upon receiving the notification message. Only if the key version number in the notification message is higher than the local key version number will the service subscriber update its local key version number, accept the key, and retrieve and store the corresponding public key and expiration date from the trust anchor management center. If the key version number in the notification message is equal to or lower than the local key version number, the service subscriber rejects the notification message, thereby preventing attackers from replaying older versions of the notification message.

[0043] In application, this invention refers to an attack in which an attacker pushes a notification message with a key version number far exceeding the actual value, causing the real service to be unacceptable to service subscribers due to the key version number being unreachable. The version difference threshold is a pre-set positive integer used to limit the range by which the key version number can lag at one time. Its value is determined by the maximum number of consecutive notification messages a service subscriber might miss during normal operation, i.e., the maximum number of versions the local key version number is allowed to lag behind the real service. A value that is too large will allow the version inflation attack to pass verification, while a value that is too small will misjudge normal missed notifications as an attack. In this embodiment, the version difference threshold is 3, meaning the local key version number is allowed to lag by a maximum of 3 versions. When the difference between the key version number in the notification message and the local key version number exceeds 3, the service subscriber determines the notification message is abnormal, rejects the notification message, and reports it to the trust anchor management center for adjudication.

[0044] In the application, upon receiving the aforementioned report, the Trust Anchor Management Center cancels the existing binding relationship between the service subscriber and the impersonated service, reissues a session round identifier to the service to identify a complete service session, and issues a key version number base that matches the current key version number of the real service to the service subscriber. The service subscriber then resets its local key version number to this base number. After these actions, the service subscriber re-registers with the Trust Anchor Management Center to rebuild the binding relationship, and the service publisher also re-registers, ensuring that both parties' key version numbers return to the same base. The purpose of these actions is to completely remove the contaminated local state after a version inflation attack.

[0045] In applications, such as Figure 3 As shown, a signature refers to a piece of authentication data that can be verified with a public key, generated by the service publisher using a signing key for each service communication message. The input for a signature is composed as follows: Where M is the signature input, For service identification, For instance identification, For session round identifiers, For timestamps, It is a random number. For message counters, For payload hash, symbol This indicates that the items are concatenated in the above order. The service identifier and instance identifier are used to identify the service and instance to which the message belongs, preventing cross-service impersonation; the timestamp records the message generation time; the random number is generated individually by the service publisher for each message to prevent replay of known signatures; the message counter monotonically increases within the same session round identifier to prevent out-of-order delivery; the payload hash is a fixed-length digest of the message payload obtained through hashing, and in this embodiment, a 256-bit hash value is used for integrity protection. The service publisher concatenates the above seven inputs, signs them, and appends the signature to the end of the message before sending it.

[0046] In the application, when a service subscriber receives a service communication message, it first compares the session round-robin identifier. If the session round-robin identifier carried by the message is higher than the local session round-robin identifier, it is determined that the service has already undergone one restart. At this time, the service's random number cache and local message counter are cleared, and the local session round-robin identifier is updated to the session round-robin identifier carried by the message, so that the random number and message counter left over from before the restart will no longer interfere with the judgment after the restart. If the session round-robin identifier carried by the message is equal to the local session round-robin identifier, it means that they are within the same session. At this time, the random number and message counter of the message are verified. If the session round-robin identifier carried by the message is lower than the local session round-robin identifier, it means that the message belongs to a session before the restart, and the service subscriber rejects the message.

[0047] In the application, the message counter verification rule is as follows: if the message counter carried by the message is greater than the local message counter, the message is determined not to have been replayed and is not out of order, and the verification passes; if the message counter carried by the message is less than or equal to the local message counter, the message is determined to be a replayed message or an out-of-order message, and the message is rejected. The local message counter is cleared when the service subscriber determines that the service is restarting, and is updated to the value of the message counter carried by the message after each successful signature verification.

[0048] In applications, the timestamp tolerance threshold refers to the maximum allowable deviation between a message's timestamp and the current moment, and it is determined as follows: in, The timestamp tolerance threshold is set to 100 milliseconds. This represents the maximum end-to-end message transmission delay, set to 50 milliseconds. This represents the synchronization error of the in-vehicle clock, taken as 30 milliseconds. This represents a safety margin of 20 milliseconds; the sum of the three is 100 milliseconds.

[0049] In the application, before verifying the signature, the service subscriber also checks whether the current time is within the validity period of the trust anchor corresponding to the message, that is, whether the current time is between the effective time and the expiration time of the trust anchor. This validity period is obtained and stored locally by the service subscriber when registering or accepting a new key version number. If the current time has exceeded the expiration time, it is determined that the message uses expired credentials, the message is rejected, and a key update request carrying the local key version number and service identifier is sent to the trust anchor management center. The service subscriber can also initiate the key update request proactively when the local key version number is later than the key version number in the announcement message, or at a preset period. After verifying the key update request, the trust anchor management center returns the public key corresponding to the new trust anchor with a key version number higher than the local key version number and its lifecycle parameters. The service subscriber updates its local key version number and locally stored public key accordingly. The purpose of setting this verification is to automatically remove expired credentials from use and shorten the time window for key exposure.

[0050] In this embodiment, the service subscriber will only complete signature verification using the public key corresponding to the local key version number if all four conditions are met simultaneously: the timestamp deviation is within 100 milliseconds, the random number has never appeared in the random number cache, the message counter is greater than the local message counter, and the current time is within the validity period of the trust anchor. This allows legitimate messages to pass while rejecting late messages, replayed messages, out-of-order messages, and messages using expired credentials. In other embodiments, the service subscriber may also complete signature verification using only the public key corresponding to the local key version number, or select one or more of the above four conditions as prerequisites for signature verification.

[0051] In the application, after successful signature verification, the service subscriber records the random number carried by the message into the random number cache and updates the local message counter with the message counter carried by the message. The purpose of this step is to ensure that the random number cache and the local message counter are synchronized after each successful verification: if the verified random number is not written back to the random number cache, the random number cache will always be empty, and subsequent replays of the same message will be misjudged as valid because the random number does not appear in the random number cache; if the local message counter is not updated, the local message counter will always remain at its initial value, and the out-of-order criterion will also fail. In this embodiment, the writing of the random number and the updating of the message counter are completed atomically after successful signature verification.

[0052] In applications, a random number cache refers to a storage structure used by service subscribers to record recent random numbers to identify replays. It includes at least a sliding window and a Bloom filter, and may further include a least recently used cache. The purpose of this combination is to handle situations where the number of random numbers may reach hundreds of thousands or even millions with limited memory, achieving a balance between query speed and storage cost.

[0053] In this application, the sliding window only stores random numbers that have appeared within the most recent time period. Random numbers older than this period are automatically discarded without explicit deletion, thus limiting replay recognition to a reasonable time range and preventing infinite accumulation. In this embodiment, the sliding window duration is 60 seconds, meaning only random numbers from the most recent 60 seconds are retained.

[0054] In applications, Bloom filters quickly determine whether a given random number has appeared before using a fixed-size memory structure. The number of hash functions is determined as follows: in, The number of hash functions used in a Bloom filter. This represents the total number of bits in the Bloom filter bit array. The number of random number entries to be accommodated. Divide by That is, the number of bits occupied by each entry. When the false positive rate is 1%, each entry occupies approximately 9.6 bits. Substituting this into the above formula, we get... Approximately 6.65, rounded up. Let's take 7. Therefore, in 1 megabyte (8,388,608 bits) of memory, the theoretically achievable number of random number entries is approximately 8,388,608 divided by 9.6, which equals about 870,000 entries. In this embodiment, the Bloom filter uses 7 hash functions to quickly determine the existence of random numbers within a fixed memory of approximately 1 megabyte, with a false positive rate of about one percent.

[0055] In the application, after the signature verification is successful, the service subscriber simultaneously records the random number into both the sliding window and the Bloom filter. In an implementation where the random number cache further includes a Least Recently Used (LRU) cache, the LRU cache retains frequently occurring random numbers using a LRU eviction policy to further reduce the possibility of high-frequency random numbers being evicted due to sliding window expiration or Bloom filter capacity limitations. In an implementation where the random number cache consists only of a sliding window and a Bloom filter, random number deduplication is performed solely by these two components.

[0056] Specifically, in the application scenario of dynamic trust anchor rotation in vehicle-to-service communication, a high-frequency reported wheel speed service generates a large number of messages carrying random numbers in a short period of time. The cache on the service subscriber side first uses a sliding window to retain random numbers from the last 60 seconds, and random numbers older than 60 seconds are automatically discarded. Then, a Bloom filter uses 7 hash functions to quickly determine the existence of about 870,000 random numbers in a fixed memory of about 1 megabyte. At the same time, the least recently used cache retains frequently occurring random numbers to prevent them from being mistakenly discarded. When a replay message arrives, its random number is determined to have already appeared because it is still within the sliding window and has been recorded by the Bloom filter, and is therefore rejected.

[0057] The technical advantage of this implementation is that it limits the replay identification to the most recent 60 seconds by using a sliding window, thus avoiding the infinite expansion of random number records; it uses a Bloom filter to quickly determine the existence of approximately 870,000 random numbers within approximately 1 megabyte of fixed memory, achieving extremely high query efficiency and minimal storage footprint at the cost of a false positive rate of approximately one percent; and it can further retain high-frequency random numbers by setting a least recently used cache.

[0058] In applications, such as Figure 4 As shown, services are categorized into different trust domains based on their functional security levels. Each trust domain represents a trust policy, and each trust domain corresponds to a trust anchor rotation frequency and a signature algorithm. Trust domains with higher functional security levels generally have trust anchor rotation frequencies and signature algorithm security strengths that are no lower than those of trust domains with lower functional security levels. Table 1 shows the correspondence between trust levels and functional security levels, as well as the recommended signature algorithms and security strengths for each trust level.

[0059] Table 1. Correspondence between Trust Levels and Functional Safety Levels and Recommended Signature Algorithms Table 2 Service types, anchor point rotation frequency, and signature algorithm configurations corresponding to each trust level In the application, service subscribers verify signatures for services belonging to different trust domains using the signature algorithm corresponding to the trust domain to which the service belongs. When the core domain controller detects an attack against a service, it temporarily elevates the service to a higher trust domain and immediately initiates an anchor rotation. Service subscribers then receive the service's broadcast announcement message carrying a higher key version number and verify the service's signature using the signature algorithm corresponding to the elevated trust domain. After the attack is resolved, the core domain controller restores the service's trust domain level to its original level, and service subscribers resume verification using the signature algorithm corresponding to the original trust domain.

[0060] Specifically, the infotainment service normally operates in the basic trust domain, employing an elliptic curve digital signature algorithm with approximately 128-bit security strength and rotating its anchor point weekly. When the core domain controller detects an abnormal call to this infotainment service, it temporarily elevates it to the highest trust domain, switches to a dual-signature algorithm, and immediately triggers an anchor point rotation. The dual-signature algorithm generates two signatures for the same signature input—one using elliptic curve digital signature and the other using a post-quantum digital signature algorithm—and appends them to the message, achieving a security strength of approximately 192 bits. Upon receiving an announcement message carrying a higher key version number, the service subscriber updates its local key version number and verifies the signature using the dual-signature algorithm. After the attack is resolved, the core domain controller restores the service to the basic trust domain, and the service subscriber resumes operating weekly with approximately 128-bit security strength, thus strengthening security during attacks and saving overhead during normal operation.

[0061] The technical advantage of this implementation is that it binds the trust policy of a service to its functional security level, so that high-risk services such as braking receive protection with approximately 192-bit strength and the fastest rotation, while low-risk services such as infotainment run with approximately 128-bit strength and slower rotation, avoiding the waste of resources or insufficient protection caused by a one-size-fits-all approach; when an attack is detected, the trust domain is temporarily upgraded and rotation is triggered, so that the security overhead can dynamically scale with the threat situation.

[0062] In an application, when a service malfunctions or its trust anchor is deemed compromised, the core domain controller marks the service as damaged and sends a stop notification message to all service subscribers. Upon receiving the stop notification message, service subscribers consider the service unavailable and cease calling the damaged service. If a functionally equivalent backup service instance exists, requests are sent to that backup service instance instead, in order to maintain business availability as much as possible while isolating the damaged service.

[0063] In the application, the Trust Anchor Management Center reissues a new Trust Anchor with a key version number higher than the current value for the compromised service, and delivers it to the service publisher through a protected channel. The version number of the new anchor is strictly higher than the current value, thus precisely satisfying the monotonicity check on the service subscriber side. After obtaining the new anchor, the service publisher rebroadcasts an announcement message carrying the new key version number, and the service subscriber re-registers accordingly. Simultaneously, the in-vehicle intrusion detection system continuously reports service communication anomalies to the core domain controller, which then initiates anchor rotation based on this information.

[0064] Specifically, when the in-vehicle intrusion detection system detects an abnormal call to a diagnostic service, it reports the anomaly to the core domain controller. The core domain controller marks the diagnostic service as compromised and sends a stop notification message to all service subscribers. Service subscribers then cease sending requests to the diagnostic service and switch to a backup instance if one exists. The trust anchor management center generates a new trust anchor with a version number higher than the current value for the service and distributes it to the service publisher via a secure channel. Simultaneously, it distributes a key version number base consistent with the new trust anchor to each service subscriber. After the service publisher recovers, it rebroadcasts a notification message carrying the new key version number. Service subscribers verify that this version number is higher than their local key version number and then re-register, completing the process from detection and isolation to recovery.

[0065] Specifically, such as Figure 2 As shown, after a diagnostic service publisher powers on, it registers with the trust anchor management center, obtains a trust anchor with an initial key version number and a session round identifier with a value of 1, and then broadcasts an announcement message carrying the key version number during the service discovery phase. Upon discovering the service, the service subscriber on the diagnostic tool side compares the key version number in the announcement message with its local key version number. If the key version number is higher than the local value, the subscriber updates its local key version number and obtains the public key corresponding to that key version number. Subsequently, the service publisher concatenates seven inputs into each diagnostic response message, signs it, and appends it to the end of the message. The service subscriber receives each message sequentially, first checking for a restart based on the session round identifier and clearing or reusing the random number cache accordingly. Then, it verifies whether the timestamp deviation is within 100 milliseconds, whether the random number is fresh, whether the message counter is greater than the local message counter, and whether the current time is within the validity period. Finally, it verifies the signature using the public key corresponding to the local key version number, and upon successful verification, records the random number in the random number cache and updates the local message counter with the message counter for that message. When an attacker replays a notification with an excessively large key version number in an attempt to disable the real service, the service subscriber rejects the notification and reports it because the version difference exceeds the version difference threshold of 3. The trust anchor management center then unbinds the service, issues a new session round identifier, and sends a key version number benchmark consistent with the real service to the service subscriber. The service subscriber then resets its local key version number and re-registers to restore normal communication.

[0066] The key version number comparison can be performed by directly comparing the key version number in the announcement message with the local key version number as integers, or by having the trust anchor management center sign the announcement field carrying the key version number and then having the service subscriber verify the signature before comparison. The timeout random number elimination can be performed by rolling elimination over a fixed time period, or by first-in, first-out elimination based on the maximum number of entries in the window.

[0067] The technical advantages of this implementation are as follows: by carrying the key version number during the service discovery phase and cooperating with monotonicity verification, key updates can be completed without re-establishing a secure transport layer connection, reducing the update overhead in in-vehicle multicast scenarios; through the version difference threshold and the reset process of the trust anchor management center, version inflation attacks can be detected and completely restored in a timely manner, avoiding forced disconnection of real services; by generating a signature containing a session round identifier and a message counter for each message, and writing a random number back to the cache and synchronously advancing the local counter after the signature is verified, the anti-replay and anti-out-of-order mechanisms continue to be effective throughout the entire service lifecycle, and will not misjudge legitimate messages after a restart as replays.

[0068] Example 2 This embodiment provides a method for rotating trust anchors in vehicle-mounted SOA service communication applied to service publishers. Corresponding to Embodiment 1, this method is described from the perspective of the service publisher.

[0069] In the application, service publishers register with the trust anchor management center before providing services to the outside world, obtaining an initial trust anchor and an initial session round identifier. The initial trust anchor includes a service identifier, a signing key, a key version number, and an expiration date, while the initial session round identifier is set to 1. The purpose of this step is to establish a consistent and trusted starting point for version evolution and session differentiation.

[0070] In the application, the service publisher includes the current key version number in its announcement message during the service discovery phase. This key version number is an integer that increments with each trust anchor rotation. Constructing the key version number as a strictly incrementing integer with each rotation is a prerequisite for the subscription-side monotonicity check and version difference threshold check to be valid: if the version number does not possess monotonically increasing properties, the subscription side has no way to determine the age of the key based on its size relationship, nor can it determine whether a version inflation attack has occurred based on its range. In this embodiment, the service publisher writes the current key version number into each broadcast announcement message, allowing the key version number to naturally propagate to each service subscriber during the service discovery process.

[0071] In the application, when the Trust Anchor Management Center responds to a service subscriber's report by unbinding the service subscriber and issues a new session round ID for the service, the service publisher re-registers and obtains the incremented session round ID, and then participates in signing with the new session round ID.

[0072] In the application, the service publisher generates a signature for each service communication message and appends the signature to the end of the message. The signature input is constructed as shown in the formula in Example 1, where the random number is generated separately by the service publisher for each message, and the message counter monotonically increases within the same session round identifier. The purpose of including the session round identifier in the signature input is to ensure that the restart event on the publisher side can be unambiguously identified by the subscriber side: after the service restarts, its message counter returns to zero. Without the introduction of the session round identifier, the subscriber side would not be able to distinguish between "legitimate new messages with zero counters" and "replay messages with smaller counters," thus misjudging legitimate messages after the restart as replays.

[0073] In the application, when a service publisher's trust anchor is leaked or the service malfunctions, it obtains a new trust anchor with a key version number higher than the current key version number from the trust anchor management center, and resends an announcement message carrying the new key version number after recovery. The new key version number is strictly higher than the current value, which precisely satisfies the monotonicity check on the subscription side, enabling the subscription side to unambiguously accept the new anchor and invalidate the old credentials.

[0074] In applications, the trust anchor management center is deployed within the core domain controller, sharing the same protected hardware operating environment. It manages the trust anchors for all services within the core domain controller's jurisdiction. This can be implemented by placing the trust anchor management center within a hardware security module of the core domain controller, or by placing it within a trusted execution environment (TEX) within the core domain controller. The validity period of a trust anchor includes an activation time and an expiration time, defining the time window during which a set of trust credentials are trusted.

[0075] In applications, signatures can be generated using elliptic curve digital signature algorithms, achieving robust security with relatively low computational and bandwidth overhead; alternatively, post-quantum digital signature algorithms can be used to mitigate the threat of future quantum computing to traditional signatures. Appending the signature to the end of the message decouples it from the original message structure, facilitating the carrying of authentication data without altering the original message format. The timestamp is obtained from a unified clock source within the vehicle, ensuring that both the sender and receiver use the same time reference. The payload hash is obtained by hashing the message's payload; in this embodiment, a 256-bit hash value is used.

[0076] Specifically, after powering on, the publisher of the braking status service registers with the trust anchor management center, obtaining an initial trust anchor and a session round identifier with a value of 1. It then includes this key version number in its notification message. Subsequently, for each status report message, the publisher first reads the clock source and fills in the timestamp, then generates a random number locally and hashes the message's payload to obtain a 256-bit payload hash. This hash, along with the service identifier, instance identifier, session round identifier, and message counter, is used as the signature input. An elliptic curve digital signature algorithm is used to generate the signature, which is then appended to the message tail. When the service re-registers due to a trust anchor leak, its session round identifier increments from 1 to 2. The subscriber uses this to identify that the service has restarted and clears the old cache and old counter.

[0077] The distribution of new trust anchors can be achieved either through a secure point-to-point delivery to the service publisher, or by the service publisher actively retrieving the new anchor after upgrading the trust domain. The payload hash can be calculated by hashing the entire payload all at once, or by hashing the payload in segments and then aggregating the hashes.

[0078] The technical advantage of this implementation method is that the service publisher only needs to add an incremental key version number field to the announcement message and add two items, session round identifier and message counter, to the signature input. This enables the subscriber to obtain complete capabilities for anti-rollback, anti-inflation, anti-replay, anti-out-of-order and restart identification without changing the message structure of the original service-oriented communication protocol. The engineering transformation cost is small and the compatibility is good.

[0079] Example 3 This embodiment provides a trust anchor rotation system for in-vehicle SOA service communication, such as... Figure 5 As shown, it includes a trust anchor management module, a service publishing module, and a service subscription module.

[0080] In the application, the trust anchor management module is responsible for issuing trust credentials. It issues an initial trust anchor containing a service identifier, signing key, incrementing key version number, and validity period to registered service publishing modules, along with an initial session round identifier. When a service subscription module reports a version anomaly, the module unbinds the service subscription module, issues a new session round identifier to the corresponding service, and distributes a key version number base consistent with that service to the service subscription module. The service subscription module then resets its local key version number to this base number. The purpose of setting up the trust anchor management module is to centrally manage the issuance, rotation, and anomaly handling of trust credentials.

[0081] In the application, the service publishing module is responsible for external announcement and message signing. It writes the current key version number into the announcement message and generates a signature for each service communication message using the service identifier, instance identifier, session round identifier, timestamp, random number, message counter and payload hash as signature inputs. The message counter monotonically increases within the same session round identifier.

[0082] In the application, the service subscription module maintains local key version numbers, locally stored public keys, and local session round identifiers for each service. It performs monotonicity and version difference threshold checks on announcement messages, resets local key version numbers based on key version numbers, identifies service restarts, verifies random numbers and message counters, and performs signature verification. Upon successful signature verification, the random number is stored in the random number cache, and the local message counter is updated using the message's message counter. The purpose of this module is to perform all checks on the subscription side to prevent rollback, version inflation, replay, and out-of-order delivery, and to ensure that relevant state variables advance synchronously after each successful verification.

[0083] In application, the system also includes a core domain controller and an in-vehicle intrusion detection system. The trust anchor management module exists as a security function within the core domain controller, utilizing the existing protected hardware environment of the core domain controller to protect the signature key. The in-vehicle intrusion detection system continuously monitors service communications and reports anomalies to the core domain controller when detected. Based on this, the core domain controller temporarily elevates the attacked service to a higher trust domain and initiates an anchor rotation. Once the threat is eliminated, the service's level is restored. Simultaneously, the trust anchor management module generates a new trust anchor with a key version number higher than the current value, which is then delivered to the service publishing module via a secure channel.

[0084] Specifically, after the in-vehicle intrusion detection system detects abnormal communication targeting a certain vehicle control service, it reports the anomaly to the core domain controller. The core domain controller temporarily elevates the service from the medium trust domain to the highest trust domain, adopts an algorithm with a security strength of approximately 192 bits, and triggers a trust anchor rotation. The trust anchor management module then generates a new trust anchor with a version number higher than the current value and distributes it to the vehicle control service publishing module via a secure channel. The service publishing module uses the new anchor to provide a higher version number in subsequent announcements and signs the messages. The service subscription module verifies that the version number is higher than the local key version number, updates the local key version number, and completes the signature verification using the public key corresponding to the version number. After the attack is eliminated, the core domain controller restores the service to the medium trust domain and runs it once a day with a security strength of approximately 128 bits.

[0085] The trust anchor management module can be implemented either as a hardware security module running within the core domain controller or as a trusted execution environment running within the core domain controller. The service subscription module's version record can be maintained either by keeping a separate version record for each service or by centrally maintaining a version record table indexed by the service identifier.

[0086] The technical advantage of this implementation method lies in centralizing the issuance and exception handling in the trust anchor management module, placing version number propagation and message signing in the service publishing module, and placing version verification, restart identification, random number and counter verification, and signature verification in the service subscription module. This makes the system functions clear and easy to implement in engineering. The three modules are linked together by key version number, session round identifier, and signature data, so that each signed message on the publishing side can be verified one by one on the subscription side, thereby achieving message-level dynamic authentication consistent with the method at the system level.

[0087] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 this application, and should all be included within the protection scope of this application.

Claims

1. A method for rotating trust anchor points in in-vehicle SOA service communication, applied to service subscribers, characterized in that, include: The service subscriber registers with the trust anchor management center and establishes a binding relationship with the service publisher. It receives the announcement message broadcast by the service publisher during the service discovery phase. The announcement message carries a key version number, which comes from the trust anchor obtained by the service publisher from the trust anchor management center and increments with each rotation of the trust anchor. When the key version number carried in the notification message is not higher than the local key version number, the notification message is rejected; when the key version number carried in the notification message is higher than the local key version number and the difference between the two does not exceed the version difference threshold, the local key version number is updated with the key version number carried in the notification message, and the public key corresponding to the updated local key version number is obtained; when the key version number carried in the notification message is higher than the local key version number and the difference between the two exceeds the version difference threshold, the notification message is rejected and a report is made to the trust anchor management center. Following the report, the system receives a key version number base issued by the Trust Anchor Management Center after unbinding the service subscriber from the service publisher, resets the local key version number to the key version number base, and re-registers with the Trust Anchor Management Center. The system receives a service communication message sent by the service publisher, the service communication message carrying a signature, and verifies the signature using the public key corresponding to the local key version number.

2. The method for rotating trust anchors in vehicular SOA service communication according to claim 1, characterized in that, The service communication message also carries a session round identifier, a random number, and a message counter. The session round identifier increments each time the service publisher registers with the trust anchor management center, and the message counter increments within the same session round identifier. The service subscriber locally maintains a random number cache, a local message counter, and a local session round identifier. Before verifying the signature, if the session round identifier carried by the service communication message is higher than the local session round identifier, it is determined that the service publisher has restarted, the random number cache and the local message counter are cleared, and the local session round identifier is updated with the session round identifier carried by the service communication message. If the session round identifier carried by the service communication message is equal to the local session round identifier, it is verified that the random number carried by the service communication message does not appear in the random number cache, and the message counter carried by the service communication message is greater than the local message counter. If the session round identifier carried in the service communication message is lower than the local session round identifier, the service communication message is rejected. After the signature verification is successful, the random number carried by the service communication message is recorded in the random number cache, and the local message counter is updated with the message counter carried by the service communication message.

3. The method for rotating trust anchors in vehicular SOA service communication according to claim 2, characterized in that, The trust anchor also includes an expiration period, the service communication message also carries a timestamp, and the signature input includes a service identifier, an instance identifier, a session round identifier, the timestamp, the random number, the message counter, and a payload hash. The payload hash is obtained by hashing the payload of the service communication message. Before verifying the signature, it is also verified that the difference between the timestamp and the current time is within the timestamp tolerance threshold, and that the current time is within the expiration period of the trust anchor.

4. The method for rotating trust anchors in vehicular SOA service communication according to claim 2, characterized in that, The random number cache includes a sliding window and a Bloom filter. The sliding window retains random numbers within a time window and discards timed-out random numbers. The Bloom filter records the existence status of random numbers. The step of recording the random number carried by the service communication message into the random number cache includes recording the random number into both the sliding window and the Bloom filter simultaneously.

5. The method for rotating trust anchors in vehicular SOA service communication according to claim 1, characterized in that, Also includes: Send a key update request carrying the local key version number and service identifier to the trust anchor management center, receive the public key corresponding to the new trust anchor with a key version number higher than the local key version number returned by the trust anchor management center after verifying the key update request, and update the locally stored public key with the public key and update the local key version number with the key version number of the new trust anchor.

6. The method for rotating trust anchor points in vehicular SOA service communication according to claim 1, characterized in that, The service is divided into multiple trust domains according to functional safety levels. Each trust domain corresponds to a trust anchor rotation frequency and a signature algorithm. The trust domain with a higher functional safety level has a trust anchor rotation frequency and a signature algorithm with security strength that are no lower than those of the trust domain with a lower functional safety level. The service subscriber verifies the signature using the signature algorithm corresponding to the trust domain to which the service publisher belongs. After the core domain controller detects an attack against the service publisher and upgrades the trust domain to which the service publisher belongs, it receives an announcement message carrying a higher key version number broadcast by the service publisher due to the trust anchor rotation triggered by the upgrade of the trust domain, and verifies the signature using the signature algorithm corresponding to the upgraded trust domain. After the attack is eliminated, the signature is verified using the signature algorithm corresponding to the original trust domain to which the service publisher belonged.

7. A method for rotating trust anchor points in vehicular SOA service communication, applied to service publishers, characterized in that... include: Register with the Trust Anchor Management Center to obtain a Trust Anchor, which includes a service identifier, a signing key, a key version number, and a validity period. The key version number is carried in the announcement message broadcast during the service discovery phase. The key version number increments with each rotation of the trust anchor, so that the service subscriber rejects the announcement message when the key version number is not higher than its local key version number, updates its local key version number when the key version number is higher than its local key version number and the difference between the two does not exceed the version difference threshold, and rejects the announcement message and reports to the trust anchor management center when the key version number is higher than its local key version number and the difference between the two exceeds the version difference threshold. After the Trust Anchor Management Center responds to the report and unbinds the service subscriber, the service subscriber re-registers with the Trust Anchor Management Center to bring the local key version number of the service subscriber back to a consistent baseline with the key version number of the service publisher; A signature is generated for the service communication message using the signature key, the signature is appended to the service communication message, and the message is sent to the service subscriber.

8. The method for rotating trust anchors in vehicular SOA service communication according to claim 7, characterized in that, The service publisher obtains an incrementing session round identifier each time it registers with the trust anchor management center. The signature input includes the service identifier, instance identifier, session round identifier, timestamp, random number, message counter, and payload hash. The random number is generated separately by the service publisher for each service communication message. The message counter increments within the same session round identifier so that when the session round identifier is higher than its local session round identifier, the service subscriber determines that the service publisher has restarted and clears its random number cache and local message counter.

9. The method for rotating trust anchor points in vehicular SOA service communication according to claim 7, characterized in that, After the trust anchor is leaked or the service publisher becomes abnormal, a new trust anchor is obtained. The new key version number of the new trust anchor is higher than the current key version number of the trust anchor. After recovery, an announcement message carrying the new key version number is rebroadcast.

10. A trust anchor point rotation system for in-vehicle SOA service communication, characterized in that, include: The trust anchor management module is used to issue trust anchors to registered service publishing modules. The trust anchor includes a service identifier, a signing key, a key version number that increments with each rotation, and a validity period. It is also used to unbind the service subscription module after receiving a report from the service subscription module, and to issue a key version number base to the service subscription module, wherein the key version number base is consistent with the key version number of the service publishing module; The service publishing module is used to carry the key version number in the announcement message broadcast during the service discovery phase, and to generate a signature for the service communication message using the signing key; The service subscription module is configured to reject the notification message when the key version number carried in the notification message is not higher than the local key version number; update the local key version number and store the public key corresponding to the updated local key version number when the key version number carried in the notification message is higher than the local key version number and the difference between the two does not exceed the version difference threshold; reject the notification message and report to the trust anchor management module when the key version number carried in the notification message is higher than the local key version number and the difference between the two exceeds the version difference threshold; and reset the local key version number to the key version number base and verify the signature with the public key corresponding to the local key version number.

Images