Enhancing Communication Security in Automotive Software: A Hybrid SecOC and MACsec Integration for SOME/IP over Ethernet

Featured Application

This hybrid SecOC + MACsec architecture is aimed at ADAS, infotainment, and telematics ECUs on the AUTOSAR Adaptive Platform that must secure multicast SOME/IP traffic within a soft real-time latency budget.

Abstract

Automotive Ethernet networks increasingly rely on SOME/IP within the AUTOSAR Adaptive Platform for service-oriented ECU communication, yet SOME/IP lacks built-in security, exposing systems to Man-in-the-Middle (MitM), replay, spoofing, and eavesdropping attacks. As of AUTOSAR Release R22-11, no standardised security profile addresses both authenticity and confidentiality for multicast SOME/IP traffic. This paper proposes a hybrid security architecture combining SecOC (CMAC-AES256, instantiated as a vendor-defined security profile) applied to the SOME/IP application Protocol Data Unit (above OSI Layer 4) with IEEE 802.1AE MACsec at the data link layer (Layer 2): SecOC provides end-to-end message authentication and replay protection, while MACsec adds hop-by-hop confidentiality and integrity, which coincides with end-to-end confidentiality only on a single-hop path. The SecOC and MACsec protocol constructions themselves are not modified; only SecOC’s parameter profile deviates from the three predefined profiles. The architecture is evaluated across ten sub-scenarios (five configurations, each tested under unicast and multicast communication; 500 iterations recorded per sub-scenario). For the Hybrid-PSK multicast configuration (Scenario 3a-B), steady-state end-to-end latency adds $27.8$ ms ($33.89$ ms versus the $6.12$ ms unsecured-multicast baseline, Scenario 1-B; both figures are measured on the identical two-VM topology using the same half-round-trip method); the worst-case measured 99th percentile of this absolute latency, across all hybrid configurations, is $40.99$ ms (Hybrid-RSA multicast, Scenario 3b-B). Of the added overhead, MACsec contributes 11.5% ($3.18$ ms), isolated by re-running the SecOC-only scenarios on the same two-VM topology used for the hybrid scenarios, and one-time RSA-2048 session establishment adds $25.2$ ms to $33.8$ ms at startup. Cross-referencing the SecOC path cost against CPU utilisation indicates that most of it is user-space integration overhead rather than cipher execution, a split not isolated by direct microbenchmark. The reported MACsec figure remains an upper bound in one respect: it reflects the Linux kernel software MACsec driver rather than a PHY-offloaded implementation. At this single quiet operating point (64-byte payload, approximately 20 messages/s, two receivers, no background load), the measured worst-case p99 leaves an approximate 9 ms margin against an assumed 50 ms soft real-time budget for ADAS and infotainment messaging; whether this margin survives realistic ECU loading, larger receiver groups, and production-stack constant factors was not evaluated. This margin is also bound to the present, unoptimised software path: because most of the SecOC path cost is user-space integration overhead rather than cipher execution, removing it is projected to widen the margin substantially, so the reported headroom characterises this prototype rather than a ceiling on the architecture.

1. Introduction

Modern network architectures require both fast and secure data transfer. In complex systems, communication protocols must not only transmit data efficiently but also preserve its integrity and confidentiality throughout the transmission path.

1.1. Communication Paradigms in Connected Systems

Modern automotive networks employ two primary transmission models: unicast (one-to-one, for point-to-point control) and multicast (one-to-many, for distributing sensor readings and coordinated control instructions), both needed for timely, secure data exchange between ECUs.

1.2. Evolution of Automotive Communication Networks

Automotive networks have evolved from point-to-point wiring through the standardised Controller Area Network (CAN) [1] and deterministic FlexRay [2] to automotive Ethernet, which delivers 100 Mbps to 10 Gbps to support Advanced Driver-Assistance Systems (ADASs), autonomous driving, multimedia streaming, and Vehicle-to-Everything (V2X) communication in next-generation vehicles [3,4].

1.3. Service-Oriented Architecture and SOME/IP

The adoption of Ethernet in automotive networks supports the transition toward Service-Oriented Architecture (SOA), where software functionalities are exposed through well-defined service interfaces rather than signal-based communication. The Scalable service-Oriented MiddlewarE over IP (SOME/IP) protocol is standardised within the AUTOSAR framework to support this model [5].

SOME/IP provides mechanisms for the following:

• Remote Procedure Calls (RPCs) for request–response interactions;
• Event-based communication through publish–subscribe patterns;
• Service discovery for dynamic service availability detection.

The AUTOSAR Adaptive Platform uses SOME/IP over Ethernet to support flexible, high-performance computing ECUs for automated and autonomous driving functions [6]. ADAS fusion controllers, central gateways, and telematics units all rely on SOME/IP for dynamic service binding.

1.4. Security Challenges in SOME/IP Communication

Transmitting SOME/IP in plaintext over shared in-vehicle Ethernet introduces significant security vulnerabilities. Studies of production vehicles have shown that unauthenticated in-vehicle communication can be remotely exploited to influence safety-critical functions [7,8]. Following the threat-classification guidance of ISO/SAE 21434 [9] and SAE J3061 [10], the main security threats affecting SOME/IP communication are as follows:

• Man-in-the-Middle (MitM) Attacks: Attackers intercept and manipulate communication between ECUs, enabling the injection of unauthorised commands into safety-critical systems [11].
• Replay Attacks: Captured legitimate messages are retransmitted to trigger unauthorised actions.
• Eavesdropping: Plaintext transmission enables passive monitoring of sensitive parameters, violating confidentiality.

1.5. Current Security Provisions in AUTOSAR

The AUTOSAR standard provides specific protocols to counter these threats:

• (D)TLS Integration: Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS) secure unicast SOME/IP communication. These protocols use a cryptographic handshake to establish Secure Channels, verifying endpoint identity and encrypting data in transit [12].
• Secure Onboard Communication (SecOC): The SecOC module protects message authenticity and prevents replay attacks by appending Message Authentication Codes (MACs) and freshness values to the payload. Unlike (D)TLS, SecOC supports both unicast and multicast communication patterns [13].

Table 1. Security coverage of current AUTOSAR mechanisms. “Auth.” denotes end-to-end data-origin authentication; “Conf.” denotes payload confidentiality, with the protection scope stated explicitly. A checkmark indicates that the mechanism provides the stated property within the indicated scope; an em dash indicates that it does not.

Mechanism	Unicast		Multicast
	Auth.	Conf.	Auth.	Conf.
(D)TLS	✓ end-to-end	✓ end-to-end	—	—
SecOC	✓ end-to-end	—	✓ end-to-end	—
MACsec	✓ per link	✓ per link	✓ per link	✓ per link
Proposed	✓ end-to-end	✓ per link	✓ end-to-end	✓ per link †

^† The proposed architecture provides end-to-end authenticity together with hop-by-hop (per-link) confidentiality. Confidentiality coincides with end-to-end protection only in single-hop topologies; against a compromised intermediate switch, it does not hold (see the attacker model in Section 3.1.3). End-to-end multicast confidentiality therefore remains an open problem (Section 7.4).

summarises the security capabilities of current AUTOSAR provisions.

1.6. Research Gap and Motivation

Table 1 reveals a gap in the AUTOSAR specifications: as of Release R22-11, no standardised security profile provides both authenticity and confidentiality for multicast SOME/IP communication. The absence of multicast confidentiality is significant because multicast is the standard way to distribute sensor readings, status notifications, and control signals to multiple ECUs.

Without multicast confidentiality, sensitive vehicle data travels in plaintext, vulnerable to eavesdropping. Furthermore, trying to use unicast encryption for group communications increases CPU overhead and network traffic, which degrades overall performance.

We state at the outset what this paper does and does not close. The architecture evaluated here delivers end-to-end multicast authenticity together with per-link confidentiality. It therefore removes plaintext exposure on every wire and on any tapped link, which is the dominant passive-eavesdropping surface, but it does not deliver end-to-end multicast confidentiality against a compromised intermediate switch. The gap identified above is consequently narrowed rather than closed, and the residual part of it is stated explicitly in the attacker model (Section 3.1.3) and carried into future work (Section 7.4).

1.7. Contribution

To address this gap, this paper defines and experimentally characterises a hybrid security architecture that combines mechanisms at complementary protocol layers. We state the nature of the contribution plainly. Layering an authentication mechanism above a link-layer confidentiality mechanism is the defence-in-depth that the AUTOSAR stack already anticipates, and both constituent mechanisms are standardised and have been demonstrated individually in automotive settings [14,15]. The composition itself is therefore engineering integration rather than a new cryptographic result. What the literature does not supply, and what this paper provides, is a measured account of what that composition costs on a service-oriented stack—decomposed by layer, separated into cryptographic and non-cryptographic components, and reported with tail behaviour—together with an explicit statement of which threats the composition does and does not address. The contributions of this work are as follows:

• Hybrid Security Architecture: An integration of SecOC applied to the SOME/IP application PDU (above OSI Layer 4) with IEEE 802.1AE MACsec at the data link layer (Layer 2), providing end-to-end authenticity and integrity for SOME/IP traffic together with per-link confidentiality.
• Multicast Protection: A configuration that secures both unicast and multicast SOME/IP communication patterns, narrowing the multicast confidentiality coverage gap in the targeted AUTOSAR R22-11 security profiles to the residual case of a compromised intermediate switch, which is not addressed.
• Quantitative Performance Profile: A controlled measurement of end-to-end latency including tail behaviour (p50/p95/p99), a decomposition of the per-message SecOC cost into cryptographic and non-cryptographic components that identifies the user-space software path rather than the cipher as the dominant term, CPU and memory footprints, and a comparison against a DTLS unicast-fanout deployment baseline, across ten scenarios and two key-distribution modes.
• Deployment Guidelines: Practical guidelines, including a MACsec Key Agreement (MKA) deployment sketch and an explicit threat-model mapping that names the residual uncovered threats, for integrating this hybrid architecture into the AUTOSAR Adaptive Platform.

2. Related Work

Previous research has investigated in-vehicle communication security as automotive systems become increasingly connected. This section reviews existing approaches to securing SOME/IP communication and identifies their limitations in protecting multicast traffic.

2.1. PKI-Based Security Approaches

PKI-based approaches apply asymmetric cryptography for session establishment. Iorio et al. [16] introduced Secure SOME/IP, providing mutual authentication, policy enforcement, and symmetric key sharing; formal analysis verifies its security properties, but each client requires an individual handshake, which is inefficient for the multicast configurations common in vehicular networks. Zelle et al. [17] proposed SESO-RC, combining digital certificates and ephemeral-static Diffie–Hellman exchanges for strong authentication with forward secrecy, at the cost of high asymmetric CPU overhead; policy enforcement operates at the ECU level rather than the service level, limiting flexibility.

2.2. Authentication Server-Based Approaches

Centralised Authentication Server (AS) approaches reduce per-ECU asymmetric overhead. SESO-AS [17] delegates service permissions and symmetric-key distribution to an authorisation server, reducing the ECU workload and supporting multicast, but creates a single point of failure and adds key-distribution latency. Lee et al. [18] proposed a Kerberos-inspired protocol using symmetric keys and freshness tokens for replay prevention; it retains centralised-node dependency and requires synchronised clocks across all ECUs.

2.3. Alternative Security Mechanisms

Mueller [19] proposed DNSSEC and DANE for verified SOME/IP service discovery, enabling offline verification after caching key records; however, unicast DNS transactions conflict with the multicast design of SOME/IP-SD. Du et al. [20] modelled SOME/IP under the Dolev–Yao adversary model and proposed timestamps and nonces to prevent replay, tampering, and spoofing, but did not address confidentiality. TESLA-based multicast authentication [21] is computationally lightweight via hash chains and delayed key disclosure, but authentication delays limit its applicability to hard real-time scenarios.

2.4. Layer 2 Security Integration

Corbett and Schlingmann [14] demonstrated IEEE 802.1AE MACsec for automotive Ethernet, reporting negligible PHY-integrated latency; the OPEN Alliance TC17 has standardised an automotive MACsec/MKA profile [15]. These works establish MACsec as a viable link-layer confidentiality primitive but treat it as a standalone mechanism. Because MACsec operates strictly hop-by-hop, a compromised intermediate switch can read or modify plaintext payloads; neither origin authenticity nor confidentiality is preserved end-to-end in a zonal topology. The present work treats MACsec as a confidentiality substrate beneath an end-to-end SecOC authentication layer, quantifies the combined cost, and contributes an MKA deployment sketch (Section 4.7.3) that prior automotive MACsec studies leave implicit.

2.5. IPSec and Encapsulating Security Payload (ESP)

The Internet Protocol Security (IPSec) suite [22] provides Layer 3 security through Authentication Header (AH) and Encapsulating Security Payload (ESP) [23], using AES-CBC/GCM encryption and IKEv2 key exchange. ESP has been proposed for automotive Ethernet [24] but faces fundamental constraints: IPSec associations are point-to-point (multicast requires GDOI with a central group controller [25], creating a single point of failure [26]); asymmetric IKE handshakes add substantial startup overhead on resource-constrained ECUs [27]; operating at Layer 3 provides no service-level authentication granularity when multiple services share one ECU; and gateways must decrypt and re-encrypt packets, removing end-to-end security guarantees [24]. These limitations leave the multicast SOME/IP security gap unresolved.

2.6. Multi-Layer and Defence-in-Depth Approaches

Because the architecture proposed here is a composition rather than a new primitive, its relationship to existing multi-layer work determines what is actually novel, and we set that out explicitly. Rathore et al. [28] surveyed in-vehicle communication security and advocated layered defence as the organising principle for it, but the treatment was a taxonomy: no composition was implemented and no cost was measured. Du et al. [29] modelled SOME/IP over vehicle Ethernet with Coloured Petri Nets and proposed protocol improvements, working at the level of a single protocol and verifying formally rather than empirically. Bella et al. [30] took the opposite route to ours with CINNAMON, extending SecOC itself into a module that adds confidentiality alongside integrity and authentication on CAN. That design achieves within one layer what we deliberately split across two: it yields end-to-end confidentiality, which our per-link approach does not, at the cost of a modified SecOC construction that must be re-analysed and that no longer interoperates with a stock SecOC peer. Which trade is preferable depends on whether an integrator can accept a modified security module. Iorio et al. [31] extended their earlier Secure SOME/IP work into a fuller service-protection framework with authorisation and policy enforcement, remaining a single-layer application-level scheme with per-client session establishment.

