um -cai 2011 01 - pudn.comread.pudn.com/downloads633/sourcecode/embedded/2571019/genericrke... ·...

UM-CAI-2011-01 Generic RKE Software Architecture Rev. 1.1 — 04 April 2011 User manual

Document information Info Content Keywords Remote Keyless Entry, protocol, implementation, PCF7961, HITAG-3,

AES

Abstract Specification of requirements and architecture of a Generic Multi-Platform RKE Software implementation.

NXP Semiconductors UM-CAI-2011-01 Generic RKE Software Architecture

UM-CAI-2011-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2011. All rights reserved.

User manual Rev. 1.1 — 04 April 2011 2 of 30

Contact information For additional information, please visit: http://www.nxp.com For sales office addresses, please send an email to: [email protected]

Revision history Rev Date Description 1.0 2011-03-28 First Release with HT3 support for PCF7961

1.1 2011-04-04 Updated and extended by AES128 support for PCF7961

http://www.nxp.com/�

mailto:[email protected]�




1. Introduction The large majority of Remote Keyless Entry applications are one-way, using two to four buttons (for door / trunk locking / unlocking) and no comfort functions (such as controlling electric window lifts or a convertible roof). Customers may be interested in using an off-the-shelf software solution based on a cryptographically reviewed protocol to reduce costs for protocol and software development on the key side.

The provided software implementation is basically tested, but not fully qualified for use in the final application. However, the software is intended as a template and good starting for a customer implementation.

Note: This document is provided under mutual NDA.

2. Generic RKE Protocol

2.1 General Requirements and Considerations

1. The protocol must have minimum complexity, regarding implementation effort and error handling.

2. The protocol must be scalable in a simple way to allow trading-off security versus protocol length (timing, battery lifetime, energy efficiency).

3. Protocol scaling and user defined field shall be configurable without changing the software.

4. Software and protocol should be prepared for selecting different cryptographic algorithms (e.g. NXP’s HT3, AES128, future requirements).

5. All data transmitted via UHF shall be Manchester encoded.

The One-Way protocol is based on NXP’s HITAG-3 crypt algorithm, or AES-128.




2.2 One-Way Protocol 2.2.1 Key-to-Car communication

RCB means Rolling Code Block.

(1) no errors, RCB repeated three times.

Figure 1: One-Way RKE example

After a button press (on a wake-up sensitive port), the controller wakes up, boots, and scans/de-bounces the button ports. If a valid button code is detected, the RCB frame is assembled as described in 2.2.2. Afterwards the key-to-car transmission (one way) can be performed (see Figure 1). After transmission of a wake-up pattern, a specified number of identical RCB blocks are following (in order to provide redundancy and robustness against transmission errors). After the transmission ends, the controller returns to power off.

Note: The final customer application may add special blocks (like e.g. comfort frames to control window operation or similar) to the protocol. This use case is not implemented here, because this is very customer specific.

2.2.2 Contents of an RCB The transmission of the RCB frames is preceded by a wake-up pattern, consisting of a selectable number (0..255) of Manchester-coded 0 bits. Each RCB begins with the preamble (run-in) byte(s).

Since the actual message (button ID and UDF) contains no “sensitive” or “secret” information, it is sent in plain text. To authenticate this message to the base station, a Sequence Response is included, which is calculated using cryptographic operations and cannot easily be forged by an attacker without knowledge of the used Secret Key. The length of the RCB frame is adjustable, since it contains optional fields and the size of certain fields is variable.

RCB 1

ButtonState

Key

Car

tA

WUP RCB 2 RCB 3




PRE FUNC UDF IDE BID RSI SR

1 .. 3 bytes 1 byte2 bytesoptional

4 bytesoptional 1 byte 4 or 2 bytes 6, 5, or 4 bytes

(2) yellow: always present; green: optional; blue: variable length

Figure 2: Scalable One-Way protocol

1) PRE: Preamble. Required for synchronization and improved settling of UHF receiver, carries no protocol information. 1, 2 or 3 bytes can be selected.

2) FUNC: Function Code. Contains protocol scaling information and “battery weak” flag and optional function bits for later extensions.

3) UDF: User Defined Field, could be a Vehicle or Key ID. Not present if DUDF=1.

4) IDE: serial number of controller (factory-programmed in EEPROM). The IDE field may be skipped (DIDE=1) in case the UDF contains a key identifier, which allows the BS to determine the IDE. At least the UDF or IDE field should be present in the protocol to be able to identify the RCB by the base station software. This is not covered by the current RKE software, thus the user has to observe this requirement.

5) BID: Button ID, contains information which buttons are pressed after device wake-up and de-bouncing.

6) RSI: Remote Sequence Increment, counter incremented by one at every wake-up. 32 bit (four bytes) or 16 bit (two lower bytes) transmission can be selected.

7) SR: Sequence Response, forms a cryptographic signature that the base station controller can validate based on the Remote Secret Key. Configurable as 6, 5, or 4 bytes long. Note that the SR also has the function of a checksum, thus an additional CRC protection of the RCB is not needed.

The maximum size of the RCB frame is 3+1+2+4+1+4+6 = 21 bytes (3 bytes preamble, 18 bytes RC-Block). The minimum possible size is 1+1+0+0+1+2+4 = 9 bytes (1 byte preamble, 8 bytes RC-Block, UDF and IDE not present). Note: When using a TED-Kit 2 for data reception, the preamble of the first sent RC-Block is removed by the TED-Kit 2 and therefore not delivered to the PC.




