In short
SecOC authenticates individual AUTOSAR PDUs above the transport, MACsec protects each Ethernet hop at layer 2, and TLS secures one endpoint-to-endpoint session, so vehicles usually run all three rather than one instead of another. AUTOSAR describes SecOC as a mechanism to verify the authenticity and freshness of PDU based communication between ECUs, requiring both the sending and receiving ECU to implement a SecOC module. IEEE describes 802.1AE MACsec as providing connectionless user data confidentiality, data integrity, data origin authenticity and privacy protection, with keys distributed per link by the MACsec Key Agreement protocol of IEEE Std 802.1X. TLS protects a session between two IP endpoints and stops at each endpoint. Choose per link and per service from a threat model, not by ranking the three.
SecOC, MACsec and TLS turn up in the same requirement paragraph and get treated as alternatives. They are not. They protect different units of data over different spans, with keys from different places, and a vehicle normally carries more than one.
The cost shows up on a bench: a setup is planned against a network diagram, brought up, and found either unreadable or rejected by the device under test for reasons no amount of staring at the payload will explain. This article separates the three layers, then covers the two things that are hard to find written down: what each does to your ability to debug, and why an ECU rejects a message whose authenticator is entirely valid. It assumes the groundwork in our complete guide to automotive Ethernet and our VLAN and QoS article.
The three layers, one sentence each
SecOC: authenticity for individual PDUs, above the transport
AUTOSAR describes SecOC as providing “a mechanism to verify the authenticity and freshness of PDU based communication between ECUs within the vehicle architecture”, requiring “both the sending ECU and the receiving ECU to implement a SecOC module”. The sender appends authentication information to an authentic I-PDU to make a secured I-PDU; the receiver verifies it. The protection travels with the message, whatever it crosses.
MACsec: hop-to-hop protection on one Ethernet link at layer 2
IEEE describes 802.1AE as specifying “provision of connectionless user data confidentiality, data integrity, data origin authenticity, and privacy protection by media access independent protocols”, with the MACsec Key Agreement protocol of IEEE Std 802.1X discovering “mutually authenticated MACsec peers” and electing a Key Server that distributes the symmetric Secure Association Keys. The scope of one secure association is the link between those peers.
TLS: end-to-end session security between two endpoints
TLS protects a session between two IP endpoints and stops at each of them. In the vehicle it appears where the communication is genuinely a session between two named parties: diagnostics over IP, external interfaces, and service communication run over a protected socket rather than a multicast group.
Why “versus” is the wrong word
Each leaves a gap the others fill. MACsec ends at every switch. TLS covers no multicast group and no CAN segment. SecOC says nothing about confidentiality or the headers in front of the payload. The question is not which one, but which applies where.
One table that separates them
| SecOC | MACsec | TLS | |
|---|---|---|---|
| Scope | Producer to consumer application | One link, peer to peer | One session, endpoint to endpoint |
| Layer | AUTOSAR, on the I-PDU | Layer 2, in front of the payload | Above TCP |
| Unit protected | One secured I-PDU | One frame on one hop | One byte stream between two sockets |
| Integrity and authenticity | Authenticator over data ID, payload and freshness value | Yes, per IEEE 802.1AE | Yes, per session and peer |
| Confidentiality | Not defined by the protocol spec | Configurable, encrypt on or off | Yes |
| Replay protection | Freshness value, a monotonic counter or timestamp | Packet number in the SecTAG, configurable window | Sequence numbering in the session |
| Key management | Out of scope of the protocol spec; provisioned per ECU | 802.1X key agreement, or static keys | Certificates and a handshake |
| Works on CAN | Yes, Profile 3 is defined for CAN | No | No |
| Works on Ethernet | Yes | Yes, this is its only medium here | Yes |
| What a tap still shows | Everything, plus freshness and authenticator bytes | Header always; payload readable when integrity only, opaque when encrypt on | Cleartext hello messages, then opaque |
Reading the table: the row that decides your bench
Read the last row first: it decides what bench you are building, and the three answers are observable, conditionally observable, and opaque by design. Settle the security concept before the capture strategy. Our capture guide covers how frames reach the analyser, this row what they are worth on arrival.
SecOC in practice
Truncated MAC, and the payload-length tradeoff
The authenticator is generated from a key, the data identifier, the authentic payload and the freshness value, and the specification allows it to be shortened: “Truncation may be desired when the message payload is limited in length and does not have sufficient space to include the full Authenticator”, with the length set per secured I-PDU by SecOCAuthInfoTruncLength.
It does not present this as free. The specification’s note states that MAC truncation “results in a lower security level at least for forgery of single MACs” and proposes a key length of at least 128 bits. The published profiles show the working range: Profile 1 carries a 24-bit truncated MAC and an 8-bit truncated freshness value, Profile 3 a 28-bit MAC and 4 bits of a 64-bit counter.
For a test engineer the consequence is arithmetic: every secured PDU is longer than the signal layout you were given, so your decode offsets move. Where the frame has no room, the specification allows the secured I-PDU to be split into the authentic I-PDU and a separate cryptographic I-PDU, putting the bytes you need in another message.
Freshness value: counter versus timestamp, and who distributes it
Each secured I-PDU is configured with at least one freshness value, a monotonic counter “realized by means of individual message counters, called Freshness Counter, or by a time stamp value called Freshness Timestamp”. Whether or not it appears in the payload it is an input to the authenticator, and the receiver’s first verification step is to calculate the expected value.
Only the least significant bits are transmitted, per SecOCFreshnessValueTruncLength, and setting that to zero means none is, so the number on the wire is a fragment of a counter both sides hold independently. The specification is candid that the counter comes from elsewhere: SecOC “relies on the existence of a software component that provides a freshness information”. That freshness manager is where synchronisation lives, outside the protocol specification.
Which PDUs get secured, and why not all of them do
Programmes secure a subset, because securing everything costs payload bytes and a MAC computation on every message. UN Regulation No. 155 requires an exhaustive risk assessment for the vehicle type and testing to verify the effectiveness of the measures implemented, as our UNECE R155 and R156 page reads clause by clause. In practice the list of data identifiers that get an authenticator is where that assessment lands for SecOC, and the reason a PDU is absent is worth recording, because an assessor can ask.
The public reference
AUTOSAR publishes the SecOC protocol specification as an open PDF in the Foundation release, so every claim above is checkable against the document.
MACsec in practice
SecTAG and ICV, added and removed per hop
A MACsec frame carries a security tag in front of the payload and an integrity check value behind it. The Wireshark dissector source gives the shape: the SecTAG is 14 octets with the optional secure channel identifier and 6 without, counted after the 2-octet MACsec EtherType that 802.1AE includes in the tag, so 16 and 8 in the standard’s own accounting; the ICV is 16 octets for the default cipher suite, which is what Wireshark implements, and ip-link exposes icvlen over the range 8 to 16, so confirm it for your link rather than assuming. The tag holds the tag control information bits, the association number, a short length field, a 32-bit packet number and, where present, the secure channel identifier. Both are applied as the frame enters the link and removed as it leaves; the next hop applies its own.
Hop-to-hop means every switch is a trust point
That has a consequence worth stating plainly: on a path with two switches between two ECUs, the traffic exists in plaintext inside each switch. MACsec makes the wire between boxes untrustworthy to an attacker; it does not make the boxes trustworthy, and a compromised one can originate traffic the next hop protects on its behalf. That is the argument for keeping SecOC on a fully MACsec-protected network: its authenticator is computed by the producing ECU and checked by the consuming ECU, so an intermediate node cannot forge a payload that verifies at the far end.
Integrity-only versus confidentiality modes
The mode is a single choice, visible in the frame. The Linux ip-link manual documents the option as encrypt on or encrypt off, which “switches between authenticated encryption, or authenticity mode only”. The Wireshark dissector quotes IEEE 802.1AE-2018 for the wire semantics: the E bit “is set if and only if confidentiality is being provided and is clear if integrity only is being provided”, and when integrity only is in use the dissector adds the EtherType and passes the payload on, since it was never modified.
Integrity-only MACsec is therefore the mode that keeps a bench working: it authenticates every frame and leaves a capture fully decodable.
Key agreement versus pre-shared keys, and the multicast caveat
Keys can be agreed or configured. MACsec Key Agreement, specified in 802.1X, discovers mutually authenticated peers and elects a key server that distributes the secure association keys. The alternative is writing keys in by hand, and the ip-macsec manual is explicit about what that is for: since 802.1AE derives its initialisation vector from the packet number, and the same key must not be used with the same IV twice, the tool “is thus mostly for debugging and testing, or in combination with a user-space application that reconfigures the keys. It is wrong to just configure the keys statically and assume them to work indefinitely.”
A second limit matters specifically in vehicles. An arXiv preprint on multicast origin authentication in MACsec and CANsec for automotive scenarios, by Cena, Seno and Scanzio, submitted to the IEEE, argues that although both use freshness values against replay, “when multicast transmissions are considered, above solutions fail to guarantee origin authentication”, because “all members of a SC know the shared encryption key” and a compromised member “can pretend to be the only node that is entitled to transmit in the SC”. They call this a masquerade attack, and their own proposal is an add-on layered on MACsec and CANsec, not a replacement. The takeaway is narrow and useful: a shared group key proves membership of the group, not identity within it.
TLS, DoIP and service communication
Where TLS sits in the diagnostic and service stacks
In diagnostics the split is visible in the port numbers. Our DoIP explainer records that the unsecured TCP data port is 13400 while the TLS-protected variant uses 3496 in both python-doipclient and the Wireshark dissector, and that the routing activation response code DeniedRequiresTLS exists for an entity that will not talk on the unsecured path. That code is not fixed by changing your source address. In service communication the SOME/IP dissector registers TLS and DTLS hand-off, as our SOME/IP decode fix list covers: the point where a working decode goes quiet.
Certificates on ECUs, and what expiry does on a bench
A certificate is valid between two dates, so TLS on an ECU depends on that ECU’s notion of time. If that ECU takes its date from the synchronised time domain, a bench whose grandmaster is wrong or absent is one where certificate validation fails for reasons unrelated to certificates, so establish where the ECU gets its wall clock before blaming the handshake. Our gPTP troubleshooting article covers getting the time domain working. The other problem is mundane: development certificates expire, and a rig that worked yesterday fails today with no code change.
Why TLS does not solve broadcast, and why SecOC exists
TLS secures a session between two parties. A signal consumed by four ECUs over a multicast group is not that, and replacing it with four unicast sessions costs bandwidth and requires every producer to know all its consumers. That is why a PDU-level mechanism exists: it authenticates a message many parties receive, without a session per receiver.
What each layer does to your debugging
Layer by layer, what stays visible
With SecOC alone everything stays visible; the cost is offsets, because your decode must know that the last payload bytes are freshness value and authenticator, or that a separate PDU carries them.
With MACsec in authenticity-only mode, everything stays visible behind a SecTAG your analyser parses. With encryption on, the header is visible and the payload is not, so you still see who talks to whom, how often and with what packet numbers. With TLS the start of the handshake is visible and the application data is not; on TLS 1.3 the certificate exchange is encrypted too, so expect less than you would on 1.2.
Lab keys versus road vehicles
The dividing line is whether you hold key material. For MACsec, Wireshark offers two decrypt routes: a table of pre-shared AES-GCM keys of 16 or 32 bytes, and an option to also use EAPOL-MKA distributed secure association keys seen in the same capture. Both presuppose a bench you control: a capture from a vehicle whose keys you were never issued stays encrypted. Plan this at bench design time, and put the link you most need to observe into a mode you can configure.
Mirroring before encryption, and instrumenting inside the ECU
Two techniques survive when the wire does not cooperate. Take the copy where the data is still in the clear, which on a switched network means choosing the mirror source deliberately. Or instrument inside the ECU, above the security layer, where the application sees plaintext. Signal-level logging answers “what did the consumer receive” where a capture answers “what was on the wire”, as our ECU testing over Ethernet article sets out.
Failure modes to plan for
Freshness desync after reset, sleep or bus-off recovery. This one costs the most time, because the symptom contradicts the evidence: the payload is right, the authenticator is right for the payload, and the receiver rejects it anyway. The mechanism follows from the construction. The specification states that the data on which the authenticator is calculated is the data identifier, the authentic payload and the complete freshness value concatenated in that order, and that the receiver builds the same input from its own expected value. If the two sides disagree about the counter, the authenticators differ over identical data, and because only the least significant bits are transmitted, the receiver cannot read the sender’s counter off the wire.
The recovery path is defined in outline: on a failed verification “the authentication verify attempt counter shall be incremented, and the freshness value shall be updated to the next valid value”, with the PDU discarded once SecOCAuthenticationVerifyAttempts is reached. That is a bounded search, not unbounded resynchronisation. What the specification does not define is where the counter is stored or how it survives a power cycle, so behaviour after a reset is a property of your freshness manager implementation. Make reset, sleep and wake, bus-off recovery and odd startup order exercise resynchronisation explicitly, and log the verification failure counter, not only the application-level symptom.
Key rollover during rest bus simulation. A simulator holds keys, and keys change. A campaign that ran for weeks stops the morning after a rotation, and the simulator reports nothing wrong because from its point of view it transmits correctly. Our rest bus simulation article covers fidelity; the key question belongs in the same setup description.
MACsec configured on one side of a link only. The link comes up at the PHY level and, with the usual validate strict, stays down at the data level, reading on the bench as a link that is up and silent. Check the validate mode before concluding anything: validate disabled accepts unprotected frames and hides the mismatch.
Certificate validity depending on a clock that depends on time synchronisation. Check the time domain before blaming the handshake.
Verification failures that present as “no response”. A rejected secured PDU is discarded before the application sees it, so a security failure and a dead ECU look identical from the tester’s chair. Surface SecOC verification status as a measurable bench output rather than leaving it in the stack.
Choosing per link and per service
Threat model first, mechanism second
Start from what a receiver has to prove. If it must prove that a specific ECU produced a specific value, that is a PDU-level authenticity requirement and link protection does not meet it. If a physical attacker on the harness must not be able to inject or read, that is a link requirement; if an outside party must not read a diagnostic session, that is a session requirement. Most vehicles produce all three, which is why most carry all three mechanisms.
Typical placement across zonal and domain designs
Placement follows topology. A zonal architecture puts more switches between a sensor and the function consuming it, increasing the trust points a link mechanism creates and strengthening the case for end-to-end PDU authenticity. Our article on domain and zonal architectures covers the topology; the consequence is that hop count is a security parameter, not only a latency one.
Latency and CPU cost, measured on your own bench
Every layer costs computation and adds bytes. We will not quote a figure, because a published number belongs to a specific silicon, key length, offload path and traffic mix, none of which is yours. Measure it: run the same traffic profile with the layer enabled and disabled, on your own hardware. That number also answers the headroom question a supplier will eventually ask.
Where keys come from in production
Key material has to exist on the device before any of this works. That happens during end-of-line programming, alongside secure boot configuration and debug interface locking, a manufacturing problem rather than a network one. Our article on production cybersecurity and HSM key injection covers that stage, and our ProMik Ethernet communication architecture article the programming path it runs over.
Where GSAS fits
Most of the difficulty here is not cryptographic, it is practical. Teams know which mechanisms their programme specifies and still lose weeks to a bench that cannot observe the network, a device under test that rejects correct messages, or a decode whose offsets moved when the authenticator arrived. Those are setup problems with setup answers.
GSAS Micro Systems works with automotive engineering teams in India as an engineering partner on that stage: reading the security concept against the bench you actually have, deciding where a link must be configurable into an observable mode, separating a verification failure from a communication failure in the test report, and settling the freshness and key questions before integration week. Our applications engineers work in IST, with teams in Bengaluru, Pune, Chennai and Hyderabad.
If you are planning a validation bench for a secured vehicle network, our automotive Ethernet capabilities page sets out the wider scope and a consultation request is the direct route. Bring the security concept, the secured data identifiers and the bench topology.
References
- AUTOSAR, “Specification of Secure Onboard Communication Protocol”, Foundation R24-11, Document ID 969 (SecOC purpose; PRS_SecOc_00103, 00208, 00210, 00211, 00213, 00300, 00306 and 00309; Profiles 1, 2 and 3): https://www.autosar.org/fileadmin/standards/R24-11/FO/AUTOSAR_FO_PRS_SecOcProtocol.pdf
- IEEE 802.1, “802.1AE: MAC Security (MACsec)” (scope statement; MACsec Key Agreement in IEEE Std 802.1X): http://1.ieee802.org/security/802-1ae/
- Wireshark,
epan/dissectors/packet-macsec.c(SecTAG lengths, 16-octet ICV, TCI E and C bit semantics quoted from IEEE Std 802.1AE-2018, decrypt routes): https://gitlab.com/wireshark/wireshark/-/blob/master/epan/dissectors/packet-macsec.c - Linux
ip-macsecmanual page (IV derived from the packet number; static keys are for debugging and testing): https://man7.org/linux/man-pages/man8/ip-macsec.8.html - Linux
ip-linkmanual page, macsec type options (encrypt onandoff,replay,window,validate,icvlen): https://man7.org/linux/man-pages/man8/ip-link.8.html - G. Cena, L. Seno and S. Scanzio, “Robust Multicast Origin Authentication in MACsec and CANsec for Automotive Scenarios”, arXiv:2502.20555, preprint, submitted to the IEEE: https://arxiv.org/abs/2502.20555
- UN Regulation No. 155, read clause by clause on our compliance page: https://www.gsasindia.com/compliance/unece-r155-r156
Also appears in:
Building for Automotive & Mobility?
Talk to our application engineers for personalized tool recommendations.
