RNDS-C-20023_2.1
RENAULT NISSAN DESIGN SPECIFICATION
(RNDS)
Part/module generic specifications, containing
RNDS-C-20023 v2.1
RENAULT STANDARD
(GDNormes)
NISSAN DESIGN
SPECIFICATION
(NDS)
Issued: 2021-05-31
IMPORTANT PART SYMBOL
_____________________________________________________________________________________
MESSAGE AUTHENTICATION CODE SPECIFICATIONS
Confidentiality level: Alliance Internal
Signature (Renault Approver)
Signature (Nissan Approver)
Philippe LANGRY
Shiro TSUJIOKA
©RENAULT 2021
©NISSAN 2021
1/54
Alliance Internal
RNDS-C-20023_2.1
Revisions
S.Matsuyama
M.Miyashita
J.B.Mange
T.Suzuki
P.Giraux
APPROVED
BY
T.Yamaguchi
H.Yamada
U.Sharma
K.Ito
Y.Kikuchi
T.Yamaguchi
Y.Kikuchi
H.Yamada
K.Naka
M.Nakamoto
K.Ito
M.Miyashita
K.Naka
H.Yamada
T.Yamaguchi
JB.Mange
AUTHOR
-MAC_SYNC_017 added
-MAC_SYNC_018 added
-Annex D added
Typo-Error fix:
-MAC_AUTH_042 updated
-MAC_PROV_012 updated
-MAC_AUTH_047 updated
- MAC_MACOFF_00x added
- MAC_AUTH_0xx updated
- MAC_SYNC_0xx updated
- MAC_PROV_0xx updated
- MAC_DBG_0xx updated
- MAC_RST_00x removed
XX6
2021-05-31
XW3
2020-06-16
XW3
DE-SPC8
2017-10-27
Newly established
1.0
SECT
APPROVED
DATE
ALTERATION
CHG
RNDS
2.1
2.0
RENAULT-NISSAN
Alliance Internal
2
RNDS-C-20023_2.1
Important Notices and Disclaimers

It complies with the agreement reached between RENAULT and NISSAN in 2020-06-16.
Any revision or alteration of this document is subject to prior approval by the RENAULT or NISSAN
secretariat.

The original version of this document was written in English.
In the event of any discrepancies or differences in meaning created as a result of translation of this
document into a foreign language, the meaning found in the English original shall take precedence.
Copyright notice
©RENAULT 2021
©NISSAN 2021
No Modification permitted without the consent of RENAULT and NISSAN.
No duplication permitted without the consent of RENAULT or NISSAN.
No circulation permitted without the consent of RENAULT or NISSAN.
For Renault and Nissan: Disclosure rules to be respected (described in AWP-B-20094)
Alliance Internal
3
RNDS-C-20023_2.1
Foreword
Renault
Issued by
:
JASMINA MILIVOJEVIC (DEA-SIC)
Validated by
:
JEAN-BAPTISTE MANGE (DEA-SIC)
Issued by
:
TAKASHI YAMAGUCHI (XX6)
HIDEAKI YAMADA (XX6)
UCHIT SHARMA (XX6)
NISSAN
YOSUKE KIKUCHI (XX6)
KATSURA ITO (XX6)
Validated by
:
SATORU MATSUYAMA (XX6)
Alliance Internal
4
RNDS-C-20023_2.1
Contents
Foreword ...........................................................................................................................................................4
Introduction .......................................................................................................................................................6
1 Scope ...........................................................................................................................................................7
2 Normative and informative references .....................................................................................................7
3 Terms and definitions .................................................................................................................................8
4 Symbols and abbreviations .......................................................................................................................8
5 Requirements ..............................................................................................................................................9
5.0
General requirement ............................................................................................................................9
5.1 Authentication ....................................................................................................................................10
5.2
Synchronization .................................................................................................................................20
5.3
MAC Key Provisioning .......................................................................................................................25
5.4
Troubleshooting .................................................................................................................................33
5.5 No MAC verification .........................................................................................................................36
Annex A (Informative).....................................................................................................................................38
Annex B (Informative) ....................................................................................................................................39
Annex C (Informative) ....................................................................................................................................54
Annex D (Informative) ....................................................................................................................................55
Alliance Internal
5
RNDS-C-20023_2.1
Introduction
This document describes the requirements for Message Authentication Code with the CAN-FD communication
software of an ECU.
Alliance Internal
6
RNDS-C-20023_2.1
1 Scope
This document describes the requirements for Message Authentication Code with the CAN-FD communication
software of an ECU.
Each requirement is described with a requirement number and a description in a chart such as presented
below:
Req_Id
Req_Text
Sub_Req_Id
Req_Id: is the unique requirement identifier for the whole project.
Sub_Req_Id: when present, is the unique requirement identifier for the whole project and in this case Req_Id
becomes the aggregation of all related Sub_Req_Id.
Req_Text: is a description of the requirement.

The word SHALL in the text means a mandatory requirement.