2.2.3 Function Code Byte The FUNC byte indicates protocol parameters and contains following information: Table 1: Function Code byte

Pos. Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit0 Name DUDF DIDE RSIM SRM1 SRM0 VBATL FCT1 FCT0 Table 2: Bit fields in Function Code byte

Name Description Default Value

DUDF Disable UDF field 0=UDF present in protocol 1=UDF not present

0

DIDE Disable IDE 0=32 bit IDE transmitted 1=IDE not transmitted

0

RSIM RSI mode 0=32 bit RSI transmitted 1=lower 16 bit of RSI transmitted

0

SRM[1..0] Sequence Response Mode 00 = transmit all 6 SR bytes (highest security) 01 = transmit 5 SR bytes 10 = transmit 4 SR bytes 11 = reserved for future use

0

VBATL Battery Voltage Low flag 0=battery voltage greater or equal threshold 1= battery voltage below threshold (weak battery indicated)

0

FCT[1..0] Function Code bits, reserved for future use 0

Remark: The FUNC byte is assembled from the RCB Configuration byte 0 (see Table 3)

2.2.4 RCB Reception and Processing on Base Station The base station (BS) receiver should accept all incoming blocks of a sequence and make them available to the base station controller. The preamble bytes should be matched by the receiver and, if required, filtered out by software, while storing the received data in a byte-aligned way.

The base station drops a received RCB if any of these apply:

• The IDE (either transmitted or obtained by using a key ID in the UDF) does not match any of the tags belonging to the vehicle;

• The RSI is outside a moving, user-defined acceptance window, which is formed by the last received value (lower limit) and this value plus N (upper limit, N = window size). Note: This requirement is not implemented in the base station demo software;

• The received SR is not equal to the internally re-calculated SR’ value (obtained by using the identical Secret Key and information in the received RCB).




Bit errors inside the RCB will almost certainly cause a non-matching SR, thus the modified RCB will be dropped.

After a dropped RCB, the BS controller should evaluate the next one.

As shown in Figure 2, the BS may receive only a subset of all possible RCB bytes. This can be forced by a configuration setting selected on key side by setting the RCB_CFG byte 0 (see Table 4 for more details). The omitted data in the RCB frame is indicated by the FUNC byte. In this case, the base station needs to use default values to replace the missing data before the SR calculation should be started. Thus, the BS must have prior information about the data used on key side before a valid communication can be established.

Note:

The down-scaling of the protocol might be applied to enhance the battery life time in some special applications, since the battery life time is approximately direct proportional to the length of the protocol.

A detailed protocol analysis is available on request.

2.2.5 Protocol Configuration Settings All RKE configuration settings are stored in EEPROM blocks (8 pages of 4 bytes each) (see Table 3). The absolute start block number of the ‘RKE configuration settings’ in physical EEPROM is determined by:

a) Page 4 bits 3..0 in case of HITAG-3 transponder;

b) MODE byte (MSB-1 and down) in case of HITAG-PRO1/2;

c) Page 5 bits 3..0 in case of HITAG-AES.

Blocks 0 and 15 cannot be used to store the configuration settings, since they are reserved for IDE, ISK and memory configuration pages. Configuration data can be written through the transponder interface during the personalization process. Hence the RKE related blocks should be placed in segments with meaningful access rights in transponder mode.

The RKE configuration settings are chosen in a similar way as for the transponder mode to provide a similar “look and feel” to the user, familiar with the NXP transponder technology.




Table 3: RKE configuration settings (RKE_CFG, block 0) in EEPROM

Relative Page

Number

Byte 3 Byte 2 Byte 1 Byte 0

0 UDF[1] UDF[0] RFU (0) RFU (0) 1 RSK0 2 RSK1 3 RSK2 4 RSK3 (AES only) 5 RCBCFG[2] RCBCFG[1] RCBCFG[0] RFU (0) 6 PRE[2] PRE[1] PRE[0] VBATREF 7 BDEB[1] BDEB[0] RFU (0) RFU (0)

The configuration settings in the RCB_CFG byte 0 are defined as follows: Table 4: Description of RKE configuration settings

Name Num. bits

Stored in RKE_CFG byte(s)

Description

UDF 16 UDF[1], UDF[0] contents of User Defined Field RSK 96..128 RSK[2/3] .. RSK[0] Remote Secret Key (used if RSKM=0, HT3

96 bit, AES 128 bit) WUPC 8 RCBCFG[2] Wake-Up bit count, number of zero bits

preceding each RCB RCBC 8 RCBCFG[1] RCB count (number of repetitions) DUDF 1 RCBCFG[0] bit 7 Disable UDF field, see 0 DIDE 1 RCBCFG[0] bit 6 Disable IDE field, see 0 RSKM 1 RCBCFG[0] bit 5 Select RSK:

0 = use RSK in Config Block 1 = use Immo Secret Key

CRM 2 RCBCFG[0] bit 4,3 Crypto mode selection (not in use by current software) 00 = HITAG-3 Others = reserved

RSIM 1 RCBCFG[0] bit 2 0 = transmit all 4 RSI bytes 1 = transmit only lower 16 bits of RSI

