--- title: "AUTOSAR E2E and SecOC" --- # AUTOSAR E2E and SecOC Check and send messages protected with AUTOSAR E2E profiles 1, 2, 4, 5, 6, 7, 11 and 22 and SecOC with CMAC/AES-128, on CAN, J1939 and SOME/IP, with keys only in secret storage and injected failures told apart from real ones. **State:** modelled: each profile agrees with the AUTOSAR protocol examples and two independent implementations (autosar-e2e for Python and for Rust, pyca/cryptography for the MAC), over python-can's bus in both directions. No real receiver has accepted or rejected the module's frames. ## What is supported - **E2E** profiles 1 (Data ID modes both, alternating, low byte and nibble), 2, 4, 5, 6, 7, 11 (both and nibble) and 22, with the CRCs of the AUTOSAR CRC library. - **SecOC** with CMAC/AES-128 (security profiles 1 to 3): a freshness counter of which the frame carries the low bits, a secured PDU header of 0, 8, 16 or 32 bits, and a secured area. ## Configure the protection The protection comes from the AUTOSAR description where it has one: the E2E transformer of a signal group, END-TO-END-PROTECTION-SETs of profiles 1 and 2, and SECURED-I-PDUs with their communication, authentication and freshness properties. For DBC files, or to override the description field by field, run **Configure E2E and SecOC Protection**. It opens `.vscode/automotive-protection.json` (creating an empty one if there is none), which has a JSON schema for completion and checks; its problems show in Problems at their key. No DBC attribute is interpreted, because the attributes found in public DBC files say neither the profile nor the layout. Keys come only from secret storage: **Set SecOC Key...** and **Remove SecOC Key...**, per workspace. They are never read from settings or files. ## Check protected messages - **CAN Bus panel, Trace view:** each protected frame's result in an E2E/SecOC column, with the reason on hover (in fixed mode, the message's failures). - **CAN Bus panel, Statistics view:** per message, frames checked and failed, CRC, Data ID and length errors, repeated, out of sequence, lost, MAC failures, replays and frames not checked. - **CAN Trace editor:** failing frames marked and explained on hover, counted in the statistics. - **Agent tools:** `protectionStatus` and `checkTraceProtection` give the same with reasons. A receiver joins at the first frame, rebuilds the freshness value from the bits sent with the configured sync attempts, and reports a replay when the whole value is sent. A recording verifies SecOC only when the freshness value to start from is set in the protection configuration, because the frames carry only its low bits. ![E2E and SecOC checks in the CAN Bus panel, with failed frames counted per protected message.](https://neuralinverse.com/docs-images/modules/automotive/e2e-secoc-checks.webp) ## Send protected messages The rest-bus simulation and Interactive Transmit (once and cyclic) send protected messages with the counter and CRC, and the freshness value and MAC computed by the bus host for each frame. - A message's E2E counter and a Data ID's freshness value count on across everything that sends on the channel. - The freshness value continues across restarts too, from the workspace's storage. - A protected message that cannot be sent protected (no key, no CMAC/AES-128 named, a configuration that does not fit the frame) is not sent, with the reason on the message. ## Injected failures The rest-bus simulation can freeze or skip a message's E2E counter, corrupt its CRC, repeat, drop or delay frames, and send a stale freshness value or a wrong MAC (see [Rest-bus simulation](https://neuralinverse.com/docs/modules/automotive/rest-bus-simulation/)). Injected failures show as, for example, "CRC (injected)" in the warning colour, and are counted apart from real ones. The trace editor reads recordings, which carry no marks: injected failures there count as failures. ## On J1939 networks A frame is checked as the parameter group that decodes it. A protected group the transport protocol carries is checked on its reassembled data, never packet by packet, with its result on the frame that completed the transfer. The simulation writes the protection into the whole group before the transport protocol splits it. ## On SOME/IP events Events and field notifiers that the Adaptive service instance manifest protects (profiles 4, 5, 6, 7, 11 and 22) are checked in the Ethernet Trace editor (an E2E column, the filter flags `e2e` and `e2efail`, and an E2E Failed / Checked column in Statistics) and in the SOME/IP panel for messages the node receives. Simulated services send protected events protected. Method protection is reported as not interpreted. **State:** modelled against vsomeip's E2E module (profiles 4 and 7, both directions) and autosar-e2e for Rust; no commercial AUTOSAR stack.