The hottest bits of car tech we cannot wait for, read by an incident responder

The CAN bus was built to trust everyone

Inside a vehicle, dozens of electronic control units talk over the Controller Area Network. CAN was designed in the 1980s for reliability in an electrically noisy, closed environment. Every message is broadcast to every node, identified by an ID that also sets its priority. There is no field for who sent it and no signature. Any node that can transmit can send any ID.

That was fine while the bus was physically closed. It stopped being fine once infotainment units gained cellular modems. The 2015 Jeep Cherokee research by Charlie Miller and Chris Valasek showed the consequence: a remote path into the head unit, a pivot onto the CAN bus, and control over steering and brakes. The fix the industry chose was layered: gateways between bus segments, and authentication on the messages that matter.

SecOC: authenticating messages on the bus

AUTOSAR’s Secure Onboard Communication (SecOC) adds two things to a protected message: a freshness value, usually a counter, and a message authentication code computed with a symmetric key shared by the sender and receiver, commonly AES-128 CMAC. The receiver recomputes the MAC and rejects anything forged or replayed.

Payload

The original signal data, for example a brake-pressure request

Freshness

Truncated counter or timestamp so a captured frame cannot be replayed

Authenticator

Truncated MAC, often 24 to 64 bits on classic CAN

Room

Classic CAN: 8 data bytes. CAN FD: 64. That is why FD makes SecOC practical

The engineering trade-offs are real. A classic CAN frame carries only eight bytes, so the MAC and the counter have to be truncated, and the bus timing budget limits how much cryptography a small ECU can do. Key provisioning on the production line and key rotation in service are harder problems than the cryptography. But for a fleet buyer, the useful question is simple: does this vehicle platform authenticate safety-relevant messages, and does it put a gateway between the diagnostic port and the powertrain?

Signed over-the-air firmware

Over-the-air updates are one of the best security improvements in vehicles. They mean a flaw can be fixed in weeks instead of waiting for a dealer visit. They also mean the update server is now a high-value target: whoever can sign an update can change every vehicle in the fleet.

The best-known design for this is Uptane, an open framework built for automotive updates. It separates the role that decides which vehicle gets which update from the repository that stores signed images, and it uses multiple keys with thresholds, so compromising one server or one key is not enough to push malicious firmware. In Europe, UNECE Regulation 155 has required a certified cybersecurity management system for new vehicles registered since July 2024, and Regulation 156 covers software update management. Ask your vehicle or telematics vendor which framework they follow and how their signing keys are protected. A vague answer is an answer.

UWB keys and the end of easy relay attacks

Passive keyless entry made car theft easier. The car sends a low-frequency challenge, the fob answers, and the doors unlock if the fob is “near.” Relay attackers use two radios: one near your front door picking up the fob, one beside the car repeating its signal. The car hears a valid answer and has no way to tell it came from forty feet away.

Ultra-wideband changes that. UWB ranging measures the time of flight of a radio pulse with enough precision to bound distance to well under a meter. A relay adds delay, and delay looks like distance. The Car Connectivity Consortium’s Digital Key 3.0 uses UWB for exactly this reason, combined with the secure ranging features in IEEE 802.15.4z. Implementation still matters, but it is a real step forward. For fleets with older fobs, motion-sleep fobs and signal-blocking pouches at the depot are cheap fixes that work today.

OBD-II fleet dongles

Aftermarket telematics dongles plug into the OBD-II port, which on many vehicles connects to the CAN bus, sometimes with no gateway in between. They add a cellular modem, GPS and a cloud backend to the vehicle. That makes them very useful and very interesting to attackers.

In 2015 a University of California, San Diego team showed that a cellular insurance dongle could be reached by text message and used to send CAN frames, including to the brakes of a test Corvette. The vendor fixed it, but the pattern still applies: a device built for data collection can often transmit too.

A small-fleet checklist

1. Inventory every connected device in every vehicle: OEM telematics, aftermarket dongles, dashcams, tablets and their cloud accounts.
2. Prefer the manufacturer’s own telematics API over a plug-in dongle when it gives you the data you need.
3. If you use a dongle, ask the vendor in writing whether it can transmit on the bus, how firmware is signed, and whether it accepts SMS commands.
4. Put the fleet admin console behind FIDO2 keys. A stolen fleet login can locate, and sometimes immobilize, every truck you own.
5. Keep telemetry ingest separate from billing and dispatch, the same way our triage console separates backups from the domain.
6. Apply OTA updates promptly. They are now your patch Tuesday on wheels.

The car tech we are most looking forward to is the kind that makes these checks boring: authenticated buses, signed updates, keys that know how far away they are. Until every vehicle in your fleet has all three, the controls above close most of the gap. The broader method, inventory then segment then recover, is the same one in the runbooks on our homepage.

Runbook takeaways

Bus

Classic CAN has no sender authentication; any node can send any ID

Authenticate

AUTOSAR SecOC adds a truncated MAC and freshness value to critical frames

Update

OTA images signed under a multi-key scheme such as Uptane

Keys

UWB distance bounding defeats simple relay theft of keyless entry

Dongles

Read-only telematics, signed firmware, private APN, isolated backend