CAN Part 13 - Seed & Key

Device Access

Lets say I have an electronic device that has some set of software or firmware on it.  In the future it might be a good idea to allow for updating the software, but I also don't want unauthorized users from updating the software.  I want to provide some security where users can prove that they are authorized to update the software on the device, and then allow them to, but lock out all users who aren't authorized.  This was the reason behind creating a Seed and Key algorithm and it is often used in CAN as a feature.

Seed & Key

When we talk about Seed and Key what we are really talking about is a set of steps to prove to the device we are talking to, that we should have some elevated level of access.  Maybe there is some internal data we don't want to be broadcased often, but in some cases we should be able to access it.  Maybe we want to manually drive outputs of our device to test basic functionality, but which might bypass safety checks.  Or maybe we want to change the entire application running on our device.

In all cases I've seen a Seed and Key will operate in some way similar to this.  We request that the device go into some elevated level allowing for more access or control.  We then request a Seed from the device.  I've seen this seed be 1 to 4 bytes in size.  We then must figure out what the Key is from the Seed.  Ideally there is only one unique Key for every Seed.  I've also seen Seeds that range from 1 to 4 bytes in size.  We must then send out the Key back to the device.  At this point the device will either respond with something positive, stating we are now unlocked.  Or we will get a negative response, which may also lock out the device for some amount of time like 10 minutes.  In this case if we request another Seed the device will give a negative response and state we need to keep waiting before trying again.

So if you want to unlock a device to get more access to it you need to know how to talk to the device, how to get elevated access, how to request the Seed, how to get the correct Key, and how to send that Key.  Then you also need to know how to do the thing you were trying to do in the first place like reprogram the device.  How can you figure out all of this?  Well most of it can be figured out without too much trouble, but hardest part will be going from a Seed to a Key.  The manufacturer of the device will have a way to get a Key from a Seed, and typically it is provided as a DLL binary.  The actual algorithm is typically not shared and instead a binary is provided to calculate the Key from the Seed.  This DLL can have multiple levels of access and can have further restrictions so that only some access can be unlocked.  No specifics will be mentioned here, but even if they were, it would only apply to this one level of access, for this one ECU.

I Have an ECU and I want to get low level access

Here is where I have little to no experience.  I'm often working on ECUs that I do have authorized access to.  In these cases the manufacturer gives me what is required to unlock the ECU and their documentation states what this elevated access will allow me to do.  If you stumbled on this blog post in the hopes that there would be some steps on how to get more performance from an ECU, or unlock the ability to do something beyond the intended functionality...you are going to be disappointed.  As I listed out previously, a Seed & Key algorithm is going to seem random.  It is like someone asking what the password is, but the password changes ever time it is asked.  And if you get the password wrong, in many cases it will lock out access for several minutes before it will allow another try. 

Lets pretend there is a 4 byte key, and for every wrong Key the ECU is locked out for 10 minutes.  This would mean it would take 81,000 years to guess every combination.  But this is for a single seed.  The seed changes every time it is asked.  The ECUs I've seen this implemented on have an RTC of some kind, so powering down and back up the ECU will not trick it.

Generic Steps

So if you do have a seed and key algorithm (usually binary provided by OEM), there are still a few things that can differ.  In most cases this is used to unlock the ISO-15765 access.  In these cases call the UDS Session Control, requesting either Extended or Programming (this is code 0x10).  Then UDS Request Key (code 0x27).  The key will be returned as an array of bytes.  Using this calculate the key, and sending it with UDS Send Key (also code 0x27).  Seed and Key use the same code but different Access Modes.  These functions can all be found in NI's Automotive Diagnostic Command Set, or my G implementation in the Hooovahh CAN ISO 15765 package.  If there is a positive response from the send Key you are all good.  Otherwise the negative response will tell you what went wrong.  If the Extended session was used then IO or variables might be able to be read or written that couldn't before.  If the Programming session was used then UDS Request Upload/Download and Transfer data should work.  Again the specifics here vary and other things like routines may need to be ran, or other DIDs needs to be set.

Other Types of Seed & Key

This previous example has been for unlocking access for UDS which is over the ISO-15765.  There is another common communication that needs to be unlocked and that is for XCP/CCP.  This also is typically protected behind a DLL.  But XCP will respond with if one or more of the the Calibration and Paging, DAQ, STIM, or Programming is unlocked.  More on this can be found with NI's ECU Measurement and Calibration toolkit.  Calling the XCP Status will return what parts of the ECU are still locked.  Then the steps are similar in that you have to get the Seed, calculate the Key, and then provide it to the ECU.  The response from the send Key will return what is unlocked.  NI has an ECU simulator built into the toolkit to test these functions out.

Part 14...

Throughout almost all of this CAN blog series we have talked about CAN and really what this is referring to is the CAN 2.0 high speed specification.  In Part 14 the next topic we will talk about CAN-FD which is an evolution of the high speed CAN specification which allows for more data transfer, while having some backwards compatibility with the more common networks used.