Method for DSRC communication

The present invention relates to a method for authenticating on-board equipment that can communicate using DSRC standards with toll beacons, where the beacon has a system-wide key and the on-board device has only individual keys that are each generated from the system-wide key based on a derived code specific to each on-board device, with the derived code from the on-board device, the derivative code is sent to the beacon to enable the beacon to imitate the individual key in order to encrypt / decrypt communication with the on-board device and / or to make available the data stored in the on-board device.

[0002] The DSRC standard communication method between such beacons and on-board equipment, whereby on-board beacons send variable derivative codes when communicating with subsequent beacons, it is known from earlier patent application No. 10 450 009.5, the priority of which is claimed in this application.

[0003] DSRC toll systems (dedicated short range transmission systems) are standardized, for example, in ISO 14906 and EN 15509 standards. DSRC communication in the radio interface can take place, for example, in accordance with the WAVE IEEE 1609.11 standard. For security reasons, system keys (Master Keys) are not stored in Onboard Units OBUs in such DSRC road toll systems, instead they only receive individual derived keys (Derived Keys). Only these individual keys are transmitted or used via the DSRC radio interface.

[0004] The derived code required for this, referred to as the "Key Diversifier" in ISO 14906 and EN 15509, represents the individual code for each on-board device for the individual Derived Key from the Master Key. According to the state of the art, the derivative code (Key Diversifier) ​​is communicated to the beacon by the on-board device at each connection between the on-board device and the beacon, so that it can also derive from the system-wide key "in flight" each individual key of the on-board device to communicate with the on-board device or access to it.

[0005] The invention described in the previous application No. 10 450 009.5, was based on the knowledge that this configuration poses a threat to data protection: because during each radio communication in the DSRC standard the derived code is initially transmitted from the on-board device via the radio interface, it can in any case be identified by eavesdropping on the radio interface or by deliberately falsified reading of a passing on-board device, and thus its route can be tracked. In this way, a traffic diagram of a particular on-board device or its user can be prepared in the toll system.

[0006] The invention described in earlier application No. 10 450 009.5 solves the problem of data protection during communication with subsequent beacons by the on-board equipment transmitting various derivative codes, by the fact that the on-board device stores a pool of individual key pairs and related derivative codes and the device on-board selects a pair from this pool as part of the communication with the beacon and uses it to communicate. This makes it possible to prevent tracking of the on-board device for a longer period of time or a greater number of beacon sections based on derivative codes issued by beacons during communication in the DSRC standard.

[0007] The present invention is based on the knowledge that said functionality can also be used advantageously for authenticity checking, i.e. for authenticating an on-board device. To this end, according to the present invention, it is envisaged that a pool of pairs of individual keys and related derivative codes is stored in the on-board device and in subsequent communications the on-board device selects a different pair from the pool each time and uses them for each communication and that the device for authentication the on-board device is stimulated by a checking device to perform at least part of the radio communication, in which the selected derivative code is sent, which is received in the checking device and compared with the pool derived codes stored in the checking device, the on-board device being authenticated by identity comparison.

[0008] The authenticity of the on-board device can therefore be checked simply without having to connect a toll system to the central device. In the "normal" operation of the radio beacon, the pool of derivative codes stored in the on-board device becomes public in individual situations over a long period of time and geographically dispersed points, i.e. in different beacons. The risk of attempted deception by eavesdropping on the air interface between the on-board device and beacons in order to discover the "secret" pool and thus, for example, providing false on-board devices with "real" derivative codes is extremely low. Thanks to the method, according to the invention, the pool of derivative codes secretly located in the on-board device is checked and in this way can be used to validate the on-board device.

[0009] Any change in the communication protocol between on-board equipment and beacons is also unnecessary with the authentication method according to the invention, since the checking device mimics any part of communication with a beacon in which derived codes are sent by the on-board equipment. For this purpose, the checking device can be configured in any way, for example as a portable or transportable device, especially a handheld device, to check the authenticity of the on-board device directly on site.

[0010] This is particularly advantageous if the on-board device is triggered by the checking device to carry out many subsequent communications in order to receive many different derivative codes and compare them with the derivative codes from the pool stored in the checking device where the on-board device is only authenticated when the comparisons confirm identity. This enables even higher reliability of the on-board device's authentication (approval).

[0011] Said pair is selected randomly or at least pseudo-randomly from the pool in the on-board device.

[0012] In another embodiment, a subset of the derived code pool stored in the on-board device can only be used for the said authentication purposes. Therefore, derivative codes are never sent to the beacon and remain secret until checked and are protected against eavesdropping attempts.

[0013] The invention is particularly suitable for communication in accordance with the DSRC ISO 14906, EN 15509, IEEE 1609.11 standards, or in standards based on them, where the derived code is the differential key in this standard.

[0014] The invention is explained below in more detail on the basis of embodiments in the accompanying drawings, in which:

Figures 1 and 2 are a block diagram and interaction diagram of the communication method between the on-board device and the beacon in accordance with previous application No. 10,450 009.5;

Figures 3 and 4 are a block diagram and interaction diagram of the first embodiment of the authentication method of the invention; and [0015] Figure 5 is an interaction diagram of the second embodiment of the authentication method of the invention.