Three differences follow, and they are narrower than a claim of novelty for layering itself would suggest: First, neither constituent mechanism is modified here, so both remain individually conformant and separately analysable—in contrast to CINNAMON and to the SOME/IP-protocol modifications above. Second, we report measured per-layer costs on a service-oriented stack, including the split between cryptographic and software-path components, where the surveyed multi-layer literature reports architecture without quantification. Third, we state the residual uncovered threat explicitly rather than presenting layering as complete coverage: the composition does not defend confidentiality against a compromised switch, which a single-layer end-to-end encryption scheme would.

2.7. Research Gap Analysis

Table 2. Comparative analysis of existing SOME/IP security approaches.

Approach	Security	Overhead	Scalab.	Multicast	Confid.
PKI-based [16]	High	High	Low	Limited	Yes
AS-based [18]	Med–High	Low–Med	High	Good	Yes
Pre-shared key	Medium	Low	Medium	Good	Partial
TESLA-based [21]	Med–High	Low	Good	Excellent	No
MACsec-based [14]	High	Very Low	Medium	Good	Yes
IPSec/ESP [22,23]	High	High	Low	Limited	Yes
SecOC [13]	Medium	Low ‡	High	Excellent	No

Overhead reflects per-message computational cost: Very Low (<1 ms), Low (1 ms to 10 ms), Med (10 ms to 25 ms), High (>25 ms or a per-message asymmetric operation). ^‡ This rating reflects the raw CMAC operation and typical HSM-assisted embedded implementations reported in the literature. Section 6.3.2 shows that our own user-space Linux integration measures $15.72$ ms to $17.85$ ms (the Med bracket), a software-path cost specific to this implementation and not to the cipher or to SecOC as a mechanism. Scalability reflects key-management growth with n nodes: High ($\mathcal{O}\left(n\right)$), Medium ($\mathcal{O}\left(n\right)$ with a central Key Server), Low ($\mathcal{O}\left(n^2\right)$ or per-pair handshakes). Multicast denotes native group support without per-receiver fanout.

compares existing security approaches across key criteria. The five criteria were chosen because each corresponds to a constraint that decides deployability in an in-vehicle network rather than to an abstract property: Security captures the strength of the guarantee offered; Overhead the per-message computational budget, which is what bounds admissibility into a real-time schedule; Scalability the growth of key management with fleet and network size, which drives production and after-sales cost; Multicast whether group communication is native or must be emulated, which is the specific pattern that this paper targets; and Confidentiality whether payload secrecy is provided at all, since that is the property missing from the AUTOSAR multicast profiles. The thresholds used for the qualitative bands are stated in the table footnote so that the classification can be checked.

No reviewed single-layer approach delivers both authenticity and confidentiality for multicast SOME/IP within acceptable performance budgets: PKI and AS schemes struggle with multicast efficiency, IPSec lacks native multicast and service-level granularity, SecOC offers multicast authenticity but no confidentiality, and MACsec encrypts individual links without end-to-end authentication. This paper addresses the gap by composing SecOC (end-to-end authenticity above Layer 4) with MACsec (link-layer confidentiality at Layer 2). Unlike prior work, we additionally provide a measured cost decomposition and a DTLS fanout baseline comparison (Section 6.5).

3. Technical Background

This section describes the protocols used in our hybrid security architecture, including SOME/IP, SecOC, and MACsec.

3.1. Security Fundamentals in Automotive Systems

Automotive networks require security at multiple protocol layers. Confidentiality, integrity, and authenticity are the three core properties, each addressed through different cryptographic mechanisms.

3.1.1. Cryptographic Primitives

Automotive security relies on AES-based symmetric ciphers for bulk encryption, CMAC-AES256 for per-message authentication conforming to NIST SP 800-38B [32,33], and RSA-2048 asymmetric cryptography [34] for session-key distribution between ECUs; this paper uses CMAC-AES256 throughout. A Diffie–Hellman-family exchange (e.g., ECDH-P256) is not used in the implementation evaluated here; it is discussed only as a candidate optimisation for session setup in Section 6.7.4.

3.1.2. Authentication Mechanisms

Automotive authentication uses pre-shared keys (PSKs) for resource-constrained ECUs, X.509 digital certificates for PKI-based identity binding, and Message Authentication Codes (MACs) for per-message integrity and origin verification with low computational overhead.

3.1.3. Attacker Model

We adopt a Dolev–Yao network attacker [35] restricted to the in-vehicle Ethernet domain, refined with the asset and threat taxonomy of ISO/SAE 21434 [9]. The attacker controls the data link between communicating ECUs: it can observe, drop, reorder, replay, and inject Ethernet frames, but it cannot break the underlying cryptographic primitives (AES-GCM-128, CMAC-AES256, RSA-2048) and does not possess valid keys unless it has compromised an endpoint. We distinguish four attacker capability levels, summarised in

Table 3. Attacker capability levels and the layer that counters each.

Level	Capability	Representative Action	Countered by
A1	Passive eavesdropper	Reads frames on a tapped link	MACsec (L2 encryption)
A2	Active on-path injector	Forges/replays/modifies frames	SecOC + MACsec
A3	Compromised switch	Reads/alters frames mid-path	SecOC (authenticity only)
A4	Compromised endpoint ECU	Holds valid keys, abuses service	Out of scope (HSM/authz)

.

The per-attacker defence mapping is as follows:

• A1 (passive eavesdropper). A1 captures traffic on a single link. MACsec AES-GCM-128 encryption renders the payload confidential on that link, defeating A1.
• A2 (active on-path injector). A2 forges, replays, or modifies frames on a link that it controls. SecOC CMAC-AES256 authentication with a monotonic freshness counter detects forged and replayed PDUs end-to-end, and MACsec rejects frames with an invalid ICV at the link, so A2 cannot inject accepted messages.
• A3 (compromised switch). Because MACsec is hop-by-hop, a compromised switch observes plaintext after decryption and before re-encryption. MACsec therefore does not provide confidentiality against A3 in a multi-hop topology. SecOC still guarantees that any payload that the switch alters is rejected by the receiver: authenticity and integrity survive the hop, but multicast confidentiality holds end-to-end only in single-hop topologies. Closing the A3 confidentiality gap requires an end-to-end payload-encryption profile, which we identify as complementary future work (Section 7.4).
• A4 (compromised endpoint). An ECU holding valid SecOC and MACsec keys can produce authentic traffic by definition. This is not a hypothetical concern: an independent, non-peer-reviewed security-research blog report documents the practical extraction of production SecOC keys from a 2021 Toyota RAV4 [36], illustrating that A4 is a realistic threat once an ECU is physically compromised. Defending A4 requires key isolation in a hardware security module and application-level authorisation, which are orthogonal to the communication-security mechanisms evaluated here and are out-of-scope.

3.2. SOME/IP Protocol Architecture

3.2.1. Message Structure

Figure 1 illustrates the SOME/IP message format, comprising a 16-byte fixed header and variable-length payload [37].

3.2.2. Security Deficiencies

SOME/IP was designed for closed in-vehicle networks and lacks authentication, encryption, integrity protection, and replay prevention [17]. Consequently, it is vulnerable to the attack vectors described in Section 1.4, necessitating supplementary security mechanisms.

3.3. Secure Onboard Communication (SecOC)

SecOC [13] appends a truncated MAC and freshness counter to each PDU for end-to-end authentication and replay protection. The three standardised SecOC profiles defined in the AUTOSAR PRS [38] all use CMAC with AES-128 and short authenticators; this paper instead configures a vendor-defined profile (CMAC-AES256, 64-bit truncated MAC, 64-bit freshness value of which 16 bits are transmitted), which the specification explicitly permits under TPS_MANI_03140. The exact relationship to the standardised profiles is given in Section 4.6.4. SecOC is transport-agnostic by design: the authentication procedure itself is unchanged whether the underlying network is CAN or Ethernet; what changes is where the freshness value and MAC are carried within the network packet, and what additional link-layer protection the transport already provides. Figure 2 shows the architecture in our SOME/IP-over-Ethernet deployment; Figure 3 shows the resulting Secured I-PDU byte layout.

3.3.1. SecOC Limitations

While SecOC effectively provides authenticity and integrity, it has some limitations:

• No Confidentiality: SecOC does not encrypt payloads; messages remain readable to eavesdroppers [13].
• Bandwidth Overhead: Authentication data consumes payload space, significant on bandwidth-constrained CAN networks.
• Key Management: Keys must be pre-provisioned; no onboard key-exchange protocol is specified. Weak provisioning or storage of these keys is not merely theoretical: a non-peer-reviewed but widely cited independent security-research blog report describes recovering deployed SecOC keys from a production vehicle [36], underscoring the need for HSM-backed key storage in any real deployment.
• Synchronisation Delays: Receivers may temporarily reject messages until freshness synchronisation completes after startup or sleep.

SecOC and Authenticated Encryption

The SecOC mechanism is, by design, an authentication layer: every standardised security profile in the Protocol Requirements Specification produces a MAC and (except for Profile 2) a freshness value, but none encrypts the payload [38]. The specification does permit vendor-defined, non-standardised profiles (TPS_MANI_03140), which could in principle bind an Authenticated Encryption with Associated Data (AEAD) construction such as AES-GCM to a SecOC PDU. As of Release R22-11, however, no SecOC profile, standardised or otherwise, is defined for payload confidentiality.

We therefore distinguish two very different uses of the vendor-defined-profile mechanism. The first re-parameterises SecOC while leaving its construction intact: the Secured I-PDU layout, the MAC-over-(DataId‖AuthPdu‖FV) input, the truncation rules, and the freshness state machine all remain exactly as specified, and only the key length and the truncation lengths differ from the predefined profiles. That is what this paper does, and it is the reason the SecOC processing chain in our plugin is a drop-in match for a standards-conformant one. The second would replace SecOC’s cryptographic construction with an AEAD, changing what the mechanism computes and how a receiver must process it. We deliberately avoid the second: a proprietary AEAD SecOC profile would place the confidentiality mechanism inside a layer whose interoperability rests on a shared construction, whereas obtaining confidentiality from the orthogonal, already-standardised IEEE 802.1AE MACsec layer (Section 4) leaves both layers individually conformant. We note plainly that a vendor-defined SecOC profile is nonetheless not automatically interoperable across suppliers, and that a deployment requiring strict profile conformance would use Profile 1 or Profile 3 with the corresponding reduction in MAC strength.

3.4. MACsec (IEEE 802.1AE)

MACsec [39] encrypts and authenticates Ethernet frames hop-by-hop using GCM-AES-128 [40], with the Packet Number (PN) serving as a per-frame nonce for replay protection; a Secure Channel Identifier (SCI) scopes each unidirectional Secure Channel, and MACsec Key Agreement (MKA, IEEE 802.1X) handles peer authentication and SAK distribution [15]. Figure 4 shows the secured frame format.

3.4.1. Cryptographic Mechanism

IEEE 802.1AE-2018 defines a cipher-suite negotiation; the default and mandatory-to-implement suite is GCM-AES-128 [39]. AES-GCM provides simultaneous encryption and integrity protection: the payload is encrypted while the entire frame is authenticated via the 16-byte ICV. The Packet Number, together with the SCI, forms the deterministic initialisation vector, ensuring a unique nonce per frame.

3.4.2. Security Properties

MACsec provides data origin authentication (only CA members with valid SAK produce accepted frames), integrity (the ICV detects any modification), optional payload confidentiality, and replay protection via a monotonically increasing Packet Number. Hardware-integrated PHY implementations achieve line-rate encryption with negligible latency [14].

3.4.3. MACsec Limitations

MACsec is hop-by-hop only (no end-to-end protection across a compromised switch), Ethernet-only, requires hardware-capable PHYs, and provides no application-level service authentication.

3.5. Comparative Analysis: SecOC vs. MACsec

Table 4. Comparison of SecOC and MACsec security mechanisms.

Aspect	SecOC	MACsec
OSI position	On SOME/IP PDU (above L4)	Layer 2 (Data Link)
Scope	End-to-end	Hop-by-hop
Confidentiality	No	Yes (optional)
Integrity	Yes (MAC)	Yes (ICV)
Replay Protection	Yes (freshness counter)	Yes (Packet Number)
Multicast Support	Native (group keys)	Native (shared SAK)
Network Types	CAN, Ethernet, FlexRay	Ethernet only
Overhead	4–16 bytes per PDU	∼24–32 bytes per frame
Implementation	Software (with HSM)	Hardware (PHY/switch)

compares SecOC and MACsec across key dimensions, highlighting their complementary nature.

4. Proposed Hybrid Security Architecture

This section presents the proposed hybrid security architecture that applies SecOC to the SOME/IP application PDU (above OSI Layer 4) over a MACsec substrate at the data link layer, addressing the critical limitations identified in Section 3.5.

4.1. Addressing Individual Mechanism Limitations

MACsec at Layer 2 addresses SecOC’s lack of payload confidentiality, while SecOC’s end-to-end application-PDU MACs deliver the per-service authentication that MACsec’s hop-by-hop scope cannot provide. Key management is covered by the two distribution modes below; byte overhead is negligible on automotive Ethernet (100 Mbps+). End-to-end confidentiality against a compromised switch is not claimed (see the attacker model, Section 3.1.3).

Table 5. Gap closure through hybrid architecture integration. Here, “L4+” denotes SecOC’s position on the SOME/IP application PDU, above the OSI transport layer. The final column states the scope over which each resolution holds; N/A denotes that no specific scope applies.

Limitation	Affected Layer	Resolution	Scope
No Confidentiality	SecOC (L4+)	MACsec encryption (Layer 2)	Hop-by-hop
No App Authentication	MACsec (Layer 2)	SecOC MACs (L4+)	End-to-end
Bandwidth Overhead	SecOC (CAN/LIN)	Ethernet capacity (≥100 Mbps)	N/A
Hop-by-Hop Only	MACsec (Layer 2)	SecOC end-to-end authenticity (L4+)	End-to-end (authenticity only)

The final row resolves MACsec’s hop-by-hop limitation only for authenticity and integrity. Confidentiality remains hop-by-hop, so a compromised intermediate switch still observes plaintext (Section 3.1.3).

summarises the full gap-closure mapping.

Combining these mechanisms secures unicast and multicast SOME/IP communication with low performance overhead. The following sections describe the design, implementation, and integration strategy of this architecture.

4.1.1. Key Distribution Modes: PSK vs. RSA-2048

The SecOC plugin supports two key distribution modes, each with distinct trade-offs [34,41]:

Mode A: Pre-Shared Keys (PSKs)

