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

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.