SRM 2 RCBCFG[0] bit 1,0 Sequence Response Mode 00 = transmit all 6 SR bytes 01 = transmit 5 SR bytes 10 = transmit 4 SR bytes 11 = reserved

PRE 24 PRE[2..0] Preamble pattern, starting on most significant non-zero bit but is always byte aligned. Example: PRE = 0x35 (hex) = 0011 0101 (bin) means that preamble is 8 bits long, first valid bit is bit 5.




Name Num. bits

Stored in RKE_CFG byte(s)

Description

BDEB 16 BDEB[1..0] Button De-bouncing configuration

Note: The CRM bits are part of the RKE configuration byte but not evaluated by the RKE software yet.

2.2.6 Button De-bouncing De-bouncing is important to compensate the mechanical behavior of the buttons, and is typically done by sampling the button ports over duration of some 10 milliseconds. Additionally, disturbance caused by power HF interference (such as mobile phones) may wake up the controller, but should ideally not be mistaken as a button press event. A flexible configurability of the de-bouncing parameters, such as the number of samples taken and their timing, is needed to achieve these goals and match the customer’s requirements.

For this purpose, the EEPROM configuration page provides 16 bits for adjustment of the de-bouncing algorithm: Table 5: De-bouncing settings

Name Num. bits

Bit position

Description

BDEB1 4 [7..4] Number of de-bouncing loops [0: 1 loop; Fh: 16 loops] BDEB1 4 [3..0] Number of detection samples in one de-bouncing loop

[0: 1 sample; Fh: 16 samples] BDEB0 4 [7..4] Number of allowed sample errors in a single de-bouncing

loop [0: 1 error; Fh: 16 errors]. The maximum error threshold is calculated by multiplying this value with the number of de-bouncing loops (BDEB1 [7..4]) .

BDEB0 4 [3..0] Pre-scaling factor [0: factor 4 (1 us); 5h: factor 128 (32 us)].

The de-bouncing algorithm is scalable with the above given settings bits. To ensure irregular sample periods, the detection (sampling) of the button port is done using a flexible adjusted delay. Therefore the used system timer provides a number of adjustable parameters.

The minimum timing between two samples is 1 us. The used timer oscillator frequency is (Fosz = 4 MHz, Tosz = 0,25 us), thus a minimum prescaler of 4 has to be used to match the defined clock timing. Furthermore the system timer provides five other prescaler values [8, 16, 32, 64, 128] to reduce the main timing if necessary. This prescaler selection can be done with the parameter (BDEB0, bit [3..0]), where only three LS bits are used and the maximum value is 5, thus all other values (bit settings) are ignored.

Another adjustable timer parameter is the reload value. It defines the upper limit for an up-counting timer until the timer is forced to stop. The counter is triggered with the adjusted clock timing mentioned above. In the de-bouncing application the current reload value is taken from a fixed list of prime numbers: [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 47, 53, 59]. This means, each button port sampling in a single de-bouncing loop is made with a new reload value to ensure a non-periodic delay.

The number of samples in a single round can be adjusted by (BDEB1, bit [3..0]), thus, the number of reload values taken from the given list can be implicitly chosen with this parameter too. The maximum number of complete de-bouncing loops then can be set with (BDEB1, bits [7..4]).




Therefore, the maximum delay in a single round with a maximum number of 16 samples and the biggest prescaler (128) selected can be calculated as follows:

[1/(Fosz / max. prescaler)] x ∑(reload values) = [1/(4 MHz/128)] x 397 = 32 us x 397 = 12.7 ms

Thus, the overall sampling time, that additional depends on the loop counter given above can be calculated to:

[Maximum loop counter] x [maximum timing in a single de-bouncing loop] = 16 x 12.7 ms = 203.3 ms.

A valid button code (BID) will be returned only, if the given maximum number of errors is not exceeded. Therefore, the number of errors for each de-bouncing loop can be set with (BDEB0, bit [7..4]). However, the overall error threshold (number of total errors) depends also on the number of de-bouncing loops, selected by (BDEB1, bits [7..4]).

2.2.7 Remote Sequence Increment The RSI values are stored in the next EEPROM block, right after the RKE configuration (‘RKE_CFG’, block 0) in block 1 (see Table 6). Table 6: RSI EEPROM mapping (RKE_CFG, block 1)

Relative Page

Number

Byte 3 Byte 2 Byte 1 Byte 0

0 RSI 0 1 RSI 1 2 RSI 2 3 RSI 3 4 RSI 4 5 RSI 5 6 RSI 6 7 RSI 7

The Remote Sequence Increment (also: Sequence Counter) is generally used in the Remote Keyless Entry application as input to a "Rolling Code" algorithm that provides cryptographic security. Usually, this value is a 32 bit wide incremental binary counter. Therefore, the sequence counter is incremented by one on every button press. The Remote Sequence Increment value (RSI) is used as a part of the input data for Sequence Response (SR) calculation (see section 2.2.9) and is also part of the RCB frame (see 2.2.2) to be transmitted to the base station. To ensure a continuously incrementing counter, the remote sequence counter is stored to a non-volatile EEPROM page.

EEPROM storage in a battery driven system involves always the potential risk of a loss of power during the EEPROM write cycle, which takes approximately up to 4 ms. Thus, a loss of valid data is possible. In addition, the electrical stress caused by repeated write operations to the same EEPROM cell will reach the maximum number of allowed write cycles early and therefore reduce the life cycle of the EEPROM cell.