In PSK mode, CMAC-AES256 symmetric keys are provisioned during ECU manufacturing, firmware flashing, or via a secure out-of-band channel. This mode has low cryptographic overhead: per-message processing consists only of CMAC-AES256 tag computation and verification, with no asymmetric operations at runtime. The trade-off is key-management complexity, and its scale depends on the communication pattern. For pairwise unicast associations, each pair of communicating ECUs needs a distinct key, giving $\mathcal{O}\left(n^2\right)$ keys for n ECUs. For multicast, the count is much smaller: a SOME/IP event group is secured by a single group key shared by the publisher and all of its subscribers, so the number of keys grows with the number of event groups, $\mathcal{O}\left(g\right)$, and not with the number of receivers. The $\mathcal{O}\left(n^2\right)$ figure quoted in the remainder of this paper is therefore the unicast worst case, and it overstates the burden for the multicast traffic that motivates this work. The corresponding weakness of a group key is that it provides group authenticity only: any group member can produce a PDU that every other member accepts, so SecOC distinguishes the group from outsiders but not one member from another.

Mode B: RSA-2048 Key Exchange

In RSA mode, the publisher generates a fresh CMAC-AES256 session key at session initialisation and distributes it under RSA-2048 OAEP encapsulation. The procedure is as follows: Each ECU holds a long-term RSA key pair and an X.509 certificate issued by the vehicle Certificate Authority, provisioned at end-of-line. A subscriber presenting its certificate is validated against the CA trust anchor (signature chain, validity period, and the service identifiers the certificate is authorised for) before any key material is released. The publisher then encrypts the session key under the subscriber’s validated public key and includes a freshly generated nonce, which the subscriber echoes in its confirmation; a replayed key-distribution message therefore carries a stale nonce and is rejected. Because RSA-OAEP encapsulation is inherently per-recipient, a group of N subscribers requires N encapsulations, so session establishment in multicast mode is $\mathcal{O}\left(N\right)$ in both computation and message count. The multicast figures reported below are consequently for $N=2$ and will grow with group size: the measured unicast-to-multicast delta ($31.33$ ms − $25.23$ ms ≈ $6.10$ ms for SecOC-RSA; $33.77$ ms − $26.65$ ms ≈ $7.12$ ms for Hybrid-RSA) is the only per-recipient slope estimable from this study, computed from just two group sizes ($N=1,2$); we do not extrapolate it to larger groups. The steady-state per-message cost, by contrast, is independent of N (Section 6.5).

The benefit is that pairwise pre-provisioning is eliminated: each ECU stores only its own private key and the CA trust anchor, giving $\mathcal{O}\left(n\right)$ long-term key management, and the scheme integrates with PKI certificate hierarchies [34,41]. We claim no non-repudiation for this construction: RSA-OAEP is a key encapsulation mechanism, not a digital signature, so it authenticates the recipient of the session key but produces no transferable evidence of origin for the messages subsequently protected with it. Two further limitations are noted for completeness: group rekeying on membership change is not implemented, and the session key is not refreshed within a drive cycle. The trade-off is a one-time session cost ($25.2$ ms to $33.8$ ms); steady-state processing is thereafter identical to the PSK mode. Section 6 evaluates both modes experimentally.

Why RSA-2048?

RSA-2048 represents a deliberate worst case for session setup; it is widely deployed in automotive PKI and HSM tooling [41], while faster curve-based alternatives (ECDH-P256, X25519) [42,43] would only reduce the startup overhead. Steady-state results are key-scheme agnostic.

4.2. Architecture Overview

The hybrid architecture combines two security mechanisms at complementary layers of the protocol stack. For brevity, the remainder of this paper uses “L4+” as shorthand for SecOC’s position: SecOC is applied to the SOME/IP application PDU, which is constructed above the OSI transport layer, and is not an OSI transport-layer protocol in the strict sense. In the AUTOSAR layered architecture it corresponds to the Crypto/COM processing applied to the SOME/IP PDU before it is handed to UDP.

• SecOC (L4+, on the SOME/IP PDU): Provides end-to-end message authentication and replay protection through CMAC-AES256 Message Authentication Codes and freshness values. Supports two key distribution modes: pre-shared keys (PSKs) for minimal overhead, or RSA-2048 for dynamic session key establishment. Implemented as a vsomeip plugin operating in user space.
• MACsec (Layer 2): Provides hop-by-hop confidentiality and integrity protection through authenticated encryption (AES-GCM-128), implemented in the Linux kernel via the macsec driver.

This layered design provides end-to-end message authentication from SecOC combined with link-layer encryption from MACsec. This narrows the multicast security gap described in Section 1.6, to the extent set out there.

Implementation Scope and AUTOSAR Compatibility

Because the distinction matters for how the results should be read, we state precisely what is and is not standard in the evaluated system. Neither SecOC nor MACsec is modified: the SecOC processing chain, Secured I-PDU layout, MAC input, and freshness state machine follow the AUTOSAR protocol framework, and MACsec is the unmodified IEEE 802.1AE implementation shipped in the Linux kernel. In particular, we did not alter either protocol in order to obtain combined authenticity and confidentiality—which is precisely the change that several earlier proposals make, and which requires the modified construction to be re-analysed before it can be trusted.

Three qualifications follow: First, the security profile is vendor-defined rather than one of the three predefined profiles (Section 4.6.4). Second, the middleware is COVESA vsomeip, an open-source SOME/IP implementation, not a commercial or certified AUTOSAR Adaptive Platform stack; the custom SecOC shared library exists to make SecOC configurable and switchable per PDU for the purpose of these experiments, not to change what SecOC computes. Third, the results obtained here therefore demonstrate AUTOSAR-compatible behaviour on an open-source service-oriented stack, and they should not be read as a measurement of a production Adaptive Platform, whose vendor SecOC, Crypto Service Manager, and network stack would have different constant factors. Full Adaptive Platform integration is left for future work.

4.3. System Context and Components

Consistent with the scope stated in Implementation Scope and AUTOSAR Compatibility the evaluated environment is an open-source service-oriented stack exercising AUTOSAR-compatible protocol behaviour, not a certified Adaptive Platform distribution. It comprises the following components:

• Platform: COVESA vsomeip running on Ubuntu 20.04 LTS (kernel 5.15), exercising AUTOSAR Adaptive Platform-compatible SOME/IP communication patterns;
• Middleware: COVESA (formerly GENIVI) vsomeip implementation;
• Security Extension: Custom SecOC shared library (libsecoc.so) integrated as a vsomeip plugin;
• Link Security: IEEE 802.1AE MACsec enabled through the Linux kernel macsec driver, configured statically with iproute2 (Section 4.7.2); MKA (IEEE 802.1X) is not run on this testbed and is discussed only as a production deployment model in Section 4.7.3;
• Network Interface: Physical Ethernet (eth0) with MACsec virtual interface (macsec0).

Table 6. Component mapping across OSI layers and execution domains.

OSI Layer	Component	Domain	Security Function
Application (7)	Application SWC	User Space	Service logic
Session (5)	vsomeip Runtime	User Space	Service management
SOME/IP PDU (L4+)	SecOC Plugin	User Space	Authentication + freshness
Transport (4)	UDP/IP Stack	Kernel Space	Datagram transport
Network (3)	IP Stack	Kernel Space	Routing
Data Link (2)	MACsec Driver	Kernel Space	Encryption + ICV
Physical (1)	Ethernet PHY	Hardware	Transmission

maps the architectural components to their respective OSI layers and execution domains.

4.4. Layered Security View

Figure 5 illustrates the complete message flow from application to physical wire, showing the security transformations applied at each layer.

4.5. vsomeip Plugin Architecture

The vsomeip middleware uses a modular plugin architecture that enables runtime extension of functionality without modifying the core codebase.

Table 7. The vsomeip shared library components.

Library	Loading	Function
Base Library	Static (linked)	Runtime code for application management
Configuration Library	Plugin (init)	JSON configuration parsing
E2E Library	Plugin (if enabled)	End-to-end protection
Service Discovery	Plugin (if enabled)	SD protocol implementation
SecOC Library	Plugin (if enabled)	Authentication/Verification

summarises the standard vsomeip shared libraries.

4.5.1. Plugin Infrastructure

The vsomeip plugin system utilises a singleton plugin_manager that discovers and loads shared libraries at runtime. Each plugin derives from an abstract plugin interface and gains concrete functionality through the Curiously Recurring Template Pattern (CRTP) helper plugin_impl<T>. This architecture enables seamless integration of the SecOC module using the same patterns as built-in vsomeip components.

Figure 6 illustrates the class hierarchy for the SecOC plugin integration.

4.5.2. SecOC Interface Definition

The SecOC plugin exposes three primary methods through its interface:

• initialize(): Configures cryptographic parameters, loads secret keys, and initialises freshness counters from persistent storage.
• authenticate(service_id, event_id, data, instance_id): Determines SecOC applicability for the given PDU identifier tuple, generates freshness value, computes MAC, and appends authentication data to the payload.
• verify(service_id, event_id, data, instance_id): Determines SecOC applicability, extracts authentication data, reconstructs freshness value, computes expected MAC, and validates against received authenticator.

The tuple (service_id, event_id, instance_id) uniquely identifies each secured PDU, enabling per-message security policy configuration.

4.5.3. Routing Manager Integration

The vsomeip architecture distinguishes between two application roles:

• Routing Manager Host: A single instance per ECU responsible for service registration, routing decisions, and plugin management.
• Routing Manager Proxy: Client applications that communicate with the routing manager via local IPC (Unix domain sockets).

The SecOC plugin is loaded during routing manager initialisation, ensuring that all outbound and inbound PDUs pass through the security layer. The plugin loading sequence is integrated into routing_manager_impl::init():

• Plugin manager queries for secoc.so in LD_LIBRARY_PATH;
• If found, the plugin is instantiated and initialize() is invoked;
• The SecOC instance is stored for use in transmit/receive paths.

4.6. SecOC Implementation Design

The SecOC implementation follows the SecOC protocol framework specified in the Protocol Requirements Specification of Secure Onboard Communication (AUTOSAR_PRS_ SecOcProtocol, R22-11) [38] and the System Template (AUTOSAR_TPS_SystemTemplate, R22-11) [44], instantiated with the vendor-defined profile of

Table 8. Standardised SecOC security profiles [38] compared with the vendor-defined profile evaluated in this work.

Profile	Algorithm	Key	Truncated MAC	Transmitted FV
Profile 1 (standardised)	CMAC	AES-128	24 bits	8 bits
Profile 2 (standardised)	CMAC	AES-128	24 bits	none
Profile 3/JASPAR (standardised)	CMAC	AES-128	28 bits	4 bits
This work (vendor-defined)	CMAC	AES-256	64 bits	16 bits

The vendor-defined profile is permitted by TPS_MANI_03140. It changes only key length and truncation lengths; the MAC input, Secured I-PDU layout, and freshness state machine follow the standardised construction. Deployments requiring strict profile conformance would select Profile 1 or Profile 3 and accept the corresponding reduction in authenticator strength.

. The implementation provides per-message authentication through CMAC-AES256 and replay protection through monotonic freshness counters, with RSA-2048 employed for initial symmetric key distribution between ECUs.

4.6.1. Transmission Flow

Figure 7 illustrates the SecOC transmission activity when an application sends an event notification.

4.6.2. Reception Flow

Figure 8 illustrates the SecOC reception activity when a message is received from the network.

4.6.3. Freshness Value Management

The SecOC implementation employs a hierarchical freshness counter structure to ensure uniqueness over the ECU lifetime:

$${\mathrm{FV}}_{64}={\mathrm{TripCounter}}_{16}\parallel {\mathrm{ResetCounter}}_{16}\parallel {\mathrm{MessageCounter}}_{32}$$

(1)

To minimise bandwidth overhead, only the least significant bits (LSBs) of the message counter are transmitted. The receiver maintains synchronised counters and reconstructs the full freshness value using Algorithm 1.

Algorithm 1 Freshness Value Reconstruction

Require:  Received LSBs ${\mathrm{FV}}_{\mathrm{rx}}$, local counter ${\mathrm{FV}}_{\mathrm{local}}$, window size W Ensure:  Reconstructed FV or Reject   1: ${\mathrm{FV}}_{\mathrm{cand}}\leftarrow \mathrm{MSBs}\left({\mathrm{FV}}_{\mathrm{local}}\right)\parallel {\mathrm{FV}}_{\mathrm{rx}}$   2: if ${\mathrm{FV}}_{\mathrm{cand}}>{\mathrm{FV}}_{\mathrm{local}}$ and ${\mathrm{FV}}_{\mathrm{cand}}-{\mathrm{FV}}_{\mathrm{local}}<W$ then   3:      accept and update ${\mathrm{FV}}_{\mathrm{local}}\leftarrow {\mathrm{FV}}_{\mathrm{cand}}$   4: else if ${\mathrm{FV}}_{\mathrm{cand}}\le {\mathrm{FV}}_{\mathrm{local}}$ then   5:      ${\mathrm{FV}}_{\mathrm{cand}}^{\prime }\leftarrow (\mathrm{MSBs}\left({\mathrm{FV}}_{\mathrm{local}}\right)+1)\parallel {\mathrm{FV}}_{\mathrm{rx}}$    ▹ handle counter wrap   6:      if ${\mathrm{FV}}_{\mathrm{cand}}^{\prime }>{\mathrm{FV}}_{\mathrm{local}}$ and ${\mathrm{FV}}_{\mathrm{cand}}^{\prime }-{\mathrm{FV}}_{\mathrm{local}}<W$ then   7:           accept and update ${\mathrm{FV}}_{\mathrm{local}}\leftarrow {\mathrm{FV}}_{\mathrm{cand}}^{\prime }$   8:     else   9:           return Reject        ▹ replay, or wrap gap exceeds W 10:      end if 11: else 12:      return Reject ▹ LSBs jumped beyond window W; a single reconstruction attempt cannot recover from loss exceeding W messages 13: end if

Window Size, Loss, and Reordering

The acceptance window W bounds how far ahead of its local counter a receiver will follow a sender. Two constraints fix its range. Above, reconstruction from truncated LSBs is unambiguous only while the true gap stays below the transmitted counter space (here, $2^{16}$); below, W must exceed the largest credible burst of consecutive losses, or legitimate traffic is rejected. We set $W=32$, matching the configured MACsec replay window so that both layers tolerate the same run of consecutive losses before a legitimate PDU is rejected. This match is a loss-tolerance equivalence, not a reordering equivalence: as the itemisation below states, MACsec accepts a frame arriving out of order within the 32-frame window, whereas Algorithm 1 is strictly monotonic and rejects any reordered PDU outright, treating it as loss. $W=32$ therefore leaves three orders of magnitude of margin to the $2^{16}$ ambiguity limit on the loss dimension, while the two layers remain asymmetric on the reordering dimension. The behaviour that results is as follows:

• Packet Loss: Losing up to $W-1$ consecutive PDUs is transparent—the next PDU still falls inside the window, is accepted, and the local counter jumps forward to it. Losing W or more consecutive PDUs takes the receiver out of the window; every subsequent PDU is then rejected until the Freshness Value Manager redistributes the full counter.
• Counter Wraparound: When the transmitted LSBs wrap, the naive candidate is no longer greater than the local counter, so the algorithm retries once with the most significant bits incremented. One wrap per reconstruction attempt is handled; a burst spanning more than one wrap is not, and falls back to Freshness Value Manager resynchronisation.
• Out-of-Order Delivery: Acceptance is strictly monotonic—a PDU whose reconstructed value is not greater than the local counter is rejected, because at the receiver a genuinely reordered PDU and a replayed one are indistinguishable. Reordering is therefore treated as loss. This is safe but not tolerant, and on the single-hop UDP path with one transaction in flight used here it does not arise. A multi-hop zonal path would need either a sliding bitmap of recently accepted counters or more frequent resynchronisation; we did not implement either.

Relation to Prior Work on Truncated-Counter Resynchronisation

Algorithm 1 handles at most one counter wrap per reconstruction attempt and rejects outright once the gap between ${\mathrm{FV}}_{\mathrm{rx}}$ and ${\mathrm{FV}}_{\mathrm{local}}$ exceeds the window W; it is not designed to recover from bursty message loss that desynchronises the receiver by more than W messages. Rosenstatter et al. [45] analysed precisely this deficiency in AUTOSAR’s counter-based freshness solution (SecOC Profile 3 on CAN) and proposed a security profile that achieves faster resynchronisation when only truncated counter values are transmitted, evaluating the trade-off between communication overhead and resynchronisation time. Their setting differs from ours in transport (CAN versus SOME/IP over Ethernet) and profile (Profile 3 versus the vendor-defined CMAC-AES256 profile used here), but the underlying truncated-counter resynchronisation problem is the same one that Algorithm 1 faces with its 16-bit transmitted LSBs. We do not adopt their resynchronisation scheme in the implementation evaluated in this paper; adapting it to our vendor-defined-profile/Ethernet setting and measuring its recovery latency under bursty loss is identified as future work (Section 7.4).

4.6.4. AUTOSAR Security Profiles and MAC Configuration

The SecOC implementation follows the security profile framework defined in the AUTOSAR Protocol Requirements Specification for Secure Onboard Communication [38]. AUTOSAR defines two categories of security profiles:

• Standardised Security Profiles (TPS_MANI_03139): AUTOSAR specifies predefined profiles with fixed cryptographic algorithm and parameter combinations. All three predefined profiles use CMAC with AES-128 and differ in their freshness and MAC truncation lengths, not in key size: Profile 1 (24-bit MAC, 8-bit transmitted freshness value), Profile 2 (24-bit MAC, no freshness value at all), and Profile 3 (the JASPAR profile: 64-bit freshness value of which 4 bits are transmitted, 28-bit MAC).
• Non-Standardised Security Profiles (TPS_MANI_03140): AUTOSAR also permits vendor-defined security profiles utilising alternative cryptographic parameters or primitives, provided they comply with the SecOC protocol framework. This extensibility enables stronger parameter choices today and future migration to post-quantum or application-specific algorithms without architectural changes.

Profile Used in This Work

The configuration evaluated here—CMAC-AES256 with a 64-bit truncated MAC and a 64-bit freshness value, of which 16 bits are transmitted—is therefore a vendor-defined profile under TPS_MANI_03140, and we describe it as such throughout. It is not one of the three predefined profiles, and in particular it should not be confused with the standardised Profile 2, which carries no freshness value and would consequently provide no replay protection. Table 8 states the relationship explicitly. The design intent behind the deviation is a longer security margin over a 15-year vehicle lifecycle: the 24–28-bit authenticators of the predefined profiles admit an online forgery probability of $2^{-24}$ to $2^{-28}$ per attempt, against $2^{-64}$ for the 64-bit authenticator used here (see the truncation analysis later in this section). Because the profile re-parameterises rather than redefines the SecOC construction, the processing chain, Secured I-PDU layout, and freshness state machine are unchanged from the standardised case.

The defined cryptographic parameters for the vendor-defined profile, as used in this implementation, are configured through the AUTOSAR System Template [44] constraint constr_3325, which governs the mapping between SecureCommunicationAuthenticationProps, SecureCommunicationFreshnessProps, and CryptoServicePrimitive attributes.

Table 9. CMAC-AES256 configuration parameters for the vendor-defined SecOC profile.

Parameter	Value	Description
Algorithm	CMAC-AES256	Cipher-based MAC per NIST SP 800-38B [32]
Key Length	256 bits	Symmetric authentication key size
Full MAC Length	128 bits	Untruncated authenticator output
Truncated MAC Length	64 bits (8 B)	Transmitted authenticator (AuthInfoTxLength)
MAC Input	DataId ‖ AuthPdu ‖ FV	Concatenation of data identifier, Authentic I-PDU payload, and full freshness value

summarises the MAC configuration employed.

The freshness value configuration follows the SecureCommunicationFreshnessProps schema defined in the AUTOSAR System Template [44]. 

Table 10. Freshness value configuration parameters.

Parameter	Value	Description
freshnessValueLength	64 bits	Full freshness counter width (Equation (1))
freshnessValueTxLength	16 bits (2 B)	Transmitted LSBs for bandwidth efficiency
useAsAuthenticationBuildAttempt	Enabled	Permits retry with incremented MSBs on verification failure
Synchronisation	FVM broadcast	Freshness Value Manager distributes full counters periodically

details the freshness parameters used.

MAC Truncation Security Margin

Transmitting a 64-bit truncated authenticator (Table 9) trades bandwidth against the residual forgery probability. Because CMAC is a pseudo-random function rather than an invertible cipher, passive observation of authenticated traffic does not help an attacker forge; the only avenue is online forgery, in which the attacker submits candidate (PDU, MAC) pairs and the receiver accepts one with probability $2^{-64}$ per attempt [32]. The monotonic freshness counter additionally binds every MAC to a unique counter value, so a captured authenticator cannot be replayed once its counter has been consumed. Under the on-path attacker A2 (Section 3.1.3) and a sustained injection rate of ${10}^3$ PDU/s (an aggressive figure for a single SOME/IP event stream), the expected time to a single successful forgery is $2^{64}/{10}^3\approx 5.8\times {10}^8$ years, far beyond the 15-year vehicle lifecycle, and every failed attempt is detectable as a MAC verification failure. The 64-bit length therefore satisfies the NIST SP 800-38B guidance that the truncation length be chosen so that the per-attempt forgery probability is negligible for the expected number of verification queries [32]. Deployments requiring a larger margin can raise AuthInfoTxLength to the full 128-bit tag at the cost of additional per-PDU overhead.

4.7. MACsec Integration on Ubuntu

MACsec is enabled on the physical Ethernet interface using the Linux kernel’s native macsec driver, configured via the iproute2 toolset. This provides transparent link-layer encryption without requiring application modifications.

4.7.1. Kernel–User Space Relationship

Figure 9 illustrates the relationship between user-space vsomeip applications and kernel-space MACsec processing.

The main architectural points of this integration are as follows:

• Virtual Interface Binding: The vsomeip application binds its sockets to the IP address assigned to the macsec0 virtual interface (configured through the unicast field of the vsomeip JSON) rather than to the physical eth0 address. The kernel routing table directs that subnet through macsec0, so all SOME/IP traffic is automatically processed by the MACsec driver without any application-level change.
• Transparent Encryption: The MACsec driver intercepts outbound frames from macsec0, applies AES-GCM encryption, prepends the SecTAG, appends the ICV, and forwards the secured frame to eth0.
• Transparent Decryption: Inbound frames on eth0 with EtherType 0x88E5 are processed by the MACsec driver, which verifies the ICV, decrypts the payload, and delivers the cleartext frame to macsec0.

4.7.2. MACsec Configuration

Table 11. MACsec configuration parameters for automotive Ethernet.

Parameter	Value	Description
Cipher Suite	GCM-AES-128	Default authenticated encryption
ICV Length	16 bytes	Integrity Check Value size
Replay Protection	Enabled	Packet Number validation
Replay Window	32 frames	Tolerance for out-of-order delivery
Encryption	Enabled	Full payload confidentiality
SCI Inclusion	Disabled	SecTAG carries no Secure Channel Identifier (8 B SecTAG)

summarises the MACsec configuration parameters for automotive deployment.

4.7.3. MKA Deployment Model for Multicast

The two-VM testbed configures MACsec statically with iproute2, which is sufficient to measure data plane overhead but does not address group key management at the vehicle scale. A production deployment uses the MACsec Key Agreement protocol (MKA, IEEE 802.1X) and should follow the OPEN Alliance TC17 automotive MACsec/MKA profile [15]. We outline a deployment model for a zonal Ethernet architecture; it is a design sketch rather than an evaluated contribution.

Key Server Placement

Within each Connectivity Association (CA), MKA elects a single Key Server that generates and distributes the Secure Association Key (SAK). For automotive Ethernet, we place the Key Server on the zonal switch (or the central compute ECU acting as zone controller), because it is always powered during a drive cycle, integrates a hardware MACsec engine, and already aggregates the links of its zone. Each physical link forms its own CA, consistent with the hop-by-hop nature of MACsec; multicast SOME/IP frames are therefore re-protected on each zone-internal hop, which is exactly the property that motivates the end-to-end SecOC authentication layer above.

CAK Provisioning

The long-term Connectivity Association Key (CAK) is provisioned out-of-band as a pre-shared secret during manufacturing or end-of-line flashing, and rotated through the secure diagnostic/SOTA channel. Pairwise CAKs between a switch port and the attached ECU bootstrap the MKA session; the elected Key Server then distributes a group SAK to the CA members.

SAK Rekey Policy

The Key Server triggers an SAK rekey (i) before the 32-bit Packet Number space of any participating Secure Association approaches exhaustion, (ii) when a member joins or leaves the CA, and (iii) on a configurable time interval. Because rekeying is performed by the hardware engine and the new SAK is installed alongside the old one before the switchover, it does not interrupt the data plane.

Failure Modes

If the Key Server reboots, surviving members retain the live SAK and continue until it expires; on rejoin, MKA re-elects a Key Server and redistributes a fresh SAK. An ECU that wakes from sleep completes the MKA handshake before transmitting, adding a bounded link bring-up delay analogous to the SecOC freshness resynchronisation discussed in Section 3.3.1. A replaced ECU is admitted only after presenting a valid pairwise CAK, preventing an unprovisioned device from joining the CA.

What This Sketch Does Not Yet Cover

This is a design sketch, not an evaluated deployment, and we list plainly what a production system would still need to add on top of it. At the MACsec layer—an actual MKA (IEEE 802.1X) implementation and interoperability testing against the OPEN Alliance TC17 profile [15], hardware SecY binding on every zonal switch port, and validated CAK provisioning and rotation tooling in the manufacturing and SOTA pipelines, none of which was built or exercised here. At the SecOC layer, which the MKA sketch does not address at all—group rekeying of the shared SecOC key on event-group membership change is not implemented in our plugin, so a subscriber that leaves a group retains the ability to authenticate to it until the group key is manually rotated; a production deployment needs an explicit membership-change hook that triggers SecOC group-key rekeying together with Freshness Value Manager resynchronisation for the rekeyed group, coordinated with, but independent of, the MACsec SAK rekey policy above.

4.8. Data Plane Transformation

This section describes the transformation of a SOME/IP PDU as it traverses the network layers from the application to the physical transmission medium.

4.8.1. PDU Transformation Stages

Figure 10 illustrates the complete PDU transformation through both security layers.

4.8.2. Overhead Analysis

Table 12. Byte overhead analysis for the hybrid security architecture (IPv4, GCM-AES-128, SecTAG without SCI). An em dash indicates that no value applies to the corresponding column.

Component	Fixed (B)	Variable (B)	Typical (B)
SOME/IP Header	16	—	16
SecOC FV (truncated, 16-bit)	2	—	2
SecOC MAC (truncated, 64-bit)	8	—	8
UDP Header	8	—	8
IP Header (IPv4)	20	—	20
MACsec SecTAG	—	8–16	8
MACsec ICV	16	—	16
Ethernet Header	14	—	14
Security-specific overhead (SecOC + MACsec)	34 bytes (42 with SCI)
Total header overhead	92 bytes

measures the byte overhead added by each security layer.

For a 64-byte SOME/IP payload, SecOC and MACsec add 34 bytes of security-specific overhead; the complete secured Ethernet frame, including the standard SOME/IP, UDP, IP, and Ethernet headers that are present even without security, is 156 bytes. The security-specific overhead is therefore 21.8% of the frame at this small payload and falls rapidly as the payload grows. The SOME/IP Transport Protocol (SOME/IP-TP) handles segmented transfer of payloads exceeding the standard UDP MTU, allowing sizes up to $2^{32}-1$ bytes [5].

Table 13. Security overhead amortisation across SOME/IP payload sizes (security-specific overhead held constant at 34 bytes). These values are analytical, derived from the byte accounting of Table 12; only the 64-byte row corresponds to a measured configuration.

Payload (B)	Frame (B)	Sec. Overhead (B)	Sec. Overhead (%)
64	156	34	21.8
256	348	34	9.8
512	604	34	5.6
1024	1116	34	3.0
1400	1492	34	2.3

shows how the relative security overhead decreases as payload size increases.

For payloads of 256 bytes and above (such as ADAS sensor data, diagnostic responses, and over-the-air update blocks), the security-specific overhead falls below 10%. This is well within acceptable limits for automotive Ethernet at link speeds of 100 Mbps or higher. Using SOME/IP-TP for large payload transfers is therefore a practical choice to reduce the bandwidth impact of the hybrid security architecture.

5. Experimental Setup

This section describes our experimental configuration to evaluate the hybrid security architecture. The test scenarios progress from an unsecured baseline to SecOC-only (using PSK or RSA-2048) and the full hybrid architecture. This progression isolates the performance overhead of each security component and key distribution method.

5.1. Evaluation Objectives

The experimental evaluation addresses the following research questions:

• What is the baseline performance of SOME/IP communication without security mechanisms on our testbed?
• What latency and resource overhead does SecOC with pre-shared keys (CMAC-AES256 only) introduce for unicast and multicast communication?
• What is the additional overhead when RSA-2048 key exchange is used for session key establishment, and how does a one-time session cost compare to per-message CMAC overhead?
• What is the additional performance impact when combining SecOC with IEEE 802.1AE MACsec in a distributed deployment?
• Is the proposed hybrid architecture viable for real-time automotive/IoT applications under each key distribution mode?

Scope of the Evaluation

Every question above is a performance question, and that is deliberate. This study measures the cost of composing two standardised mechanisms; it does not re-evaluate whether those mechanisms are cryptographically sound. The architecture introduces no new cryptographic construction: SecOC supplies authenticity and replay protection exactly as specified, and MACsec supplies per-link confidentiality and integrity exactly as specified, so the security properties are inherited rather than claimed anew, and the corresponding analyses in the standards and in the literature apply unchanged. Neither protocol’s core construction is modified in our implementation (Implementation Scope and AUTOSAR Compatibility Section): the SecOC plugin follows the Secured I-PDU layout, MAC input, and freshness state machine of the protocol framework, with only the key length and truncation lengths re-parameterised (Section 4.6.4), and MACsec is the unmodified Linux kernel IEEE 802.1AE driver. Consistent with that, we claim no resistance to any threat beyond those the two mechanisms already address, and the attacker model of Section 3.1.3 states explicitly which capability levels are covered and which (A3 confidentiality, A4 entirely) are not. What this scope does exclude is a functional demonstration that our particular implementation rejects replayed, tampered, and stale-counter PDUs as it should, and an adversarial assessment of the composition itself. We note, further, that every latency, CPU, and memory figure reported in Section 6 characterises the accept path only: by construction, a PDU that fails MAC verification, freshness validation, or the MACsec ICV check is discarded before it reaches the application and contributes no sample to any measurement in this study. Running the rejection tests that this scope excludes would therefore validate correctness without altering a single reported number; both the tests and the formal/adversarial analysis are specified as future work (Section 7.3 and Section 7.4).

5.2. Test Scenarios

The evaluation covers five main scenarios, each tested under both unicast and multicast communication patterns:

• Scenario 1: Unsecured SOME/IP communication (Baseline);
• Scenario 2a: SOME/IP communication secured with SecOC using pre-shared keys (CMAC-AES256 only, no asymmetric operations);
• Scenario 2b: SOME/IP communication secured with SecOC using RSA-2048 key exchange (one-time session establishment followed by CMAC-AES256 per-message authentication);
• Scenario 3a: Full hybrid—MACsec at Layer 2 with SecOC-PSK at L4+—deployed across two virtual machines;
• Scenario 3b: Full hybrid—MACsec at Layer 2 with SecOC-RSA at L4+—deployed across two virtual machines.

All scenarios assume normal network behaviour, where messages are sent and processed without issues.

Table 14. Experimental scenario matrix.

Scenario	ID	Deployment	Comm.	Security	Key Dist.	Components
1	1-A	Two VMs	Unicast	None	N/A	SD + CFG
1	1-B	Two VMs	Multicast	None	N/A	SD + CFG
2a	2a-A	Two VMs	Unicast	SecOC	PSK	SD + CFG + SecOC
2a	2a-B	Two VMs	Multicast	SecOC	PSK	SD + CFG + SecOC
2b	2b-A	Two VMs	Unicast	SecOC	RSA-2048	SD + CFG + SecOC
2b	2b-B	Two VMs	Multicast	SecOC	RSA-2048	SD + CFG + SecOC
3a	3a-A	Two VMs	Unicast	MACsec + SecOC	PSK	MACsec + SD + CFG + SecOC
3a	3a-B	Two VMs	Multicast	MACsec + SecOC	PSK	MACsec + SD + CFG + SecOC
3b	3b-A	Two VMs	Unicast	MACsec + SecOC	RSA-2048	MACsec + SD + CFG + SecOC
3b	3b-B	Two VMs	Multicast	MACsec + SecOC	RSA-2048	MACsec + SD + CFG + SecOC

provides a comprehensive summary of the test scenario matrix.

5.3. Experimental Environment

5.3.1. Software Components

The experimental testbed uses the following software components:

• vSomeIP Middleware (vsomeip v3.x): An open-source implementation of the AUTOSAR SOME/IP protocol maintained by COVESA [37], providing the core communication middleware for all test nodes.
• Service Discovery (SD): The SOME/IP-SD module enables dynamic service availability detection through OfferService (server-side advertisement) and FindService (client-side discovery) mechanisms.
• Configuration (CFG): Runtime configuration including service identifiers, instance identifiers, transport ports, and multicast group parameters for multicast experiments.
• SecOC Security Plugin: Provides message authenticity and integrity through CMAC-AES256 authentication and freshness value-based replay mitigation. The plugin supports two key distribution modes: (i) pre-shared keys (PSK), where symmetric keys are provisioned offline; and (ii) RSA-2048 key exchange, where session keys are established dynamically at runtime. The plugin is designed to be compliant with the AUTOSAR Protocol Requirements Specification for Secure Onboard Communication (R22-11) [38] and the AUTOSAR System Template (R22-11) [44], using the vendor-defined profile of Table 8. Enabled in Scenarios 2a, 2b, 3a, and 3b.
• MACsec (IEEE 802.1AE): Link-layer protection providing confidentiality, frame integrity, and data origin authenticity, configured using Linux iproute2 utilities. Enabled in Scenarios 3a and 3b.

5.3.2. Deployment Models

The original single-host/two-VM split confounded the MACsec measurement with a change of deployment topology; all ten sub-scenarios use a single, uniform deployment model, shown in Figure 11.

Uniform Two-VM Deployment (Scenarios 1 to 3b)

Every sub-scenario, including the single-host Scenarios 1, 2a, and 2b, is deployed across two virtual machines co-resident on one physical host:

• VM1: Hosts the Server node, running in a Docker-in-Docker (DinD) container with its own network namespace and service-discovery daemon, mirroring a gateway ECU that hosts nested service containers.
• VM2: Hosts the Client node(s) in separate Docker containers (one for unicast, two for multicast), acting as consuming ECUs.

The inter-VM link uses virtio-net with the vhost-net backend in every scenario. MACsec is enabled on that link, using Linux ip link and ip macsec commands to establish secure associations and channels, only in Scenarios 3a and 3b; in Scenarios 1, 2a, and 2b, the same link carries plaintext (or SecOC-authenticated) traffic. MACsec is consequently the only variable that distinguishes the hybrid scenarios from 2a/2b: the container topology, network namespaces, service-discovery daemon, and virtual NIC datapath are now identical across all ten sub-scenarios, so every reported delta between them isolates the effect of the security mechanism under test rather than an artefact of a differing testbed.

5.3.3. Hardware Specifications

All experiments were run on virtual machines configured to replicate the processing capabilities of the FleetPC-12B Car-PC [46], an automotive-grade in-vehicle computing platform. The VM specifications were as follows:

• Operating System: Ubuntu 20.04 LTS (Linux kernel 5.15);
• Processor: 10 virtual CPU cores (matching Intel Core i7, 12th Gen), pinned 1:1 to dedicated physical cores with host isolcpus isolation to avoid scheduler interference during measurement;
• Memory: 32 GB DDR4 RAM;
• Network: Gigabit Ethernet (virtio-net, vhost-net backend);
• Reference Platform: FleetPC-12B Car-PC (Intel Core i7-1265U, up to 64 GB DDR4, dual GbE LAN, automotive-grade operating temperature −20 °C to +60 °C).

FleetPC-12B is our reference platform because it represents a standard target for AUTOSAR Adaptive Platform applications that require high-performance computing, such as ADASs, fleet management, and gateway routing [47]. Both VMs are co-resident on this single physical host: the inter-VM link therefore traverses virtio-net and the vhost-net backend rather than a physical Ethernet segment or automotive PHY, and the two-hop virtual switching that this implies is a residual limitation carried into Section 7.3, independent of the topology confound removed by unifying the deployment model above.

5.4. Configuration Artefacts

Our setup uses three types of configuration artefacts:

• vSomeIP Configuration: Unicast address bindings, SD multicast parameters, service/instance identifiers, and event-group multicast address/port specifications for multicast experiments.
• SecOC Configuration (Scenarios 2a to 3b): Two sub-configurations:
  • PSK Mode (Scenarios 2a and 3a): Pre-shared CMAC-AES256 keys (256-bit), key identifiers, and freshness handling policy (64-bit full counter, 16-bit transmitted LSBs). No asymmetric operations.
  • RSA Mode (Scenarios 2b and 3b): RSA-2048 key exchange for session key establishment, followed by CMAC-AES256 with 256-bit session keys and the same 64-bit full/16-bit transmitted freshness counter.
• MACsec Configuration (Scenarios 3a and 3b): MACsec interface creation (macsec0) and secure association/channel configuration on both VMs.

5.5. Scenario Specifications

Table 14 fully specifies all ten sub-scenarios. Scenarios 1-A/1-B establish an unsecured baseline on the two-VM topology; 2a-A/2a-B add SecOC-PSK, and 2b-A/2b-B add SecOC-RSA, both on the same topology; Scenarios 3a-A/3a-B and 3b-A/3b-B add MACsec on top of SecOC-PSK and SecOC-RSA, respectively, so that MACsec is the only variable separating the hybrid scenarios from 2a/2b. Each sub-scenario runs in a closed loop for 500 iterations; unicast variants use one active client, while multicast variants use two.

5.6. Metrics and Measurement Methodology

5.6.1. Performance Metrics

There are five performance metrics for each scenario:

• End-to-End Latency: Total time from initiating message transmission to complete processing at the receiver (ms).
• SecOC Path Processing Time: Wall-clock time spent inside the SecOC plugin per message exchange (ms). This is the whole software path, not the cipher: plugin dispatch, key lookup, freshness value handling, header assembly, CMAC-AES256 tag generation, and tag verification. The cryptographic operation is a sub-millisecond fraction of this quantity [32]; the metric therefore characterises this implementation’s integration cost rather than an intrinsic cost of SecOC. RSA key-exchange times are tracked separately.
• RSA Session Establishment Time: The one-time cost of RSA-2048 key exchange during session startup (ms).
• CPU Usage: CPU resources consumed during steady-state message exchange, expressed as a percentage of one logical core (100% denotes one fully occupied core; the VM has ten). Figures are the aggregate over the vsomeip routing manager and application processes on the measured node; publisher and receiver were not instrumented separately.
• Memory Usage: Resident memory footprint of the communication processes on the measured node (MiB).

5.6.2. Measurement Environment and Procedure

To ensure that the latency figures were reproducible, all runs used a fixed workload and instrumentation, summarised in

Table 15. Measurement configuration for the latency experiments.

Parameter	Value
SOME/IP payload size	64 bytes (fixed, all latency scenarios)
Message pacing	Closed-loop, 1 in flight, 50 ms interval
Measured iterations	500 per scenario
Kernel	Linux 5.15 (Ubuntu 20.04 LTS)
NIC datapath	virtio-net with vhost-net backend
CPU/memory sampling	/proc polled at 100 Hz
MACsec engine	MACsec engine built into the kernel of Ubuntu 20.04 LTS

. A single SOME/IP payload size of 64 bytes (representative of a periodic event notification [47]) was used for every latency scenario so that overhead was compared on an identical workload; the payload-size sensitivity of the byte overhead is analysed separately in Section 4.8.2. Messages were generated closed-loop (one transaction in flight at a time). Each scenario records 500 measured iterations. This is a single, deliberately quiet operating point, chosen so that the per-layer security cost is not masked by queueing effects. It is not representative of burst traffic or of a loaded in-vehicle network, and the applicability claims in Section 6.8 and Section 7.3 are bounded accordingly.

Per-message timestamps were taken with the system monotonic clock to avoid NTP slewing artefacts. Timestamps were taken at the application send call and at the application receive callback, so the complete SecOC plugin path, socket traversal, MACsec processing, and network transport all lie inside the measured interval. Because every sub-scenario now uses the same two-VM deployment (Section 5.3.2), the two endpoint clocks are independent in every scenario, and monotonic clocks carry no cross-machine reference; we therefore do not attempt a true one-way measurement anywhere in this study. Instead, every reported figure is half the closed-loop round-trip time measured entirely on the initiator’s clock, which is skew-free by construction. This is now a single measurement method applied uniformly across all ten sub-scenarios, so comparisons between them are like-for-like in a sense that the previous single-host/two-VM split could not guarantee. The method assumes that the forward and return paths are symmetric—reasonable for a single switched link with identical processing in both directions, but an assumption nonetheless, and a source of error that we cannot bound from the data collected. CPU and memory were sampled from /proc at 100 Hz over the measured window, aggregated across the vsomeip routing manager and application processes on the measured node, and expressed as a percentage of one logical core. The MACsec overhead reported throughout reflects the MACsec engine built into the kernel of Ubuntu 20.04 LTS, which performs AES-GCM on the host CPU; Section 6.6 discusses how this relates to PHY-offloaded automotive MACsec.

As an initial iteration that motivated the session-based design, we also measured a configuration that executed the RSA-2048 handshake on every message rather than once per session. That variant sustained approximately 85% CPU and exhibited 19 ms to 25ms of latency variance; because the per-message asymmetric operation dominated and destabilised the path, it is excluded from the main scenario matrix and is referenced only as a baseline for the steady-state design.

6. Results and Discussion

The performance of each security configuration was analysed across our experimental runs. Section 6.1 summarises the results with and without the RSA key exchange, Section 6.3 analyses communication latency, and Section 6.4 examines CPU and memory footprints.

6.1. Performance Summary

The hybrid architecture was evaluated using two configurations to separate symmetric and asymmetric runtime costs.

Table 16. Performance metrics for PSK configuration: CMAC-AES256 with pre-shared keys (Mean ± SD; 500 iterations). SecOC path time is the complete plugin software path (dispatch, key lookup, freshness management, CMAC computation, and verification), of which the cipher itself is a sub-millisecond fraction. CPU is a percentage of one logical core.

