Security Access Service Identifier (0x27): UDS Protocol

The Security Access Service is used to modify the ECU data stored in memory, before that the user first has to grant access through this service. The purpose of this service is to supply a method to access information and/or diagnostic services that have restricted access for security, emissions, or safety reasons. Diagnostic services for downloading/uploading routines or information into a server and reading specific memory locations from a server square measure things wherever security access could also be needed. Improper routines or information downloaded into a server may doubtless injury the physical science or alternative vehicle elements or risk the vehicle’s compliance to emissions, safety, or security standards. The security construct uses a seed and key relationship.

Remember always the ECU’s are will be in the locked state after power on as default, if any problem is there or you want to write or read any data which is in the locked state by the OEM, then you need to unlock the ECU to change the data by using the Security Access Service Identifier (0x27).

How to Unlock an ECU in a vehicle?

To unlock an ECU in a vehicle, first, the Client will send the seed request. for security access the sub-functions are from 0x00 – 0xFF are available with a different security level. If you are not understanding the security level don’t worry I will explain below for your doubt clear. basically, all the odd values are used for seed request whereas the next even values (Seed request security level + 1) are will be used to send the security key to the ECU to unlock by using the Security Access Service Identifier (0x27)

To prevent that the ECU is modified by unauthorized persons most UDS services are locked. To get access to services that are used to modify the ECU the user first has to grant access through the Security Access Service Identifier (0x27). Only after the security access service has been passed, services like Request Download and Transfer Data can be used. The security concept used is called “Seed and Key”. Security Access Service flow:

• The client sends a request for a “seed” to the server that it wants to unlock.
• The server replies by sending the “seed” back to the client.
• The client then generates a “key” based on the “seed” and sends the key to the server.
• If the client-generated the “key” with the correct algorithm the server will respond that the “key” was valid and that it will unlock itself.

Security Access Seed Request Frame

The below table explains how to request seed from client to server for unlocking an ECU as per the above steps. Please remember that the Security Access Service Identifier (0x27) mostly supports in Extended diagnostic session, so before you request it you should know the diagnostic session that how to jump from the default session to the extended diagnostic session. If you want to learn this then please go to my default session tutorial and first learn that and then come to this session. For remind you, it is 10 03

The above table defines what are the data format should be maintained to use the Security Access service in UDS Protocol for requesting a seed. Let me explain you by one example how to request a seed:

Security Access Seed Response Frame

The response message has a response SID and if it is a positive response the parameter is an echo of the request message parameter. If it is a negative response the parameter is one of eight negative response codes.

The above table defines what are the data format should be maintained to use the Security Access Service Identifier (0x27) in UDS Protocol for getting a seed key response from an ECU. Let me explain to you by one example of how an ECU sends a response frame for the above request seed. Remember I have taken the example as the response seed key is 0x1234, it can be anything as per the OEM algorithm implementation.

Security Access SendKey Request Frame

When the client will request a seed first to the ECU, the ECU will receive, and as per the ECU behavior, it will send the response as positive or negative. If it is negative then the client should take the decision of what action needs to be done. But if it is positive, then the Client will receive the seed key sent by the server and then the client will generate a security key from that seed key sent by the ECU. So let’s go discuss how the client will send this security key and in which format. Look onto the below table for details:

I hope you already understood the format from the above table as to how to send a generated send key. So let’s go see how it will be in a CAN frame with an example:

• Byte0[06]: This is a PCI byte. The LSB nibble having 6 which means this frame is holding 6 bytes of data in this CAN frame. The MSB nibble defines types of frame, so here it is “0” that means it is a single frame.
• Byte1[27]: This a first data byte in CAN data frame which means it will be a service Identifier. Since it is having 27 in hex, it is a security access service identifier.
• Byte2[02]: So in the Security access service Identifier of UDS protocol, the second byte is the seed or “send key” byte. since it is a second request byte as we have already sent the seed request and received the “seed key” from the server, now we need to send the “sendkey” as Sub-function, so this will be the next value of requested “seed key” Sub-function.
• Byte3-6[D4C3B2A1]: These are the generated real security key to which the ECU will be used to unlock the ECU. I have given an example value it will change as per the written code generator algorithm.
• Byte7[55]: This value is empty as there is no data to send. So the default value will be 0x55.