Thus, to minimize the possibility of memory loss and data corruption, the RKE system uses a special algorithm to store the RSI value. To reduce the number of write cycles to the sequence counter, eight EEPROM pages are used instead of one to store the counter’s value (see Table 6).




After initialization, the first button press causes an increment of the value stored in the first of the eight reserved EEPROM page. After the next wake up (next button press) the next (second) EEPROM page is incremented by one, and so on, until all eight pages are incremented once. The next round (nr. 9) will start again with an increment on page 1. The current RSI value is the sum of all eight page values. Thus, it is recommended, that all EEPROM pages used for RSI storage are initially set to zero after production. The incrementing of pages over time (rounds) is shown in Table 7. Table 7: Remote Sequence Increment algorithm

Page Round

0 1 2 3 4 5 6 7 8 9 10 11 12 …

1 0 1 1 1 1 1 1 1 1 2 2 2 2

2 0 0 1 1 1 1 1 1 1 1 2 2 2

3 0 0 0 1 1 1 1 1 1 1 1 2 2

4 0 0 0 0 1 1 1 1 1 1 1 1 2

5 0 0 0 0 0 1 1 1 1 1 1 1 1

6 0 0 0 0 0 0 1 1 1 1 1 1 1

7 0 0 0 0 0 0 0 1 1 1 1 1 1

8 0 0 0 0 0 0 0 0 1 1 1 1 1

Sum 0 1 2 3 4 5 6 7 8 9 10 11 12 … The implemented algorithm is also capable to detect and repair corrupted data in an EEPROM page, provided that a write error has no impact on more than one page at a time. The transponder memory section hosting the RSI pages should be configured readable in cipher mode (after successful authentication) only, but no write access must be allowed (see section 2.2.8).

2.2.8 Improved Resync Strategy In case only the lower 16 bits of the RSI are transmitted (bit RSIM=1), it may occur that the RSI moves outside the acceptance windows of the base station.

In this case, instead of overwriting the RSI pages, it is recommended that the BS read all eight RSI pages via LF after transponder authentication (or even in PLAIN read access mode), calculate the sequence counter value by summing all page values, and update its acceptance window (means the internal sequence counter) for the next RKE reception.

By just reading the RSI pages, the write access in LF wireless access mode to RSI pages is avoided completely; hence the risk of EEPROM write fails in transponder mode because of LF power loss is not existent anymore.




2.2.9 Generation of Sequence Response (SR) 2.2.9.1 HITAG-3

Regardless of the protocol parameters, always the same data (12 bytes) are used as input vector to the cryptographic operation. The input vector consists of the key Identifier (IDE) and a part called Challenge. Additional to that, the used Remote Secret Key (SK) must be loaded to the cryptographic unit. The used hardware platform provides a special cryptographic unit which is capable of HITAG-3 calculation. Thus special ROM-Library functions are available, to easily load the data like IDE and Secret Key to this cryptographic calculation unit. However, the used Challenge needs to be assembled in RAM before. The RSI bytes shall be placed in this Challenge such that they are the first to be shifted into the HITAG-3 shift register, followed by the UDF, the FUNC and the BID bytes.

A configurable number of bytes from the output vector (Response) are used as SR in the RCB. See Figure 3.

Figure 3: Hitag 3 Algorithm applied to generic RKE application

Identifier [0-3] Chall. [0-3] Chall. [4-7]

Response [0-5]

SK [0-11]

SR [0-5]

Identifier [0-3] UDF, FUNC, BID RSI [0-3]

HT3 (96 bit algorithm)

Challenge (see doc HT3-SA)

Response (see doc HT3-SA)

Secret Key




The complete Hitag 3 algorithm (high level) is shown in Figure 4:

Initialize RegisterRSK

Mix-Up 1

Generate MAC

Generate Response

Challenge

IDE

Mix-Up 2

START

END

MAC (not used)

1 byte 2 bytes 4 byte 1 byte 4 byte 4…6 bytes

FUNC UDF IDE BID RSI SR

1..3 bytes

PRE

(3) Shift register contents remain unchanged between steps. Black arrows indicate temporal flow, blue lines data flow.

Figure 4: Generating the Sequence Response using HITAG-3 Crypto

The Secret Key, the IDE, the assembled Challenge and some constant values are loaded in a special order to the hardware crypto unit during a process called Mix-Up 1. After this it is possible to extract the first encrypted data bytes. The first two encrypted bytes are called MAC. The MAC is extracted from the calculation unit to increase the security level but never used in the RKE protocol.

The Secret Key and additional constant values are loaded again to the crypto unit during the second part of the process, called Mix-Up 2. After Mix-Up 2, the first N most significant bytes of the output stream (N=6,5,or 4) are used as Sequence Response (SR).

Exactly equivalent operations must be performed on the key fob and on the base station side (after frame reception), in order to obtain the same result (SR = SR’).

Detailed information about the Hitag 3 algorithm can be found in the HT3-SA document.




Remark:

The Secret Key used in above calculations can be either the Remote Secret Key (RSK), or the Immobilizer Secret Key (ISK), selectable by the configuration bit RSKM (see Table 4).

Note: The secret key byte order is chosen in the same way as for the NXP HITAG-3 transponder implementation.

2.2.9.2 AES-128