[0016] The method of communication according to previous application No. 10 450 009.5, which forms the basis of the present authentication method, is described for the first time with reference to Figs. 1 and 2.

[0017] Figs. 1 and 2 show exemplary OBU on-board equipment and an exemplary RSE beacon (roadside equipment) of a toll system that has multiple on-board equipment (OBU) and RSE beacons. OBU on-board equipment and RSE beacons communicate with each other via appropriate radio interfaces 1 in accordance with the DSRC standard (dedicated short range transmission), in particular in accordance with the ISO 14906 or EN 15509 standard or standards based on them or compatible with them.

[0018] RSE beacons have, respectively, one or more MK system master keys (Master Keys). For example, they connect to a central device (not shown) that manages or distributes the system-wide key or system-wide keys for the RSE beacon.

[0019] For security reasons, OBU on-board devices do not store one system-wide key (MK), they only receive individually derived DK (Derived Keys) from it. Individual DK keys can be used to encrypt communication on radio interface 1 ("Encryption Keys") and / or as "Access Credential Keys" in order to gain access to data stored in the OBU on-board device, which is known to a person skilled in the art. field.

[0020] DK individual keys are derived from the system-wide MK key according to a given differentiation rule, where the Div Diverifier (Div) code identifies or is a parameter of the differentiation principles suitable for the on-board device, i.e.

DK = f (MK, Div).

[0021] The DK individual key can only be created from the system-wide MK key when the derivative code Div.

[0022] The OBU on-board unit contains a pool of 8 pairs of different Divi derivative codes and the associated associated DKi individual keys. The pool of par 8 can be calculated in advance based on the system-wide MK key, for example, during initialization or on the output of the on-board device in the programming station (OBU Programming Station, OPS) and stored in the OBU on-board device.

[0023] As part of the communication between the on-board device and the beacon, the RSE beacon sends its request (Beacon Service Table BTS) to the passing on-board device in the first step 2. After the BTS request by the RSE beacon, in step 9 the OBU on-board device selects a pair (Divi , DKi) randomly (or pseudo randomly) from pool 8 and sends the Divi derivative code of the selected pair in VST response to the RSE beacon (step 10). Alternatively, a pair (Divi, DKi) can be selected from a list of pairs in pool 8 according to specific rules, for example the oldest or furthest pair first.

[0024] The RSE beacon can now retrieve the individual key DKi of the corresponding OBU on-board from the system-wide MK key based on the derivative code DKi (step 4) and use it in further communication, for example as an encryption key or credential key (step 5).

[0025] Figs. 3 and 4 show the authentication method for checking the authenticity of the OBU on-board device based on the communication method of Figs. 1 and 2. To this end, a CHK check device is used that implements or mimics at least some (or all) of the functionality of the RSE beacon from Fig. 1 and 2, namely in each case the part of radio communication on radio interface 1 that causes the OBU on-board device to send one of its Divi derivative codes, however, not to the RSE beacon, but to the CHK checking device. Accordingly, in Figs. 3 and 4, the same components are designated with the same reference numbers as in Figs. 1 and 2, and reference is made to them in their description.

[0026] The same pool of 8 pairs (Divi, DKi) is stored in the CHK checking device as in the OBU on-board device, whereas in the simplest case, it is only enough to store Divi derivative codes from the pool 8 in the CHK checking device.

[0027] After the OBU on-board device sent a random derived code from its pool 8 (steps 9, 10) - after a corresponding request by the CHK checking device in step 2 - as previously described in Figs. 1 and 2, in step 4 'The received Divi derivative code can be compared to the Divi derivative code from the pool stored in the CHK checking device, i.e. it is checked whether the received Divi derivative code is contained in this pool:

DiVj e {Div,}?

[0028] If so (identity "y"), the OBU on-board device is thus confirmed or authenticated, i.e. authenticity is checked. If not (no 'n' identity), the OBU on-board device is not authenticated (it is incorrect) and for example an alarm can be triggered and a corresponding message can be saved.

[0029] Fig. 5 shows a further development of the embodiment of the method of Figs. 3 and 4, in which the CHK checking device repeatedly performs said communication steps 2,10 with the OBU, so that it then sends a plurality of variable derived codes Divi1, Divi2,

Divi3 etc. In step 4 ", all received Divi1 derived codes. Divi2, Divi3 etc. are compared with the pool of {Divi} derivative codes stored in the CHK checking device and only then the OBU on-board device is considered correct or authenticated if all these received codes derivatives are contained in a pool ("y").

[0030] Optionally, each method described may employ a part of pool 8 in the OBU on-board device for communication with the CHK checking device, i.e. from pool 8 you can choose a special derived code (codes) Divi or Divi1 . Divi2, Divi3 etc. for the purpose of the said authorization. Derivative codes of this part are not used for communication of the OBU on-board device with RSE beacons, so they do not get outside during the "normal" operation of OBU on-board devices and cannot be overheard.

[0031] The invention is not limited to the embodiments shown, but includes all variants and modifications that fall within the scope of the appended claims.

Kapsch TrafficCom AG Representative:

PL-PAT-2012-199

EP 2 529 359 B1