A Lightweight Identity-Based Secure Communication Scheme for In-Vehicle Networks

1. Introduction

As automotive electronic/electrical (E/E) architectures evolve from distributed electronic control units (ECUs) toward domain-centralized and software-defined vehicle (SDV) architectures, in-vehicle networks have become critical communication infrastructures supporting intelligent vehicle services rather than merely carrying control signals. Communication technologies such as Controller Area Network (CAN/CAN FD) and Automotive Ethernet [1], together with diagnostic protocols including Unified Diagnostic Services (UDS) [2] and Diagnostics over CAN (DoCAN) [3], provide fundamental support for remote diagnostics, over-the-air (OTA) software updates, parameter configuration, and intelligent vehicle management. However, the increasing connectivity of modern vehicles significantly expands the attack surface of in-vehicle networks, exposing critical communication channels to threats such as message eavesdropping, tampering, replay, and unauthorized access [4,5,6]. As the communication gateway between external networks and the in-vehicle domain, the Telematics Control Unit (T-Box) plays a vital role in vehicle–cloud interaction, remote diagnostics, and software maintenance. Once compromised, it may provide attackers with a direct entry point into the in-vehicle network, resulting in diagnostic abuse, malicious command injection, software-update hijacking, and other severe security risks [7,8,9]. Therefore, establishing a lightweight and trustworthy secure communication mechanism between the T-Box and in-vehicle ECUs has become a fundamental requirement for next-generation intelligent vehicles.

Existing secure communication mechanisms for in-vehicle networks mainly rely on either symmetric cryptography or certificate-based public-key infrastructures (PKIs). Symmetric cryptography provides efficient confidentiality and integrity protection for high-frequency message transmission but cannot independently accomplish authenticated key establishment or identity verification. In contrast, certificate-based public-key cryptography supports mutual authentication and secure key agreement through digital certificates. However, these approaches require certificate issuance, distribution, verification, renewal, and revocation throughout the vehicle lifecycle. Considering that a modern vehicle may contain dozens or even hundreds of ECUs with service lifetimes exceeding ten years, certificate management inevitably introduces considerable computational, storage, communication, and maintenance overhead. Consequently, resource-constrained in-vehicle devices require a secure communication mechanism that simultaneously provides authenticated key establishment, lightweight deployment, and simplified key management.

Identity-Based Cryptography (IBC) provides an attractive alternative to conventional PKI by allowing a node's public key to be directly derived from its identity, thereby eliminating the need for certificate management. Since the identity-based cryptographic concept was first proposed by Shamir [10] and later realized using pairing-based constructions [11], IBC has been widely regarded as an effective solution for secure communication in large-scale distributed systems. In vehicular environments, engineering identifiers such as vehicle identification numbers (VINs), ECU addresses, functional identifiers, and domain identifiers naturally satisfy the uniqueness requirement of identities and can be securely associated with long-term private keys during vehicle manufacturing or maintenance. This property makes identity-based cryptography particularly suitable for in-vehicle networks consisting of numerous heterogeneous ECUs while significantly reducing the complexity of key deployment and lifecycle management.

Although identity-based cryptography effectively eliminates certificate management, authenticated key establishment based on pairing operations remains computationally expensive for resource-constrained ECUs. Fortunately, session establishment is performed only occasionally, whereas data transmission dominates normal in-vehicle communication. This observation motivates a layered security architecture in which computationally intensive identity-based cryptographic operations are confined to the session-establishment phase, while lightweight symmetric cryptography is employed to protect subsequent high-frequency data transmission. Such a design preserves strong authentication while significantly reducing the cryptographic overhead during routine communication.

Motivated by the above observations, this paper proposes a lightweight identity-based secure communication scheme for resource-constrained in-vehicle networks. The proposed scheme separates authenticated session establishment from data-plane protection. During session establishment, communicating parties authenticate each other through an identity-based authenticated key agreement protocol and establish a shared session key with explicit key confirmation. After the secure session is established, independent encryption and authentication subkeys are derived from the negotiated session key to provide confidential, authenticated, and replay-resistant message transmission with minimal computational overhead. Furthermore, the proposed architecture enables the T-Box to maintain multiple isolated secure sessions with different ECUs, thereby supporting secure remote access and concurrent communication in practical vehicular environments.

To validate the proposed scheme, a multi-node software simulation platform consisting of independent T-Box and ECU processes is implemented. Comprehensive experiments are conducted to evaluate session establishment latency, data-plane processing overhead, communication cost, multi-session scalability, resource consumption, and resilience against representative network attacks. The experimental results demonstrate that the proposed scheme achieves efficient authenticated communication while satisfying the lightweight requirements of resource-constrained in-vehicle networks.

The main contributions of this paper are summarized as follows.

(1) A decoupled identity-based secure communication framework is designed for resource-constrained in-vehicle networks. Identity-based authentication and session key establishment are performed only when a session is initialized, since these operations are relatively expensive. After the session is established, vehicle messages are protected using symmetric cryptographic operations, which reduces the processing overhead of frequent data transmission. The framework also avoids the certificate management required by conventional PKI-based schemes.

(2) A T-Box-oriented multi-session communication architecture is developed to maintain an independent security context for each target ECU and to support gateway decrypt-and-forward and end-to-end ciphertext-forwarding modes, thereby providing cryptographic session isolation, secure off-board access, and deployment flexibility in multi-ECU environments.

(3) A lightweight identity-based authenticated key-establishment protocol and a parameterized batch-authentication mechanism are designed. The former provides mutual authentication, explicit key confirmation, session binding, and direction-specific and purpose-specific subkey separation, while the latter amortizes authentication costs across message batches and provides verify-before-release integrity and replay protection using standard classical-CAN frames.

(4) The scheme is formally analyzed using ProVerif 2.05 and evaluated on a multi-node software platform scaling to 18 ECUs. All 11 symbolic verification queries are satisfied, and all 1,200 mutated-frame trials are rejected without plaintext release. For the selected k=8 and t=128 profile, the median host-side processing latency is 1.036 ms per 8-byte message. Under the 500-kbit/s unstuffed classical-CAN model, the amortized wire cost is 138.75 bits per message and the modeled bus load is 49.95% at 18 ECUs.

2. Related Work

For secure communication in intelligent connected vehicle in-vehicle networks, existing research has gradually evolved from simple message protection to the coordinated consideration of authentication, key agreement, and engineering deployment. Reviews and research progress show that vehicular network security protection is expanding from single-message authentication to intrusion detection, secure communication architectures, key management, and coordinated optimization with engineering deployment [12,13,14,15]. Considering the limited payload, high real-time requirements, and constrained ECU resources of in-vehicle networks, related work can generally be divided into four levels: data protection, authentication and key agreement, engineering adaptation, and adaptation of Chinese commercial cryptographic algorithms. In-vehicle networks mainly rely on CAN/CAN FD and automotive Ethernet. Because classical CAN has a small payload, diagnostic and long-message transmission usually still depends on ISO-TP/UDS, which requires security-mechanism design to account for field overhead, segmented transmission, and latency constraints [16,17,18,19].

(1) Lightweight security mechanisms for data protection

Early cryptographic protection for in-vehicle networks mainly focused on message confidentiality and integrity, using symmetric encryption, message authentication codes (MACs), and related techniques to resist eavesdropping, tampering, and forgery [12,18,19]. Such methods are computationally efficient and suitable for the data-plane protection needs of resource-constrained ECUs, and have therefore long held an important position in CAN message authentication research. Studies on CAN network authentication schemes show that lightweight MAC schemes, truncated MAC schemes, and authentication constructions for payload-constrained scenarios are typical technical routes in this direction [18,19,20].

However, these methods also have clear limitations. If the authentication field is long, it significantly increases the payload occupation and segmentation pressure of CAN/CAN FD messages. If the authentication field is further compressed, authentication strength and security margin are weakened. Existing studies and evaluations generally indicate that traditional full-length MAC authentication or high-overhead security mechanisms, when deployed in resource-constrained in-vehicle networks, often increase message length, consume limited bus bandwidth, and introduce additional end-to-end latency [16,17,18,19,20].

(2) Cryptographic mechanisms for authentication and key agreement

Relying only on symmetric cryptography makes it difficult to independently solve node identity trust and session key establishment. Researchers have therefore introduced digital signatures, authentication protocols, and session key distribution mechanisms to realize mutual authentication and secure session establishment between nodes [12,21]. In recent years, research on CAN bus authentication mechanisms has shifted from simply ensuring message authenticity and integrity toward the coordinated design of multiple security objectives, including node identity confirmation, session initialization, key agreement, and replay protection [18,20,21,22].

Although such methods can solve identity authentication and key agreement more completely, their engineering implementation cost is high. For vehicular networks with many nodes and diverse service types, reducing the complexity of key distribution, management, and update while maintaining authentication strength remains a key challenge for protocol deployment [22]. In particular, schemes based on traditional public-key cryptography and certificate systems require certificate issuance, distribution, verification, and revocation maintenance, which easily introduces additional system complexity. Asymmetric cryptographic operations also increase the computation, storage, and communication burden on nodes. Security evaluations and comparative studies show that in in-vehicle networks with many ECUs and long life cycles, security mechanisms must not only satisfy cryptographic security properties, but also consider deployability, maintainability, and infrastructure dependence [12,13,14].

(3) Engineering adaptation for vehicular scenarios

In recent years, the research focus has further shifted from algorithmic feasibility to protocol-stack deployment. On the one hand, security-architecture research for CAN FD has begun to focus on how to embed encryption and authentication mechanisms more carefully into in-vehicle communication frame structures while jointly considering message length, segmented transmission, bus load, and real-time constraints [16,17,19]. On the other hand, AUTOSAR SecOC has become an important engineering reference for in-vehicle message authenticity and freshness protection. Related studies analyze and improve its authentication-field organization, freshness mechanism, and software implementation overhead. SecOC realizes authenticity and replay protection by appending authentication information to PDUs and combining it with a freshness mechanism, but it also introduces software-layer processing and resource consumption [20,21,23].

In addition, regarding latency and schedulability after security mechanisms are introduced, studies have analyzed the worst-case response time of security-aware CAN FD, showing that the overhead of authentication and encryption cannot be discussed separately from in-vehicle real-time constraints [16,19]. Therefore, existing engineering studies generally prefer separating the session establishment stage from the data transmission stage: computationally expensive authentication and key agreement are limited to initialization, while lighter symmetric protection mechanisms are used for subsequent data transmission [2,17,23].

For asymmetric cryptography, certificate-based public-key schemes are relatively mature, but introduce high certificate management and maintenance costs in large-scale ECU environments. By contrast, identity-based cryptography reduces dependence on traditional certificate systems through identity-as-public-key, providing a new implementation path for node authentication and session establishment. Therefore, this paper introduces the identity-based cryptographic mechanism and applies it to low-frequency session initialization and node identity binding. During high-frequency data transmission, symmetric mechanisms are used to realize lightweight encryption and authentication protection. This design avoids introducing high-overhead asymmetric operations into every data interaction. While ensuring identity authentication, key agreement, and data protection, it reduces bus load, computational overhead, and key management complexity, making it more consistent with the engineering deployment needs of resource-constrained in-vehicle networks. Considering the development trends of vehicular authentication, SecOC engineering implementation, and dynamic key management, this layered design combining low-frequency identity authentication and session establishment with high-frequency symmetric data protection fits well with the current evolution of in-vehicle secure communication mechanisms [20,21,23].

In summary, existing studies still have shortcomings. Data protection mechanisms relying solely on symmetric cryptography cannot independently solve node identity authentication and session key establishment. Although certificate-based public-key schemes provide relatively complete security mechanisms, they introduce high certificate management complexity in vehicular environments with many ECUs and long life cycles. Existing lightweight schemes attempt to reduce message authentication and computation overhead, but there is still no unified and systematic solution that simultaneously considers identity trust, session key agreement, data-plane protection, and secure access requirements in T-Box off-board access scenarios under resource-constrained conditions [12,13,14,200].

To address these challenges, this paper proposes a lightweight identity-based secure communication scheme for in-vehicle networks. The proposed scheme adopts a layered architecture that applies identity-based authenticated key agreement during session establishment and lightweight symmetric cryptography for subsequent data transmission. By eliminating certificate management and separating computationally intensive authentication from high-frequency message protection, the proposed scheme achieves both efficient deployment and low-latency secure communication for resource-constrained in-vehicle nodes.

3. Identity-Based Secure Communication Scheme for In-Vehicle Nodes

3.1. System Model

The considered in-vehicle communication system consists of a T-Box, an in-vehicle gateway, and multiple Electronic Control Units (ECUs). The vehicle communicates with external services through cellular, Wi-Fi, or Bluetooth networks, while local diagnostic access is provided through the OBD-II interface. The T-Box serves as the main access point between external services and the in-vehicle network. It receives remote diagnostic, configuration, control, and OTA requests, identifies the target ECU, and manages the corresponding secure session. The in-vehicle gateway connects the T-Box to the internal CAN/CAN-FD network and forwards authorized messages to the corresponding ECUs, such as braking, body control, battery management, and powertrain ECUs.