Regardless of the protocol parameters, always the same 16 bytes are used as input vector for the cryptographic operation. This input vector consists of the User Defined Field (UDF), the FUNC byte, the button code (BID), the key Identifier (IDE), the sequence increment (RSI) and four times of a constant byte value (0xFF). Thus the first 12 bytes used as input vector are the same as for HITAG3. Since the PCF7961 does not provide a special cryptographic unit, the AES calculation is done in software. In all other implementations, a hardware AES engine can be used. Therefore the input vector needs to be assembled in RAM. The Secret Key (SK) is read from EEPROM inside the cryptographic software module. A configurable number of bytes from the output vector are used as Sequence Response (SR) in the RCB, while the first two MS bytes are ignored to be the unused MAC (see Figure 5). The MAC is extracted but ignored to be equivalent to the Transponder AES protocol and the HITAG-3 algorithm.

Figure 5: AES Algorithm applied to generic RKE application

Note: The secret key byte order is chosen in the same way as for the NXP AES transponder implementations.

Byte [0-3] Byte [4-7] Byte [8-11]

Output [2-7]

SK [0-15]

SR [0-5]

Identifier [0-3] UDF, FUNC, BID RSI [0-3]

AES (128 bit algorithm)

Rolling Code Block

Response

Secret Key Byte [12-15]

FFFFFFFFh




2.2.1 UHF transmitter settings As first step, ASK is used. Later, FSK shall be possible by default (using a compile switch to select either modulation scheme). For FSK, it needs to be figured out how to configure the Lopster in the TED-Kit2.

For details regarding the UHF configuration, please refer to source file defs.h.

3. Implementation

3.1 Key side 3.1.1 Hardware platforms

The first implementations support the PCF7961XTT (first HT3 implementation) and PCF7961MTT (first AES128 implementation).

3.1.2 Programming Language C language shall be used on all platforms as far as possible.

For MRK-II based products, the IAR Embedded Workbench shall be used for development.




3.1.3 Flow diagrams The following flow diagrams show the different aspects and abstraction levels of the RKE software.

Device Wake-Up & Init

Button De-Bouncing

Preparation of Remote Data Frame

Power-Off

no button pressed

Transmit via UHF

Button Press

Flash LED200 ms

EE/RSI write error

(4) Some blocks are detailed in following figures.

Figure 6: RKE Flow chart – top level

Note: In case of an EEPROM write error on RSI, it must be made sure, that only a single page can be corrupted and no other page is influenced by a fail condition e.g. due to weak battery.




Boot Routine

Basic Initialization: clocks, watchdog,

port settings

Check battery voltage, compare with threshold

Read configuration settings from EEPROM, decode to

variables in RAM

START

END

enable UHF Tx, switch on power amp

(5) The UHF power amplifier shall be switched on before the battery voltage check.

Figure 7: RKE Flow chart – device wake-up and initialization




assemble Function Code byte

run crypto engineKey:=RSK

(HT3, RFU...)

START

END

check & repair RSI counter, increment RSI

Fill Tx Buffer dep. on protocol options;

use first 4, 5, or 6 bytes of crypto output vector as Sequence Response

assemble crypto input vector:

UDF(2), Func(1), BID(1), IDE(4), RSI(4)

ERROR

EE/RSI write error

(6)

Figure 8: RKE Flow chart – preparation of Remote Data Frame

Note: In case of an EEPROM write error in RSI, it must be made sure, that only a single page can be corrupted and no other page is influenced by a fail condition e.g. due to weak battery.




transmit preamble (byte oriented)

transmit Tx buffer

START

END

Transmit via UHF:

set Tx registers

power down Tx

repeated N times ?no

yes

Note: Tx power amp already enabled

