1

As an Automotive Security Professional, my state of the art approach to implement a Secure Access would be to have an ECU generate a challenge (nonce + ID), forward it to the tester who can pass the challenge to the backend system which signs it with a private key. The ECU can then use the public key to verify that the access request is authentic.

However, what seems to be more widely used is the Seed-And-Key Algorithm which basically works like this:

  • Both ECU and tester share a secret key derivation function
  • The ECU generates a nonce and sends nonce and ID to the tester
  • The tester seeds the KDF with the nonce and forwards the key back to the ECU
  • Since the ECU can perform the same KDF with the same seed, it will obtain the same key
  • If keys are identical, the ECU can allow access

This Seed-And-Key method seems to have no real theoretical background or RFC. Was it ever proven to be secure? To me the concept of keeping the algorithm confidential as opposed to the key seems counterintuitive.

Anders
  • 64,406
  • 24
  • 178
  • 215
AdHominem
  • 3,006
  • 1
  • 16
  • 26

1 Answers1

1

The seed-and-key process is UDS public ($$$) spec. But that says nothing more than the on wire representation. The underlying algorithm for the permutation is left up to the manufacturer. I don't know that the described algorithm is "most common". I've seen a few described in papers.

So, was it ever secure?

Depends on the underlying algorithm. XOR of a static key (looking at one OEM in particular), no. I've heard reports of AES-128 or RSA. Are these secure? Absolutely. Are they circumvented? Regularly, not through cryptanalysis (usually), but that's the game we play.

As for confidentiality of algorithms:

UDS doesn't care what permutation is done. It gains an OEM nothing to put a sticker on their ECU saying "Our UDS SaK algorithm is AES-128 based." So it's best left unsaid. Would it benefit the manufacturer to publish their spec so independent researchers can tell them when they're doing something wrong? Maybe. Or the OEM hires a security department for that.

As for your first paragraph:

Looking forward, the latest UDS spec now describes an asymmetric cryptographic authentication routine. Due to the amount of data (on CAN buses that have not all transitions to FD) and it's recency along with long ECU engineering lead times may help explain why modern ECUs still run symmetric based SaK.

foreverska
  • 1,115
  • 11