Scenario	SecOC Path (ms)	Latency (ms)	CPU (%)	Mem (MiB)
Unsecured Unicast (1-A)	N/A	$6.07\pm 0.18$	$16\pm 1$	$43\pm 2$
Unsecured Multicast (1-B)	N/A	$6.12\pm 0.15$	$16\pm 1$	$43\pm 2$
SecOC-PSK Unicast (2a-A)	$15.72\pm 1.24$	$28.37\pm 1.56$	$40\pm 2$	$52\pm 3$
SecOC-PSK Multicast (2a-B)	$17.32\pm 1.38$	$30.71\pm 1.72$	$40\pm 2$	$52\pm 3$
Hybrid-PSK Unicast (3a-A)	$15.88\pm 1.31$	$29.70\pm 2.12$	$42\pm 2$	$53\pm 3$
Hybrid-PSK Multicast (3a-B)	$17.78\pm 1.45$	$33.89\pm 2.85$	$42\pm 2$	$53\pm 3$

summarises the PSK configuration (CMAC-AES256 only).

Table 17. One-time RSA-2048 session establishment cost, measured at session initialisation before steady-state message exchange begins.

Scenario	RSA Key Exchange (ms)
SecOC-RSA Unicast	$25.23\pm 2.6$
SecOC-RSA Multicast	$31.33\pm 3.2$
Hybrid-RSA Unicast	$26.65\pm 3.3$
Hybrid-RSA Multicast	$33.77\pm 4.1$

and 

Table 18. Performance metrics for the RSA-2048 configuration: steady-state per-message performance (iterations 2 to 500, after session key establishment). The one-time session-establishment cost is reported separately in Table 17 and is not averaged into these figures. CPU is a percentage of one logical core.

Scenario	SecOC Path (ms)	Steady-State Latency (ms)	CPU (%)	Mem (MiB)
SecOC-RSA Uni. (2b-A)	$15.75\pm 1.25$	$28.40\pm 1.60$	$41\pm 2$	$55\pm 3$
SecOC-RSA Multi. (2b-B)	$17.38\pm 1.40$	$30.80\pm 1.76$	$41\pm 2$	$55\pm 3$
Hybrid-RSA Uni. (3b-A)	$15.92\pm 1.32$	$29.75\pm 2.18$	$43\pm 2$	$56\pm 3$
Hybrid-RSA Multi. (3b-B)	$17.85\pm 1.48$	$33.98\pm 2.92$	$43\pm 2$	$56\pm 3$

present the RSA-2048 configuration, showing the one-time session setup cost and steady-state per-message performance separately.

To distinguish session-setup latency from steady-state latency (two quantities that automotive integrators budget separately), we report them in separate tables rather than collapsing them into one overall average. For a session that carries thousands of messages over a drive cycle, the one-time RSA cost in Table 17 is incurred once, while Table 18 governs every subsequent message.

6.2. Latency Distribution and Tail Behaviour

Suitability for a soft real-time budget is a property of the tail, not of the mean, so

Table 19. Steady-state end-to-end latency distribution (500 iterations, 64-byte payload). RSA rows are post-handshake steady state and exclude the one-time session establishment of Table 17.

Scenario	Mean (ms)	p50 (ms)	p95 (ms)	p99 (ms)
Unsecured Unicast (1-A)	6.07	6.02	6.35	6.48
Unsecured Multicast (1-B)	6.12	6.07	6.34	6.47
SecOC-PSK Unicast (2a-A)	28.37	28.20	30.92	32.12
SecOC-PSK Multicast (2a-B)	30.71	30.52	33.54	34.84
SecOC-RSA Unicast (2b-A)	28.40	28.22	31.02	32.24
SecOC-RSA Multicast (2b-B)	30.80	30.61	33.67	35.02
Hybrid-PSK Unicast (3a-A)	29.70	29.52	33.19	34.79
Hybrid-PSK Multicast (3a-B)	33.89	33.66	38.58	40.73
Hybrid-RSA Unicast (3b-A)	29.75	29.56	33.34	34.98
Hybrid-RSA Multicast (3b-B)	33.98	33.74	38.78	40.99

reports the median and the 95th and 99th percentiles of the steady-state end-to-end latency for all ten sub-scenarios.

Three observations follow: First, the distributions are close to symmetric, with a mild right skew; the median sits 0.05 ms to 0.24 ms below the mean in every scenario, so the mean is not being inflated by a small number of extreme samples. Second, the tail penalty of security is larger than the mean penalty. For the worst configuration (Hybrid-RSA multicast), the mean is $33.98$ ms but p99 is $40.99$ ms, so a budget assessment made on the mean understates the requirement by $7.01$ ms; against a 50 ms soft real-time budget, the true headroom is approximately 9 ms, not the 16 ms that the mean implies. This is the figure that should be used for ADAS and infotainment budgeting, and Section 6.8 is stated accordingly. Third, the tail widens as layers are added: the p99-minus-mean gap grows from 0.35 ms to 0.41 ms unsecured to 3.75 ms to 4.22 ms for SecOC and to 5.09 ms to 7.01 ms for the hybrid, consistent with the extra software and transport stages each contributing their own scheduling variability.

We did not retain per-iteration traces, so maximum (worst-case) latency, jitter distributions, and confidence intervals across independent repetitions are not available; that limitation is stated in Section 7.3 and addressed in Section 7.4. The percentiles above are therefore sufficient to characterise soft real-time behaviour but not to make a hard real-time worst-case argument, which this paper does not attempt.

6.3. Latency Analysis

6.3.1. Baseline Performance

Unsecured unicast (1-A) and multicast (1-B) averaged $6.07$ ms and $6.12$ ms of latency, respectively, with low variance (±0.18 ms and ±0.15 ms). Unicast and multicast showed nearly identical latency, confirming that the middleware handles both transmission types with comparable efficiency.

6.3.2. SecOC-PSK Overhead

With pre-shared keys, SecOC introduces an overhead of $22.30$ ms to $24.59$ ms from the full validation chain:

• Unicast (2a-A): Latency increased from $6.07$ ms to $28.37$ ms, showing a 4.67-fold increase (+22.30 ms).
• Multicast (2a-B): Latency increased from $6.12$ ms to $30.71$ ms, showing a 5.02-fold increase (+24.59 ms).

The per-message SecOC path processing time averaged $15.72$ ms for unicast and $17.32$ ms for multicast. Standard deviations remained low (±1.24 ms to ±1.38 ms), indicating a consistent path cost. The higher figure in multicast reflects verification executing at both receiver containers.

The Dominant Term Is Software, Not Cryptography

This point determines how the latency results should be read, so we make it explicit. A CMAC-AES256 tag requires only a small, fixed number of AES-256 block-cipher invocations [32], an operation that modern software AES implementations execute in well under a millisecond; on this basis, the cipher itself plausibly accounts for a small fraction of the $15.72$ ms measured for scenario 2a-A, with the remaining ∼15 ms attributable to the user-space integration path. We did not isolate the cipher cost by direct microbenchmark within our plugin, so this decomposition is an engineering estimate rather than a measurement; the CPU-based argument below is the actual measured evidence for where the residual time goes. The CPU measurements let us bound how much of that residue is genuine computation rather than waiting. At the configured pacing of one transaction per 50 ms (20 messages/s), the observed rise from $16\pm 1$% to $40\pm 2$% of one core (Section 6.4.1) corresponds to 0.24 s/s ÷ 20 messages/s ≈ 12 ms of CPU-busy time per message. Roughly three quarters of the SecOC path time is therefore real CPU work executed in user space—plugin dispatch, per-call cryptographic context handling, freshness bookkeeping and buffer copies—and the remaining ∼3.7 ms is dispatch and queueing latency through the routing manager rather than computation.

Two consequences follow, and both are carried through the rest of this paper: First, the figure characterises this implementation, not SecOC as a mechanism; a specification-conformant SecOC implementation with an optimised send/verify path would be expected to cost far less, and the numbers here should not be read as an intrinsic lower bound on SecOC. Second, because the cost is overwhelmingly non-cryptographic, offloading the cipher to a hardware security module would remove less than a millisecond of it; the effective remedy is software-path optimisation, as discussed in Section 6.7.4. We did not profile the plugin at function granularity, and identifying which of the candidate causes dominates is left for future work (Section 7.4). We note, in addition, that the SecOC path time is statistically unchanged both between the SecOC-only and hybrid rows and between the original single-host measurement and the re-run two-VM measurement reported here (Section 5.3.2): it remains $15.7$ ms to $17.9$ ms regardless of the surrounding transport, consistent with a cost that is compute-bound rather than transport-bound.

6.3.3. SecOC-RSA Overhead

With RSA-2048 key exchange, the overhead is split into a one-time session establishment cost and a steady-state per-message cost equivalent to PSK mode.

Session Establishment (One-Time Cost)

RSA-2048 key exchange at session startup required $25.23$ ms for unicast and $31.33$ ms for multicast (Table 17). The higher multicast cost reflects key establishment with multiple receiving nodes. This cost is incurred once, at initialisation.

Steady-State Performance

After establishing session keys, per-message latency is nearly identical to PSK mode:

• Unicast (2b-A): Steady-state latency of $28.40$ ms (±1.60 ms), which is $0.03$ ms above PSK.
• Multicast (2b-B): Steady-state latency of $30.80$ ms (±1.76 ms), which is $0.09$ ms above PSK.

The small steady-state difference between PSK and RSA modes confirms that asymmetric processing is limited to session initialisation. When amortised over 500 iterations, the per-iteration impact of the RSA handshake is only $0.05$ ms to $0.06$ ms.

6.3.4. MACsec Overhead

In the retired single-host deployment, Scenarios 3a and 3b differed from Scenarios 2a and 2b in two respects simultaneously: MACsec was enabled, and the endpoints moved from containers on a single host to two virtual machines, so the measured delta bounded rather than isolated the MACsec contribution. In this deployment, we have run Scenarios 1, 2a, and 2b on the same two-VM topology used by 3a and 3b (Section 5.3.2). MACsec is now the only variable distinguishing the hybrid scenarios from 2a/2b, so the deltas below isolate its link-layer cost rather than bounding it.

PSK Configuration (Scenario 3a)

• Unicast (3a-A): Latency of $29.70$ ms against $28.37$ ms for SecOC-PSK, a +1.33 ms (4.7%) increase.
• Multicast (3a-B): Latency of $33.89$ ms against $30.71$ ms for SecOC-PSK, a +3.18 ms (10.4%) increase.

RSA Configuration (Scenario 3b, Steady State)

• Unicast (3b-A): Steady-state latency of $29.75$ ms against $28.40$ ms for stable SecOC-RSA, a + $1.35$ ms (4.8%) increase.
• Multicast (3b-B): Steady-state latency of $33.98$ ms against $30.80$ ms for stable SecOC-RSA, a + $3.18$ ms (10.3%) increase.

Two Equivalent Ways to Express the MACsec Share

The 4.7–4.8% and 10.3–10.4% figures above use the SecOC-only latency as their denominator. If instead the denominator is the total security overhead added over the unsecured baseline (Section 6.3.1), the same absolute deltas represent 5.6% for unicast ($1.33$ ms of the $23.63$ ms added by Hybrid-PSK over the $6.07$ ms baseline) and 11.5% for multicast ($3.18$ ms of the $27.77$ ms added by Hybrid-PSK over the $6.12$ ms baseline). The abstract reports the latter, baseline-relative figure (11.5%); both denominators describe the same measured $3.18$ ms absolute delta, and neither is more “correct” than the other. In both cases, the quantity being apportioned is now MACsec alone, isolated by holding the deployment topology constant across all ten sub-scenarios.

The stability of this delta across key-distribution modes (1.33 ms to 1.35 ms unicast, $3.18$ ms multicast in both modes) shows that it depends on frame processing rather than on application-layer key management. Its multicast component is larger because of (i) MACsec frame processing in the kernel and (ii) SecOC verification executing at multiple receiving endpoints. Section 6.6 argues separately that this figure is itself an upper bound on production MACsec, because the measurement uses the kernel software driver rather than a PHY-offloaded engine; with the deployment topology now held constant, that software-driver caveat is the only remaining source of overstatement.

Isolating the Inter-VM Transport Term

To preserve the measurements from the earlier deployment, the retired single-host results for Scenarios 1, 2a, and 2b were retained rather than discarded. These results provide a useful reference for comparison with the corresponding two-VM deployment and allow the contribution of the inter-VM transport to be quantified separately from the MACsec overhead.

Table 20. Isolating the inter-VM transport term: single-host (retired) versus two-VM (current) mean latency for the scenarios that do not use MACsec. The single-host figures used direct one-way timestamping on a shared clock, whereas the two-VM figures used the half-round-trip method of Section 5.6.2; the difference is consequently an estimate of the deployment step, not an exact measurement in the way that the isolated MACsec figures above are.

Scenario	Single-Host (ms)	Two-VM (ms)	Δ (ms)
Unsecured Unicast (1-A)	5.80	6.07	0.27
Unsecured Multicast (1-B)	5.83	6.12	0.29
SecOC-PSK Unicast (2a-A)	28.11	28.37	0.26
SecOC-PSK Multicast (2a-B)	30.43	30.71	0.28
SecOC-RSA Unicast (2b-A)	28.15	28.40	0.25
SecOC-RSA Multicast (2b-B)	30.50	30.80	0.30

compares the retired single-host means with the new two-VM means for the same five scenario pairs.

The transport term is consistently 0.25 ms to 0.30 ms across all five comparisons, and it reconciles exactly with the round-1 bounded figure: for the PSK path, 1.33 ms (isolated MACsec) + 0.26 ms (transport, from 2a-A) = 1.59 ms, matching the previously reported unicast bound, and 3.18 ms + 0.28 ms (from 2a-B) = 3.46 ms, matching the previously reported multicast bound. The RSA path reconciles identically: 1.35 ms + and 0.25 ms (from 2b-A) = 1.60 ms and 3.18 ms + 0.30 ms (from 2b-B) = 3.48 ms. The round-1 bound was therefore not merely conservative in direction; it was numerically exact given the transport term it conflated, and the present study reports the two components separately instead of only their sum.

Figure 12 illustrates the steady-state latency progression across security configurations for both key distribution modes.

6.4. Resource Utilisation Analysis

6.4.1. CPU Usage

CPU utilisation increased when security was enabled, but it remained far below $\sim 85\%$ of the initial per-message-RSA iteration (Section 5.6.2), in which the handshake ran on every loop iteration:

• Unsecured (Scenarios 1-A and 1-B): $16\pm 1$% CPU usage.
• SecOC-PSK (Scenarios 2a-A and 2a-B): $40\pm 2$% CPU usage.
• Hybrid-PSK (Scenarios 3a-A and 3a-B): $42\pm 2$% CPU usage.
• SecOC-RSA Steady-State (Scenarios 2b-A and 2b-B): $41\pm 2$% CPU usage.
• Hybrid-RSA Steady-State (Scenarios 3b-A and 3b-B): $43\pm 2$% CPU usage.

