UDS SID "Security Access" (0x27)

Definiert in ISO 14229-1:2006 ab Seite 45.

https://udsoncan.readthedocs.io/en/latest/udsoncan/intro.html

Das Arbeitsprinzip hierbei ist eine Challenge/Response Sicherheitsabfrage:

1. Tester (Client) fordert einen SEED beim Client an
2. ECU (Server) generiert den SEEND mittels eines internen geheimen Algorithmus und sendet diesen zum Tester
3. Der Tester ist ebenfalls im Besitz des geheimein Algorithmus und berechnet aus dem SEED einen KEY und sendet diesen zum Client
4. Der Client vergleicht den empfangenen KEY mit seinem für die SEED-Berechnung verwendeten KEY und gibt Zugriff wenn er überein stimmt

1. Tester sendet (Request SEED) 0x27 0x01 an ECU
   1. ECU generate SEED and KEY
2. ECU sendet (SEED) 0x27 0x01 xx xx … an Tester
   1. Tester calculate KEY from SEED
3. Tester sendet (Verify KEY) 0x27 0x02 xx xx … an ECU
   1. ECU verify KEY
4. ECU sendet (ACCESS GRANTED) 0x27 0x02 an Tester

Security Access works using a shared-secret between ECU and authorized tester (secret algorithm/private key). The purpose is to restrict access to certain services/subfunctions by i.e. unauthorized tester/tools (3rd party) or users lacking certain access rights.

To request Security Access, the tester will first send a command to request a random seed from the ECU (i.e. 0x27 01). If the ECU will allow this in their current state, it may respond with a positive response including the seed (i.e. 0x67 01 AA BB CC DD). Then the tester application needs to take this seed (0xAA BB CC DD) and apply a secret key generation algorithm to it (i.e. a cryptographic function using a private key only known to ECU and authorized tester) - once the key is calculated it needs to be sent back to the ECU (i.e. 0x27 02 66 77 88 99). The ECU can reply to this with a positive response (i.e. 0x67 02) or an Negative Response Code (i.e. 0x7F 0x27 0x35).

That means a tester will not always be granted security access at the requested security level. It is possible for the ECU to deny the access - common reasons are:

    transition to this security access level is not possible from the current session/security level (i.e. NRC 0x7F serviceNotSupportedInActiveSession, NRC 0x22 conditionsNotCorrect, NRC 0x31 requestOutOfRange...)
    the key send by tester does not match the key which the ECU expects (NRC 0x35 invalidKey)
    tester tried to many times with the wrong key (NRC 0x36 exceedNumberOfAttempts)
    the ECU is not allowing unlocking security access currently due to too many wrong attempts before - tester needs to wait a certain timeout first (NRC 0x37 requiredTimeDelayNotExpired)

The purpose of this service is to provide a means to access data and/or diagnostic services which have
restricted access for security, emissions or safety reasons. Diagnostic services for downloading/uploading
routines or data into a server and reading specific memory locations from a server are situations where
security access may be required. Improper routines or data downloaded into a server could potentially
damage the electronics or other vehicle components or risk the vehicle’s compliance to emissions, safety or
security standards. The security concept uses a seed and key relationship.
A typical example of the use of this service is as follows:
⎯ client requests the “seed”;
⎯ server sends the “seed”;
⎯ client sends the “key” (appropriate for the Seed received);
⎯ server responds that the “key” was valid and that it will unlock itself.
ISO 14229:2006(E)
46 © ISO 2006 – All rights reserved
A vehicle-manufacturer-specific time delay may be required before the server can positively respond to a
service SecurityAccess “requestSeed” message from the client after server power up/reset and after a certain
number of false access attempts (see further description below). If this delay timer is supported, then the
delay shall be activated after a vehicle-manufacturer-specified number of false access attempts has been
reached or when the server is powered up/reset and a previously performed SecurityAccess service has failed
due to a single false access attempt. If the server supports this delay timer, then after a successful
SecurityAccess service “sendKey” execution the server internal indication information for a delay timer
invocation on a power up/reset shall be cleared by the server. If the server supports this delay timer, and
cannot determine if a previously performed SecurityAccess service prior to the power up/reset has failed, then
the delay timer shall always be active after power up/reset. The delay is only required if the server is locked
when powered up/reset. The vehicle manufacturer shall select if the delay timer is supported.
The client shall request the server to “unlock” by sending the service SecurityAccess “requestSeed” message.
The server shall respond by sending a “seed” using the service SecurityAccess “requestSeed” positive
response message. The client shall then respond by returning a “key” number back to the server using the
appropriate service SecurityAccess “sendKey” request message. The server shall compare this “key” to one
internally stored/calculated. If the two numbers match, then the server shall enable (“unlock”) the client’s
access to specific services/data and indicate that with the service SecurityAccess “sendKey” positive
response message. If the two numbers do not match, this shall be considered a false access attempt. If
access is rejected for any other reason, it shall not be considered a false access attempt. An invalid key
requires the client to start over from the beginning with a SecurityAccess “requestSeed” message.
If a server supports security, but the requested security level is already unlocked when a SecurityAccess
“requestSeed” message is received, that server shall respond with a SecurityAccess “requestSeed” positive
response message service with a seed value equal to zero (0). The server shall never send an all zero seed
for a given security level that is currently locked. The client shall use this method to determine if a server is
locked for a particular security level by checking for a non-zero seed.
There shall always be a fixed relationship for each level of security supported so that the sendKey
sub-function parameter value used for any given security level shall be equal to the requestSeed sub-function
parameter value used for that security level plus one.
Only one security level shall be active at any instant of time. For example, if the security level associated with
requestSeed 03 hex is active, and a tester request is successful in unlocking the security level associated with
requestSeed 01 hex, then only the secured functionality supported by the security level associated with
requestSeed 01 hex shall be unlocked at that time. Any additional secured functionality that was previously
unlocked by the security level associated with requestSeed 03 hex shall no longer be active. The security
levels numbering is arbitrary and does not imply any relationship between the levels.
Attempts to access security shall not prevent normal vehicle communications or other diagnostic
communication.
Servers which provide security shall support reject messages if a secure service is requested while the server
is locked.
Some diagnostic functions/services requested during a specific diagnostic session may require a successful
security access sequence. In such a case, the following sequence of services shall be required:
⎯ DiagnosticSessionControl service;
⎯ SecurityAccess service;
⎯ secured diagnostic service.
There are different accessModes allowed for an enabled diagnosticSession (session started) in the server.
IMPORTANT — The server and the client shall meet the request and response message behaviour as
specified in 7.5.2 in the event that those addressing methods are implemented for this service