|
GM WORLDWIDE ENGINEERING STANDARDS
GMW3110
© Copyright 2010 General Motors All Rights Reserved
February 2010
Page 125 of 336
8.8 SecurityAccess ($27) Service.
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 modes
for downloading routines or data into a node and reading specific memory locations from a node are situations
where security access may be required. Improper routines or data downloaded into a node could potentially
damage the electronics or other vehicle components or risk the vehicle’s compliance to emission, safety, or
security standards. This mode is intended to be used to implement the data link security measures defined in
SAE J2186 (E/E Data Link Security).
8.8.1 Service Description.
The security concept uses a seed and key relationship. The seed and key are
each 16-bit numbers (2-byte). The security seed and key shall be stored in non-volatile memory during the
manufacturing process of the Node.
Note:
The security seed shall be a random non-zero and non-$FFFF number. The security seed shall be
generated for each individual part (all nodes with the same part number shall NOT have the same security
key).
The security key shall be derived from the security seed using an external encryption algorithm
.
The SPS
programming security algorithm for a node is assigned by GM Service and Parts Operations. The
manufacturing device control security algorithm for a node is assigned by the Manufacturing Serial Data
Design Engineer. Under no circumstances shall the encryption algorithm ever reside in the node.
A typical example of the use of this service is as follows:
Tester requests the Seed.
Node sends the Seed.
Tester sends the Key (appropriate for the Seed received).
Node responds that the Key was valid and that it will unlock itself
A 10 s time delay shall be required before the node can positively respond to a service SecurityAccess
requestSeed message from the tester after node power-on. This delay is only required if the MEC > 0 or the
vulnerability flag is = $FF when powered on. Reference the pseudo code in paragraph 8.8.6.2 for further
clarification.
The tester shall request the node to unlock itself by sending the service SecurityAccess requestSeed
message. The node shall respond by sending a seed using the service SecurityAccess “requestSeed” positive
response message. The tester shall then respond by returning a key number back to the node using the
service SecurityAccess sendKey request message. The node shall compare this key to one internally stored. If
the two numbers match, then the node shall enable (unlock) the tester’s access to specific services and
indicate that with the service SecurityAccess sendKey positive response message. If upon two attempts of a
service SecurityAccess “sendKey” request message by the tester, where the two keys do not match, then the
node shall insert a 10 s time delay before allowing further attempts. The 10 s delay shall be invoked for each
subsequent failed attempt. An invalid key requires the external tester to start over from the beginning with a
Security Access request message.
If a device supports security, but is already unlocked (MEC > 0 or the vulnerability flag is = $FF) when a
SecurityAccess requestSeed message is received, that node shall respond with a SecurityAccess
requestSeed positive response message service with a seed value of $0000. A tester shall use this method to
determine if a node is locked by checking for a non-zero seed.
Attempts to access security shall not prevent normal vehicle communications or other diagnostic
communication.
Nodes which provide security shall support reject messages if a secure service is requested while the node is
locked (e.g., TransferData $36 service). Reference the description and pseudo code sections of each
diagnostic service to determine where security access applies.
This service requires a TesterPresent ($3E) to be sent prior to a P3
C
timeout or the node shall lock itself
(unless it was already unlocked when this service was first requested).
Nodes are considered locked or unlocked based on the table below. See paragraph 9.3.2.6 for definitions of
the Manufacturers Enable Counter and Vulnerability Flag. The Security Status does not change state when the
MEC value is written to $00. The Security Status is evaluated when a SecurityAccess “requestSeed” message
is received. See Table 99.
--``,,``````,``,,``,,,`,`,`,,-`-`,,`,,`,`,,`---
Do'stlaringiz bilan baham: |