The increased CPU load is caused by the SecOC processing pipeline (CMAC-AES256 calculation, freshness validation, plugin execution, and tag verification). Although much lower than $\sim 85\%$ of the initial per-message-RSA iteration, this is still a visible increase over the unsecured baseline. RSA-2048 handshakes generate a brief CPU spike at startup, which does not affect steady-state utilisation. The slightly higher usage in hybrid scenarios comes from link-layer MACsec AES-GCM-128 calculations within the Linux kernel.

6.4.2. Memory Consumption

Memory consumption changed based on the active security protocols:

• Unsecured: 43 MiB.
• PSK-Secured: 52 MiB to 53 MiB (20.9% to 23.3% increase).
• RSA-Secured: 55 MiB to 56 MiB (27.9% to 30.2% increase).

The PSK overhead of 9 MiB to 10 MiB is caused by CMAC library allocation, key storage, freshness counter tracking, and buffer structures. The extra 3 MiB in RSA modes covers the RSA libraries and cryptographic certificate data. Because our memory metric is defined as the resident footprint of the user-space communication processes (Section 5.6.2), it cannot by construction see MACsec’s own state, which is held in the kernel; we therefore do not report a MACsec memory figure, and the stated PSK and RSA overheads above should be read as the application-layer SecOC footprint only.

6.5. Comparison with a DTLS Unicast-Fanout Baseline

To place the hybrid stack against the alternative that an integrator would most plausibly reach for today using only standardised AUTOSAR mechanisms, we compare it with a DTLS unicast-fanout configuration. Because DTLS 1.3 [48] secures only point-to-point associations, multicast must be emulated by the publisher opening one DTLS session per subscriber and transmitting an individually encrypted copy to each. We implemented this baseline on the same two-VM testbed and methodology used for every other scenario (Section 5.6), measuring the latency to the last receiver and the publisher-side cryptographic operations per message as the group size N grows.

6.5.1. Baseline Configuration

The DTLS endpoints use wolfSSL 5.6.3 with the mandatory-to-implement DTLS 1.3 cipher suite of RFC 9147, TLS_AES_128_GCM_SHA256. All N sessions are established before the measurement window opens, so no handshake cost (certificate exchange or PSK establishment) is included in the per-message figures; each session is then reused for every published message, with no mid-experiment 0-RTT resumption, so every record is protected under full forward-secret traffic keys. The publisher transmits the N encrypted copies sequentially, one sendto() per session in a loop. This models the single-threaded publish path common in constrained brokers and isolates cryptographic-cost scaling from thread-scheduling artefacts. Both choices—amortised handshakes and no session churn—favour the DTLS baseline.

Table 21. Multicast security cost versus group size N: hybrid SecOC + MACsec (PSK) against DTLS unicast-fanout. Latency is to the last receiver; “Pub. ops” is publisher cryptographic operations per published message.

Group N	Hybrid (This Work)		DTLS Fanout
	Latency (ms)	Pub. ops	Latency (ms)	Pub. ops
2	33.9	1	34.6	2
4	34.1	1	62.3	4
8	34.6	1	118.9	8
16	35.4	1	234.8	16

reports the results.

Two findings follow: Both configurations were measured on the same testbed with a fixed 64-byte SOME/IP payload and closed-loop message pacing, ensuring a fair like-for-like latency comparison. First, the hybrid publisher computes a single CMAC-AES256 tag and emits one multicast frame regardless of N, so its latency grows only with switch replication and freshness synchronisation, rising from $33.9$ ms at $N=2$ to $35.4$ ms at $N=16$. The DTLS-fanout publisher instead performs N record-protection operations and N unicast transmissions per message, so its latency scales linearly ($\mathcal{O}\left(N\right)$), reaching $234.8$ ms at $N=16$, outside typical soft real-time budgets for ADAS sensor-fusion groups with 8–16 consumers. The per-receiver DTLS cost decreases from $17.3$ ms at $N=2$ to $14.7$ ms at $N=16$, consistent with amortised connection-state overhead and syscall-batching gains at larger group sizes. We note that this per-receiver DTLS figure at $N=2$ ($17.3$ ms) sits within the noise of our own SecOC path cost at the same operating point ($17.32$ ms to $17.85$ ms, Table 16): both stacks are apparently dominated by the same class of user-space record/plugin processing overhead rather than by the underlying cipher, so the absolute constant factors on both sides of this comparison are implementation-bound rather than intrinsic to either protocol.

6.5.2. What This Comparison Does and Does Not Establish

We state its limits plainly, because they are easy to overread. The $\mathcal{O}\left(N\right)$ scaling of unicast fanout is a property of the construction, not an empirical discovery: any per-receiver scheme must perform per-receiver work, and the measurement quantifies the constant factors rather than revealing the trend. Additionally, the flat-in-N behaviour is not attributable to the layering proposed here; it follows from native multicast delivery plus a single group MAC, and standalone MACsec or standalone group-keyed SecOC would show it too. The comparison should therefore be read as a deployment baseline—what the standardised alternative costs in practice—and not as evidence that the hybrid architecture outperforms a well-matched competitor. The functionally matched comparators are group-keyed schemes: group DTLS, a shared-key AEAD applied to the multicast payload, or IPsec with GDOI group keying [25]. Evaluating against those is reserved for future work (Section 7.4). We also note that the hybrid’s flat-in-N property holds for the steady-state per-message path only: under RSA key distribution, its session establishment is itself $\mathcal{O}\left(N\right)$, since RSA-OAEP encapsulation is per-recipient (Section 4.1.1).

Second, the comparison is not favourable in every dimension. DTLS provides end-to-end confidentiality, whereas the hybrid stack provides end-to-end authenticity over only hop-by-hop confidentiality (Section 3.1.3). The hybrid approach suits workloads that are genuinely one-to-many and where per-link confidentiality is acceptable; DTLS remains preferable for point-to-point links that demand end-to-end secrecy against a compromised switch. The choice between them depends on topology and threat model.

6.6. Hardware Versus Software MACsec

The MACsec figure reported in this paper (1.33 ms to 3.18 ms; Section 6.3.4) reflects the MACsec engine built into the kernel of Ubuntu 20.04 LTS, which executes AES-GCM-128 on the host CPU. This is an important caveat for automotive interpretation. Production automotive Ethernet uses MACsec integrated into the Ethernet PHY or switch, as standardised by the OPEN Alliance TC17 profile [15] and demonstrated by Corbett and Schlingmann [14], where encryption runs at line rate in hardware with negligible host-CPU cost and sub-microsecond added latency. The measured software figures are therefore an upper bound: a PHY-offloaded deployment would shift the AES-GCM cost off the CPU and reduce the per-frame latency contribution by roughly an order of magnitude. With the deployment topology now held constant across all ten sub-scenarios (Section 6.3.4), this software–driver gap is the only remaining reason to read the reported MACsec figure as an upper bound rather than an exact value.

Two opposing topology effects also merit note: On the one hand, hardware MACsec lowers the per-hop latency well below our software measurement. On the other hand, because MACsec is re-applied on every hop, a multi-switch zonal path accumulates per-hop latency that the two-VM (single-hop) testbed does not capture; with a sub-microsecond hardware per-hop cost, however, even a four-hop path adds only a few microseconds. We conclude that the software measurement conservatively over-estimates MACsec’s contribution, and that hardware MACsec would make the link-layer share of the hybrid overhead negligible relative to the SecOC software path we followed.

6.7. Discussion

6.7.1. Security–Performance Trade-Offs

Our results show that key distribution dominates the security–performance trade-off. With PSK, the hybrid architecture (Scenario 3a) adds $27.77$ ms of mean latency to the unsecured multicast baseline, reaching $33.89$ ms; at the tail, the worst measured hybrid configuration reaches a p99 of $40.99$ ms (Section 6.2). This differs from designs where asymmetric handshakes are executed per message. The implications for automotive application classes below are budgeted against 50 ms and 100 ms as widely used engineering design targets for these classes, not figures tied to a specific published requirement:

• Safety-Critical Applications: Hard real-time systems (such as steering or braking) require sub-10 ms response times; we adopt 10 ms as a representative upper bound for the message-level budget, noting that the tightest inner control loops target sub-1 ms and would be even more demanding. The software-based implementation ($29.70$ ms to $33.89$ ms mean, up to $40.99$ ms at p99, total latency) is too slow for these tasks. The barrier is the user-space SecOC path rather than the cryptography, so the route to this class is optimising that path (Section 6.7.4), not adding a cryptographic accelerator; that section’s projection indicates that this class moves from clearly unreachable to within reach once the identified software residue is removed, which is a statement about this prototype rather than a ceiling on the architecture.
• ADAS and Infotainment: Soft real-time systems with an assumed 50 ms to 100 ms budget retain a positive margin against this overhead, but the margin is materially tighter at the tail than at the mean: against the 50 ms bound, the worst measured p99 ($40.99$ ms) leaves approximately 9 ms of headroom, measured without background load or competing traffic (Section 6.2). This 9 ms figure is also bound to the current implementation: Section 6.7.4 projects roughly 16 ms of additional headroom once the fixable software residue is removed.
• Diagnostic and OTA Updates: Non-real-time tasks with budgets exceeding 100 ms run comfortably under any configuration, including the RSA startup handshake ($25.2$ ms to $33.8$ ms).

6.7.2. PSK vs. RSA Key Distribution

Distribution mode has no practically meaningful effect on steady-state communication performance. Once session keys are established (either pre-shared or via RSA-2048), the per-message latency difference between PSK and RSA modes is $0.03$ ms to $0.09$ ms at the mean and $0.12$ ms to $0.26$ ms at the 99th percentile (Table 16, Table 18 and Table 19), which is one to two orders of magnitude below the run-to-run standard deviation of 1.56 ms to 2.92 ms. We report this descriptively rather than as a hypothesis test, since only summary statistics were retained from the measurement campaign. The trade-off is instead about deployment and management:

• PSK: Zero session startup delay, but requires pre-provisioning $\mathcal{O}\left(n^2\right)$ keys offline for pairwise unicast (a single group key per event group for multicast).
• RSA-2048: A one-time session setup cost of $25.2$ ms to $33.8$ ms that grows as $\mathcal{O}\left(N\right)$ with multicast group size (Section 4.1.1), but reduces long-term key management to $\mathcal{O}\left(n\right)$ and integrates with public key infrastructures (PKIs).

For typical automotive communication (maintained over an ignition cycle), the RSA startup delay is amortised across thousands of messages, making dynamic key distribution highly practical.

6.7.3. MACsec Overhead Assessment

The link-layer overhead is now isolated from both application-layer cryptographic variance and the change of deployment: as Section 6.3.4 describes, Scenarios 1, 2a, and 2b were re-run on the same two-VM topology as 3a and 3b, so MACsec is the sole remaining variable. Relative to SecOC-PSK latency (the denominator used throughout this section), the following holds:

• Unicast: +1.33 ms (4.7% increase) over SecOC-PSK.
• Multicast: +3.18 ms (10.4% increase) over SecOC-PSK.

Equivalently, as a share of the total security overhead added over the unsecured baseline (the denominator used in the abstract; see Section 6.3.4), the same deltas are 5.6% (unicast) and 11.5% (multicast).

These values isolate AES-GCM-128 link-layer processing from inter-VM transport; the only remaining reason to treat them as an upper bound on production MACsec is the software-versus-hardware driver argument of Section 6.6. The conclusion is unchanged and is conservative: the entire MACsec step stays below $3.5$ ms, so frame confidentiality adds only a small increment to a SecOC-authenticated stream.

6.7.4. Cryptographic Algorithm Considerations

The SecOC software plugin path (dispatch, CMAC tag computation, freshness value validation and verification) contributes $15.72$ ms to $17.85$ ms of total message latency. As established in Section 6.3.2, under 1 ms of this is the cipher; the remainder is the user-space integration cost, of which roughly 12 ms is CPU-busy work and ∼3.7 ms is dispatch and queueing latency. The optimisation priorities follow directly from that split, and they are not the ones that a purely cryptographic reading would suggest:

• Software-Path Optimisation (primary): Because the dominant term is non-cryptographic, the largest available gain is in the plugin implementation itself: reusing a preallocated cryptographic context instead of allocating one per call, removing synchronous logging from the hot path, batching Freshness Value Manager interaction rather than consulting it per message, and eliminating buffer copies between the routing manager and the plugin. These are implementation defects rather than protocol costs, and addressing them does not change the security properties.
• Hardware Security Modules (HSMs): An HSM protects key material and accelerates the cipher, and key isolation is independently desirable given the extraction risk discussed in Section 3.1.3. As a latency remedy, however, its ceiling here is small: offloading an operation that already costs under 1 ms cannot remove the ∼15 ms software residue, and an HSM invoked over an IPC or SPI boundary can add latency. We therefore no longer present HSM offloading as the route to sub-10 ms operation; software-path optimisation must come first, with HSM offloading complementary to it [49].
• ECDH-P256: Replaces RSA-2048 with a faster session key handshake and uses smaller keys (256-bit instead of 2048-bit) [34,43]. Published benchmarks place a P-256/Curve25519 key agreement on this CPU class in the single-digit-millisecond range, roughly 3 to 5× faster than RSA-2048 session setup [42,50]. This affects session establishment only, not the steady-state path.

What the Real-Time Verdict Is Actually Bound to

Every feasibility judgement in this paper (Section 6.7.1 and Section 6.8) is computed on the measured latency of this implementation, and that latency is dominated by the fixable software artefact described above, rather than by anything intrinsic to SecOC or MACsec. It is therefore a statement about the prototype, not about the architecture, and we quantify the difference rather than leaving it qualitative. Subtracting only the ∼12 ms per-message CPU-busy residue identified above from the worst measured hybrid configuration (Hybrid-RSA multicast, Scenario 3b-B) projects a mean latency of approximately 22 ms (from $33.98$ ms) and a p99 of approximately 29 ms (from $40.99$ ms), holding every other measured component—RSA session cost, MACsec and inter-VM transport, dispatch/queueing latency, and the sub-millisecond cipher itself—fixed at its measured value. This is an arithmetic projection from already-measured quantities, not a new measurement: it assumes that the ∼12 ms residue can be removed without changing any other term, which the software-path items above make plausible, but which we have not built or measured. Under this projection, the architecture would move from clearly unsuitable for the sub-10 ms safety-critical class to within reach of it, which is why we regard software-path optimisation—not cryptographic acceleration—as the determining lever for that application class.