The word SHOULD in the text means a recommendation or advice on implementing a requirement. Such
recommendations or advice are expected to be followed; unless justified reasons are stated for not doing
so.
2 Normative references
These normative references apply the latest version.
Normative
[1] RFC4493 - The AES-CMAC Algorithm
[2] SHE - Secure Hardware Extension functional specification Version1.1
[3] RNDS-C-00065 - Unified Diagnostic Services (UDS) Implementation
[4]
CAN message specifications
[6] FIPS197 - Federal Information Processing Standards Publication 197 -ADVANCED ENCRYPTION
STANDARD (AES)
[8] RNDS-B-00010 - CAN High Speed and CAN –FD Communication Software
[9] SAE J1979-1 - E/E Diagnostic Test Modes
[10] RN common DTC List : “DTC Codes for DiagMux specification”
Alliance Internal
7
RNDS-C-20023_2.1
3 Terms and definitions
For the purpose of this standard, the following terms and definitions apply.
Terms/ definitions
Explanations
AES
Standard AES cryptographic algorithm as defined in the FIPS 197 (Refer to [6]).
AES-CMAC
The standard described in RFC4493
Authentic CAN
The traditional applicative data of a CAN frame without any security (no anti replay
DATA
counter, no MAC).
CAN ID
Identifier for CAN frame 11bit.
CAN_ID padding
The additional 5 most significant bits (with value 0) added to CAN_ID to achieve
complete 2 bytes length.
DID
Diagnostic Identifier. DIDs are used to retrieve the information recorded inside the
ECU for troubleshooting and analysis purpose.
KMAC
The secret symmetric key used in the AES-CMAC algorithm to mutually authenticate
all ECUs involved in highly privileged function. This key is unique per vehicle and is
shared among all ECUs involved in highly privileged functions. This key is never
export outside of the vehicle and it is never transmitted in clear text inside the vehicle.
KMASTER_ECU
The key used to register KMAC in an ECU involved in highly privileged function. This
key is unique per ECU. This key is never export outside of the vehicle and it is never
transmitted in clear text inside the vehicle.
LSB_ARC
The 2 Least Significant Bytes of the anti-replay counter.
Padding
The additional bits added to CAN frame payload to achieve the DLC supported by
CAN FD specification
Secured CAN
A frame with a counter and MAC attached to the message.
frame
tMAC
The truncated to 64 bits output of the AES-CMAC algorithm.
Excl. Time
This column gives the exclusion time, that is the minimum time that should be kept
between 2 tranmsission of frames for the periodic and event frames. Without
additional event, the frame is sent every "Period"ms. In case of additional event, the
minimum time between 2 frames is "Excl TIme"ms.
4 Symbols and abbreviations
For the purpose of this standard, the following symbols and abbreviated terms apply.
Abbreviations
Description
ARC
Anti-Replay Counter
CAN
Controller Area Network
ECU
Electronic Control Unit
MAC
Message Authentication Code
tMAC
truncated Message Authentication Code
Alliance Internal
8
RNDS-C-20023_2.1
5 Requirements
5.0 General requirement
MAC_GNR_00X General requirement
MAC_GNR_001 Parameters in requirements SHALL comply with Table 0.
MAC_GNR_002 Hardware SHALL be selected which MAC key writing and other nonvolatile memory writing does not conflict. If necessary (due to
performance), supplier SHALL explain reason and how to implement
to R/N and make agreement.
Table 0 - Parameter definition
Parameter
Definition
N
Emission counter increment value when an ECU detects unexpected reset.
N = 1 000 000 is the default value
t0
Maximum threshold time duration for transmission of resynchronization frame when
any error counter reaches X.
t0 = 1 ms is the default value
t1, t2
Minimum and Maximum threshold time deviation between two consecutive sync
frame, when event sync frame and periodic sync frame transmission is overlapping.
t1 = 0.5 ms is the default value
t2 = 1 ms is the default value
t3
Time within which a resynchronization frame will be sent when an ECU receives a
valid tMAC synchronization frame with an anti-replay counter lower than their current
reception counter minus W.
t3 = 1 ms is the default value
t4
Maximum threshold time duration for detect initial key DTC(U1327-54) after clear
DTC command.
t4 = 200 ms
t5
Maximum threshold time duration for detect initial key DTC(U1327-54) after any ECU
start up(Ex: wake up, hot or cold start).
t5 = 500 ms
W
Anti-Replay Counters acceptance window length. It is designed to allow CAN frames
to be received in a different order than the emission order.
W = 64 is the default window size
X
Maximum threshold value for error counter. Whenever error counter value reaches
X, ECU transmits resynchronization frame.
X = 2 is the default error count.
F
Emission ARC threshold for DTC in case of abnormal ARC jump.
F = 0xFF0000000000 is the default threshold
Alliance Internal
9
RNDS-C-20023_2.1
5.1
Authentication
This section describes the authentication algorithm between all ECU supporting the highly privileged functions.
KMAC is the shared AES key used in the AES-CMAC algorithm.
The layout of the secured CAN frame is as follow:
[Authentic CAN DATA] [Padding] [LSB_ARC] [tMAC]
For more details about the layout of a secured CAN frame, refer to Ref [8] and CAN message list.
The length of LSB_ARC is always 2 bytes.
The Anti-Replay Counter is a monotonous counter saved in each ECU (6 bytes long).
tMAC is the most significant 64 bits (8 bytes) of output of AES-CMAC algorithm as defined in RFC4493
computed from the message M = [CAN_ID padding] [CAN_ID] [Authentic CAN DATA] [Full Anti-Replay
Counter] and the secret key KMAC.
The total number of Anti-Replay Counters is equal to the number of ECUs that emit secured CAN frames. For
receivers, the number of Anti-Replay Counters to handle SHALL be defined according to CAN message list.
Each receivers ECU SHALL maintain a table that match the CAN frame ID with the corresponding ARC.
Table 1 ― Example of ARCs
CAN ID
ARC ID
Emitter
204
ECU1
1
10c
ECU1
1
364
ECU2
2
2a8
ECU2
2
531
ECU3
3
32f
ECU4
4
2ba
ECU5
5
Alliance Internal
10
RNDS-C-20023_2.1
Fig. 1 ― Anti-Replay Counters for emitters and receivers
The receiver ECU keeps track of which CAN frames it has already processed on the basis of these Anti-Replay
Counters with the use of a sliding window of all acceptable sequence numbers. Currently, the default AntiReplay Counter window is W = 64 CAN frames. This is illustrated in Fig. 2. W is the window length of
acceptance for anti-replay counters. It is designed to allow CAN frames to be received in a different order than
the emission order. This different order is caused by the architecture with GW. GW must transmit many frames
from one CAN bus to another. This transmission is managed by arbitration rule. Each CAN frame has priority
based on CAN ID, so sometimes GW transfers later received frame with high priority to another bus than early
received frame with low priority. W is a mechanism to absorb different order of ARC.
Fig. 2 ― Anti-Replay Counter window illustration
When a CAN frame is received, if the ARC falls within the window and was not previously received, then verify
MAC of the received frame. If it is valid, the frame is accepted, and marked as received.
Alliance Internal
11
RNDS-C-20023_2.1
If the ARC falls within the window and was previously received, the packet is dropped.
If the received ARC is greater than the highest sequence number in the window, then verify MAC of the
received frame. If it is valid, the frame is accepted, and marked as received. The sliding window is then moved
to the right. The frame is also marked as received.
If received Anti-Replay Counter is less than the lowest sequence in the window, the frame is dropped, and the
corresponding error counter is incremented.
During the boot sequence of a receiver ECU, it must increment all receiver ARCs in RAM by the window value
W = 64.
During special condition when Anti-Replay counter reaches maximum value (0xFFFFFFFFFFFF),
there verification of secured frame should be done based on MAC value only (no check for ARC
increment).
MAC_AUTH_00x MAC generation
MAC_AUTH_001 The ECU SHALL send all secured CAN frames with the following
elements in the given order: Authentic CAN DATA, the padding, the LSB
of the Anti-Replay Counter and the tMAC. Regarding value of the
padding, refer to [CANSW-FD059a] in Ref[8].
MAC_AUTH_002 The tMAC value is the AES-CMAC output as defined in RFC4493
truncated to the most significant 64 bits (8 bytes). This algorithm has
2 inputs:
- the message M which is defined as the concatenation of the
CAN_ID padding, CAN_ID, the Authentic CAN DATA and an Anti-Replay
Counter
- the secret AES key KMAC.
MAC_AUTH_003 CAN_ID padding length is 5 bits for CAN frames with IDs of 11 bits.
MAC_AUTH_004 Value of the padding is 0x00.
MAC_AUTH_005 Value of CAN_ID padding is 0x00.
MAC_AUTH_01x Anti-Replay emission counter
MAC_AUTH_011 Each ECU that sends secured CAN frame SHALL keep an internal AntiReplay Counter. This counter has a length of 6 bytes.
Alliance Internal
12
RNDS-C-20023_2.1
MAC_AUTH_012 This counter SHALL be incremented by one each time that this ECU
sends one secured CAN frame.
This counter SHALL be incremented before sending one secured CAN
frame.
The steps to send one secured CAN frame SHALL be below.
1) increment this counter by one
2) calculate MAC value
3) send one secured CAN frame
Example
when this counter is 0x000000000000 (6 bytes),
1) increment this counter from 0x000000000000 to
0x000000000001
2) calculate MAC , using 0x000000000001 as this counter
3)
send one secured CAN frame
The LSB_ARC of this counter SHALL be appended to the Authentic CAN
MAC_AUTH_013 DATA (after the padding if there are some).
Initial value of this counter at ECU delivery from supplier to OEM
MAC_AUTH_014 SHALL be 0x000000000000 (6 bytes).
This counter SHALL NOT be changed even if this ECU sends one secured
MAC_AUTH_015 CAN frame, if counter is 0xFFFFFFFFFFFF (6 bytes).
This counter SHALL never be reset; neither by deliberately / abnormal
MAC_AUTH_016 operation nor after counter reaches 0xFFFFFFFFFFFF.
MAC_AUTH_02x Anti-Replay reception counters
MAC_AUTH_021 Each
ECU
that
receives
secured CAN frame SHALL
keep
the
corresponding Anti-Replay Counter of the emitting ECU. This counter is
also 6 bytes for each.
MAC_AUTH_022 Initial value of this counter at ECU delivery from supplier to OEM
SHALL be 0x000000000000 (6 bytes).
Example:
ECM receives 2 secured CAN frames from ADAS and 1 secured frame
from BCM. ECM has to keep 2 Anti-replay reception counters of 6 bytes
each.
Alliance Internal
13
RNDS-C-20023_2.1
MAC_AUTH_023 This counter SHALL never be reset; neither deliberately nor abnormal
operation.
Alliance Internal
14
RNDS-C-20023_2.1
MAC_AUTH_03x MAC verification
MAC_AUTH_031 When receiving a secured CAN frame, the ECU SHALL verify the MAC.
MAC_AUTH_032 Verifying the MAC SHALL comply with the following algorithm:
1) Extract tMAC from secured CAN frame by selecting the last 8 bytes
2) Extract the LSB of the Anti-Replay Counter by selecting the previous
2 bytes.
3) Extract the Authentic CAN DATA by removing the Padding, LSB_ARC and
tMAC from the secured CAN frame.
In order to detect padding position, frame structure SHALL be
analyzed every time.
*In case of Container Type CAN-FD Frame, the length of
AUTHENTIC_CAN_DATA could be changed depending on contained
I-PDUs structure (amount, order, etc.).
4) If LSB_ARC = 0xFFFF and stored full Anti-Replay Counter (FAR) =
0xFFFFFFFFFFFF, then execute below steps else proceed to 5).
o
Compute the tMAC value with stored FAR as the AES-CMAC
defined in RFC4493 truncated to the most significant 64 bits
(8 bytes) with the following parameters :