Because ECUs have limited computing and storage resources, computationally intensive identity-based cryptographic operations are performed only during session establishment. Lightweight symmetric cryptographic operations are then used for subsequent data transmission. During system initialization, a trusted Key Generation Center (KGC) establishes the system parameters and generates an identity-based private key for each T-Box, gateway, and ECU according to its unique identity. These private keys are securely provisioned during vehicle manufacturing or maintenance. In normal vehicle operation, the T-Box performs mutual authentication and session key agreement with each target ECU through the gateway and maintains a separate session state for each ECU. The considered attack surface includes both remote network access and physical diagnostic access through the OBD-II interface. The system model also includes secure message forwarding and session isolation across multiple T-Box–ECU sessions.

3.2. Threat Model and Security Requirements

In the proposed system model, a trusted Key Generation Center (KGC) initializes the system public parameters and generates an identity-based private key for each T-Box, gateway, and ECU according to its unique identity. The identity information of a node, such as its vehicle identifier, functional address, and ECU type, is used as its public-key identifier, thereby eliminating the need for conventional public-key certificates. The generated private keys are securely provisioned into the corresponding nodes during vehicle production or maintenance. The T-Box acts as the primary interface between external communication networks and the in-vehicle network, while the gateway controls and forwards messages between the external access domain and the ECUs connected through CAN or CAN FD. Each T-Box–ECU pair establishes an independent secure session for subsequent message exchange.

As shown in Fig. 1, we consider two categories of attackers: remote attackers and physical attackers. A remote attacker may access the vehicle through cellular networks, Wi-Fi, Bluetooth, or other wireless interfaces and attempt to compromise the T-Box. After gaining control of the T-Box or its communication software, the attacker may further access the in-vehicle gateway and target ECUs. A physical attacker may connect a malicious diagnostic device to the OBD-II interface and directly send messages to the gateway or the in-vehicle network. These attackers may operate either passively or actively. A passive attacker can monitor the communication channel, collect protocol messages, and analyze communication patterns. An active attacker can intercept, modify, delete, delay, replay, or inject session-negotiation messages and protected data packets. The attacker may also impersonate a legitimate T-Box, gateway, or ECU, or attempt to establish an unauthorized session using previously captured messages.

Figure 1. Threat model.

Figure 1. Threat model.

We further assume that an attacker may compromise the software environment of an ordinary vehicle node and control the messages transmitted by that node. However, the KGC is trusted, and the system master secret is not disclosed. Identity-based private keys stored in protected storage cannot be directly extracted unless the corresponding security boundary is broken. The attacker is assumed to have full knowledge of the system architecture, communication protocol, and cryptographic algorithms, but cannot break the underlying cryptographic primitives within polynomial time. Invasive hardware attacks, side-channel attacks, and continuous physical-layer jamming of the in-vehicle bus are outside the scope of this work.

Based on the above attacker capabilities, the proposed in-vehicle secure communication scheme should satisfy the following security requirements.

Confidentiality:Since CAN and CAN FD use a broadcast communication mechanism, any node connected to the in-vehicle network may receive the transmitted frames. Therefore, business data, diagnostic commands, vehicle status information, and other sensitive messages should be encrypted so that only the intended communication entities can recover the plaintext.

Authentication:The T-Box, gateway, and target ECU should mutually verify each other before establishing a secure session. The session key must be cryptographically bound to the identities of both communication parties, preventing an attacker from impersonating a legitimate node or replacing one participant’s identity during session negotiation.

Message Integrity:The receiver should be able to verify that a received message was generated by an authenticated communication peer and has not been modified during transmission. Any unauthorized modification to the message header, ciphertext, session identifier, sequence number, or authentication tag should be detected, and the corresponding message should be rejected.

Message Freshness:An attacker may retransmit previously captured session-negotiation messages or protected data packets to impersonate a legitimate node or trigger repeated vehicle operations. Therefore, session random values, session identifiers, sequence numbers, or other freshness information should be incorporated to ensure that previously accepted messages cannot be reused in the current session.

Session Key Security and Key Separation:The established session key should be known only to the authenticated communication parties. An attacker should not be able to derive the session key from public parameters, intercepted protocol messages, or the keys of unrelated nodes. In addition, different ECUs, sessions, communication directions, and cryptographic purposes should use independent keys so that the disclosure of one session key does not compromise other secure sessions.

3.3. Framework Overview

To satisfy the secure communication requirements between the T-Box and in-vehicle ECUs, this paper proposes a lightweight identity-based secure communication framework. As illustrated in Fig. 2, the proposed framework consists of four functional components: offline identity-based key provisioning, online authenticated session establishment, lightweight data-plane protection, and secure T-Box session management. By separating computationally intensive identity-based authentication from high-frequency data transmission, the framework simultaneously achieves certificate-free identity authentication, secure session establishment, and lightweight data protection.

Figure 2. Overall architecture of the in-vehicle secure communication scheme.

Figure 2. Overall architecture of the in-vehicle secure communication scheme.

The scheme consists of the following parts:

(1) Offline Identity-Based Key Provisioning

The offline provisioning stage establishes the trust foundation of the proposed framework. A trusted Key Generation Center (KGC) initializes the system parameters and generates long-term identity-based private keys according to the unique identity of each legitimate node. The generated private keys are securely provisioned into the T-Box, gateway, and ECUs during vehicle manufacturing or authorized maintenance. Through offline identity binding and secure key provisioning, this stage establishes the initial trust relationship among in-vehicle nodes and provides the cryptographic basis for subsequent authenticated session establishment.

(2)

Identity-Based Authenticated Session Establishment

During the online stage, the T-Box and the target ECU establish an authenticated secure session based on their long-term identity-based private keys and fresh session randomness. The communicating parties exchange temporary negotiation parameters, derive a shared session root key, and perform explicit key confirmation to verify the consistency of the negotiated key. Since computationally intensive identity-based cryptographic operations are confined to the session-establishment phase, the proposed framework achieves strong authentication while maintaining low communication overhead during subsequent data transmission.

(3) Lightweight Data-Plane Protection

After a secure session has been established, subsequent communication enters the data-plane protection stage. Independent encryption and authentication subkeys are derived from the negotiated session root key to protect service messages. Each transmitted message is associated with a session identifier and freshness information to provide confidentiality, integrity, source authentication, and replay protection. By employing lightweight symmetric cryptographic operations during high-frequency communication, the proposed framework significantly reduces computational overhead while preserving secure end-to-end message transmission.

(4) T-Box Multi-Session Management and Secure Forwarding

To support practical remote-access scenarios, the T-Box maintains independent secure sessions with multiple target ECUs. A dedicated session management mechanism is adopted to isolate the security context of different communication sessions and support efficient session reuse. According to different deployment requirements, the proposed framework supports both gateway decrypt-and-forward and end-to-end ciphertext forwarding modes, thereby enabling secure and flexible communication between off-board services and in-vehicle ECUs.

Based on the above architecture, the subsequent sections present the detailed design of offline identity-based key provisioning, authenticated session establishment, lightweight data-plane protection, and T-Box session management. As a concrete realization of the proposed identity-based framework, the protocol is instantiated using the SM9 identity-based cryptographic algorithm, while the overall architecture is independent of any particular identity-based cryptographic standard. Table 1 summarizes the main protocol parameters used throughout the proposed framework.

3.4. Offline Identity-Based Key Provisioning

(1) System initialization. In the system initialization stage, the trusted key generation center KGC generates the system master private key $msk$and master public key $mpk$, and publishes the system parameters $\mathrm{params}$. These parameters include bilinear-pairing group parameters, generators ${\mathrm{P}}_1$ and ${\mathrm{P}}_2$, hash-to-group mapping functions, and related values. The system parameters $\mathrm{params}$ and master public key $mpk$ serve as the public trust foundation of the in-vehicle security domain. They can be preconfigured in relevant nodes during vehicle production, or distributed through a software update link with integrity and authenticity protection.

This process provides basic support for subsequent node private-key generation, identity binding, and session key agreement, while avoiding the additional management overhead caused by certificate issuance, distribution, and verification in traditional certificate systems.

(2) Private-key generation. For the unique identity $\mathrm{I}{\mathrm{D}}_{\mathrm{i}}$ of each vehicular node, the system generates the corresponding SM9 private key based on its identity information. To prevent the same identity from reusing the same mapping input under different cryptographic functions, a public function tag $\mathrm{tag}$ is introduced in the identity hashing stage to distinguish the functional domains corresponding to different purposes. Let the system master private key be $\mathrm{s}\in {\mathrm{Z}}_{\mathrm{n}}^{*}$, the base point in the system parameters be ${\mathrm{P}}_1$, and the group order be n. The node private-key generation process is as follows:

First, calculate the hash mapping value according to the node identity and function tag.

$\mathrm{h}={\mathrm{H}}_1(\mathrm{ID}\left|\right|\mathrm{tag},\mathrm{n})$

where ${\mathrm{H}}_1:\{{0,1\}}^{*}\to {\mathrm{Z}}_{\mathrm{n}}^{*}$denotes the hash mapping function, whose output is a nonzero integer modulo n; the public usage tag can be represented by a fixed hexadecimal constant. For example, one can define

$\mathrm{ta}{\mathrm{g}}_{\mathrm{KA}}=0\mathrm{x}01,\mathrm{ta}{\mathrm{g}}_{\mathrm{SIG}}=0\mathrm{x}02,\mathrm{ta}{\mathrm{g}}_{\mathrm{ENC}}=0\mathrm{x}03$

corresponding to key agreement, digital signature, and encryption functions, respectively. In this way, the same node identity obtains mutually independent identity mapping inputs under different security functions. Then, the intermediate value is calculated.

${\mathrm{t}}_1=(\mathrm{s}+\mathrm{h}{)}^{-1}(\mathrm{mod} \mathrm{n})$

where (s+h)⁻¹mod  n denotes the multiplicative inverse of the integer s+h modulo n, that is, there exists$(\mathrm{s}+\mathrm{h})\cdot {\mathrm{t}}_1\equiv 1(\mathrm{mod} \mathrm{n})$After obtaining ${\mathrm{t}}_1$, further calculate the scalar.

${\mathrm{K}}_{\mathrm{i}}=\mathrm{s}\cdot {\mathrm{t}}_1 \mathrm{mod} \mathrm{n}$

Finally, the node private key is

${\mathrm{D}}_{\mathrm{i}}={\mathrm{k}}_{\mathrm{i}}{\mathrm{P}}_1=(\mathrm{s}\cdot {\mathrm{t}}_1){\mathrm{P}}_1$

where ${\mathrm{k}}_{\mathrm{i}}{\mathrm{P}}_1$denotes scalar multiplication on the elliptic-curve group, namely multiplying the base point ${\mathrm{P}}_1$by an integer scalar to obtain a point ${\mathrm{D}}_{\mathrm{i}}$ on the curve. Therefore, ${\mathrm{D}}_{\mathrm{i}}$ is essentially not an ordinary integer, but a point on the elliptic-curve group G1, which can be written as

${\mathrm{D}}_{\mathrm{i}}=({\mathrm{x}}_{{\mathrm{D}}_{\mathrm{i}}},{ \mathrm{y}}_{{\mathrm{D}}_{\mathrm{i}}})$

where the ${\mathrm{x}}_{{\mathrm{D}}_{\mathrm{i}}}$and ${\mathrm{y}}_{{\mathrm{D}}_{\mathrm{i}}}$ denote the coordinate representation of the curve point. This point constitutes the private key of the ECU node under the specified function tag $\mathrm{tag}$.

The ECU node private-key generation algorithm is shown in Algorithm 1. It first calculates the hash value $h$ according to the identity information and function tag, then combines it with the system master private key $\mathrm{s}$ to calculate the modular inverse ${\mathrm{t}}_1$, generates the scalar ${\mathrm{k}}_{\mathrm{i}}$, and finally obtains the private key ${\mathrm{D}}_{\mathrm{i}}$ through elliptic-curve scalar multiplication. Because different tags tag lead to different $h$ values and consequently different derived values ${\mathrm{t}}_1$, ${\mathrm{k}}_{\mathrm{i}}$ and ${\mathrm{D}}_{\mathrm{i}}$, private keys generated under different security functions remain independent even for the same node identity $\mathrm{I}{\mathrm{D}}_{\mathrm{i}}$. This realizes functional-domain separation and avoids cross-purpose parameter reuse.

Algorithm 1: SM9-based private-key generation algorithm for vehicular ECU nodes