Security Access SendKey Response Frame

When the client will send the “sendkey” request message with a valid security key, the server will check to compare that key with the sake key generated by the client and if it will match then the server will unlock the ECU. Then after unlock the ECU will send a positive response message as below table.

If you understood the above table that how the server should send the positive response message, then let’s go see really in CAN data frame how the client is sending the positive response message. Please look at the below table.

In the above table it defines the CAN “sendkey” response message.

• Byte0[02]: This PCI byte is holding an LSB nibble having 6 which means this frame is holding 2 bytes of data in this CAN frame. The MSB nibble defines types of frame, so here it is “0” that means it is a single frame.
• Byte1[67]: This a first data byte in the CAN data frame which means it will be a positive response service Identifier. Since it is having 67 in hex, it is a security access positive response service identifier.
• Byte2[02]: This is the second byte in diagnostic response message of security access. So this byte is the Sub-function Identifier for the requested sub-function. Since it is 02 hence it is “sendkey“.
• Byte3-7[55]: These are the empty data byte filled as 0x55 for default.

Security Access Negative Response Message

The Security Access Service Identifier (0x27) is having different negative response codes that are used to inform the user if any wrong request or any fault is there in ECU for which the ECU is not able to execute this Security Access Service Identifier (0x27) successfully. Suppose the request message sent by the client is not supported in that ECU or any kind of problem. You might say it is a hardware fault, security mismatch, software fault, timing issue, or sequence issue defined as per the ISO14229 standard or OEM, then the client will send a negative response message with the particular code value. As per this code, the client can understand the problem and it needs to be fixed. Please look at the below table for getting to know all the security access negative response codes (NRC).

• Sub-function Not Supported (12 hex): The Function (session type) in the request message is not supported.
• Incorrect Message Length/Invalid Format (13 hex): The length of the message is wrong or might be invalid data format.
• Conditions Not Correct (22 hex): Used when the server is in a critical normal mode activity and therefore can not perform the requested DTC control functionality as per the request message. It might be the temperature or voltage etc as defined and implemented by the OEM by the developer.
• Request Sequence Error (24 hex): This will Send if the “sendKey” sub-function is received without first receiving a“requestSeed” request message. This NRC mostly come for this wrong sequence in between the “requestSeed” or “sendKey” only.
• Request Out Of Range [31 hex]: The server shall use this response code if it detects an error in the DTC Setting Control Option Record in this service.
• Invalid Key [0x35]: This will Send by the ECU if an expected “sendKey” sub-function value is received and the value of the key does not match the server’s internally stored or calculated key.
• Exceeded Number Of Attempts [0x36]: This NRC will send by the ECU if the delay timer is active due to exceeding the maximum number of allowed false access attempts. The number of retry or attempts can be any number as per the OEM. This is not coming under ISO14229 specification.
• Required Time Delay Not Expired [0x37]: This NRC will Send if the delay timer is active and a request is transmitted.

Security Access NRC frame format

In the below table, you would have understood the frame, but let me explain to you also how it is as per the below table so that you can do the same in your canalyzer or canoe tool for simulation.

• Byte0[02]: This PCI byte defines the single frame and two bytes of data.
• Byte1[7F]: This is a Negative response service identifier. It is defined in the ISO14229 standard.
• Byte2[22]: This is a second byte and having the value 0x22 so that it means the error is the condition is not correct. So what is that condition, if you want to know then you need to follow the OEM document that what are the conditions that are implemented in the security access service identifier.

Key points of Security Access Service (0x27)

Once the ECU will get unlocked, then you can able to read or write any authorized data to or from the ECU. but if you will not do any task after unlocking your ECU, automatically the ECU will be locked after some time as per the timing parameter defined by the OEM.

I hope you guys will understand this service ID very well if you have any doubt you can ask your question in my forum website. Please write your comment below if this tutorial helps you in understanding or getting a good job or helping you crack the interview in the Automotive field.