send wake-up (sel. # of 0 bits)

Figure 9: RKE Flow chart – transmit UHF frame




3.1.4 Software Modules The current RKE software is divided in modules to pool logical program segments, increase modularity and to increase the readability of the complete system. Table 8: Module description

C-Modules Description main.c The backbone of the RKE application. This module is called first after

wake up.

hardware.c All hardware related functions e.g. modulator, transmitter, LED etc. are combined here.

ee_prom.c This module extracts some configuration data from EEPROM and provides a function to get a variable read access to it.

eeprom.s52 The module with all pre-defined page data which is flashed to EEPROM during programming sequence using the IAR tool chain.

buttons.c Button detection and de-bouncing is realized in this module.

data_dispatch.c The main data handler which provides a number of set and get functions. The dispatcher is used to prevent the software from using global (project wide) variables and to share the appropriate data with all necessary modules.

rke.c All RKE related functions and function calls which are necessary to assemble and transmit the remote data frame (RCB frame) are inserted here.

si.c The increment of the sequence counter (RSI) is done in this module. Additional to that, the module provides functions to repair the EEPROM page increment data and to return the current RSI to the calling function.

crypt.c Interface to crypt functions.

hitag3.c The Hitag 3 crypto algorithm is implemented here.

AES128.c The AES crypto algorithm is implemented here.

transmit.c This module transmits the Wake-Up pattern and the final RCB frame according to the transmission parameters WUPC and RCBC.

timer.c This module provides functions to get access to the two system timers 0 and 1.

Global Header Description defs.h All constants are defined here.

romlib_parser.h The names of the used ROM-Lib functions depend on the appropriate platform (e.g. PCF7961). Thus, to support the generic requirements, platform independent function names should be used instead. Therefore a translation of the platform depending names to generic ones are done here. Thus, if other platforms should be supported, add additional renaming parts separated by compile switches.

types.h The used types according to NXP coding conventions are defined here.

Remark:

Most of the C-modules given above provide an appropriate header file to export useful module functions. Pre-processor compile switches are part of the project settings.




3.1.5 Memory Space There are two different RKE system available providing Hitag 3 or AES crypto algorithm. Each appropriate crypto software module consists of a different number of statements and variables Thus each final compiled RKE application allocates a different memory space (see Table 9).

Note: Especially the limited and hardware platform depending RAM DATA space must be observed for future applications or additional functions to be included.

This data shows that the PCF7941 and PCF7952 platforms cannot be supported due to insufficient code or data memory size and the lack of extensibility. Table 9: Memory allocation (Release build)

Memory Hitag 3 AES CODE 2554 bytes 3242 bytes DATA 133 bytes 169 bytes

CONST 28 bytes 284 bytes

3.2 Base Station RKE Reception (TED-Kit2) The RKE reception on base station side can be emulated using a Transponder Evaluation Development Kit (TED-Kit 2). For that purpose the TED-Kit 2 has to be extended by a Lopster based RF XBoard for UHF communication and the system drivers has to be installed (please contact NXP for further information).

Special demo software, using the MS Visual Studio 2005 platform and written in C++, is provided too, to get access to the TED-Kit 2 and to demonstrate the reception of the data telegram (RCB frames). Both crypto standards (Hitag 3 and AES) are supported and can be selected by user after startup. The received crypto data is verified and the telegram is displayed in a command shell window. Additional to that, other information about the reception process and the verification is given too.

In case of the various setting options for RCB transmission on key side, the base station needs further information about the key data (e.g. IDE, UDF, RSI, etc.), in case the RCB frame is reduced to a subset of the possible RCB data length. In any case, the used Preamble needs to be known on base station side before a reception of data is possible. For a valid decryption of the data, the selected Secret Key (ISK or RSK) must be also known.

At this stage of development, the base station demo software keeps all necessary data about the current used key controller in constant defines. Thus, if another key with different settings should be tested, these constants need to be updated and the software needs to be re-compiled, to fit the demo software to the special key settings and before a valid communication can be accomplished. The constants can be found on the top of the module [rke.cpp].

Please be aware that the demo software execution file needs a TED-Kit 2 DLL (tk2d.dll) in the same directory path. Otherwise the start of the software fails.

Please be also aware that the TED-Kit 2 is only able to receive a maximum data length of 512 bytes due to a reception buffer limitation. The first preamble (max. 3 bytes) of the RC Block is not stored in the receive buffer. Thus, depending on the RCB configuration, the number of sent RCB frames can be increased up to (18 bytes [first frame] + 21 bytes [all other frames incl. preamble] * 254 transmissions [RCBC-1] = 5352 bytes) but only




verified up to 512 bytes. Therefore the number of received RC-Frames vs. the number of verified (compared) RC-Frames is displayed in the command shell.

3.2.1 Crypto Module: Input and Output Vector The demo software supports two different crypto algorithms Hitag 3 and AES. Therefore the software uses two different crypto modules. Each module requires a special set of input data and delivers corresponding output data.

3.2.1.1 Hitag 3

The input vector consists of 8 bytes, is called Challenge and has the following byte order: Challenge[0] = RSI[0] Challenge[1] = RSI[1] Challenge[2] = RSI[2] Challenge[3] = RSI[3] Challenge[4] = UDF[0] Challenge[5] = UDF[1] Challenge[6] = func_byte

Challenge[7] = button_code

Note: The 96 bit secret key and the 32 bit Identifier (IDE) is fed to the crypto module separately.

The output vector consists of 6 bytes, is called Response and can be extracted from the crypto module in the correct byte order. The (ignored) MAC is extracted before inside the crypto module, thus invisible for the user.

3.2.1.2 AES

The input vector consists of 16 bytes, is called Inreg and has the following byte order: Inreg[0] = 0xFF Inreg[1] = 0xFF Inreg[2] = 0xFF Inreg[3] = 0xFF Inreg[4] = RSI[3] Inreg[5] = RSI[2] Inreg[6] = RSI[1] Inreg[7] = RSI[0] Inreg[8] = IDE[3] Inreg[9] = IDE[2] Inreg[10] = IDE[1] Inreg[11] = IDE[0] Inreg[12] = UDF[1] Inreg[13] = UDF[0] Inreg[14] = func_byte

Inreg[15] = button_code

Note: The 128 bit secret key is fed to the crypto module separately.

The output vector consists of 16 bytes, is called OutBlock and is extracted from the crypto module in the reverse byte order. Furthermore, a 2-byte MAC output is generated




to match the HITAG-3 function. Thus the output vector must be re-sorted to get the 6 bytes for Response, and the first two bytes of the OutBlock must be ignored, because this is the (unused) MAC.

MAC[1] = OutBlock[15] (ignored)

MAC[0] = OutBlock[14] (ignored)

Response[0] = OutBlock[13]






3.3 Basic System Tests A few tests of the RKE software have been done during software development to match the general requirements.

Based on the different settings of RCBCFG byte 0, all possible lengths of the RCB frame (18 bytes down to 8 bytes, see 2.2.2) and preamble length (3 bytes down to 1 byte) have been tested. These tests imply a previous data set up in the base station demo code to replace missing data by local defines (see above) during reception and data verification (see Table 10 for more details).

The number of wake up bits, adjusted by WUPC and the number of RCB frames, set by RCBC, have been tested. As mentioned above, the TED-Kit 2 is not able to receive more than 512 bytes, thus data verification on base station side is not possible beyond this maximum number of bytes. Thus, if the maximum RCB frame length of 21 bytes (3 bytes preamble + 18 bytes RC-Block) is transmitted, RCBC should be set to the maximum of 24 (= 1+[(512-18) / 21], rounded down), and if the RCB frame length is set to 9 bytes (1 byte preamble + 8 bytes RC-Block) minimum, a maximum number of 57 (= 1+ [(512-8) / 9] , rounded down) frames can be transmitted. However, the RCBC can be always set to the maximum value of 255, because buffer exceeding data will be ignored on base station side.

As mentioned before, the key controller provides two different Secret Keys, the Immobilizer Secret Key (ISK) and the Remote Secret Key (RSK). Both can be used for encryption, depending on the settings bit (RSKM) in RCBCFG byte 0. Therefore, the Secret Key values and its selection must be pre-defined on base station side (demo code) to enable a correct validation of the received Sequence Response data.

The validity of the Hitag 3 and AES algorithm is tested by compare tests with a PC based Hitag 3 (respectively AES) test module. The same module is working in the base station demo code.

Debugging integrity tests are performed during development to test the general plausibility of the module functions.




The following table shows the detailed data transmissions tests. Depending on the settings of RCB_CFG byte 0, the length of the RC-Block varies. Therefore the first column of the table gives the number of transmitted bytes except the preamble, which had a fixed length of 2 bytes in this test. The next columns then show the number of bytes according to the set RC-Block segment bytes.

Table 10: RC-Block transmission test results (Basic functional tests)

Data length

RC Block [bytes] Test Result

FUNC UDF IDE BID RSI SR 18 1 2 4 1 4 6 pass 17 1 2 4 1 4 5 pass 16 1 0 4 1 4 6 pass

1 2 4 1 2 6 pass 1 2 4 1 4 4 pass

15 1 0 4 1 4 5 pass 1 2 4 1 2 5 pass

14 1 0 4 1 2 6 pass 1 0 4 1 4 4 pass 1 2 0 1 4 6 pass 1 2 4 1 2 4 pass

13 1 0 4 1 2 5 pass 1 2 0 1 4 5 pass

12 1 0 0 1 4 6 pass 1 0 4 1 2 4 pass 1 2 0 1 2 6 pass 1 2 0 1 4 4 pass

11 1 0 0 1 4 5 pass 1 2 0 1 2 5 pass

10 1 0 0 1 2 6 pass 1 0 0 1 4 4 pass 1 2 0 1 2 4 pass

9 1 0 0 1 2 5 pass 8 1 0 0 1 2 4 pass




4. Setup and Demonstration To get started with the current RKE application, please do the following steps:

• Take a TED2 with Lopster X Board extension, if the provided base station demo software should be used.

• Use a 7961 key flashed with [GenericRKE.d52] key application or use IAR embedded workbench to flash the controller (see Figure 10).

• Copy the base station demo software [GenericRKEDemo.exe] and the [tk2d.dll] to a working folder.

• Start the demo software [GenericRKEDemo.exe] (see Figure 11).

• In the command shell: select the crypto algorithm ([a] = AES, [h] = Hitag 3) (see Figure 11)

• Press a button on the 7961 board and check the data output in the command shell (see Figure 12)

Figure 10: IAR Workbench




Figure 11: Crypto-Mode selection

Figure 12: Transmitted AES Frame

property nam

e.

Error! Unknow

n document property nam

e. Error! U

nknown docum

ent property




5. Legal information

5.1 Definitions Draft — The document is a draft version only. The content is still under internal review and subject to formal approval, which may result in modifications or additions. NXP Semiconductors does not give any representations or warranties as to the accuracy or completeness of information included herein and shall have no liability for the consequences of use of such information.

5.2 Disclaimers Limited warranty and liability — Information in this document is believed to be accurate and reliable. However, NXP Semiconductors does not give any representations or warranties, expressed or implied, as to the accuracy or completeness of such information and shall have no liability for the consequences of use of such information.

In no event shall NXP Semiconductors be liable for any indirect, incidental, punitive, special or consequential damages (including - without limitation - lost profits, lost savings, business interruption, costs related to the removal or replacement of any products or rework charges) whether or not such damages are based on tort (including negligence), warranty, breach of contract or any other legal theory.

Notwithstanding any damages that customer might incur for any reason whatsoever, NXP Semiconductors’ aggregate and cumulative liability towards customer for the products described herein shall be limited in accordance with the Terms and conditions of commercial sale of NXP Semiconductors.

Right to make changes — NXP Semiconductors reserves the right to make changes to information published in this document, including without limitation specifications and product descriptions, at any time and without notice. This document supersedes and replaces all information supplied prior to the publication hereof.

Suitability for use — NXP Semiconductors products are not designed, authorized or warranted to be suitable for use in medical, military, aircraft, space or life support equipment, nor in applications where failure or malfunction of a NXP Semiconductors product can reasonably be expected to result in personal injury, death or severe property or environmental damage. NXP Semiconductors accepts no liability for inclusion and/or use of

NXP Semiconductors products in such equipment or applications and therefore such inclusion and/or use is at the customer’s own risk.

Applications — Applications that are described herein for any of these products are for illustrative purposes only. NXP Semiconductors makes no representation or warranty that such applications will be suitable for the specified use without further testing or modification.

NXP Semiconductors does not accept any liability related to any default, damage, costs or problem which is based on a weakness or default in the customer application/use or the application/use of customer’s third party customer(s) (hereinafter both referred to as “Application”). It is customer’s sole responsibility to check whether the NXP Semiconductors product is suitable and fit for the Application planned. Customer has to do all necessary testing for the Application in order to avoid a default of the Application and the product. NXP Semiconductors does not accept any liability in this respect.

Export control — This document as well as the item(s) described herein may be subject to export control regulations. Export might require a prior authorization from national authorities.

5.3 Licenses Purchase of NXP <xxx> components

<License statement text>

5.4 Patents Notice is herewith given that the subject device uses one or more of the following patents and that each of these patents may have corresponding patents in other jurisdictions.

<Patent ID> — owned by <Company name>

5.5 Trademarks Notice: All referenced brands, product names, service names and trademarks are property of their respective owners.

<Name> — is a trademark of NXP B.V.




6. List of figures

Figure 1: One-Way RKE example .................................... 4Figure 2: Scalable One-Way protocol .............................. 5Figure 3: Hitag 3 Algorithm applied to generic RKE

application ....................................................... 12Figure 4: Generating the Sequence Response using

HITAG-3 Crypto .............................................. 13Figure 5: AES Algorithm applied to generic RKE

application ....................................................... 14Figure 6: RKE Flow chart – top level .............................. 16Figure 7: RKE Flow chart – device wake-up and

initialization ..................................................... 17Figure 8: RKE Flow chart – preparation of Remote Data

Frame ............................................................. 18Figure 9: RKE Flow chart – transmit UHF frame ........... 19Figure 10: IAR Workbench ................................................ 25Figure 11: Crypto-Mode selection ..................................... 26Figure 12: Transmitted AES Frame .................................. 26




7. List of tables

Table 1: Function Code byte .......................................... 6Table 2: Bit fields in Function Code byte ........................ 6Table 3: RKE configuration settings (RKE_CFG, block 0)

in EEPROM ....................................................... 8Table 4: Description of RKE configuration settings ........ 8Table 5: De-bouncing settings ........................................ 9Table 6: RSI EEPROM mapping (RKE_CFG, block 1) . 10Table 7: Remote Sequence Increment algorithm .......... 11Table 8: Module description .......................................... 20Table 9: Memory allocation (Release build) .................. 21Table 10: RC-Block transmission test results (Basic

functional tests) ............................................... 24


Please be aware that important notices concerning this document and the product(s) described herein, have been included in the section 'Legal information'.

© NXP B.V. 2011. All rights reserved.

For more information, please visit: http://www.nxp.com For sales office addresses, please send an email to: [email protected]

Date of release: 04 April 2011 Document identifier: UM-CAI-2011-01

8. Abbreviations RKE Remote Keyless Entry

RCB Rolling Code Block

RSI Remote Sequence Increment

RSK Remote Secret Key

9. Contents

1. Introduction ......................................................... 3 2. Generic RKE Protocol ......................................... 3 2.1 General Requirements and Considerations ....... 3 2.2 One-Way Protocol .............................................. 4 2.2.1 Key-to-Car communication ................................. 4 2.2.2 Contents of an RCB ........................................... 4 2.2.3 Function Code Byte ............................................ 6 2.2.4 RCB Reception and Processing on Base Station

........................................................................... 6 2.2.5 Protocol Configuration Settings .......................... 7 2.2.6 Button De-bouncing ........................................... 9 2.2.7 Remote Sequence Increment........................... 10 2.2.8 Improved Resync Strategy ............................... 11 2.2.9 Generation of Sequence Response (SR) ......... 12 2.2.9.1 HITAG-3 ........................................................... 12 2.2.9.2 AES-128 ........................................................... 14 2.2.1 UHF transmitter settings .................................. 15 2.3 Two-Way RKE .... Error! Bookmark not defined. 3. Implementation .................................................. 15 3.1 Key side ........................................................... 15 3.1.1 Hardware platforms .......................................... 15 3.1.2 Programming Language ................................... 15 3.1.3 Flow diagrams .................................................. 16 3.1.4 Software Modules ............................................ 20 3.1.5 Memory Space ................................................. 21 3.2 Base Station RKE Reception (TED-Kit2) ......... 21 3.2.1 Crypto Module: Input and Output Vector .......... 22 3.2.1.1 Hitag 3 .............................................................. 22 3.2.1.2 AES .................................................................. 22 3.3 Basic System Tests .......................................... 23 4. Setup and Demonstration ................................. 25 5. Legal information .............................................. 27 5.1 Definitions ........................................................ 27 5.2 Disclaimers....................................................... 27 5.3 Licenses ........................................................... 27 5.4 Patents ............................................................. 27

5.5 Trademarks ...................................................... 27 6. List of figures ..................................................... 28 7. List of tables ...................................................... 29 8. Abbreviations ..................................................... 30 9. Contents ............................................................. 30

um -cai 2011 01 - pudn.comread.pudn.com/downloads633/sourcecode/embedded/2571019/genericrke... ·...

Documents