the message M which is the concatenation of the
CAN_ID padding, the CAN_ID, the Authentic CAN
DATA extracted in 3) and the full Anti-Replay Counter
FAR ;

o
the secret AES key KMAC ;
Compare the calculated tMAC with the one extracted in 1).

If values are identical then accept the secured CAN
frame and add FAR to the list of received ARCs (if
not present).

If values are not identical then don’t use the
Secured CAN frame and increment the
corresponding error counter (see
MAC_SYNC_01x).
5) Compute 3 full Anti-Replay Counter candidates (FAR) of the emitter
as follow with selecting MSB corresponding to the Secured CAN
frame ID:
o
“FAR1 = MSB || LSB extracted in 2)”
Alliance Internal
15
RNDS-C-20023_2.1
o
“FAR2 = MSB+1 || LSB extracted in 2)”
o
“FAR3 = MSB-1 || LSB extracted in 2)”
o
If MSB = 0xFFFFFFFF (4 bytes), “FAR2 = MSB || LSB
extracted in 2)”
o
If MSB = 0x00000000 (4 bytes), “FAR3 = MSB || LSB
extracted in 2)”
6) Compute the tMAC1 value with FAR1 as the AES-CMAC defined in
RFC4493 truncated to the most significant 64 bits (8 bytes) with
the following parameters :
o
the message M which is the concatenation of the CAN_ID
padding, the CAN_ID, the Authentic CAN DATA extracted in
3) and the full anti-replay counter FAR1 ;
o
the secret AES key KMAC ;
o
If LSB extracted in 2) > LSB stored in local ECU, then
7)
compute the tMAC3 value with FAR3 as the AES-CMAC
defined in RFC4493 truncated to the most significant 64
bits (8 bytes) with the following parameters :

the message M which is the concatenation of the
CAN_ID padding, the CAN_ID, the Authentic CAN
DATA extracted in 3) and the full Anti-Replay Counter
FAR3 ;

o
the secret AES key KMAC ;
If LSB extracted in 2) < LSB stored in local ECU, then
compute the tMAC2 value with FAR2 as the AES-CMAC
defined in RFC4493 truncated to the most significant 64
bits (8 bytes) with the following parameters :

the message M which is the concatenation of the
CAN_ID padding, the CAN_ID, the Authentic CAN
DATA extracted in 3) and the full Anti-Replay Counter
FAR2 ;

