# SecOC testing from the bus side: what a tester can check

How to test AUTOSAR SecOC without the keys: freshness and MAC on the wire, replay and reorder behaviour, truncated MAC length, and what each result means.

Source: https://auto-st.com/insights/secoc-testing · Updated: 2026-10-07

SecOC (AUTOSAR Secure Onboard Communication) adds a message authentication code (MAC) and a freshness value to selected CAN messages so a receiver can reject forged or replayed frames. AutoST and any bus-side tester work on the part you can observe without the secret key: is the authenticator actually present, does the receiver reject a replay, does it drop a frame with a broken MAC, and does the freshness window behave. Those checks catch the configuration mistakes that make SecOC ineffective, and none of them requires breaking the cryptography. Forging a valid MAC is out of scope here; that is where a penetration tester with key material or an HSM review takes over.

## What is on the wire

A SecOC-protected message carries its normal payload plus a Secured part: a freshness value (often a truncated counter) and a truncated MAC. A typical layout on a classic CAN frame looks like this:

```
payload:    2 bytes  (the actual signal, e.g. a torque request)
freshness:  1 byte   (low bits of the freshness counter)
MAC:        up to 5 bytes (truncated authenticator)
```

The MAC is computed over the payload, the freshness value and a data identifier, with a key held in the sending and receiving ECUs. The receiver recomputes the MAC from its own freshness estimate and compares the truncated result. A tester reads this layout from the communication matrix: which message IDs are secured, how long the MAC is and how the freshness is built.

## The checks a bus-side tester can run

### Is the authenticator present at all

The first check is the cheapest. Capture the messages that the matrix marks as secured and confirm that the freshness and MAC bytes are really there and change over time. A "secured" signal that goes out as plain payload, or with a MAC that never changes, is a configuration that was never switched on.

### Does a replay get rejected

Record a genuine secured frame and send it again later, unchanged. A correct receiver rejects it, because the freshness value is now stale. If the receiver acts on the replayed signal, either the freshness check is off or the window is so wide that replay inside it is trivial. This is the single most valuable SecOC check and it needs no key.

```
observe:  genuine frame, freshness counter = 0x41
replay:   same frame, freshness counter = 0x41   (now stale)
expected: receiver ignores it
weak:     receiver acts on it  -> freshness not enforced
```

### Does a corrupted MAC get dropped

Take a genuine frame and flip a bit in the MAC field, then send it. The receiver must drop it. If it is acted on, verification is either disabled or falls back to accept on error, which is a common and serious misconfiguration. Flipping a bit in the payload while leaving the MAC untouched tests the same thing from the other side: the recomputed MAC no longer matches, so the frame must be dropped.

### How wide is the freshness window

Receivers tolerate some drift in the freshness counter so a lost frame does not desynchronise them. Send frames with freshness values ahead of and behind the current one and observe where acceptance stops. A window of a few counts is reasonable; a window of hundreds, or no upper bound, weakens the replay protection you just confirmed.

### Are all messages in a group protected

A frequent gap is partial coverage: the headline message of a function is secured, but a related message that influences the same actuator is not. Compare the secured set on the wire against the full set of safety- or security-relevant messages for that function. An unprotected sibling message is a way around the protected one.

## What the results mean

| Observation | What it means |
| --- | --- |
| No MAC or static MAC on a secured ID | SecOC not active for that message |
| Replay accepted | Freshness not enforced or window too wide |
| Corrupted MAC accepted | Verification off or fail-open fallback |
| Payload change accepted without MAC change | Receiver not verifying the MAC |
| Related message unprotected | Partial coverage, protection can be bypassed |

Each of these is a finding about the configuration and the receiver behaviour, not about the cipher. That distinction matters in the report: the fix is usually a MESSAGE or receiver configuration change, not a new algorithm.

## Where the bus tester stops

What a bus-side test cannot tell you is whether the key management, the freshness master and the HSM-backed key storage are sound. Whether the MAC algorithm and its truncation length are strong enough for the threat, whether keys are unique per vehicle and how they are provisioned are questions for a cryptographic review and for the penetration test, not for traffic observation. A clean bus-side result means the protection is switched on and enforced; it does not certify the cryptography underneath.

## How AutoST tests SecOC

AutoST exercises the bus-facing behaviour: it confirms the authenticator is present on the secured IDs, replays captured frames to test freshness enforcement, corrupts the MAC and the payload to test verification, and probes the freshness window, all from CAN or CAN FD traffic. The findings go into the same risk score and Fix Plan as the UDS and DoIP results. AutoST does not analyse the key management or the HSM and does not forge MACs; the cryptographic side stays with a penetration tester.

## FAQ

**Can you test SecOC without the keys?**

Yes, from the bus side. You can confirm that a MAC and a freshness value are present, that a replayed frame is rejected, that a frame with a corrupted MAC is dropped and that the freshness window behaves. What you cannot do without the key is forge a valid MAC, and that is the cryptographer's job, not the bus tester's.

**What is the most common SecOC finding on the bench?**

Protected signals that an ECU still accepts without a valid authenticator, usually because a receiver was configured to verify but falls back to accepting on a verification error, or because only some messages in a group are protected. Both show up by replaying and by corrupting the authenticator.

**Does SecOC encrypt the CAN data?**

No. SecOC provides authenticity and freshness, not confidentiality. The payload stays readable on the bus; what SecOC adds is a message authentication code and a freshness value so a receiver can tell a genuine, fresh message from a forged or replayed one.

## Sources

- [AUTOSAR Specification of Secure Onboard Communication (SecOC)](https://www.autosar.org/standards)
- [ISO 11898-1:2024 Road vehicles, Controller area network (CAN), Part 1: Data link layer](https://www.iso.org/standard/63648.html)
- [ISO/SAE 21434:2021 Road vehicles, Cybersecurity engineering](https://www.iso.org/standard/70918.html)

## Related

- [SecOC (Secure Onboard Communication)](https://auto-st.com/glossary/secoc)
- [CAN Bus (Controller Area Network)](https://auto-st.com/glossary/can-bus)
- [HSM (Hardware Security Module)](https://auto-st.com/glossary/hsm)
- [Choosing a CAN interface for ECU security testing](https://auto-st.com/insights/choosing-a-can-interface-for-security-testing)
- [Break it on the bench, not in the field.](https://auto-st.com/ecu-fuzzing)
- [Speaks the buses your ECUs speak.](https://auto-st.com/protocols-hardware)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/insights/secoc-testing