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 sup

ply 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 injure the physical science or alternative vehicle elements or risk the vehicle’s compliance with emissions, safety, or security standards. The security construct uses a seed and key relationship.

Remember always the ECUs 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 from 0x00 – 0xFF are available with different security levels. If you are not understanding the security level don’t worry I will explain it below for your doubt clearly. basically, all the odd values are used for seed request whereas the next even values (Seed request security level + 1) will be used to send the security key to the ECU to unlock by using the Security Access Service Identifier (0x27)

To prevent 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 Service 0x27 Frame Format

The frame format for the security access service in the UDS protocol includes the 0x27 service identifier (SID) and additional data. In the Security Access service, there are no sub-functions. It has Security levels or you can say that the Levels are considered sub-functions as per your understanding.

In the UDS protocol standard, security access levels are utilized to restrict and control the privileged operations that can be performed by a diagnostic tester on an electronic control unit (ECU) in a vehicle.

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 Extended diagnostic sessions, 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. To remind you, it is 10 03

Data Byte	Parameter Name	Hex Value
0	PCI	0x01-0xFF
1	SID: Security Access Request	0x27
2	SBF: Request Seed	0x01,03,05-7D (all odd values between 0x00-0xFF)
3	Data Record[0] (High Byte)	0x00 – 0xFF
n…	Data Record[n] (Low Byte)	0x00 – 0xFF

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

Byte 0	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6	Byte 7
0x02	0x27	0x01	0x55	0x55	0x55	0x55	0x55

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.

Data Byte	Parameter Name	Hex Value
0	PCI	0x01-0xFF
1	Security Access Response ID	0x67
2	Request Seed SBF	0x01,03,05-7D (odd values between 0x00-0xFF)
3	Security Seed[High Byte]	0x00 – 0xFF
4	Security Seed[Low Byte]	0x00 – 0xFF

The above table defines what 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 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.

Byte 0	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6	Byte 7
0x04	0x67	0x01	0x12	0x34	0x55	0x55	0x55

Security Access SendKey Request Frame

When the client will request a seed first to the ECU, the ECU will receive it, and as per the ECU’s 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 at the below table for details:

Data Byte	Parameter Name	Hex Value
0	PCI	0x01-0xFF
1	SID: Security Access Request	0x27
2	SBF: Send Key	0x02,04,06-7E (even values between 0x00-0xFF)
3	Data Record[0] (High Byte)	0x00 – 0xFF
n…	Data Record[n] (Low Byte)	0x00 – 0xFF

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:

Byte 0	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6	Byte 7
0x06	0x27	0x02	0xA1	0xB2	0xC3	0xD4	0x55

• Byte0[06]: This is a PCI byte. The LSB nibble has 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” which means it is a single frame.
• Byte1[27]: This is the first data byte in the 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 unlocking the ECU will send a positive response message as below table.

Data Byte	Parameter Name	Hex Value
0	PCI	0x01-0xFF
1	Security Access Response ID	0x67
2	Request Seed SBF	0x01,03,05-7D (odd values between 0x00-0xFF)
3	Security Seed[High Byte]	0x00 – 0xFF
4	Security Seed[Low Byte]	0x00 – 0xFF

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

Byte 0	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6	Byte 7
0x02	0x67	0x02	0x55	0x55	0x55	0x55	0x55

The above table 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” which means it is a single frame.
• Byte1[67]: This is the 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 the 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 an 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 comes 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 retries 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.

Byte 0	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6	Byte 7
0x02	0x7F	0x27	0x22	0x55	0x55	0x55	0x55

• 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[27]: This is the 2nd byte of diagnostic data and defines the Security Access Service Identifier.
• Byte3[22]: This is a 3rd byte and has the value 0x22 so 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 doubts you can ask your question on my forum website. Please write your comment below if this tutorial helps you in understanding or get a good job or helping you crack the interview in the Automotive field.