the secret AES key KMAC ;
8) Compare the computed values tMAC1, tMAC2 and tMAC3 with the
one extracted in 1). If no values are identical, don’t use the
Secured CAN frame and increment the corresponding error counter
(see MAC_SYNC_01x).
Alliance Internal
16
RNDS-C-20023_2.1
9) Order is important in this algorithm. If tMAC1 is identical to
the one extracted in 1):
o
If LSB extracted in 2) > LSB stored in local ECU then
update the corresponding counter with the value FAR1 and
add FAR1 to the list of received ARCs
o
If LSB extracted in 2) <= LSB stored in local ECU and FAR1
> (Local FAR – W) and FAR1 is not already in the list of
received ARCs then add FAR1 to the list of received ARCs
o
If LSB extracted in 2) <= LSB stored in local ECU and FAR1
is already in the list of received ARCs then don’t use the
secured CAN frame and increment the corresponding error
counter (see MAC_SYNC_01x).
o
If LSB extracted in 2) < LSB stored in local ECU and FAR1
<= (Local FAR – W) then don’t use the secured CAN frame
and increment the corresponding error counter (see
MAC_SYNC_01x).
10) Order is important in this algorithm.
o
If LSB extracted in 2) < LSB stored in local ECU and tMAC2
is identical to the one extracted in 1) then update the
corresponding counter with the value FAR2 and add FAR2 to
the list of received ARCs
o
If LSB extracted in 2) > LSB stored in local ECU and tMAC3
is identical to the one extracted in 1) and FAR3 > (Local
FAR – W) and FAR3 is not already in the list of received
ARCs then add FAR3 to the list of received ARCs.
o
If LSB extracted in 2) > LSB stored in local ECU and FAR3
is already in the list of received ARCs then don’t use the
secured CAN frame and increment the corresponding error
counter (see MAC_SYNC_01x).
o
If LSB extracted in 2) > LSB stored in local ECU and FAR3
<= (Local FAR – W) then don’t use the secured CAN frame
and increment the corresponding error counter (see
MAC_SYNC_01x).
MAC_AUTH_033
Two version of software SHALL be provided:
Alliance Internal
17
RNDS-C-20023_2.1
a) One version with no MAC verification (defined in
MAC_AUTH_032, MAC_AUTH_04X,
MAC_SYNC_00X, MAC_SYNC_02X).
For more details about no MAC specification, refer to section 5.5.
b) One version with mandatory MAC leaving no security backdoor
(i.e. configuration file, hidden feature, …).
The supplier SHALL provide the evidence / explanation on approach
adopted for functionality removal.
* By “version with no MAC verification”, we mean the MAC verification is
executed, but received frames are not dropped even if the MAC
verification’s result is not acceptable (defined in MAC_AUTH_032,
MAC_AUTH_04X, MAC_SYNC_00X, MAC_SYNC_02X).
Receiver does not increment Error counter and does not send Resync
frame.
MAC_AUTH_04X List of received ARCs
MAC_AUTH_041 Each receiver ECU SHALL maintain a list of the last W received values of
ARCs for each ARC. (For more information, refer to §5.1 Authentication
Page.10,11)
Example:
ADAS ECU has 3 different receiver ARC, it SHALL keep 3 lists of 64 values
corresponding to the last ARC received for each counter.
MAC_AUTH_042 Each list is updated when receiving a valid and secured CAN frame with the
ARC value contained in this secured CAN frame (see MAC_AUTH_03X for
conditions)
Example:
The list is implemented using a bitfield of 64 bits which are all 0 initially.
Current counter is 100 and the next received secured CAN frame ARC is 37
which is in the window 37-100. Then the list is updated to 10000000… The
next received secured CAN frame ARC is 39 which is also in the window 37100. Then the list is updated to 1010000…
MAC_AUTH_043 When receiving a valid and ARC that is greater than the current local ARC,
then the current full Anti-Replay Counter SHOULD be updated and the list
SHALL be shifted.
Alliance Internal
18
RNDS-C-20023_2.1
Example:
Current counter is 100. Current list is 10011000… Next received counter is
104 which is greater than 100. Then the list must be shifted by 104-100=4
bits. The new list is updated to 10000000…
MAC_AUTH_044 When receiving a synchronization frame as defined in MAC_SYNC_00x,
the receiver ECU SHALL NOT update the list of received values. The counter
contained in the synchronization frame is not a regular secured frame, it
does not contain any applicative data.
MAC_AUTH_045 If added value (+1 or +N or +64 ) makes Anti-Replay counter larger than
maximum value (0xFFFFFFFFFFFF), ARC value SHALL be set as maximum
value (0xFFFFFFFFFFFF). And maximum value of the window SHALL be set
as maximum value (0xFFFFFFFFFFFF).
MAC_AUTH_046 After ARC was set as maximum value (0xFFFFFFFFFFFF),
the window SHALL NOT be shifted
and window bits SHALL be continued to update
and each value whose window bit is equal to "0" can be accepted except
maximum value (0xFFFFFFFFFFFF) that will be always accepted whatever
the window bit value is.
MAC_AUTH_047 When current reception ARC value is smaller than window size (W), the
minimum value in the window SHALL be kept
as "0x000000000001".
MAC_AUTH_05X Diag Mux DTC
Diag Mux DTC implementation for a MAC Reception Failure
MAC_AUTH_051 Diag Mux DTC SHALL show MAC authentication failure of periodical secured
frames.
MAC_AUTH_052 The ECU SHALL implement a Diag Mux DTC per MAC ECU.
MAC_AUTH_053 Diag Mux DTC code SHALL be assigned according to [10] (See Fig.6.
•
Upper 2 byte of DTC SHALL be a secured frame emitter ECU’s value
defined in [10].
•
Upper 2 byte of DTC SHALL not be non-secured frame emitter ECU’s
value defined in [10].
DTC Status bits of DIAG Mux DTC
Alliance Internal
19
RNDS-C-20023_2.1
MAC_AUTH_054 ECU SHALL implement the DTC status bits that are compliant with Ref[3]
for each Diag Mux DTC.
•
Bit0 (TestFailed)
•
Bit3 (ConfirmedDTC)
MAC_AUTH_055 Bit 0 SHALL be raised if, for a period of 2 seconds, all Secured frames
coming from a specific ECU fail to authenticate (see MAC_AUTH_032) and
DTC SHALL go to Current status.
•
Sync, Resync frames are out of scope.
•
Bit0’s judgement time(B0JT) SHALL be longer one of the following
2 time length;
1. 2 seconds
2. 3 times of reception cycle
MAC_AUTH_056 Bit 0 SHALL be reset if at least one secured frame success to authenticate
or any ECU start up (Ex: wake up, hot or cold start) and DTC SHALL go to
Past status.
MAC_AUTH_057 Bit 3 SHALL be raised synchronously with bit 0.
Comment: This bit SHALL be reset by DTC clear command (Ref[3]and[9]).
MAC_AUTH_058 At delivery timing, bit 0 and bit 3 SHALL be 0.
Diag Mux DTC Check
MAC_AUTH_059 This check SHALL start as soon as possible when CAN-FD communication
is active and stop when the ECU stops CAN-FD communication.
State transition Description (Nominal sequence description)
The Diag Mux DTC behavior models are specified in the Annex B as
example.
Fig.6 Diag Mux DTC code assignment
Alliance Internal
20
RNDS-C-20023_2.1
5.2 Synchronization
The Anti-Replay Counters of the different emitting ECUs must be kept synchronized with all the receiving ECUs.
All ECUs SHALL write all current counter values to non-volatile memory when shutting down (go to sleep).
The following scenarios may force a de-synchronization (mismatch of ARC):
1. ECUs are not powered on at the same time
2. The network may delay or drop the transmission of secured CAN frame
3. ECUs may reset unexpectedly if power is lost for a sufficient period of time
4. Part replacement
For 1) and 2), the emitter continues to send secured CAN frames while the receivers don’t receive the
corresponding secured CAN frame. If the number of missed CAN frames is less than 2^16 (length of LSB_ARC
in bits), then the receivers are able to recover by themselves. If the number is > 2^16 then the full counter has
to be transferred to the receivers. In order to achieve this, all emitter ECUs will send their full ARC in a low rate
CAN frame called the synchronization frame. The time period of this synchronization CAN frame must be lower
than the time required to increase the counter by 2^16. The synchronization frame includes a MAC.
For 3) and 4) if the receivers reset and lose the current counter, then it will be resynchronized with the low rate
synchronization CAN frame sent by the emitter (see previous paragraph). If the emitter reset and lose the
current counter, then all secured CAN frames will be dropped by the receivers. The emitter must receive the
full ARC from one (or more) receivers. When receiving more than X secured CAN frame that fail to authenticate
(wrong MAC), receiver ECUs must send all the full Anti-Replay Counters in a secured CAN frame called the
resynchronization frame. The resynchronization frame includes a MAC.
Improvement leads:
1. When a receiver detects a valid synchronization frame with an Anti-Replay Counter lower than their
current emission counter minus W, the receiver immediately send a resynchronization frame. This
decreases the time required to resynchronize the emitter as the receiver does not wait X
authentication errors.
2. When an emitter detects that it has reset unexpectedly, then it immediately increases its own
emission counter by N (to be evaluated depending on the maximum number of frames emitted
during 20 minutes). It immediately stores this new counter in non-volatile memory and sends a
synchronization frame including the updated counter.
3. When an emitter receives a resynchronization frame with a counter sufficiently inferior to the current
one, the emitter immediately sends a synchronization frame with the current counter.
MAC_SYNC_00x
Synchronizing frame : sync frame
MAC_SYNC_001 All emitter ECUs SHALL send a so called sync frame to all of its
receivers.
Alliance Internal
21
RNDS-C-20023_2.1
This sync frame contains the full Anti-Replay Counter of the emitter (6
bytes), the padding (2 bytes) and the tMAC value (8 bytes). Regarding
value of the padding, refer to [CANSW-FD015a] in Ref[8].
For more details refer CAN message list.
MAC_SYNC_002 The tMAC value is the AES-CMAC output as defined in Ref [1] truncated
to the most significant 64 bits (8 bytes). This algorithm has 2 inputs:
- the message M which is defined as the concatenation of the
CAN_ID padding, CAN_ID, the Authentic CAN DATA including the full AntiReplay Counter (6 bytes) and the padding (2 bytes).
- the secret AES key KMAC.
MAC_SYNC_003 The emitter does not increase their current emission Anti-Replay Counter
when sending a synchronization frame.
MAC_SYNC_004 All receivers SHALL replace the current full Anti-Replay Counter when
receiving a sync frame with a valid tMAC and a counter which is greater
than the currently stored one.
In
addition,
the
window
SHALL
be
shifted
as
specified
in
MAC_AUTH_043.
MAC_SYNC_005 The sync frame SHALL be send frequently (1 sec), with a time period,
which is lower than the time required to increase the counter by 2^16.
MAC_SYNC_006 If the receiver cannot verify the tMAC value of the sync frame
successfully, it SHALL drop the sync frame and not update the current
local Anti-Replay Counter value. Don’t send any resync frame in this case.
MAC_SYNC_007 Minimum interval time between periodic*1 and event*2 sync frame
transmission SHALL be between t1 ms and t2 ms. (*3)
When event sync frame and periodic sync frame transmission timing is
overlapping, event sync frame SHALL be transmitted after transmitting
periodic sync frame.
*1: Sync frame transmitted periodically (refer MAC_SYNC_005 )
*2: Sync frame transmitted corresponding to resync frame (refer
MAC_SYNC_043 )
*3:
start: when to store 1st consecutive sync frame data to tx buffer
end: when to store 2nd consecutive sync frame data to tx buffer
Alliance Internal
22
RNDS-C-20023_2.1
MAC_SYNC_01x
Error counters
MAC_SYNC_011 The receivers ECUs SHALL keep an error counter for each receiving AntiReplay Counter.
MAC_SYNC_012 When one of the error counter reaches X, or when one of the error
counter keeps X, then receiver SHALL send resync frame within t0 ms
(*). And receiver SHALL NOT increment error counter and keeps error
counter
value
in
X
until
MAC_SYNC_013.
(refer
MAC_AUTH_032,033)
(*)
start: when to receive MAC frame
end: when to store resync frame data to tx buffer
MAC_SYNC_013 When receiving a valid secured CAN frame for a given anti-replay counter,
the corresponding error counter SHALL be reset to 0 (Even if a valid
sync or resync frame is received, do not reset error counter. Because
sync and resync frame are not secured frame.).
MAC_SYNC_014 In case of incrementing error counter, if error counter is smaller than
X, then receiver SHALL increment the corresponding error counter.
MAC_SYNC_015 After error counter reaches X, value SHALL be kept until error counter
reset defined by [MAC_SYNC_013]
MAC_SYNC_016 Initial value of error counters SHALL be 0.
MAC_SYNC_017 In case that trigger of resync frame transmission happens due to
[MAC_SYNC_012] within excl. time (defined in [4]) for Resync frame,
ECU SHALL send resync after excl. time (Refer to Annex D).
MAC_SYNC_018 In case that several triggers of resync frame transmission happen due
to [MAC_SYNC_012] within excl. time (defined in [4]) for Resync
frame, ECU SHALL send the latest resync frame after excl. time (Refer
to Annex D).
MAC_SYNC_02x
Resynchronization frame : resync frame
MAC_SYNC_021 The resynchronization frame contains all the received full Anti-Replay
Counters, the padding and the tMAC value. Regarding value of the
padding, refer to [CANSW-FD015a] in Ref[8].
Alliance Internal
23
RNDS-C-20023_2.1
For more details refer CAN message list.
MAC_SYNC_022 The tMAC value is the AES-CMAC output as defined in Ref [1] truncated
to the most significant 64 bits (8 bytes). This algorithm has 2 inputs:
- the message M which is defined as the concatenation of the
CAN_ID padding, CAN_ID, the Authentic CAN DATA including all received
full Anti-Replay Counter (6 bytes * number of counters received) and the
padding (dependent on the number of counters).
- the secret AES key KMAC.
MAC_SYNC_023 When receiving a resync frame, all emitters SHALL replace their current
anti-replay emission counter with the one contained in the resync
frame if it is greater than the currently stored one and tMAC is valid.
MAC_SYNC_024 If the emitter ECU cannot verify the tMAC value of the resync frame
successfully, it SHALL drop the CAN frame. Don’t send any sync frame
in this case.
MAC_SYNC_025 When receiving a resync frame, each emitters SHALL NOT update their
current anti-replay emission counter with the one contained in the
resync frame if it is not greater than the currently stored one.
Example:
BCM receives 4 Anti-Replay Counters (from 4 different ECUs). It maintains 4
error counters. If any of these error counter reaches X. The BCM send a
resync frame containing the 4 full Anti-Replay Counters (6*4=24 bytes)
concatenated with the corresponding tMAC value (8 bytes). Total length
of this resync frame is 24+8=32 bytes.
MAC_SYNC_03x
Anti-replay counters saving strategy
MAC_SYNC_031 All emitters and receivers SHALL save all the current counters in nonvolatile memory when going to sleep or shutdown.
MAC_SYNC_032 All emitters and receivers SHALL save all the current counters in nonvolatile memory every time the ARC is increased by N.
MAC_SYNC_033 All emitters and receivers SHALL read all the current counters from
non-volatile memory on startup.
MAC_SYNC_034 Reliability of non-volatile memory SHALL NOT be lost even if each the
Alliance Internal
24
RNDS-C-20023_2.1
current counters in non-volatile memory may be overwritten 100 000
times in vehicle life.
MAC_SYNC_035 All receiver ECUs SHALL immediately increment the reception counters
by W after loading them from non-volatile memory to RAM on startup.
This new value SHALL NOT be directly written to non-volatile memory.
It
SHALL
wait
for
the
standard
saving
strategy
defined
in
MAC_SYNC_031 and MAC_SYNC_032.
MAC_SYNC_04x
Resynchronization delay improvements
MAC_SYNC_041 When an ECU receives a valid tMAC synchronization frame with an AntiReplay Counter lower than their current reception counter minus W, then
ECU SHALL immediately send a resynchronization frame for this current
counter within t3 ms (*).
(*)
start: when to receive above-mentioned sync frame
end: when to store resync frame data to tx buffer
MAC_SYNC_042 When an emitter ECU detects that it has reset unexpectedly(*), it
SHALL increase its own emission counter by N, store this updated
counter
in
non-volatile
memory
and
immediately
send
a
synchronization frame.
If ARC value becomes bigger than 0xFFFFFFFFFFFFF by adding N, ARC
value SHALL keep 0xFFFFFFFFFFFFF.
(*) Detection example of unexpected reset:
When power on, ECU confirms last shutdown result whether it was
normal or abnormal. In case of abnormal, it is handled occurrence of
an unexpected reset like CPU reset, WDT.
All resets that ECU recognizes it cannot execute normal shutdown
process.
For example, ECU failed to write ARC on NVM when it shutdowns by
abnormal condition (e.g. SW exception handling).
MAC_SYNC_043 When an emitter receives a valid tMAC resynchronization frame with
an anti-replay counter lower than their current emission counter minus
W, it SHALL send a synchronization frame within t3 ms as per the timing
requirement in MAC_SYNC_007.
Alliance Internal
25
RNDS-C-20023_2.1
5.3 MAC Key Provisioning
KMAC and KMASTER_ECU are generated by the plant equipment with some off-board during vehicle production.
The plant equipment sends them to all required ECUs during vehicle production with security technology
following to “Memory Update Protocol” of Ref [2] and KMAC and KMASTER_ECU are updated. All ECUs can then
communicate using this KMAC key to authenticate CAN frames as described in the previous parts of this
document. KMASTER_ECU key is required in order to update KMAC.
During after sales also, KMAC and KMASTER_ECU are generated by the diagnostic tool with some off-board. The
diagnostic tool sends them to the replaced ECUs to update KMAC and KMASTER_ECU.
Two use cases are described to update KMAC and KMASTER_ECU:
1.
Vehicle production in plant
2.
Part replacement in after sales
The following are sequence to update KMAC and KMASTER_ECU
Fig. 3 ― Sequence to update KMAC and KMASTER_ECU
On the other hand, KMAC cannot export outside of the vehicle because of security reason. So we shall have
method to confirm that KMAC have been updated correctly.
MAC A is calculated by offboard servers using initial value of KMAC
Alliance Internal
26
RNDS-C-20023_2.1
MAC B is calculated by the ECU using new KMAC and the routine described in MAC_PROV_012.
MAC B is gotten from MAC ECU after storing new KMAC.
Fig. 5 ― Sequence to confirm that KMAC is updated
MAC_PROV_000x
Key update
MAC_PROV_0001 Receiving any MAC frames SHALL NOT be a condition for Update of KMAC
and KMASTER_ECU.
[Note.1] It is assumed that the keys are the same during MAC
communication establishment, but in the after-sales phase, physical
replacement is performed due to ECU failure, and a temporary key
mismatch situation may occur. If the MAC key-writing process is
implemented on the premise of receiving the MAC frame, this process
will not be able to be executed due to the failure of MAC communication.
[Note.2] It is assumed that the keys are the same during MAC
communication establishment, but there may be a situation where the
keys are temporarily mismatched, for example, when physical exchange
is performed in case of ECU failure.
If the MAC key writing process is implemented on the premise of
receiving a MAC frame, this process will not be able to be executed due
to the failure of MAC communication.
If the MAC key writing process is implemented on the premise of
receiving a MAC frame, this process will not be able to be executed due
Alliance Internal
27
RNDS-C-20023_2.1
to the failure of MAC communication, so it SHALL be specified to avoid
this failure.
MAC_PROV_0002 MAC ECUs SHALL implement specification of Ref [2]. This protocol
(Memory Update Protocol) is used to update KMAC and KMASTER_ECU.
MAC_PROV_0003 Key ID 0x1 and 0x4 for key slots of Ref [2] SHALL NOT be used for other
purpose because key ID 0x1 is used for KMASTER_ECU and key ID 0x4 is
used for KMAC.
MAC_PROV_0004 FID’ is 5bit length. For more detail, refer [2].
MAC_PROV_0005 Initial value of KMASTER_ECU at ECU delivery from supplier to OEM SHALL
be 0x0153F7000099ED9F320451AA8A7D9707 (16 bytes).
MAC_PROV_0006 Initial value of KMAC at ECU delivery from supplier to OEM SHALL be
0x10357F020289AD8F512662BA988F1111 (16 bytes).
MAC_PROV_0007 Diagnostic communication (UDS) SHALL be used to update key. The
following is “request” and “positive response”. For more detail, refer to
the latest version of [3] and Annex A.
1) Request
A_Data byte
#1
Parameter
Byte Value
RoutineControl Request SID
0x31
sub-function
#2
routineControlType=startRoutine
0x01
routineControlType=stoptRoutine
0x02
routineControlType=requestRoutineResult
0x03
routineID
#3
byte#1(MSB)
0x02
#4
byte#2(LSB)
0x53
routineControlOptionRecord
#5
M1(related to Ref [2])
:
:
#20
#21
M2(related to Ref [2])
:
M3(related to Ref [2])
:
0x00-0xFF
0x00-0xFF
byte#1(MSB)
0x00-0xFF
0x00-0xFF
byte#32(LSB)
0x00-0xFF
byte#1(MSB)
0x00-0xFF
:
#68
0x00-0xFF
byte#16(LSB)
:
#52
#53
byte#1(MSB)
byte#16(LSB)
0x00-0xFF
0x00-0xFF
Alliance Internal
28
RNDS-C-20023_2.1
M1, M2, M3 (#5~#68) support condition is below.
routineControlType(Hex)
M1, M2, M3 support condition
startRoutine(01)
Mandatory
stoptRoutine(02)
User option
requestRoutineResult(03)
Forbidden
2) Positive response
A_Data
Parameter
byte
#1
#2
Byte Value
RoutineControl Request SID
0x71
routineControlType
routineControlType=startRoutine
0x01
routineControlType=stoptRoutine
0x02
routineControlType=requestRoutineResult
0x03
routineID
#3
byte#1(MSB)
0x02
#4
byte#2(LS
0x53
B)
routineInfo
#5
Type 3 Routine and routineCompleted
0x30
Type 3 Routine and routineAborted
0x31
Type 3 Routine and routineActive
0x32
routineStatusRecord
#6
ERC(related to Ref [2])
#7
byte #1(MS
0x00-0xFF
B)
0x00-0xFF
byte #2(LS
B)
#8
M4(related to Ref [2])
:
#39
byte #1(MS
0x00-0xFF
B)
0x00-0xFF
:
0x00-0xFF
byte#32(LS
B)
#40
M5(related to Ref [2])
:
#55
byte#1(MS
0x00-0xFF
B)
0x00-0xFF
:
0x00-0xFF
byte#16(LS
B)
ERC(#6,7) support condition is below.
routineControlType(Hex)
ERC support condition
startRoutine(01)
Mandatory
Alliance Internal
29
RNDS-C-20023_2.1
stoptRoutine(02)
Mandatory
requestRoutineResult(03)
Mandatory
M4,M5 (#8~#55) support condition is below.
routineControlType(Hex)
M4,M5 support condition
startRoutine(01)
Mandatory
stoptRoutine(02)
Mandatory
requestRoutineResult(03)
Mandatory
M4,M5 (#8~#55) value is below.
routineStatus(Hex)
M4,M5 Value
routineCompleted (0)
Value: Refer to
MAC_PROV_0010
Value: 0x00…(48 byte) Fix.
routineAborted (1)
Refer to MAC_PROV_0011
Value: 0x00…(48 byte) Fix.
routineActivet (2)
Refer to MAC_PROV_0011
MAC_PROV_0008
Based on M1, M2 and M3 information, MAC ECUs SHALL update KMAC or
KMASTER_ECU.
MAC_PROV_0009
After key update, ERC generated by Ref [2] SHALL be set in response
data.
When key update is succeed, ERC SHALL be set as 0x0000.
MAC_PROV_0010
If key update is successful, M4 and M5 generated by Ref [2] SHALL be
set in response data.
MAC_PROV_0011
If key update is not successful, 0x0000.... (32 byte) in M4 SHALL be set
in response data. And 0x0000.... (16 byte) in M5 SHALL be set in
response data.
Other Diagnostic specification SHALL be followed to Ref [3].
If key
(KMASTER_ECU and KMAC ) update finishes successfully under current
condition of DTC (U1327-52), DTC SHALL go to Past status.
Key update failure DTC implementation for a MAC key update
MAC_PROV_0012
failure
Key update failure DTC SHALL be implemented to detect MAC key
(KMASTER_ECU or KMAC) update failure. This DTC SHALL be detected
when either of KMASTER_ECU or KMAC update fail.
MAC_PROV_0013
Key update failure DTC code SHALL be assigned U1327-52.
Alliance Internal
30
RNDS-C-20023_2.1
DTC Status bits of Key update failure DTC
MAC_PROV_0014 ECU SHALL implement the DTC status bits that are compliant with
Ref[3] for this DTC.
•
Bit0 (TestFailed)
•
Bit3 (ConfirmedDTC)
MAC_PROV_0015 Bit 0 SHALL be raised if Key(KMASTER_ECU or KMAC) upadte fail occur
and DTC SHALL go to Current status.
MAC_PROV_0016 Bit 0 SHALL be reset if Key(KMASTER_ECU and KMAC) update success and
DTC SHALL go to Past status.
MAC_PROV_0017 Bit 3 SHALL be raised synchronously with bit 0.
Comment: This bit SHALL be reset by DTC clear command
(Ref[3]and[9]).
MAC_PROV_0018 At delivery timing, bit 0 and bit 3 SHALL be 0.
State transition Description (Nominal sequence description)
Key update failure DTC behavior models are specified in the
Annex B as example.
MAC_PROV_0019 Keys inside the ECU SHALL never be changed by any mean, except
by using the SHE protocol. It will not be possible to erase KMAC and
KMASTER_ECU.
MAC_PROV_0020 Keys SHALL remain the same after an ECU flashing.
MAC_PROV_0021 The number of key update is not limited. It can be done more than
once.
MAC_PROV_0022 Under key update process, Emission / Reception MAC frame SHALL
be treated as follows.
MAC_PROV_0023 Reception frames with MAC SHALL be dropped.
MAC_PROV_0024 Emission frames with MAC behavior SHALL be decided by supplier.
MAC_PROV_0025 In case conflict between MAC communication process and MAC key
registration
happens,
arbitration
function(*)
SHALL
be
implemented. Key registration process SHALL have a priority.
Alliance Internal
31
RNDS-C-20023_2.1
(*) Requirement for arbitration function
a) Interruption by key registration process happens under MAC
communication process, MAC communication process SHOULD stop
immediately, then start MAC key registration process. If it's difficult,
to start MAC key registration after finishing MAC communication
process can be acceptable.
b) Interruption by MAC communication process happens under MAC
key registration process, MAC communication process starts, after
finishing MAC key registration process and dropping frames emitted
and received under MAC key registration process.
MAC_PROV_01x
Key confirmation
MAC_PROV_011 The MAC value is the AES-CMAC output as defined in RFC4493 to the
16 bytes.
MAC ECUs SHALL be able to caluculate MAC using 2 inputs:
- the message X defined as:
0x4436F90004D9991EE22563CC967D2345
- the secret AES key KMAC
The message X SHALL be stored in MAC ECU.
MAC_PROV_012 Diagnostic communication (UDS) SHALL be used to confirm to update
key correctly. The following is “request” and “positive response”.
1) Request
A_Data byte
#1
Parameter
Byte Value
RoutineControl Request SID
0x31
sub-function
#2
routineControlType=startRoutine
0x01
routineID
#3
byte#1(MSB)
0x02
#4
byte#2(LSB)
0x54
2) Positive response
A_Data
Parameter
byte
#1
#2
RoutineControl Request SID
Byte Value
0x71
routineControlType
startRoutine
0x01
routineID
#3
byte#1(MSB)
0x02
Alliance Internal
32
RNDS-C-20023_2.1
#4
byte#2(LSB)
0x54
Type 1 Routine and RoutineCompleted
0x10
Type 1 Routine and routineAborted
0x11
routineInfo
#5
routineStatusRecord
#6
The calculated MAC
byte#1(MSB)
:
0x00-0xFF
:
#21
0x00-0xFF
byte#16(LSB)
0x00-0xFF
The calculated MAC (#6~#21) value is below.
routineStatus(Hex)
The calculated MAC Value
routineCompleted (0)
Value: Refer to
MAC_PROV_011
Value: 0x00…(16byte) Fix.
routineAborted (1)
MAC_PROV_013
Other Diagnostic specification SHALL be followed to Ref [3].
5.4 Troubleshooting
Troubleshooting the MAC errors in ECUs must be possible through standard UDS.
For trouble shooting of hardware problem like processor failure, memory failure (RAM & ROM), etc. are defined
separately (are out of scope of MAC Specification).
For such hardware failure troubleshooting, separate DTC are defined under diagnostic specification.
MAC_DBG_01x
Key diagnosis
Initial key DTC implementation for detection of MAC
initial key
MAC_DBG_011 Initial key DTC SHALL be implemented to detect key(KMAC)
initial value defined in [MAC_PROV_0006].
MAC_DBG_012 Initial Key DTC code SHALL be assigned U1327-54.
DTC Status bits of Initial key DTC
MAC_DBG_013 ECU SHALL implement the DTC status bits that are
compliant with Ref[3] for this DTC.
•
Bit0 (TestFailed)
•
Bit3 (ConfirmedDTC)
Alliance Internal
33
RNDS-C-20023_2.1
MAC_DBG_014 Bit 0 SHALL be raised if KMAC is initial value and DTC SHALL
go to Current status.
MAC_DBG_015 Bit 0 SHALL be reset if KMAC is not initial value and DTC
SHALL go to Past status.
MAC_DBG_016 Bit 3 SHALL be raised synchronously with bit 0.
Comment: This bit SHALL be reset by DTC clear command
(Ref[3]and[9]).
MAC_DBG_017 At delivery timing, bit 0 and bit 3 SHALL be 1.
Initial key DTC Check
MAC_DBG_018 Initial key DTC SHALL be detected by the following.
•
Key(KMAC) update
•
Within t4 ms after Clear DTC command
•
Within t5 ms after any ECU start up(Ex: wake up, hot or
cold start)
State
transition
Description
(Nominal
sequence
description)
•
Initial key DTC behavior models are specified in the
Annex B as example.
MAC_DBG_02x
Anti-Replay emission counter diagnosis
Full ARC counter DTC implementation for full emission
ARC monitoring
MAC_DBG_021 Anti-Replay emission counter DTC SHALL be implemented
for full emission ARC monitoring purpose.
MAC_DBG_022 This DTC SHALL be detected when the full emission ARC
reach to the threshold F at the first time.
MAC_DBG_023 Anti-Replay emission counter DTC code SHALL be assigned
U1CB0-86.
DTC Status bits of Anti-Replay emission counter DTC
MAC_DBG_024 ECU SHALL implement the DTC status bits that are
compliant with Ref[3] for this DTC.
•
Bit0 (TestFailed)
•
Bit3 (ConfirmedDTC)
Alliance Internal
34
RNDS-C-20023_2.1
MAC_DBG_025 Bit 0 SHALL be raised if the full emission ARC value is greater
or equal than the threshold F and DTC SHALL go to Current
status.
MAC_DBG_026 Bit 0 SHALL be reset if full emission ARC value is under
threshold F and DTC SHALL go to Past status.
MAC_DBG_027 Bit 3 SHALL be raised synchronously with bit 0.
Comment: This bit SHALL be reset by DTC clear command
(Ref[3]and[9]).
MAC_DBG_028 At delivery timing, bit 0 and bit 3 SHALL be 0.
Anti-Replay emission counter DTC Check
MAC_DBG_029 The full emission ARC value SHALL be tested every 1 second.
MAC_DBG_030 This check SHALL start as soon as possible when CAN-FD
communication is active and stop when the ECU stops CANFD communication.
Snapshot value with Anti-Replay emission counter DTC
MAC_DBG_031 The ECU SHALL keep the full emission ARC value as
snapshot in the first time the DTC is recorded, and SHALL
not update
the value according to full emission ARC value
increasing (meaning to keep a snapshot of full emission ARC
value of first jump across the threshold F).
MAC_DBG_032 This full emission ARC snapshot SHALL be recorded only by
dedicated DTC “U1CB0-86”.
MAC_DBG_033 This full emission ARC snapshot SHALL be able to be called
by only $1904 for DTC “U1CB0-86” via DID “0xF054” .
MAC_DBG_034 initial value of 0xF054 SHALL be 0x000000000000.
MAC_DBG_035 DID “0xF054” SHALL not be allowed;
•
to be read by $22
•
to be written by $2E
State
transition
Description
(Nominal
sequence
description)
Alliance Internal
35
RNDS-C-20023_2.1
•
Anti-Replay emission counter DTC
behavior models are
specified in the Annex B as example.
5.5 No MAC verification
Detailed specification of “version with no MAC verification” (mentioned in MAC_AUTH_033 a).
MAC_MACOFF_00x Version with no MAC verification
MAC_MACOFF_001 Secured Frame emission
Same as MAC_AUTH_00x, MAC_AUTH_01x
MAC_MACOFF_002 Secured Frame reception
(Related requirements: MAC_AUTH_03x, MAC_AUTH_02x)
All frames SHALL be accepted regardless of tARC/tMAC.
MAC_MACOFF_003 List of received ARCs management
(Related requirements: MAC_AUTH_04x)
ECU SHALL regard verification result of list of received ARCs as
acceptable (i.e. not received ARC before).
MAC_MACOFF_004 Sync Frame
(Related requirements: MAC_SYNC_00x)
o
Tx：Send Sync frame with ARC counter management (i.e.
same as with MAC verification specification)
o
Rx：Reception without MAC verification. When ECU receives
Sync frame, ARC SHALL be updated by using select-High
logic without MAC verification.
MAC_MACOFF_005 Error counters
(Related requirements: MAC_SYNC_01x)
Fixed to 0
MAC_MACOFF_006 Resync Frame
(Related requirements: MAC_SYNC_02x)
o
Tx：No Transmission
o
Rx：Reception without MAC verification. When ECU receives
Resync frame, ARC SHALL be updated by using select-High
logic without MAC verification.
Alliance Internal
36
RNDS-C-20023_2.1
MAC_MACOFF_007 Anti-Replay counters saving strategy/ Resynchronization delay
improvements
Same as MAC_SYNC_03x/ MAC_SYNC_04x.
MAC_MACOFF_008 MAC Key Provisioning / Troubleshooting
Same as section5.3 / section5.4.
* DiagMuxDTC for MAC SHALL NOT be detected because of no MAC
verification.
Alliance Internal
37
RNDS-C-20023_2.1
Annex A
(Informative)
MAC KEY PROVISIONING Routine Service sequence is defined as reference.
Routine
Predefined execution time
or condition of stop.
Times
> 31 01 0253 M1..M3
<
71
01
0253
32
> 31 03 0253
0000
< 71 03 0253 30 ERC M4..M5
M4..M5(Fix 0)
Result
Start of the routine.
requested :
positive
response.
Direct response of the ’ECU.
0x01 = StartRoutine
3 = routine type 3
2 = routine active
> 31 03 0253
< 71 03 0253 32 0000 M4..M5(Fix 0)
Diagnosis non-blocked during the execution
but sending a positive response.
0x03 = RequestRoutineResult
Alliance Internal
38
RNDS-C-20023_2.1
Annex B
DTC behavior
(Informative)
B-1) Diag Mux DTC
・State transition diagram
Diag Mux DTC for secured frame emitter X
1. Clear DTC is the highest priority
2. Status of DTC SHALL be set as below:
Not record：bit0=0, bit3=0
Past: bit0=0, bit3=1
Current: bit0=1, bit3=1
Alliance Internal
39
RNDS-C-20023_2.1
・Time chart
Alliance Internal
40
RNDS-C-20023_2.1
Below is the implementation example；