Input: node identity $\mathrm{I}{\mathrm{D}}_{\mathrm{i}}$, function $\mathrm{tag}$, system master private key $\mathrm{s}$, system parameters$({\mathrm{P}}_1,\mathrm{n})$ Output: long-term node private key${ \mathrm{D}}_{\mathrm{i}}$ 1. Compute the identity mapping value $\mathrm{h}={\mathrm{H}}_{\mathrm{i}}(\mathrm{I}{\mathrm{D}}_{\mathrm{i}}\left|\right|\mathrm{tag},\mathrm{n})$ 2. Compute the modular-inverse intermediate value ${\mathrm{t}}_1=(\mathrm{s}+\mathrm{h}{)}^{-1}\mathrm{mod} \mathrm{n}$ 3. Compute the private-key scalar ${\mathrm{k}}_{\mathrm{i}}=\mathrm{s}\cdot {\mathrm{t}}_1\mathrm{mod} \mathrm{n}$ 4. Perform elliptic-curve scalar multiplication ${\mathrm{D}}_{\mathrm{i}}={{\mathrm{k}}_{\mathrm{i}}\mathrm{P}}_1$ 5. Output the long-term private-key point${ \mathrm{D}}_{\mathrm{i}}$ Here, the operation$[{\mathrm{k}}_{\mathrm{i}}]{\mathrm{P}}_1$ in step 4 denotes scalar multiplication on the elliptic-curve group ${\mathrm{G}}_1$, multiplying the base point${ \mathrm{P}}_1$ by an integer ${\mathrm{k}}_{\mathrm{i}}$ and outputting a curve point ${\mathrm{D}}_{\mathrm{i}}$.

During system deployment, node private keys are uniformly generated by the KGC based on the system master key and node identifiers, and are distributed to the corresponding ECUs as an important part of node identity credentials. To ensure the security of private-key material, private-key storage and use should be restricted to a protected trusted environment to prevent plaintext exposure in ordinary software layers. In addition, key distribution, update, revocation, and audit mechanisms should be combined to manage long-term node private keys throughout their life cycle, thereby ensuring the reliability of the identity-authentication foundation for in-vehicle nodes.

3.5. Identity-Based Authenticated Session Establishment

The online stage is responsible for mutual identity authentication and session key agreement between the T-Box and the target ECU, assuming that the offline trust root has been established and long-term node private keys have been securely injected. After an off-board service request is forwarded by the T-Box to the in-vehicle target ECU, the two parties exchange temporary public values, construct a shared intermediate value based on SM9, derive the session key, and finally use authentication tags generated from the shared key to confirm the consistency of the negotiation result. Because this process binds node identity information and temporary session randomness at the same time, it effectively provides key isolation between different communicating entities and different session instances, and establishes a secure session foundation for remote diagnosis, parameter configuration, control-command protection, and OTA services. The specific process is as follows:

Let the T-Box node be A and the target ECU node be B. The online session establishment process can be divided into four stages: session initialization, generation of vehicular SM9 negotiation parameters, calculation of the vehicular SM9 shared session key, and vehicular SM9 key confirmation.

First, in the session initialization stage, T-Box node A and target ECU node B complete the initial information exchange required for session establishment through a handshake. Specifically, node A sends a session negotiation request message ${\mathrm{M}}_1$ to node B:

${\mathrm{M}}_1=\mathrm{K}{\mathrm{A}}_{\mathrm{Req}}(\mathrm{I}{\mathrm{D}}_{\mathrm{A}},\mathrm{I}{\mathrm{D}}_{\mathrm{B}},{\mathrm{R}}_{\mathrm{A}}),$

where $\mathrm{I}{\mathrm{D}}_{\mathrm{A}}$ and $\mathrm{I}{\mathrm{D}}_{\mathrm{B}}$ denote the identities of the two communicating parties, and the negotiation parameter ${\mathrm{R}}_{\mathrm{A}}$ generated by node A for the current session. After node B receives the request, it returns a session negotiation response message. After receiving the message, B returns the following message ${\mathrm{M}}_2$ to A:

${\mathrm{M}}_2=\mathrm{K}{\mathrm{A}}_{\mathrm{Resp}}\left({\mathrm{R}}_{\mathrm{B}}\right),$

where ${\mathrm{R}}_{\mathrm{B}}$ denotes the negotiation parameter generated by node B. Through the above handshake messages, the two parties complete session initialization and establish the basis for subsequent shared-intermediate construction and session key derivation. Next, in the vehicular SM9 negotiation-parameter generation stage, the two parties select one-time random numbers and combine them with the negotiation parameters of the current session. Let the system master private key be $\mathrm{s}\in {\mathrm{Z}}_{\mathrm{n}}^{*}$ and the system master public key be

${\mathrm{P}}_{\mathrm{pub}}=\mathrm{s}{\mathrm{P}}_1,$

where ${\mathrm{P}}_1$ and ${\mathrm{P}}_2$ are base points on the corresponding groups, and the mapping $\mathrm{e}:{\mathrm{G}}_1\times {\mathrm{G}}_2\to {\mathrm{G}}_{\mathrm{T}}$ denotes the bilinear pairing. For any node $\mathrm{U}\in \{\mathrm{A},\mathrm{B}\}$ with an identity identifier, the identity hash value $\mathrm{I}{\mathrm{D}}_{\mathrm{U}}$ is defined as

${\mathrm{H}}_{\mathrm{U}}={\mathrm{H}}_1(\mathrm{I}{\mathrm{D}}_{\mathrm{U}}\left|\right|\mathrm{tag},\mathrm{n}),$

The public identity point on the elliptic curve is further constructed.

${\mathrm{Q}}_{\mathrm{U}}={\mathrm{h}}_{\mathrm{U}}{\mathrm{P}}_1+{\mathrm{P}}_{\mathrm{pub}}=({\mathrm{h}}_{\mathrm{U}}+\mathrm{s}){\mathrm{P}}_1$

On this basis, node A selects a random number ${\mathrm{r}}_{\mathrm{A}}\in {\mathrm{Z}}_{\mathrm{n}}^{*}$ and calculates the negotiation parameter:

${\mathrm{R}}_{\mathrm{A}}={\mathrm{r}}_{\mathrm{A}}{\mathrm{Q}}_{\mathrm{B}},$

Node B selects a random number ${\mathrm{r}}_{\mathrm{B}}\in {\mathrm{Z}}_{\mathrm{n}}^{*}$ and calculates the negotiation parameter:

${\mathrm{R}}_{\mathrm{B}}={\mathrm{r}}_{\mathrm{B}}{\mathrm{Q}}_{\mathrm{A}}.$

Because the generation of ${\mathrm{R}}_{\mathrm{A}}$ and ${\mathrm{R}}_{\mathrm{B}}$ depends on both local random numbers and identities, such negotiation parameters have session randomness and are directly bound to the communication objects, thereby enhancing key isolation across different sessions and communication entities.

Next, in the vehicular negotiation-parameter generation stage, the two parties combine their own private keys and local random numbers to construct shared intermediate values based on the bilinear pairing. After receiving ${\mathrm{R}}_{\mathrm{B}}$, node A calculates

${\mathrm{g}}_1^{\mathrm{A}}=\mathrm{e}({\mathrm{R}}_{\mathrm{B}},{\mathrm{D}}_{\mathrm{A}}),$

${\mathrm{g}}_2^{\mathrm{A}}=\mathrm{e}({\mathrm{P}}_{\mathrm{pub}},{\mathrm{P}}_2){\mathrm{r}}_{\mathrm{A}},$

${\mathrm{g}}_3^{\mathrm{A}}=({\mathrm{g}}_1^{\mathrm{A}}){\mathrm{r}}_{\mathrm{A}}$

Node B correspondingly calculates:

${\mathrm{g}}_1^{\mathrm{B}}=\mathrm{e}({\mathrm{R}}_{\mathrm{A}},{\mathrm{D}}_{\mathrm{B}}),$${\mathrm{g}}_2^{\mathrm{A}}=\mathrm{e}({\mathrm{P}}_{\mathrm{pub}},{\mathrm{P}}_2){\mathrm{r}}_{\mathrm{B}},$$\mathrm{c}=({\mathrm{g}}_2^{\mathrm{B}}{)}^{\mathrm{rB}}$

where ${\mathrm{D}}_{\mathrm{A}}$ and ${\mathrm{D}}_B$ denote the private keys generated and securely injected for nodes A and B during the offline stage. Thus, the online stage does not regenerate node private keys, but constructs the shared intermediate value by combining the identity private keys established offline with the one-time random values of the current session.

After constructing the shared intermediate values, both parties use an SM3-based key derivation function to generate their local session root keys.

Node A calculates:

${\mathrm{S}}_{\mathrm{A}}=\mathrm{KD}{\mathrm{F}}_{\mathrm{SM}3}(\mathrm{I}{\mathrm{D}}_{\mathrm{A}}\left|\right|\mathrm{I}{\mathrm{D}}_{\mathrm{B}}\left|\right|{\mathrm{R}}_{\mathrm{A}}\left|\right|{\mathrm{R}}_{\mathrm{B}}\left|\right|{\mathrm{g}}_1^{\mathrm{A}}\left|\right|{\mathrm{g}}_2^{\mathrm{A}}\left|\right|{\mathrm{g}}_3^{\mathrm{A}},\hspace{0.25em} {\mathrm{k}}_{\mathrm{s}}),$

Node B calculates:

${\mathrm{S}}_{\mathrm{B}}=\mathrm{KD}{\mathrm{F}}_{\mathrm{SM}3}(\mathrm{I}{\mathrm{D}}_{\mathrm{A}}\left|\right|\mathrm{I}{\mathrm{D}}_{\mathrm{B}}\left|\right|{\mathrm{R}}_{\mathrm{A}}\left|\right|{\mathrm{R}}_{\mathrm{B}}\left|\right|{\mathrm{g}}_1^{\mathrm{B}}\left|\right|{\mathrm{g}}_2^{\mathrm{B}}\left|\right|{\mathrm{g}}_3^{\mathrm{B}},\hspace{0.25em} {\mathrm{k}}_{\mathrm{s}}),$

where ${\mathrm{k}}_{\mathrm{s}}$ denotes the output length of the session root key. Under correct protocol execution, the following should hold:

${\mathrm{S}}_{\mathrm{A}}={\mathrm{S}}_{\mathrm{B}}=\mathrm{S}$

The resulting $\mathrm{S}$ is the session root key shared by the T-Box and the target ECU in the current session.

Finally, in the vehicular key-confirmation stage, to verify the consistency of the negotiation result, the two parties perform bidirectional authentication-tag confirmation based on the session root key S. Let the confirmation key derived from $\mathrm{S}$ be

${\mathrm{K}}_{\mathrm{c}}=\mathrm{KD}{\mathrm{F}}_{\mathrm{SM}3}\left(\mathrm{S}\left|\right|“\mathrm{confirm}”,{\mathrm{k}}_{\mathrm{c}}\right)$

where kc denotes the confirmation-key length, and the string $"\mathrm{confirm}"$ is used as a usage identifier to realize domain separation between the key-confirmation process and the subsequent service data protection process.

On this basis, node B first derives the confirmation key ${\mathrm{S}}_{\mathrm{B}}$ from its local session root key and calculates the authentication tag.

${\mathsf{\delta }}_{\mathrm{B}}=\mathrm{HMAC}-\mathrm{SM}{3}_{{\mathrm{K}}_{\mathrm{c}}}^{\mathrm{B}}(\mathrm{I}{\mathrm{D}}_{\mathrm{A}}\left|\right|\mathrm{I}{\mathrm{D}}_{\mathrm{B}}\left|\right|{\mathrm{R}}_{\mathrm{A}}\left|\right|{\mathrm{R}}_{\mathrm{B}}\left|\right|1),$

It is then sent to node A. After receiving it, node A derives the confirmation key ${\mathrm{S}}_{\mathrm{A}}$ from its local session root key ${\mathrm{K}}_{\mathrm{c}}^{\mathrm{A}}$ and recalculates