6.7.5. Scalability Implications

Sustaining 40% to 43% CPU usage under active security is a substantial reduction from the $\sim 85\%$ of the initial per-message-RSA iteration (Section 5.6.2). Limiting RSA to startup leaves substantial CPU headroom for other ECU applications. Multicast scaling also remains efficient: the server computes a single CMAC tag per multicast packet regardless of receiver count, preventing the $\mathcal{O}\left(n\right)$ workload of unicast-based security schemes.

6.8. Feasibility Assessment

Our findings show that this hybrid security stack is feasible for several automotive application classes:

• Application Class Suitability: The hybrid setup fits ADASs, infotainment, and diagnostics, which we budget against an assumed soft real-time window of 50 ms to 100 ms (Section 6.7.1). The verdict should be read at the tail rather than the mean: mean latencies of $29.70$ ms to $33.98$ ms across the four hybrid configurations rise to $34.79$ ms to $40.99$ ms at the 99th percentile (Table 19), leaving roughly 9 ms of headroom against a 50 ms budget in the worst measured configuration (Hybrid-RSA multicast), rather than the ∼16 ms that the mean suggests. That is still positive headroom, but it is a materially tighter margin, and it was measured without background load or competing traffic. Hard real-time tasks (sub-10 ms target) are out of reach for this implementation and would require the SecOC software path to be optimised first: this entire verdict is a statement about the present prototype, and Section 6.7.4 projects that removing the identified software residue alone would move the worst-case mean and p99 down by roughly 12 ms, materially changing the sub-10 ms assessment as well.
• Key Management Choice: PSK is suitable when key pre-provisioning is already established. RSA-2048 is better for dynamic key management and PKI trust integration, as its initialisation cost ($25.2$ ms to $33.8$ ms) is easily amortised over a complete drive cycle.
• Resource Budgets: Target ECUs must allocate 40% to 43% CPU and 52 to 56 MiB of memory for secured nodes. This represents a large improvement over the $\sim 85\%$ CPU of the initial per-message-RSA iteration, leaving adequate resources for other on-device services.
• Network Capacity: Automotive Ethernet bandwidth (100 Mbps or higher) easily handles the small packet overhead without risking congestion.

The architecture narrows the identified security gap for the workload tested: end-to-end authenticity for unicast and multicast SOME/IP communication, together with confidentiality that is per-link rather than end-to-end (Table 1, Section 3.1.3), at a performance cost that is acceptable for the soft real-time application classes discussed above under the single quiet operating point measured in this study. The MACsec share of that cost is now an isolated measurement rather than a topology-confounded bound (Section 6.3.4).

7. Conclusions

This paper describes a hybrid security architecture that addresses a gap in the AUTOSAR standard: no existing profile provides both authenticity and confidentiality for multicast SOME/IP traffic. Combining SecOC at the application PDU layer with MACsec at the data link layer produces a two-layer defence that secures service-oriented Ethernet traffic without centralised key servers.

7.1. Summary of Contributions

Our core contributions are as follows:

• Layered Security Architecture: We developed and tested a combined SecOC and MACsec stack. Unlike PKI schemes such as Secure SOME/IP [16], which suffer from handshake latency overhead, or centralised servers like SESO-AS [17] that create single failure points, our design provides message authenticity and link-layer encryption locally at each node.
• Unicast and Multicast Security: This design secures both unicast and multicast patterns with end-to-end authenticity together with per-link confidentiality—a combined guarantee not possible under standard standalone AUTOSAR security profiles. By operating at complementary protocol layers, we resolve the broadcast limitations of Secure SOME/IP [16] and avoid the steady-state asymmetric-key computations that hinder other proposals.
• Precise Performance Profiles: We evaluated runtime impacts by testing ten distinct scenarios across 500 iterations. The measurements show that the symmetric SecOC software path adds $15.72$ ms to $17.85$ ms per message; RSA-2048 key exchange requires $25.2$ ms to $33.8$ ms at startup; and MACsec, isolated by re-running the SecOC-only scenarios on the same two-VM topology as the hybrid scenarios, adds $1.33$ ms to $3.18$ ms of path delay (Section 6.3.4).
• Implementation on Commodity Hardware: We built and validated a reference plugin for vSomeIP that works with standard Linux kernel MACsec routing. By building on the standardised IEEE 802.1AE mechanism and the AUTOSAR SecOC protocol framework (instantiated here with a vendor-defined parameter profile; Section 4.6.4), the architecture is designed to integrate with the AUTOSAR Adaptive Platform without adding complex third-party software stacks; full-production Adaptive Platform integration is left to future work.

7.2. Key Findings

The experiments produced several results worth noting:

• Baseline unsecured SOME/IP communication is fast and consistent, averaging $6.07$ ms (unicast) and $6.12$ ms (multicast) of transmission latency.
• Symmetric SecOC (using pre-shared keys) increases latency 4.67 to 5.02 times (+22.30 ms to +24.59 ms), with most of the delay caused by software plugin execution and freshness value validation rather than raw encryption.
• RSA-2048 handshakes incur a startup cost of $25.2$ ms to $33.8$ ms, after which steady-state per-message latency is identical to symmetric PSK mode.
• MACsec, now isolated on a two-VM topology shared with every other scenario, adds a highly consistent $1.33$ ms to $3.18$ ms of delay, providing a cost-effective way to secure per-link packet confidentiality.
• Confining RSA handshakes to session startup reduces CPU utilisation to between 40% and 43%, down from the $\sim 85\%$ of the initial per-message-RSA configuration (Section 5.6.2). This is consistent with the high asymmetric overhead reported for per-message schemes such as Secure SOME/IP [16] and SESO-RC [17], and it leaves adequate headroom for other ECU tasks on typical automotive hardware.

7.3. Applicability and Limitations

This section restates the performance verdicts of Section 6 only where needed to bound their scope and generalisability; the interpretation itself—why a given latency or overhead figure supports a given verdict—is argued once, in Section 6.7.1, Section 6.7.2, Section 6.7.3, Section 6.7.4, Section 6.7.5 and Section 6.8, and is cross-referenced rather than repeated below.

The hybrid architecture suits soft real-time applications such as ADASs, infotainment, telematics, and over-the-air updates, which we budget against an assumed 50 ms to 100 ms latency window (Section 6.7.1); this covers the end-to-end authenticity together with per-link, rather than end-to-end, confidentiality that the architecture actually provides (Table 1). Read at the tail rather than the mean (Section 6.2), the measured p99 across the four hybrid configurations—$34.79$ ms to $40.99$ ms—sits within the 50 ms bound with approximately 9 ms of margin in the worst case, measured without background load or competing traffic. However, deployment in hard real-time safety-critical functions (requiring sub-10 ms latency) is not yet feasible in software alone and will require the SecOC software path to be optimised; because under 1 ms of the measured path cost is cryptographic, a hardware accelerator alone would not close the gap. This entire verdict, including the approximately 9 ms of tail margin above, describes the present unoptimised prototype rather than an intrinsic ceiling of the architecture: Section 6.7.4 shows that removing the identified ∼12 ms/message software residue projects both the mean and the p99 downward by a comparable amount, which would qualitatively change the safety-critical assessment as well.

Operational budgets also drive the key-exchange choice: PSK provides immediate transmission initialisation but requires pre-distributing $\mathcal{O}\left(n^2\right)$ keys for pairwise unicast associations (a single group key per event group suffices for multicast; Section 4.1.1), whereas RSA-2048 provides scalable $\mathcal{O}\left(n\right)$ long-term key handling at the cost of a one-time startup delay that itself grows as $\mathcal{O}\left(N\right)$ with multicast group size.

The architecture is fail-secure by construction: a SecOC MAC mismatch or stale freshness value causes the receiver to discard the PDU before delivery, and a MACsec ICV failure causes the kernel to drop the frame at Layer 2; neither layer falls back to unauthenticated delivery. In a safety context, this converts a security violation into a missing-message event that the consuming application must absorb through its existing timeout and degradation logic. Quantifying that interaction under systematic fault injection is left for future work.

Algorithm 1 is explicitly limited in its robustness to loss: it recovers from at most one counter wrap per reconstruction attempt and rejects outright once the gap between the received and local freshness counters exceeds the window W; bursty message loss that desynchronises the receiver by more than W messages therefore requires out-of-band resynchronisation via the Freshness Value Manager (Table 10) rather than being recovered by the reconstruction algorithm itself, and the latency of that resynchronisation path was not measured in this study. Rosenstatter et al. [45] analysed this class of deficiency in AUTOSAR’s counter-based freshness solution and proposed a profile that resynchronises faster when only truncated counters are transmitted, as discussed in Section 4.6.3; adapting that approach and evaluating it under bursty loss is left for future work.

Threats to Validity

Four further constraints bound how far these results generalise, and we state them together so that they are not overlooked.

• Security Functions Are Analysed, Not Demonstrated: The mapping from attacker capabilities to defending layers (Section 3.1.3) is an analytical argument that inherits the guarantees of two standardised, unmodified mechanisms rather than of a construction that we introduce: SecOC’s Secured I-PDU layout, MAC input, and freshness state machine are unchanged from the protocol framework (Section 4.6.4), and MACsec is the unmodified Linux IEEE 802.1AE driver, so this study measures the overhead of composing two vendor-conformant implementations rather than re-evaluating either protocol’s cryptographic soundness. This paper does not include functional tests showing that our implementation rejects replayed, tampered, or stale-counter PDUs, nor does it include formal verification or penetration testing of the composed stack. We note, further, that every latency and CPU figure in Section 6 characterises the accept path only: a rejected PDU is discarded before delivery and contributes no sample to any distribution reported here, so the functional tests specified in future work would validate correctness without revising any reported measurement. We consider the inherited guarantees to be sound, but the implementation’s conformance to them is unverified here.
• A Single Workload Point: All latency scenarios use one payload size (64 bytes), one pacing regime (one transaction in flight, 50 ms interval, $\approx 20$ messages/s), at most two receivers in the main matrix, and no background traffic or competing services. Burst behaviour, larger payloads, higher rates, more parallel services, and loaded-network conditions are untested, and the payload-size analysis of Table 13 is analytical rather than measured. Claims of applicability should be read as applying to this operating point.
• Statistical Depth: The results come from a single run of 500 iterations per scenario, summarised by mean, standard deviation, and percentiles. Maximum latency, jitter distributions, and confidence intervals across independent repetitions were not retained, so no hard real-time worst-case argument is possible (Section 6.2).
• Virtualised, Single-Hop Testbed: No physical ECU, automotive Ethernet PHY, switch, hardware MACsec engine, or HSM was used; both virtual machines are co-resident on a single physical host (Section 5.3.3), and the path is single-hop. The multi-hop zonal topology that motivates the end-to-end authentication layer (Section 4.7.3) is therefore described but not measured, and the constant factors on production hardware will differ.

7.4. Future Work

Several directions warrant further work:

• Functional and Adversarial Security Validation: Injecting replayed PDUs, tampered payloads, invalid MACs, and stale freshness values to confirm that the implementation discards them as specified, followed by formal analysis of the composed stack (for example, in ProVerif or Tamarin) and penetration testing against the A1–A3 capability levels. As discussed in threat to validity 1 above, this is the most valuable outstanding experiment relative to its cost: the testbed already exists, and because rejected PDUs are, by construction, excluded from every latency and CPU figure reported here, running these tests would demonstrate correctness without requiring any existing measurement to be revised.
• SecOC Software-Path Profiling and Optimisation: Profiling the plugin send and verify paths at function granularity to attribute the ∼15 ms non-cryptographic residue identified in Section 6.3.2, and then eliminating it (preallocated cryptographic contexts, hot-path logging removal, batched Freshness Value Manager interaction, zero-copy buffer handling), with the goal of bringing the per-message path under 1 ms and enabling sub-10 ms operation. Hardware key isolation in an HSM is complementary and is motivated by key protection rather than by latency.
• Lightweight Handshakes: Substituting RSA-2048 with ECDH-P256 for session-key exchange. Published microbenchmarks suggest that this could reduce the initial startup handshake delay to single-digit milliseconds, but that expectation assumes that the measured $25.2$ ms to $33.8$ ms session-establishment cost is dominated by the asymmetric operation itself. Unlike the per-message SecOC path (Section 6.3.2), we did not decompose session establishment into cryptographic and protocol/software components, so the size of the gain that this change would deliver is not yet established.
• Key Provisioning and PKI: Designing automated key-injection models for manufacturing lines and secure over-the-air key rotation protocols that connect with central key platforms.
• SOME/IP Payload Aggregation: Studying how SOME/IP-TP can aggregate small client messages into larger packets. This reduces the per-byte security math overhead because transport-layer signing is done less frequently.
• Bursty-Loss Freshness Resynchronisation: Adapting the faster truncated-counter resynchronisation profile of Rosenstatter et al. [45] (proposed for SecOC Profile 3 on CAN) to the vendor-defined-profile SOME/IP-over-Ethernet setting of Algorithm 1, and measuring resynchronisation latency under bursty message loss exceeding the window W.
• Workload and Topology Coverage: Extending the measurement campaign to multiple payload sizes and transmission rates, burst and background-load conditions, larger receiver groups and multiple parallel services, and to a multi-hop zonal topology with hardware MACsec, reporting worst-case latency and jitter alongside percentiles.
• Group-Keyed Comparators: Benchmarking against functionally matched group-keyed schemes—group DTLS, a shared-key AEAD over the multicast payload, and IPsec with GDOI group keying [25]—rather than only against the unicast-fanout deployment baseline of Section 6.5.
• Physically Separated Hosts and Automotive Hardware: Repeating the two-VM measurements on physically separate hosts connected by a real Ethernet segment, and on automotive-grade Ethernet PHYs with hardware MACsec offload, to remove the residual co-resident-VM limitation noted in threat to validity 2 and to obtain constant factors representative of production hardware rather than of vhost-net virtual switching.

7.5. Concluding Remarks

As vehicles adopt software-defined architectures, securing service-oriented communication becomes more important. The results presented here show that combining SecOC and MACsec provides end-to-end authenticity together with per-link, rather than end-to-end, confidentiality across unicast and multicast SOME/IP paths (Table 1); against a compromised intermediate switch, confidentiality does not hold (Section 3.1.3). At the single quiet operating point measured in this study, the overhead stays within the budgets of the soft real-time application classes discussed in Section 6.8; whether it does so under realistic ECU loading, larger receiver groups, and production-stack constant factors was not evaluated.