Diag Mux DTC SHALL have the timer for each ECU.
₋
MIN : 0sec
₋
MAX : 2sec
₋
Default : 0sec

Timer SHALL start detecting a MAC verification fail for secured frame from each sender ECU.

When the timer reaches 2sec, Diag Mux DTC SHALL be raised as Current status.

The timer SHALL keep MAX value if it reaches MAX value.

The timer SHALL be reset when ECU receives a valid secured frame from a specific ECU. If Diag Mux DTC raised, it SHALL go to Past status.
As examples, 6 cases for DiagMuxDTC(MAC) are defined as reference.
Alliance Internal
41
RNDS-C-20023_2.1
Alliance Internal
42
RNDS-C-20023_2.1
Alliance Internal
43
RNDS-C-20023_2.1
Alliance Internal
44
RNDS-C-20023_2.1
Alliance Internal
45
RNDS-C-20023_2.1
Alliance Internal
46
RNDS-C-20023_2.1
B-2) Key update failure DTC (U1327-52)
・State transition diagram
1. Clear DTC is the highest priority
2. Status of DTC SHALL be set as below:
Not record：bit0=0, bit3=0
Past: bit0=0, bit3=1
Current: bit0=1, bit3=1
Alliance Internal
47
RNDS-C-20023_2.1
・Time chart
Alliance Internal
48
RNDS-C-20023_2.1
B-3) Initial key DTC (U1327-54)
・State transition diagram
1. Clear DTC is the highest priority
2. Status of DTC SHALL be set as below:
Not record：bit0=0, bit3=0
Past: bit0=0, bit3=1
Current: bit0=1, bit3=1
<INITIAL KEY CHECK CONDITION>
1. Key Update
2. Within 200msec after Clear DTC command
3. Within 500msec after any ECU start up(Ex: wake up, hot or cold start)
Alliance Internal
49
RNDS-C-20023_2.1
・Time chart
Alliance Internal
50
RNDS-C-20023_2.1
B-4) Anti-Replay emission counter DTC (U1CB0-86)
・State transition diagram
1. Clear DTC is the highest priority
2. Status of DTC SHALL be set as below:
Not record：bit0=0, bit3=0
Past: bit0=0, bit3=1Current: bit0=1, bit3=1
Alliance Internal
51
RNDS-C-20023_2.1
・Time chart
Alliance Internal
52
RNDS-C-20023_2.1
Annex C
Note: implementation of FAR counter
(Informative)
<FAR counter over flow risk >
FAR calculation use 6 byte range, but software internal value is defined as 8 byte range (like a long long type)
depends on implementation. To define FAR variable in software, this case include extra 2 byte. This 2 byte
should not be used and FAR 6byte should be protected from over flow. Because this extra 2 byte count up
have risk of sending infinite Resync frame and never to success re-synchronizing FAR counter.
So, each FAR increment logic need guard logic to limit 0xFFFFFFFFFFFF.
<Impact of wrong implementation>
1st issue: If there is no guard to FAR, counter value overflow
FAR
FAR=0x0001000000000000
FAR=0x0000FFFFFFFFFFFF
t
0
ECUA
ECUB
Secured CAN frame
2nd issue: In this case, always
Secured CAN frame
MAC verification is failed.
ID
ARCA
ARCB
ｔMACB
Because MSB is different from
ECUA.
ECUA’s FAR emission counter:
ECUA’s FAR reception counter:
0x0001 00000000 0000
3rd issue: Resync is always failed.
0x0000 FFFFFFFF FFFF
Because ECUA emission FAR is always
larger than received Resync ARCA.
Alliance Internal
53
RNDS-C-20023_2.1
Annex D
Note: Resync Tx timing considering excl. time
(Informative)
Resync transmission case samples considering excl. time are described as follows.
Alliance Internal
54