${\mathsf{\delta }}_{\mathrm{B}}^{\text{'}}=\mathrm{HMAC}-\mathrm{SM}{3}_{{\mathrm{K}}_{\mathrm{c}}}^{\mathrm{A}}(\mathrm{I}{\mathrm{D}}_{\mathrm{A}}\left|\right|\mathrm{I}{\mathrm{D}}_{\mathrm{B}}\left|\right|{\mathrm{R}}_{\mathrm{A}}\left|\right|{\mathrm{R}}_{\mathrm{B}}\left|\right|1)$

If the condition ${\mathsf{\delta }}_{\mathrm{B}}^{\text{'}}={\mathsf{\delta }}_{\mathrm{B}}$ is satisfied, node A passes verification, indicating that node B has correctly obtained a shared session key consistent with node A.

Subsequently, node A uses the same method and the confirmation key ${\mathrm{K}}_{\mathrm{c}}^{\mathrm{A}}$ to calculate a return authentication tag ${\mathsf{\delta }}_{\mathrm{A}}$ and sends it to node B. After receiving ${\mathsf{\delta }}_{\mathrm{A}}=\mathrm{HMAC}-\mathrm{SM}{3}_{{\mathrm{K}}_{\mathrm{c}}}^{\mathrm{A}}(\mathrm{I}{\mathrm{D}}_{\mathrm{A}}\left|\right|\mathrm{I}{\mathrm{D}}_{\mathrm{B}}\left|\right|{\mathrm{R}}_{\mathrm{A}}\left|\right|{\mathrm{R}}_{\mathrm{B}}\left|\right|0)$, node B recalculates the tag ${\mathsf{\delta }}_{\mathrm{A}}^{\text{'}}=\mathrm{HMAC}-\mathrm{SM}{3}_{\mathrm{Kc}}^{\mathrm{B}}(\mathrm{I}{\mathrm{D}}_{\mathrm{A}}\left|\right|\mathrm{I}{\mathrm{D}}_{\mathrm{B}}\left|\right|{\mathrm{R}}_{\mathrm{A}}\left|\right|{\mathrm{R}}_{\mathrm{B}}\left|\right|0)$ using its local confirmation key ${\mathrm{K}}_{\mathrm{c}}^{\mathrm{B}}$. If the condition ${\mathsf{\delta }}_{\mathrm{A}}^{\text{'}}={\mathsf{\delta }}_{\mathrm{A}}$ is satisfied, node A has also correctly obtained the same shared session key as node B. At this point, both parties complete bidirectional key confirmation and the online secure session is formally established; otherwise, node B determines that this session establishment has failed and terminates the current session.

It should be noted that the constants 1 and 0 in the formulas are used as identifiers for the confirmation message initiated by node B and the return confirmation message sent by node A, respectively. Introducing different direction-distinguishing constants into the authentication-tag input effectively prevents replay attacks caused by identical bidirectional confirmation-message formats. Thus, the key-confirmation process not only verifies whether both parties have correctly obtained the same shared session key, but also further enhances the security and distinguishability of online session establishment.

In summary, the complete SM9-based online session establishment process between the T-Box and the target ECU is shown in Algorithm 2.

Algorithm 2: SM9-based online session key agreement algorithm between the T-Box and ECU

Input: system public parameters $\mathrm{params}$, T-Box identity $\mathrm{I}{\mathrm{D}}_{\mathrm{A}}$, ECU identity $\mathrm{I}{\mathrm{D}}_{\mathrm{B}}$, T-Box private key ${\mathrm{d}}_{\mathrm{A}}$, ECU private key ${\mathrm{d}}_{\mathrm{B}}$ Output: session root key $\mathrm{S}$, confirmation key ${\mathrm{K}}_{\mathrm{c}}$ 1: The T-Box selects a random number ${\mathrm{r}}_{\mathrm{A}}$ and calculates a temporary public value ${\mathrm{R}}_{\mathrm{A}}$. 2: The T-Box sends $(\mathrm{I}{\mathrm{D}}_{\mathrm{A}},{\mathrm{R}}_{\mathrm{A}})$ to the ECU. 3: The ECU selects a random number ${\mathrm{r}}_{\mathrm{B}}$ and calculates a temporary public value ${\mathrm{R}}_{\mathrm{B}}$. 4: The ECU calculates the shared intermediate value according to $(\mathrm{I}{\mathrm{D}}_{\mathrm{A}},{\mathrm{R}}_{\mathrm{A}},\mathrm{I}{\mathrm{D}}_{\mathrm{B}},{\mathrm{R}}_{\mathrm{B}},{\mathrm{d}}_{\mathrm{B}},{\mathrm{r}}_{\mathrm{B}})$ and derives the session root key ${\mathrm{S}}_{\mathrm{B}}$. 5: The ECU derives the confirmation key ${\mathrm{K}}_{\mathrm{c}}^{\mathrm{B}}$ according to ${\mathrm{S}}_{\mathrm{B}}$ and generates an authentication tag ${\mathsf{\delta }}_{\mathrm{B}}$. 6: The ECU sends the message $(\mathrm{I}{\mathrm{D}}_{\mathrm{B}},{\mathrm{R}}_{\mathrm{B}},{\mathsf{\delta }}_{\mathrm{B}})$ to the T-Box. 7: The T-Box calculates the shared intermediate value according to $(\mathrm{I}{\mathrm{D}}_{\mathrm{A}},{\mathrm{R}}_{\mathrm{A}},\mathrm{I}{\mathrm{D}}_{\mathrm{B}},{\mathrm{R}}_{\mathrm{B}},{\mathrm{d}}_{\mathrm{A}},{\mathrm{r}}_{\mathrm{A}})$ and derives the session root key ${\mathrm{S}}_{\mathrm{A}}$. 8: The T-Box derives the confirmation key ${\mathrm{K}}_{\mathrm{c}}^{\mathrm{A}}$ according to ${\mathrm{S}}_{\mathrm{A}}$and verifies the tag ${\mathsf{\delta }}_{\mathrm{B}}$. 9: If verification succeeds, the T-Box generates an authentication tag ${\mathsf{\delta }}_{\mathrm{A}}$ and sends it to the ECU. 10: The ECU uses ${\mathrm{K}}_{\mathrm{c}}^{\mathrm{B}}$ to verify ${\mathsf{\delta }}_{\mathrm{A}}$. 11: If verification succeeds, set $\mathrm{S}\leftarrow {\mathrm{S}}_{\mathrm{A}}={\mathrm{S}}_{\mathrm{B}}$, ${\mathrm{K}}_{\mathrm{c}}\leftarrow {\mathrm{K}}_{\mathrm{c}}^{\mathrm{A}}={\mathrm{K}}_{\mathrm{c}}^{\mathrm{B}}$. 12: Return $\mathrm{S}, {\mathrm{K}}_{\mathrm{c}}$.

3.6. Lightweight Data-Plane Protection

After online session establishment between the T-Box and the target ECU is completed and the shared session root key S is obtained, subsequent communication enters the data-plane stage. In this paper, the data plane refers to the message transmission process that actually carries service contents such as diagnostic commands, control commands, parameter configuration, status responses, and OTA upgrade data on the basis of an established secure session. Unlike the preceding handshake stage, which focuses on identity authentication, session key agreement, and consistency confirmation, the data-plane stage focuses on how to use the established session key system to provide confidentiality, integrity, source authentication, and replay protection for continuously transmitted service messages. Therefore, subsequent data-plane communication does not directly use the session root key S for service data protection. Instead, data-plane subkeys for different purposes are further derived from S, and these subkeys are used to encrypt and authenticate vehicular service messages. In this way, the identity-binding relationship established during the handshake stage can be further transferred to the data-plane secure channel, providing a unified security protection foundation for remote diagnosis, parameter configuration, control-command protection, and OTA data transmission.

Functionally, the mechanism in this section mainly includes two parts. First, a session identifier is generated based on current session information, and data-plane encryption and authentication keys are derived on this basis. Second, service messages are encrypted and authenticated according to a unified data-plane message format.

3.6.1. Subkey Derivation for Vehicular Bidirectional Data Communication

To establish a clear correspondence between subsequent data-plane communication and the current established session, the session identifier $\mathrm{sid}$ is defined as

$\mathrm{sid}=\mathrm{SM}3\left(\mathrm{SM}3\right({\mathrm{ID}}_{\mathrm{A}}\left)\right|\left|\mathrm{SM}3\right({\mathrm{ID}}_{\mathrm{B}}\left)\right|\left|\mathrm{Encode}\right({\mathrm{R}}_{\mathrm{A}}\left)\right|\left|\mathrm{Encode}\right({\mathrm{R}}_{\mathrm{B}}\left)\right)$

where ${\mathrm{ID}}_{\mathrm{A}}$ and ${\mathrm{ID}}_{\mathrm{B}}$ denote the identity identifiers of the T-Box and target ECU, respectively; ${\mathrm{R}}_{\mathrm{A}}$and ${\mathrm{R}}_B$ denote the negotiation parameters exchanged by both parties during online session establishment; and the deterministic encoding function $\mathrm{Encode}(\bullet )$ converts the negotiation parameters into a unique byte-string representation according to unified rules, ensuring that both communicating parties obtain consistent hash, key-derivation, and authentication results for the same inputs. Because the value $\mathrm{sid}$ is jointly determined by the identities of both parties and the current session parameters, it corresponds one-to-one with this session. Different communicating parties or different negotiation parameters derive different identifiers $\mathrm{sid}$. In subsequent communication, $\mathrm{sid}$ serves both as the session index field of data-plane messages and as part of the subkey derivation input to strengthen the binding between the key and the current session.

On this basis, this paper uses an SM3-based key derivation function to expand the session root key $\mathrm{S}$. Let $\mathrm{labe}{\mathrm{l}}_{\mathrm{i}}$ denote the usage identifier of the i-th subkey and ${\mathrm{n}}_{\mathrm{i}}$ denote its output length; the corresponding subkey is defined as

${\mathrm{K}}_{\mathrm{i}}=\mathrm{KD}{\mathrm{F}}_{\mathrm{SM}3}(\mathrm{S}\left|\right|\mathrm{sid}\left|\right|\mathrm{labe}{\mathrm{l}}_{\mathrm{i}}\left|\right|{\mathrm{n}}_{\mathrm{i}}).$

By introducing the session identifier $\mathrm{sid}$ and usage label $\mathrm{labe}{\mathrm{l}}_{\mathrm{i}}$ into the derivation function, different subkeys derived from the same session root key are kept independent across different uses, avoiding direct reuse of the same root key for different functions. For vehicular bidirectional data communication, this paper derives the following four subkeys:

${\mathrm{K}}_{\mathrm{enc}}^{\mathrm{A}\to \mathrm{B}}=\mathrm{KD}{\mathrm{F}}_{\mathrm{SM}3}(\mathrm{S}\left|\right|\mathrm{sid}\left|\right|“\mathrm{ENC}\_\mathrm{A}2\mathrm{B}”\left|\right|16)；$

${\mathrm{K}}_{\mathrm{mac}}^{\mathrm{A}\to \mathrm{B}}=\mathrm{KD}{\mathrm{F}}_{\mathrm{SM}3}(\mathrm{S}\left|\right|\mathrm{sid}\left|\right|“\mathrm{MAC}\_\mathrm{A}2\mathrm{B}”\left|\right|32),$

${\mathrm{K}}_{\mathrm{enc}}^{\mathrm{B}\to \mathrm{A}}=\mathrm{KD}{\mathrm{F}}_{\mathrm{SM}3}(\mathrm{S}\left|\right|\mathrm{sid}\left|\right|“\mathrm{ENC}\_\mathrm{B}2\mathrm{A}”\left|\right|16),$

${\mathrm{K}}_{\mathrm{mac}}^{\mathrm{B}\to \mathrm{A}}=\mathrm{KD}{\mathrm{F}}_{\mathrm{SM}3}(\mathrm{S}\left|\right|\mathrm{sid}\left|\right|“\mathrm{MAC}\_\mathrm{B}2\mathrm{A}”\left|\right|32).$

Here, the corresponding value denotes the A-to-B data encryption key ${\mathrm{K}}_{\mathrm{enc}}^{\mathrm{A}\to \mathrm{B}}$ derived from the session root key S. Its derivation input includes the current session identifier $\mathrm{sid}$ and functional direction identifier, ensuring that the key is used only for A-to-B data encryption in the current session. The value 16 in the formula indicates that the derived key output length is 16 bytes, corresponding to the 128-bit key length required by SM4. Similarly, ${\mathrm{K}}_{\mathrm{mac}}^{\mathrm{A}\to \mathrm{B}}$, ${\mathrm{K}}_{\mathrm{enc}}^{\mathrm{B}\to \mathrm{A}}$ and ${\mathrm{K}}_{\mathrm{mac}}^{\mathrm{B}\to \mathrm{A}}$ denote the A-to-B data authentication key, the B-to-A data encryption key, and the B-to-A data authentication key in the current session, thereby separating subkeys across different communication directions and security uses. Based on the above session identifier generation process and subkey derivation relationship, the session binding and subkey expansion process for vehicular bidirectional data communication is summarized in Algorithm 3.

Algorithm 3: Session identifier generation and subkey derivation algorithm

Input: session root key $\mathrm{S}$, identity identifiers $\mathrm{I}{\mathrm{D}}_{\mathrm{A}}$, $\mathrm{I}{\mathrm{D}}_{\mathrm{B}}$, negotiation parameters ${\mathrm{R}}_{\mathrm{A}}$, ${\mathrm{R}}_{\mathrm{B}}$ Output: session identifier $\mathrm{sid}$ and subkeys ${\mathrm{K}}_{\mathrm{enc}}^{\mathrm{A}\to \mathrm{B}},{\mathrm{K}}_{\mathrm{mac}}^{\mathrm{A}\to \mathrm{B}},{\mathrm{K}}_{\mathrm{enc}}^{\mathrm{B}\to \mathrm{A}},{\mathrm{K}}_{\mathrm{mac}}^{\mathrm{B}\to \mathrm{A}}$ 1: Hash the node identity identifiers to avoid directly exposing the original identity information ${\mathrm{h}}_{\mathrm{A}}\leftarrow \mathrm{SM}3(\mathrm{I}{\mathrm{D}}_{\mathrm{A}}),{\mathrm{h}}_{\mathrm{B}}\leftarrow \mathrm{SM}3(\mathrm{I}{\mathrm{D}}_{\mathrm{B}})$. 2: Deterministically encode the negotiation parameters to ensure unique representation ${\mathrm{r}}_{\mathrm{A}}\leftarrow \mathrm{Encode}({\mathrm{R}}_{\mathrm{A}}),{\mathrm{r}}_{\mathrm{B}}\leftarrow \mathrm{Encode}({\mathrm{R}}_{\mathrm{B}})$. 3: Generate the session identifier to ensure session uniqueness $\mathrm{sid}\leftarrow \mathrm{SM}3({\mathrm{h}}_{\mathrm{A}}\left|\right|{\mathrm{h}}_{\mathrm{B}}\left|\right|{\mathrm{r}}_{\mathrm{A}}\left|\right|{\mathrm{r}}_{\mathrm{B}})$. 4: Derive the A-to-B encryption subkey ${\mathrm{K}}_{\mathrm{enc}}^{\mathrm{A}\to \mathrm{B}}\leftarrow \mathrm{KD}{\mathrm{F}}_{\mathrm{SM}3}(\mathrm{S}\left|\right|\mathrm{sid}\left|\right|"\mathrm{EN}{\mathrm{C}}_{\mathrm{A}}2\mathrm{B}"\left|\right|16)$. 5: Derive the A-to-B authentication subkey ${\mathrm{K}}_{\mathrm{mac}}^{\mathrm{A}\to \mathrm{B}}\leftarrow \mathrm{KD}{\mathrm{F}}_{\mathrm{SM}3}(\mathrm{S}\left|\right|\mathrm{sid}\left|\right|"\mathrm{MA}{\mathrm{C}}_{\mathrm{A}2\mathrm{B}}"\left|\right|32)$. 6: Derive the B-to-A encryption subkey ${\mathrm{K}}_{\mathrm{enc}}^{\mathrm{B}\to \mathrm{A}}\leftarrow \mathrm{KD}{\mathrm{F}}_{\mathrm{SM}3}(\mathrm{S}\left|\right|\mathrm{sid}\left|\right|"\mathrm{EN}{\mathrm{C}}_{\mathrm{B}2\mathrm{A}}"\left|\right|16)$. 7: Derive the B-to-A authentication subkey ${\mathrm{K}}_{\mathrm{mac}}^{\mathrm{B}\to \mathrm{A}}\leftarrow \mathrm{KD}{\mathrm{F}}_{\mathrm{SM}3}(\mathrm{S}\left|\right|\mathrm{sid}\left|\right|"\mathrm{MA}{\mathrm{C}}_{\mathrm{B}2\mathrm{A}}"\left|\right|32)$. 8: Return $\mathrm{sid},{ \mathrm{K}}_{\mathrm{enc}}^{\mathrm{A}\to \mathrm{B}},{ \mathrm{K}}_{\mathrm{mac}}^{\mathrm{A}\to \mathrm{B}}, {\mathrm{K}}_{\mathrm{enc}}^{\mathrm{B}\to \mathrm{A}},{ \mathrm{K}}_{\mathrm{mac}}^{\mathrm{B}\to \mathrm{A}}$.

3.6.2. Vehicular Data Encryption Mechanism

After subkey derivation is completed, vehicular data-plane communication adopts an encrypt-then-authenticate structure to provide confidentiality, integrity, source authentication, and replay protection for service and control data. To support the transmission requirements of different data types such as control messages, service messages, and keepalive messages, this paper designs a unified message format for the data-plane protocol data unit (PDU). Its core fields include message type $\mathrm{type}$, session identifier $\mathrm{sid}$, sequence number $\mathrm{seq}$, direction bit $\mathrm{dir}$, plaintext length field $\mathrm{len}$, initialization vector or random number $\mathrm{nonce}$, ciphertext $\mathrm{ciphertex}$, and authentication tag $\mathrm{tag}$.

The sender first constructs the message header:

$\mathrm{header}=(\mathrm{type}\left|\right|\mathrm{sid}\left|\right|\mathrm{seq}\left|\right|\mathrm{dir}\left|\right|\mathrm{len})$

Let the encryption key be ${\mathrm{K}}_{\mathrm{enc}}^{\mathrm{dir}}$ and authentication key be ${\mathrm{K}}_{\mathrm{mac}}^{\mathrm{dir}}$ in the current direction; the sender then calculates

$\mathrm{ciphertext}=\mathrm{Enc}({\mathrm{K}}_{\mathrm{enc}}^{\mathrm{dir}},\mathrm{nonce},\mathrm{plaintext})$

$\mathrm{tag}=\mathrm{HMAC}-\mathrm{SM}{3}_{{\mathrm{K}}_{\mathrm{mac}}^{\mathrm{dir}}}\left(\mathrm{header} \left|\right| \mathrm{nonce} \left|\right| \mathrm{ciphertext}\right)$

The final transmitted data-plane message can be expressed as:

$\mathrm{PDU}=\mathrm{h}\mathrm{eader}\left|\right|\mathrm{nonce}\left|\right|\mathrm{cip}\mathrm{h}\mathrm{ertext}\left|\right|\mathrm{tag}$

This paper adopts SM4-CTR as the data-plane encryption algorithm and HMAC-SM3 as the authentication algorithm. SM4-CTR is convenient for adapting to segmented transmission and arbitrary-length payload protection in CAN/CAN FD scenarios. HMAC-SM3 is used to jointly authenticate the header, random number, and ciphertext, ensuring that the message is not tampered with during transmission and that the legitimacy of the message source can be verified, as shown in Algorithm 4.

Algorithm 4: Vehicular message encryption algorithm

Input: session identifier $\mathrm{sid}$, message type $\mathrm{type}$, sending-direction sequence number $\mathrm{seq}$, direction bit $\mathrm{dir}$, service plaintext $\mathrm{plaintext}$, directional encryption key ${\mathrm{K}}_{\mathrm{enc}}^{\mathrm{dir}}$, directional authentication key ${\mathrm{K}}_{\mathrm{mac}}^{\mathrm{dir}}$, random number/initialization vector $\mathrm{nonce}$ Output: data-plane protocol data unit $\mathrm{PDU}$ 1: Determine the message type $\mathrm{type}$ field according to the current service type and obtain the current session identifier $\mathrm{sid}$. 2: Read and update the sequence number $\mathrm{seq}$ in the current sending direction. 3: Calculate the plaintext length field: $\mathrm{len} \leftarrow |\mathrm{plaintext}|$ 4: Construct the message header: $\mathrm{h}\mathrm{eader}\leftarrow (\mathrm{type}\parallel \mathrm{sid}\parallel \mathrm{seq}\parallel \mathrm{dir}\parallel \mathrm{len})$. 5: Encrypt the service plaintext using the directional encryption key: $\mathrm{cip}\mathrm{h}\mathrm{ertext}\leftarrow \mathrm{SM}4-\mathrm{CTR}\left({\mathrm{K}}_{\mathrm{enc}}^{\mathrm{dir}},\hspace{0.17em}\mathrm{nonce},\hspace{0.17em}\mathrm{plaintext}\right)$. 6: Calculate the authentication tag using the directional authentication key :$\mathrm{tag}\leftarrow \mathrm{HMAC}-\mathrm{SM}{3}_{{\mathrm{K}}_{\mathrm{mac}}^{\mathrm{dir}}}\left(\mathrm{h}\mathrm{eader}\parallel \mathrm{nonce}\parallel \mathrm{cip}\mathrm{h}\mathrm{ertext}\right)$. 7: Concatenate the fields to generate the final data-plane message: $\mathrm{PDU}\leftarrow \mathrm{h}\mathrm{eader}\parallel \mathrm{nonce}\parallel \mathrm{cip}\mathrm{h}\mathrm{ertext}\parallel \mathrm{tag}$.

After receiving a data-plane message, the receiver processes it in the order of verify first, decrypt later. It first checks whether $\mathrm{sid}$ exists and whether the corresponding session is still valid. It then verifies whether $\mathrm{seq}$ satisfies the current policy according to the locally maintained freshness state. After passing the session check and freshness check, it uses the authentication key in the corresponding direction to recalculate the expected authentication tag.

$\mathrm{ta}{\mathrm{g}}^{\text{'}}=\mathrm{HMAC}-\mathrm{SM}{3}_{{\mathrm{K}}_{\mathrm{mac}}^{\mathrm{dir}}}\left(\mathrm{header} \left|\right| \mathrm{nonce} \left|\right| \mathrm{ciphertext}\right)$

It then compares the result with the received tag $\mathrm{tag}$. If $\mathrm{ta}{\mathrm{g}}^{\text{'}}$= $\mathrm{tag}$ is satisfied, the message has not been tampered with during transmission and comes from a legitimate sender holding the correct authentication key. The receiver then decrypts it using the encryption key in the corresponding direction.

$\mathrm{plaintext}=\mathrm{Dec}({\mathrm{K}}_{\mathrm{enc}}^{\mathrm{dir}},\mathrm{nonce},\mathrm{cip}\mathrm{h}\mathrm{ertext})$

The recovered plaintext is then delivered to the upper-layer application for processing, as shown in Algorithm 5.

Algorithm 5: Vehicular message decryption and receiving algorithm

Input: received data-plane protocol data unit $\mathrm{PDU}$, directional encryption key ${\mathrm{K}}_{\mathrm{enc}}^{\mathrm{dir}}$, directional authentication key ${\mathrm{K}}_{\mathrm{mac}}^{\mathrm{dir}}$, local session state table, local sequence-number/freshness state Output: plaintext $\mathrm{plaintext}$ or discarded message 1: Receive the data-plane message $\mathrm{PDU}$ and parse$\mathrm{h}\mathrm{eader}$, $\mathrm{nonce}$, $\mathrm{cip}\mathrm{h}\mathrm{ertext}$ and $\mathrm{tag}$. 2: Extract $\mathrm{type}$, $\mathrm{sid}$, $\mathrm{seq}$, $\mathrm{dir}$ and $\mathrm{len}$ from $\mathrm{h}\mathrm{eader}$. 3: Check whether the session identifier $\mathrm{sid}$ exists and whether the corresponding session is valid. 4: If $\mathrm{sid}$ does not exist or the session has expired, discard the message and terminate. 5: Check whether the current receiving policy is satisfied according to the locally maintained sequence-number/freshness state $\mathrm{seq}$. 6: If $\mathrm{seq}$ is illegal, repeated, or outside the receiving window, discard the message and terminate. 7: Recalculate the expected authentication tag: $\mathrm{ta}{\mathrm{g}}^{\text{'}}\leftarrow \mathrm{HMAC}-\mathrm{SM}{3}_{{\mathrm{K}}_{\mathrm{mac}}^{\mathrm{dir}}}\left(\mathrm{h}\mathrm{eader} \left|\right| \mathrm{nonce} \left|\right| \mathrm{cip}\mathrm{h}\mathrm{ertext}\right)$. 8: Compare $\mathrm{ta}{\mathrm{g}}^{\text{'}}$ with the received $\mathrm{tag}$ for consistency. 9: If $\mathrm{ta}{\mathrm{g}}^{\text{'}}\ne \mathrm{tag}$ holds, discard the message and terminate. 10: If authentication succeeds, perform decryption: $\mathrm{plaintext}\leftarrow \mathrm{SM}4-\mathrm{CT}{\mathrm{R}}^{-1}\left({\mathrm{K}}_{\mathrm{enc}}^{\mathrm{dir}},\hspace{0.17em}\mathrm{nonce},\hspace{0.17em}\mathrm{cip}\mathrm{h}\mathrm{ertext}\right)$. 11: Check whether the decrypted plaintext length is consistent with the expected value $\mathrm{len}$. 12: If the lengths are inconsistent, discard the message and terminate. 13: Update the local sequence-number state and deliver the recovered plaintext $\mathrm{plaintext}$ to the upper-layer application.

In summary, after online session establishment and key confirmation are completed, this section designs a data-plane secure communication mechanism centered on the session root key S. The mechanism first expands S into data-plane subkeys for different directions and uses based on the session identifier $sid$ and usage labels. The sender then encrypts the payload using SM4-CTR and jointly authenticates the header, random number, and ciphertext using HMAC-SM3. The receiver completes message verification and plaintext recovery in the order of verify first, decrypt later.

3.7. T-Box Multi-Session Management and Secure Forwarding

As the unified access node for off-board access to the in-vehicle network, the T-Box must implement request parsing, target ECU locating, access control, session maintenance, and message forwarding in engineering deployment. For off-board access requests, the T-Box first parses the target ECU identifier and service type, and determines whether the request has access permission according to the local access-control policy. If a reusable valid session already exists for the target ECU, the corresponding session parameters are directly invoked for secure forwarding; otherwise, online session establishment and subkey update are triggered again. Thus, secure T-Box access and forwarding can be viewed as a unified process integrating request parsing, permission judgment, session retrieval, state maintenance, and mode-based forwarding.

To support concurrent access to multiple ECUs, the T-Box uses the target ECU identifier $\mathrm{I}{\mathrm{D}}_{\mathrm{B}}$ as an index and maintains the corresponding session context in the session state table ST, namely

$\mathrm{ST}[\mathrm{I}{\mathrm{D}}_{\mathrm{B}}]=(\mathrm{sid},{\mathrm{K}}_{\mathrm{enc}}^{\mathrm{A}\to \mathrm{B}},{\mathrm{K}}_{\mathrm{mac}}^{\mathrm{A}\to \mathrm{B}},{\mathrm{K}}_{\mathrm{enc}}^{\mathrm{B}\to \mathrm{A}},{\mathrm{K}}_{\mathrm{mac}}^{\mathrm{B}\to \mathrm{A}},\mathrm{seq},\mathrm{fres}\mathrm{h},\mathrm{lifetime})$

where $\mathrm{sid}$ denotes the session identifier; ${\mathrm{K}}_{\mathrm{enc}}^{\mathrm{A}\to \mathrm{B}}$, ${\mathrm{K}}_{\mathrm{mac}}^{\mathrm{A}\to \mathrm{B}}$, ${\mathrm{K}}_{\mathrm{enc}}^{\mathrm{B}\to \mathrm{A}}$ and ${\mathrm{K}}_{\mathrm{mac}}^{\mathrm{B}\to \mathrm{A}}$donate bidirectional encryption and authentication subkeys; $\mathrm{seq}$ denotes the sequence-number state; $\mathrm{fres}\mathrm{h}$ denotes the freshness state; and $\mathrm{lifetime}$ denotes the session validity period. This state-maintenance method enables the T-Box to quickly locate the session parameters corresponding to a target ECU and complete session reuse, state update, expiration judgment, and multi-session isolation.

Considering service requirements and system trust boundaries, this paper supports two forwarding modes. GW-Forward denotes gateway decrypt-and-forward mode, in which the T-Box decapsulates, verifies, re-encapsulates, and then forwards service messages. E2E-Forward denotes end-to-end ciphertext forwarding mode, in which the T-Box is only responsible for mapping and forwarding handshake messages and ciphertext messages, without directly decrypting the service payload. The former facilitates unified access control, auditing, and anomaly detection, while the latter helps reduce trust dependence on the T-Box and reduce service plaintext exposure. The specific processing flow can be summarized as request parsing and access-control judgment, session retrieval or reconstruction, forwarding-mode selection, secure message forwarding, and session-state update.

4. Security Verification

4.1. ProVerif Tool and Symbolic Model

ProVerif is an automated verifier for cryptographic protocols expressed in the applied pi calculus [33]. It analyzes secrecy and correspondence properties under the Dolev-Yao attacker model by translating protocol processes into Horn clauses. The verification workflow comprises three steps: protocol and query specification, automatic symbolic analysis over unbounded concurrent sessions, and interpretation of the resulting true, false, or unproved judgments. In this work, ProVerif 2.05 is used to verify the session-establishment and data-plane security properties of the proposed identity-based secure communication scheme.

The public UDP/CAN communication path is modeled as an attacker-controlled channel. The adversary can intercept, modify, delay, replay, delete, and inject arbitrary protocol messages, and can compose any term derivable from its current knowledge. The KGC master secret and the long-term private keys of the honest T-Box A and target ECU B remain confidential. To evaluate multi-session isolation against an unrelated-node compromise, the private key of a third ECU C is explicitly disclosed to the attacker. The cryptographic hash function, key-derivation function, message-authentication mechanism, and symmetric encryption algorithm are modeled as perfect cryptographic primitives. The identity-based authenticated key-agreement operation is abstracted using identity-key extraction, identity-bound ephemeral public values, and an agreement equation stating that A and B derive the same session root key only when their identities, long-term credentials, and fresh ephemeral values are correctly matched.

The four session-establishment messages, M₁, M₂, KC₁, and KC₂, are modeled explicitly. The key-confirmation tags bind ID_A, ID_B, R_A, R_B, and distinct direction labels to the confirmation key. After successful bidirectional confirmation, the model derives the session identifier sid and four direction- and purpose-specific subkeys, namely K_enc-A, K_mac-A, K_enc-B, and K_mac-B. A representative protected PDU in each direction contains the message type, session identifier, sequence number, direction indicator, payload length, nonce, ciphertext, and message-authentication tag. The tag covers the complete header, nonce, and ciphertext. Before delivering the recovered plaintext, the receiver verifies the authentication tag and performs a serialized check-and-insert operation on the (sid, seq, dir) replay state.

4.2. Security-Property Verification

Authentication verification. Mutual authentication and session agreement are expressed as two injective correspondence queries. Q1 requires every T-Box acceptance event to correspond to a unique ECU begin event with the same identities, ephemeral values, and session root key. Q2 requires every ECU acceptance event to correspond to a unique T-Box acceptance event for the same transcript. These queries jointly detect impersonation, replayed handshakes, unknown-key-share behavior, and failure of explicit key confirmation within the symbolic model.

Session-key confidentiality and key-isolation verification. Five private probe values are protected respectively by the session root key and the four derived subkeys. Queries Q3-Q7 ask whether the attacker can recover any probe. Under the perfect-cryptography abstraction, a true non-derivability result means that the corresponding key is not derivable from public parameters, recorded protocol messages, or the compromised key of ECU C. Distinct public KDF labels and sid are included in every derivation term, thereby modeling separation by session, direction, and cryptographic purpose.

Data confidentiality verification. The private service payloads serviceA2B and serviceB2A are encrypted with their corresponding subkeys before being released on the public channel. Q8 and Q9 test whether the attacker can derive either plaintext from the complete network trace.

Integrity and Freshness. Q10 and Q11 use injective correspondences between PDU-receive and PDU-send events. The event arguments include the two identities, sid, seq, and recovered plaintext. Consequently, a successful result requires every accepted PDU to match one unique authentic send event; changes to the header, direction, sequence number, nonce, ciphertext, or tag cannot lead to acceptance, and the same authenticated (sid, seq, dir) tuple cannot be accepted twice in the modeled receive state.

Verification results. The complete model was executed with ProVerif 2.05,we will get the results shown in Fig. 3.The results Q1 and Q2 are true, establishing injective mutual authentication and agreement on the session transcript and root key. Q3-Q7 are true, showing non-derivability of the session root key and all four direction/purpose subkeys, even when the long-term private key of unrelated ECU C is disclosed. Q8 and Q9 are true, confirming bidirectional service-data confidentiality. Q10 and Q11 are also true, establishing integrity, source authentication, and one-time acceptance of the modeled sequence-numbered PDU. Therefore, all eleven queries are satisfied under the stated symbolic assumptions.

Figure 3. Verification results.

Figure 3. Verification results.

5. Simulation Testing and Performance Evaluation

This section uses a multi-node software simulation platform to verify correct handshake establishment, key confirmation, and data protection, and to evaluate session establishment, data-plane processing, communication overhead, multi-ECU scalability, resource consumption, and security-mechanism effectiveness. The platform represents the intended deployment roles while keeping the measured scope explicit.

5.1. Experimental Environment and Evaluation Metrics

A multi-node software simulation platform was developed to evaluate the proposed identity-based secure communication scheme for in-vehicle networks. The T-Box, gateway, and ECU nodes were implemented as independent software processes communicating through UDP sockets. Fig. 4 illustrates the corresponding deployment roles and multi-ECU configuration. Unless otherwise specified, all reported latency results were obtained from host-side software measurements on this platform and therefore exclude physical CAN transmission, arbitration, controller queuing, and hardware-acceleration effects.

Figure 4. Supporting experimental setup and multi-ECU node arrangement.

Figure 4. Supporting experimental setup and multi-ECU node arrangement.

The evaluation focused on session-establishment performance, data-plane processing latency, communication overhead, multi-ECU scalability, and security effectiveness. Session establishment was evaluated using end-to-end UDP completion time and the execution time of the principal cryptographic operations. For the data-plane evaluation, 30 independent sessions were established, and 240 fixed-length 8-byte application messages were processed under each parameter configuration. Scalability was evaluated for configurations containing 1, 4, 8, 12, and 18 ECUs, with three independent runs conducted for each configuration. Communication overhead was analytically estimated using a 500-kbit/s classical CAN model, excluding arbitration delay, dynamic bit stuffing, retransmissions, and transport-layer headers. Security effectiveness was evaluated using 12 frame-mutation attack classes and six packet-loss scenarios. The recorded metrics included rejection rate, receiver-side processing latency, plaintext-release events, loss-detection rate, and authenticated resynchronization performance.

5.2. Session Establishment Performance Evaluation

Session-establishment performance was evaluated using single-ECU handshake latency and multi-ECU scalability. In the single-ECU experiment, a persistent T-Box process communicated with a persistent ECU process over UDP. Following a warm-up phase, 30 handshake trials were conducted, all of which completed successfully. As shown in Table 2, the median end-to-end T-Box completion time was 287.560 ms, the P95 latency was 292.545 ms, and the handshake success rate was 100%. The measured T-Box-side processing components included 32.509 ms for ephemeral-parameter generation, 201.473 ms for SM9 session-key computation, 5.619 ms for subkey derivation, and 7.494 ms for bidirectional key-confirmation generation and verification. The remaining latency was attributable to message serialization, process scheduling, UDP communication, and other protocol-processing operations. Among the measured cryptographic components, SM9 session-key computation accounted for the largest proportion of the session-establishment latency.

Multi-ECU scalability was further evaluated by sequentially establishing secure sessions between a single T-Box and 1, 4, 8, 12, and 18 ECUs. Three independent runs were conducted for each configuration. As summarized in Table 3, the total authentication time increased approximately in proportion to the number of ECUs over the tested range, whereas the normalized authentication time remained relatively stable at approximately 475–500 ms per ECU. In the 18-ECU configuration, the median offline key-generation time was 405.416 ms, and the median sequential session-establishment time was 8551.829 ms, corresponding to an average of 475.102 ms per ECU. These results indicate that the proposed implementation exhibits predictable scalability under sequential multi-ECU session establishment.

The results indicate that SM9 session-key computation was the primary contributor to session-establishment latency. Both the single-ECU test and the sequential multi-ECU tests achieved a 100% session-establishment success rate, while the total authentication time increased approximately linearly with the number of ECUs. In an embedded deployment, hardware acceleration, pairing precomputation, and parallel session scheduling may reduce the initial connection latency.

5.3. Data-Plane Processing Performance

Data-plane performance was evaluated by varying the authentication batch size k and transmitted tag length t for a fixed 8-byte application payload. For each configuration listed in Table 4, 30 independent SM9 sessions were established, and 240 messages were processed within each session. To reduce potential ordering bias, the configuration sequence was randomized within each session using the fixed seed 20260720. The reported host-side processing times include cryptographic computation, message serialization, and protocol processing, but exclude physical CAN transmission, arbitration, controller queuing, and operating-system socket latency.

For the configuration of k=8 and t=128, the median sender-side and receiver-side processing times were 0.521 and 0.516 ms/message, respectively, yielding a combined median of 1.036 ms/message and a P95 latency of 1.074 ms/message. Increasing the batch size from k=1 to k=8 reduced the combined median processing time from 3.108 to approximately 1.038 ms/message by amortizing the costs of HMAC generation, verification, message serialization, and related protocol processing across multiple messages. When k=8, increasing the tag length from 64 to 128 bits changed the combined median only from 1.038 to 1.036 ms/message under the current host-side test conditions, while increasing the average frame cost from 1.125 to 1.250 frames/message. Considering the trade-off between processing latency, communication overhead, and authentication strength, the k=8, t=128 configuration was selected for the subsequent evaluation.

Figure 5. Data-plane performance under batch-size and tag-length ablations.

Figure 5. Data-plane performance under batch-size and tag-length ablations.

5.4. Communication Overhead and Bus Load Analysis

In the full-batch configuration, eight DLC-8 data frames carry eight independently encrypted 8-byte application messages, while two additional DLC-8 frames carry the 128-bit HMAC-SM3 authentication tag. A complete batch therefore comprises ten CAN frames with a total payload of 80 bytes, corresponding to an average of 10 bytes and 1.25 frames per application message. Routing information and frame type are encoded in preconfigured CAN identifiers, whereas a receiver-maintained batch sequence number provides freshness protection. Both the identifier-related information and the sequence number are incorporated into the authenticated context. For a partial batch containing mmm application messages, the sender transmits mmm data frames and two authentication frames. Consequently, under the unstuffed classical-CAN frame model, the amortized communication cost decreases from 333 bits/message for m=1 to 138.75 bits/message for m=8.

Figure 6. Classical-CAN bus-load comparison.

Figure 6. Classical-CAN bus-load comparison.

Table 5. Cross-scheme communication cost under the common 8-B model.

Scheme / Profile	Bits/ Message	Frames/ Message	1 ECU	4 ECUs	18 ECUs	Evidence / Condition
No-security CAN baseline	111.00	1.00	2.220%	8.88%	39.96%	Common baseline
WSP [28]	131.00	1.00	2.620%	10.48%	47.16%	Literature lower bound
LEAP [32]	174.00	2.00	3.480%	13.92%	62.64%	Unified 8-B projection
EAS [29]	205.00	3.00	4.100%	16.40%	73.80%	Literature lower bound
MAuth-CAN [30]	222.00	2.00	4.440%	17.76%	79.92%	Bounded projection
Sensors 2025[34]	166.00	1.50	3.320%	13.32%	59.94%	Data-dependent bound
ours	138.75	1.25	2.775%	11.10%	49.95%	Repository deterministic mapping

Table 5. Cross-scheme communication cost under the common 8-B model.

Scheme / Profile	Bits/ Message	Frames/ Message	1 ECU	4 ECUs	18 ECUs	Evidence / Condition
No-security CAN baseline	111.00	1.00	2.220%	8.88%	39.96%	Common baseline
WSP [28]	131.00	1.00	2.620%	10.48%	47.16%	Literature lower bound
LEAP [32]	174.00	2.00	3.480%	13.92%	62.64%	Unified 8-B projection
EAS [29]	205.00	3.00	4.100%	16.40%	73.80%	Literature lower bound
MAuth-CAN [30]	222.00	2.00	4.440%	17.76%	79.92%	Bounded projection
Sensors 2025[34]	166.00	1.50	3.320%	13.32%	59.94%	Data-dependent bound
ours	138.75	1.25	2.775%	11.10%	49.95%	Repository deterministic mapping

For the 18-ECU configuration, the proposed profile yields a modeled bus load of 49.95%. This value is slightly higher than the 47.16% lower-bound estimate reported for WSP, mainly because the proposed mapping preserves the standard controller-managed identifier and CRC fields and uses a 128-bit authentication tag rather than a 32-bit tag. Nevertheless, under the same unified traffic model, the proposed profile results in a lower modeled bus load than LEAP (62.64%), EAS (73.80%), MAuth-CAN (79.92%), and the Sensors 2025 scheme (59.94%). EC-SVC is not included in this comparison because it is designed for CAN FD and relies on an edge-based security agent [25].

Figure 7. Unified modeled bus-load comparison for 1-18 ECUs.

Figure 7. Unified modeled bus-load comparison for 1-18 ECUs.

5.5. Lifecycle Time Decomposition and Qualified Cross-Scheme Comparison

To make the measurement boundary explicit, the lifecycle cost is decomposed into offline key generation, online authentication, and established-session data processing. T_KG includes KGC setup and extraction of the identity keys for the T-Box and target ECU. T_AUTH includes both ephemeral generations, both SM9 session-key computations, directional KDF operations, bidirectional key-confirmation generation and verification, and auxiliary serialization. For the 8-B data plane, T_S,opt and T_R,opt denote sender protection and receiver verification/decryption, respectively.

$T_{\mathrm{t}\mathrm{o}\mathrm{t}\mathrm{a}\mathrm{l},\mathrm{c}\mathrm{o}\mathrm{l}\mathrm{d}}^{\mathrm{r}\mathrm{e}\mathrm{f}}=T_{\mathrm{K}\mathrm{G}}+T_{\mathrm{A}\mathrm{U}\mathrm{T}\mathrm{H}}+T_{\mathrm{S},\mathrm{o}\mathrm{p}\mathrm{t}}+T_{\mathrm{R},\mathrm{o}\mathrm{p}\mathrm{t}}$

$T_{\mathrm{K}\mathrm{G}}=T_{\mathrm{s}\mathrm{e}\mathrm{t}\mathrm{u}\mathrm{p}}+T_{\mathrm{e}\mathrm{x}\mathrm{t},\mathrm{T}}+T_{\mathrm{e}\mathrm{x}\mathrm{t},\mathrm{E}}$

$T_{\mathrm{A}\mathrm{U}\mathrm{T}\mathrm{H}}=T_{\mathrm{R}}+T_{\mathrm{K}\mathrm{A}}+T_{\mathrm{K}\mathrm{D}\mathrm{F}}+T_{\mathrm{K}\mathrm{C}}+T_{\mathrm{a}\mathrm{u}\mathrm{x}}$

$T_{\mathrm{D}\mathrm{A}\mathrm{T}\mathrm{A},\mathrm{o}\mathrm{p}\mathrm{t}}=T_{\mathrm{S},\mathrm{o}\mathrm{p}\mathrm{t}}+T_{\mathrm{R},\mathrm{o}\mathrm{p}\mathrm{t}}$

Table 6. Lifecycle time decomposition and measurement boundaries.

Boundary	Symbol / Formula	Median (ms)	Payload/Scale	Measurement Boundary
Offline key generation	TKG	204.851	T-Box + 1 ECU	10-run host lifecycle
Online authentication	TAUTH	475.163	1 ECU	Both endpoints, sequential
sender	TS,opt	0.521	8 B	30 independent blocks
receiver	TR,opt	0.516	8 B	30 independent blocks
data total	TDATA,opt	1.036	8 B	Paired per-block median
cold reference	TKG+TAUTH+TS,opt+TR,opt	681.050	mixed runs	Component reference; not wall time
online reference	TAUTH+TS,opt+TR,opt	476.199	mixed runs	Component reference; not wall time

Table 6. Lifecycle time decomposition and measurement boundaries.

Boundary	Symbol / Formula	Median (ms)	Payload/Scale	Measurement Boundary
Offline key generation	TKG	204.851	T-Box + 1 ECU	10-run host lifecycle
Online authentication	TAUTH	475.163	1 ECU	Both endpoints, sequential
sender	TS,opt	0.521	8 B	30 independent blocks
receiver	TR,opt	0.516	8 B	30 independent blocks
data total	TDATA,opt	1.036	8 B	Paired per-block median
cold reference	TKG+TAUTH+TS,opt+TR,opt	681.050	mixed runs	Component reference; not wall time
online reference	TAUTH+TS,opt+TR,opt	476.199	mixed runs	Component reference; not wall time

The 681.050-ms cold-reference value and the 476.199-ms online-reference value are arithmetic combinations of marginal medians from two separate experiments: the lifecycle benchmark and the compact 8-B data-plane benchmark. The data-plane total, by contrast, is calculated from paired sender-plus-receiver values within each block, yielding a directly measured median of T_DATA,opt=1.036 ms/message.

Table 7. Timing formulas and qualified reference points for related in-vehicle schemes.

Scheme	Key Generation / Update	Authentication	Data Processing	Platform / Payload	Boundary Qualification
ours	TKG=204.851 ms	TAUTH=475.163 ms	1.036 ms/8 B	Windows/Python host	sequential SM9; no bus time
Lightweight CAN [26]	41.630 ms generation; 2TM+Tv=0.24 ms update	4TM=0.45 ms	<378 µs at 80 MHz (original test)	Raspberry Pi 3B	32-bit tag; separate values
WSP [28]	4TM+2TA=20.45 ms	2TM+2TA=20.22 ms	<378 us at 80 MHz in original test	protocol-specific hardware	formula/hardware rows differ
EAS [29]	4TM=0.45 ms	4TM+2TA=20.45 ms	authentication only	harmonized operation cost	two RTR frames
MAuth-CAN [30]	not reported	3TM+Tw=0.34 ms+Tw	authentication only	CAN prototype	Tw unresolved
LEAP [32]	199.4 ms total update	merged with data path	1.998 ms/CAN message	ATmega328, 16 MHz	RC4; 11-bit embedded ID
EC-SVC [25]	424 ms at 16 ECUs	access-control/key phase	0.753 ms/48 B sharing	TMS320 + edge, CAN FD	includes communication in sharing
Sensors 2025 [34]	DBK 1.144/0.0858 ms	merged security module	0.85/0.064 ms	30/400 MHz	compression dependent

Table 7. Timing formulas and qualified reference points for related in-vehicle schemes.

Scheme	Key Generation / Update	Authentication	Data Processing	Platform / Payload	Boundary Qualification
ours	TKG=204.851 ms	TAUTH=475.163 ms	1.036 ms/8 B	Windows/Python host	sequential SM9; no bus time
Lightweight CAN [26]	41.630 ms generation; 2TM+Tv=0.24 ms update	4TM=0.45 ms	<378 µs at 80 MHz (original test)	Raspberry Pi 3B	32-bit tag; separate values
WSP [28]	4TM+2TA=20.45 ms	2TM+2TA=20.22 ms	<378 us at 80 MHz in original test	protocol-specific hardware	formula/hardware rows differ
EAS [29]	4TM=0.45 ms	4TM+2TA=20.45 ms	authentication only	harmonized operation cost	two RTR frames
MAuth-CAN [30]	not reported	3TM+Tw=0.34 ms+Tw	authentication only	CAN prototype	Tw unresolved
LEAP [32]	199.4 ms total update	merged with data path	1.998 ms/CAN message	ATmega328, 16 MHz	RC4; 11-bit embedded ID
EC-SVC [25]	424 ms at 16 ECUs	access-control/key phase	0.753 ms/48 B sharing	TMS320 + edge, CAN FD	includes communication in sharing
Sensors 2025 [34]	DBK 1.144/0.0858 ms	merged security module	0.85/0.064 ms	30/400 MHz	compression dependent

Figure 8. scheme time decomposition and cross-scheme timing references.

Figure 8. scheme time decomposition and cross-scheme timing references.

5.6. Attack-Frame Mutation, Rejection, and Authenticated Resynchronization

The attack experiment applies controlled mutations to the same compact frames used during normal traffic. For each case, the test harness records the trial identifier, independent session block, representative frame mutation, receiver rejection reason, processing latency, and number of plaintext messages released. Each of the 12 attack classes is repeated 100 times. A timeout or explicit state violation is counted as a rejection only when no unauthenticated plaintext is delivered.

Table 8. Receiver outcomes for 12 representative frame-mutation attacks.

Attack Class	Representative Mutation	Rejected	Rejection Rate	Median / P95 (ms)	Plaintext-Release Trials
Ciphertext bit flip	D4 byte 1 XOR 0x01	100/100	100.0%	1.4184/1.5282	0
Authentication fragment 1 bit flip	A1 byte 1 XOR 0x80	100/100	100.0%	1.4120/1.4970	0
Authentication fragment 2 bit flip	A2 byte 8 XOR 0x01	100/100	100.0%	1.4228/1.5076	0
Zero-tag forgery	A1=A2=0x00...00	100/100	100.0%	1.4042/1.4759	0
Data-frame deletion	Delete D5	100/100	100.0%	1.1837/1.2433	0
Data-frame insertion	Duplicate D6 before D6	100/100	100.0%	0.0037/0.0060	0
Data-frame reordering	Swap D2 and D7	100/100	100.0%	1.4190/1.4900	0
Full-batch replay	Replay accepted D1-D8, A1, A2	100/100	100.0%	1.4174/1.4692	0
Unknown CAN identifier	D1 ID: 321 -> 400	100/100	100.0%	0.0021/0.0039	0
Data/authentication identifier confusion	D3 ID: 321 -> 322	100/100	100.0%	0.0030/0.0051	0
Authentication-fragment truncation	Delete A2; detect at timeout	100/100	100.0%	0.0032/0.0044	0
Tag-profile downgrade	128-bit sender parsed as 64-bit profile	100/100	100.0%	1.4387/1.5006	0

Table 8. Receiver outcomes for 12 representative frame-mutation attacks.

Attack Class	Representative Mutation	Rejected	Rejection Rate	Median / P95 (ms)	Plaintext-Release Trials
Ciphertext bit flip	D4 byte 1 XOR 0x01	100/100	100.0%	1.4184/1.5282	0
Authentication fragment 1 bit flip	A1 byte 1 XOR 0x80	100/100	100.0%	1.4120/1.4970	0
Authentication fragment 2 bit flip	A2 byte 8 XOR 0x01	100/100	100.0%	1.4228/1.5076	0
Zero-tag forgery	A1=A2=0x00...00	100/100	100.0%	1.4042/1.4759	0
Data-frame deletion	Delete D5	100/100	100.0%	1.1837/1.2433	0
Data-frame insertion	Duplicate D6 before D6	100/100	100.0%	0.0037/0.0060	0
Data-frame reordering	Swap D2 and D7	100/100	100.0%	1.4190/1.4900	0
Full-batch replay	Replay accepted D1-D8, A1, A2	100/100	100.0%	1.4174/1.4692	0
Unknown CAN identifier	D1 ID: 321 -> 400	100/100	100.0%	0.0021/0.0039	0
Data/authentication identifier confusion	D3 ID: 321 -> 322	100/100	100.0%	0.0030/0.0051	0
Authentication-fragment truncation	Delete A2; detect at timeout	100/100	100.0%	0.0032/0.0044	0
Tag-profile downgrade	128-bit sender parsed as 64-bit profile	100/100	100.0%	1.4387/1.5006	0

All 1200 mutated-frame trials were rejected, and no attacked batch released plaintext. Ciphertext, tag, ordering, and replay mutations failed authentication; inserted frames and data/authentication identifier confusion were rejected by the batch state machine; unknown identifiers failed route lookup; truncated authentication fragments were detected at timeout; and a 64-bit receiver interpretation of a 128-bit sender profile failed because the tag length is included in the authenticated context. These finite tests validate the implemented rejection paths but do not constitute a formal proof or demonstrate availability under sustained flooding.

Table 9. Loss detection and authenticated counter resynchronization.

Loss Scenario	Trials	Detection Rate	Damaged Plaintext Released	Recovery Rate	Recovery Frames / bits	Median / P95 (ms)
Loss of D1	30	100.0%	0	100.0%	3 / 333	2.3270/2.4778
Loss of D4	30	100.0%	0	100.0%	3 / 333	2.3685/2.4583
Loss of D8	30	100.0%	0	100.0%	3 / 333	2.3697/2.4609
Loss of A1	30	100.0%	0	100.0%	3 / 333	2.4057/2.4710
Loss of A2	30	100.0%	0	100.0%	3 / 333	2.3663/2.4654
Loss of two data frames	30	100.0%	0	100.0%	3 / 333	2.3640/2.4331

Table 9. Loss detection and authenticated counter resynchronization.

Loss Scenario	Trials	Detection Rate	Damaged Plaintext Released	Recovery Rate	Recovery Frames / bits	Median / P95 (ms)
Loss of D1	30	100.0%	0	100.0%	3 / 333	2.3270/2.4778
Loss of D4	30	100.0%	0	100.0%	3 / 333	2.3685/2.4583
Loss of D8	30	100.0%	0	100.0%	3 / 333	2.3697/2.4609
Loss of A1	30	100.0%	0	100.0%	3 / 333	2.4057/2.4710
Loss of A2	30	100.0%	0	100.0%	3 / 333	2.3663/2.4654
Loss of two data frames	30	100.0%	0	100.0%	3 / 333	2.3640/2.4331

For the loss of D1, D4, D8, A1, A2, or two data frames, every damaged batch was detected without plaintext release. In all 30 trials per scenario, the next complete batch was accepted after authenticated resynchronization. Recovery requires three frames, corresponding to a 333-bit unstuffed lower bound, and the measured host-processing median ranges from 2.327 to 2.406 ms. This exceptional control traffic is excluded from the steady-state 2.775% per-ECU load estimate.

5.7. Cross-Scheme Trade-Offs and Security Boundaries

No evaluated scheme is superior across all communication, computation, and security dimensions. Under the common 8-B classical-CAN model, our profile requires 138.75 bit/message and produces 49.95% offered load at 18 ECUs. This is 5.92% more wire traffic than the 131-bit/message WSP lower bound, but 20.26%, 32.32%, and up to 37.50% less than the aligned LEAP, EAS, and MAuth-CAN reference mappings, respectively [24,26,27,28,29,30,32]. The proposed result also lies within the compression-dependent Sensors 2025 range [34].

Table 10. Qualified peer comparison of the proposed compact data plane.

Dimension	Proposed Profile	Peer Reference	Relative Result	Qualification
Wire cost (8-B message)	138.75 bits	WSP: 131 bits	5.92% higher	128-bit batch tag; standard CAN fields
Wire cost (8-B message)	138.75 bits	LEAP: 174 bits	20.26% lower	Unified 8-B projection
Wire cost (8-B message)	138.75 bits	EAS: 205 bits	32.32% lower	Authentication-only lower bound
Wire cost (8-B message)	138.75 bits	MAuth-CAN: 158-222 bits	12.18-37.50% lower	Trigger DLC is implementation dependent
18-ECU bus load	49.95%	Sensors 2025: 39.96-79.92%	Within range	Compression-dependent bound
Data-plane host time	1.036 ms/8 B	EC-SVC 0.753 ms/48 B; LEAP 1.998 ms/message	Not ranked	Hardware, payload, bus, and timing boundaries differ
Authentication strength	128-bit tag per 8-message batch	WSP: 32-bit tag	Longer tag; coarser granularity	Up to about 80-ms batch window at 100 Hz
Loss recovery	3 authenticated frames; 333-bit lower bound	No aligned peer result	Not ranked	Exceptional path; 0.666-ms wire-time lower bound
Classical-CAN compatibility	Standard IDs, CRC, and DLC8 payloads	WSP field repurposing	Controller-compatible mapping	Physical-controller validation pending

Table 10. Qualified peer comparison of the proposed compact data plane.

Dimension	Proposed Profile	Peer Reference	Relative Result	Qualification
Wire cost (8-B message)	138.75 bits	WSP: 131 bits	5.92% higher	128-bit batch tag; standard CAN fields
Wire cost (8-B message)	138.75 bits	LEAP: 174 bits	20.26% lower	Unified 8-B projection
Wire cost (8-B message)	138.75 bits	EAS: 205 bits	32.32% lower	Authentication-only lower bound
Wire cost (8-B message)	138.75 bits	MAuth-CAN: 158-222 bits	12.18-37.50% lower	Trigger DLC is implementation dependent
18-ECU bus load	49.95%	Sensors 2025: 39.96-79.92%	Within range	Compression-dependent bound
Data-plane host time	1.036 ms/8 B	EC-SVC 0.753 ms/48 B; LEAP 1.998 ms/message	Not ranked	Hardware, payload, bus, and timing boundaries differ
Authentication strength	128-bit tag per 8-message batch	WSP: 32-bit tag	Longer tag; coarser granularity	Up to about 80-ms batch window at 100 Hz
Loss recovery	3 authenticated frames; 333-bit lower bound	No aligned peer result	Not ranked	Exceptional path; 0.666-ms wire-time lower bound
Classical-CAN compatibility	Standard IDs, CRC, and DLC8 payloads	WSP field repurposing	Controller-compatible mapping	Physical-controller validation pending

The measured data-plane median of the proposed implementation is 1.036 ms per 8-B message on the Windows host. Published values such as 0.064 ms for Sensors 2025 at 400 MHz, 0.753 ms for EC-SVC with a 48-B CAN-FD payload, 1.998 ms/message for LEAP on a 16-MHz ATmega328, and 5.153 ms for the Lightweight CAN encryption reference use different processors, payloads, algorithms, and timing boundaries [25,26,32]. They provide engineering context but do not support a platform-independent speed ranking. Within the present implementation, T_AUTH=475.163 ms dominates the established-session data path, whereas the offline T_KG=204.851 ms cost can be amortized over the key lifetime.

Our profile provides confidentiality, identity-bound session establishment, directional key separation, integrity and replay protection, route and policy binding, standard CAN-frame compatibility, and verify-before-release processing. These properties are obtained at the cost of batch authentication: one 128-bit tag covers eight messages, and at 100 Hz the earliest message may wait up to approximately 80 ms for batch completion. Frame loss may also trigger a three-frame authenticated resynchronization. The profile is therefore appropriate for cyclic status, monitoring, and diagnostic traffic that tolerates aggregation; hard-real-time braking, steering, or restraint-control traffic should use a shorter batch, per-message authentication, or CAN FD. Sustained denial-of-service, arbitration monopolization, and bus-off behavior remain outside the present evaluation.

Table 11. Security functions and deployment boundaries.

Scheme	Confidentiality	Integrity / Replay	Route / Access	CAN Mapping	DoS / Bus-Off	Main Limitation
ours	Yes	Yes/tested	Tested/policy binding	Standard	Limited/not tested	batch delay, tag truncation, resynchronization
WSP [28]	Yes	Yes/yes	Threat-model limited/no	CRC/extended-ID repurposing	Not central/no	tested controller could not modify those fields
Lightweight CAN [26]	Yes	Yes/yes	Yes/no	CRC/extended-ID repurposing	Not central/no	32-bit tag and nonstandard field use
EAS [29]	No	Yes/yes	Yes/no	RTR-dependent	Not central/no	authentication-only and extra RTR traffic
MAuth-CAN [30]	No	Yes/yes	Yes/no	Standard controller	Partial/yes	authentication-only; trigger/wait overhead
LEAP [32]	Yes	Embedded ID/tested	Tested/pairwise	Application repacking	Tested/no	RC4 design and only 11 identity bits
EC-SVC [25]	Yes	Yes/yes	Access policy/yes	CAN-FD	Not central/no	edge dependency and expensive access-control setup
Sensors 2025[34]	Tested	Tested/tested	Brute-force test/no	Compression dependent	Tested/no	load advantage depends on trace compressibility

Table 11. Security functions and deployment boundaries.

Scheme	Confidentiality	Integrity / Replay	Route / Access	CAN Mapping	DoS / Bus-Off	Main Limitation
ours	Yes	Yes/tested	Tested/policy binding	Standard	Limited/not tested	batch delay, tag truncation, resynchronization
WSP [28]	Yes	Yes/yes	Threat-model limited/no	CRC/extended-ID repurposing	Not central/no	tested controller could not modify those fields
Lightweight CAN [26]	Yes	Yes/yes	Yes/no	CRC/extended-ID repurposing	Not central/no	32-bit tag and nonstandard field use
EAS [29]	No	Yes/yes	Yes/no	RTR-dependent	Not central/no	authentication-only and extra RTR traffic
MAuth-CAN [30]	No	Yes/yes	Yes/no	Standard controller	Partial/yes	authentication-only; trigger/wait overhead
LEAP [32]	Yes	Embedded ID/tested	Tested/pairwise	Application repacking	Tested/no	RC4 design and only 11 identity bits
EC-SVC [25]	Yes	Yes/yes	Access policy/yes	CAN-FD	Not central/no	edge dependency and expensive access-control setup
Sensors 2025[34]	Tested	Tested/tested	Brute-force test/no	Compression dependent	Tested/no	load advantage depends on trace compressibility

Figure 9. Sensitivity of the proposed profile to ECU count and per-ECU message rate: (a) baseline and WSP comparison; (b) load over the tested operating grid.

Figure 9. Sensitivity of the proposed profile to ECU count and per-ECU message rate: (a) baseline and WSP comparison; (b) load over the tested operating grid.

6. Conclusions

This paper proposes a lightweight identity-based secure communication scheme for resource-constrained in-vehicle networks. By combining SM9-based offline private-key provisioning with authenticated session-key agreement, the scheme eliminates certificate management and confines computationally intensive identity-based operations to the low-frequency session-establishment phase. After explicit bidirectional key confirmation, the session root key is expanded into direction- and purpose-specific subkeys, while SM4-CTR and HMAC-SM3 provide confidentiality, integrity, source authentication, and replay protection for high-frequency data transmission.

To support off-board access to multiple in-vehicle nodes, the T-Box maintains an independent security context for each target ECU and supports both gateway decrypt-and-forward and end-to-end ciphertext-forwarding modes. This design enables session isolation, session reuse, access-control enforcement, and flexible secure forwarding. The ProVerif model satisfies all 11 verification queries for mutual authentication, session-key confidentiality and isolation, bidirectional data confidentiality, integrity, and freshness, including the modeled compromise of an unrelated ECU private key.

Evaluation on the multi-node software simulation platform gives a median T-Box–ECU handshake time of 287.560 ms for a single ECU, with a P95 latency of 292.545 ms and no handshake failures observed in the test runs. A breakdown of the latency shows that most of the handshake time is spent on SM9 shared-key computation. As the number of ECUs increases, the total time required for sequential session establishment grows nearly linearly. Across the tested multi-ECU configurations, the corresponding normalized authentication time remains approximately 475-500 ms per ECU.With k=8 and t=128, the median processing time for an 8-B data message is 1.036 ms, and the P95 latency is 1.074 ms. For a 500-kbit/s classical CAN bus, each protected message occupies 138.75 bits under the adopted traffic model. At 18 ECUs, this corresponds to a modeled bus load of 49.95%. In the robustness tests, all 1200 mutated frames were rejected, and none resulted in plaintext release. Every tested frame-loss case was also detected, with communication subsequently restored through authenticated resynchronization.

These results demonstrate that the proposed scheme separates strong identity-based authentication from lightweight routine message protection while preserving multi-session security and standard CAN-frame compatibility. However, the current results are host-side software measurements, and the bus-load values are analytical estimates that exclude physical arbitration, dynamic bit stuffing, controller queuing, hardware acceleration, sustained denial-of-service, and bus-off behavior. Future work will implement the scheme on embedded T-Box and ECU hardware over real CAN/CAN FD networks, optimize SM9 operations through precomputation or hardware support, and investigate adaptive authentication batching and real-time schedulability under representative vehicular traffic.