WO2009027380A1

WO2009027380A1 - Method for etcs online key management

Info

Publication number: WO2009027380A1
Application number: PCT/EP2008/061102
Authority: WO
Inventors: Detlef Kendelbacher; Holger Schilling; Fabrice Stein
Original assignee: Siemens Aktiengesellschaft
Priority date: 2007-08-27
Filing date: 2008-08-26
Publication date: 2009-03-05
Also published as: DE102007041177A1; DE102007041177B4

Abstract

The invention relates to a method for ETCS online key management for controlling trains by radio. In said method, entity-specific authentication keys are used for establishing each new radio link between the entities Radio Block Center (RBC) and ETCS vehicle, said authentication keys being transmitted to the entities by a key management center (KMC) via a data link. In order to save communication resources for distributing keys, the authentication keys are encoded by means of a transfer key for the transmission.

Description

description

ETCS online key management process

The invention relates to a method for ETCS online key Selma management of radio-control-entity-specific authentication key used in the for établie ^¬ tion each new radio link between the entities block center (RBC) and ETCS vehicle, which (from a key center KMC ) are transmitted via a data link to the En ^¬ titäten.

The ETCS - European Train Control System - is based on a uniform European standard for train control systems, which enables interoperable railway traffic and thus forms the basis for increased performance and reduced costs. In the so-called Level 2 and 3 of the ETCS, the continuous operation of ETCS vehicles is carried out by section-wise responsible RBC (Radio Block Center), through which the reference variables to the ETCS vehicles are handled by GSM-R Global digital radio System for Mobile Communication - Railway.

The safety-critical data transmission between the jewei ^¬ time RBC and the guided ETCS vehicle is protected by kryptolo ^¬ cal assurance procedures. For the end-to-end backup procedure, a secret cryptographic session key is used that is valid for the duration of the connection. The responsible RBC for the

Train control changes with the movement of the vehicle along the route. At the RBC boundaries, a handover to the next RBC occurs, in which the radio connection and thus the session key is newly established. The security of data transmission, in particular respects ^¬ Lich protection against hacker attacks, depends on the kyptologischen keys used advertising kept secret to. To meet this security requirement, a key management procedure is applied which governs the generation, distribution, storage, use and deletion of cryptological keys in the ETCS.

Prior art key management uses several key types:

1. A personalization key is inserted by the manufacturer of the hardware. It is specific to each entity - vehicle, RBC - and manufacturer access protected. The personalization key is used to encrypt the keys to be stored in the entity and is never used outside the system.

2. With a transport key, the transport of

Authentication key on the way to the entity ge ^¬ protects. The transport key is used in key generation in a protected environment to encrypt the authentication keys and at the manufacturer to decrypt the authentication keys.

3. The authentication key is entity specific and is needed to establish the connection between ETCS vehicle and RBC. For the ETCS communication, the ETCS on-board requires the authentication key of all RBC with which it needs to communicate in addition to his own Authentifizierungsschlüs ^¬ sel. An RBC requires the authentication keys of all ETCS vehicles with which it must communicate in addition to its own authentication key. The Retention of the authentication key is ^encrypted .

4. The session key secures the data to be transmitted between the vehicle and RBC. The session key is derived at the time the connection is established from the authentication keys of the participating communication partners and a random variable exchanged between the communication partners. The session key is maintained for the duration of a communication link between RBC and ETCS

Vehicle valid. After ^{disconnecting} the session key is deleted.

The introduction of the authentication key in the ETCS vehicles and RBC route centers can be done both offline, as well as online. When offline process all authentication keys are introduced before the start of the Sys ^¬ tems in the entities. This fixes the possible communication relationships. Extensions, such as the inclusion of new vehicles in the ETCS, require an update of the authentication keys in the respective entities. In the online process, a key exchange takes place between entities and a key distribution center - KMC Key Management Center - to nachzula ^¬ required authentication key via a data connection, if necessary. The transmission of the authentication key is encrypted.

Previously developed ETCS systems use only the offline key management. This will be the secret

Authentication key for all intended communication ^¬ tion connections by the manufacturer of the system, ie manufacturer-specific, introduced into the entities. For future planned online key management KMC will be set up by the train operators, who will take over the online transmission of the required keys to the domestic and foreign ETCS vehicles on request.

The national KMC of the various rail operators can exchange data to refer requested key foreign ETCS vehicles from KMC of the corresponding train ^¬ operator. Communication can be offline or online. When using the offline data exchange, the KMC must be pre-supplied with the keys of all national and international ETCS vehicles. When using the online data exchange, the transfer of erfor ^¬ sary key at the time of the request and selective tive can take place. It can therefore be assumed that in a national KMC all authentication keys are available for communication with the national and international authorities and can be retrieved as needed. The message format between the KMCs of different rail operators is defined by an UNISIG standard in subset 38.

International traffic ETCS vehicles must accommodate for the post ^¬ load of keys associated with their competent homeland KMC. In contrast to the communication of the ETCS vehicles with the RBC, the data exchange between the ETCS vehicles and the KMC is not standardized. The Übertra ^¬ transmission protocol is a national issue train ^¬ operator. Additional communication resources and, if necessary, international mobile phone connections are required for this. The extra resource consumption becomes particularly critical when an RBC handover is to be in parallel with communication with a KMC. This can add additional mobile require resources or additional coordination of call control.

The invention has for its object to provide a method of the generic type, which is characterized by more resource-efficient key distribution.

According to the invention, the object is achieved by encrypting the authentication keys for transmission with a transport key.

By the claimed online key management to the difficulties referred to in a simple way vermie ^¬ while both meets the existing requirements of the UNISIG standard, as also takes into account the specific needs of railway operators. In addition, the advantages consist in a resource-efficient key distribution, in the shortening of connection establishment phases with the need of key transmission and in the possibility of securing the key management of internationally operating trains of a railway operator with national system extensions.

The method according to the invention regulates the administration and distribution of the authentication keys between the entities KMC, RBC and ETCS vehicle. For this purpose, the function of the transport key is extended. The transport key over ^¬ now not only takes the protection of authenticatio ^¬ approximate key from the key generation in the KMC to the manufacturer, but also the protection of the transport of au- fizierungsschlüssel from KMC to the entities RBC and ETCS vehicle. For this purpose, the ETCS vehicles and the trackside RBC of the railway operator are extended by a non-secure key memory for receiving the encrypted transport key. This is the Transport key another in each entity to spei ^¬ chernder key.

The encryption of the authentication key to be transmitted to an entity takes place with the transport key related to the entity. The decryption of the authentication key is done with the Transportschlüs ^¬ sel in the entities. The storage of the authentication key is encrypted in a preferably access-protected storage medium. This storage medium can be housed in a non-secure computer.

Takes place off the exchange of vehicle-specific transport key during initial commissioning by the manufacturer or maintenance by the operator or manufacturer between manufacturers and maintenance and the national key distribution KMC of the operator, possibly via protected infrastruc ^¬ ture.

The introduction of the transport key into the ETCS vehicle possibly requires the encryption of the transport key with a manufacturer-specific personalization key.

With the application of the method according to the invention an online key management with minimal effort for Instal ^¬ lation, maintenance and modification is possible. Key data only needs to be managed centrally in one place. The distri ^¬ development and updates are automatic means unprotected infrastructure.

The effort of the manufacturers and operators of the ETCS system for introducing and managing the authentication keys is significantly reduced. Only the personalization and transport keys have to be left by the manufacturer or Operators are created in a protected environment and introduced into the entities. The process takes place only once during system generation and does not have to be repeated during later maintenance activities.

The ETCS vehicles have all required future Keyring ^¬ sel to communicate with non-cooperative RBC already during communication with cooperative RBC advance. Abroad, the ETCS vehicle thus has all the keys for all RBC own and third party operators without additional key management activities.

New ETCS vehicles can easily be integrated into the ETCS system. The keys of the ETCS vehicle needed in all RBCs are distributed automatically - automatically learning system.

The UNISIG standards for communication ETCS vehicle - RBC and KMC - KMC are fully complied with. There are no changes or extensions necessary.

For online key management, no additional mobile connections are normally necessary, since existing ETCS radio connections are shared. As a result, there are no new requirements for additional radio resources, in particular with regard to radio channels and GSM terminals.

Railway operators can independently and flexibly define update protocols between KMC and RBC and between ETCS vehicle and RBC.

There are no repercussions and requirements on the vehicle and track infrastructure of other railway operators. The method is robust and also works in cases where the advance distribution of keys from the KMC via RBC to the ETCS vehicles - cache - can not be performed, eg after repair abroad, or is not successful, eg due to radio channel interference. With the alternative methods b) explained in more detail below, namely requesting keys in the cooperative RBC, and c), namely requesting keys in the cooperative KMC, each ETCS vehicle can be supplied with the required authentication keys in every situation.

The necessary update protocols and local non ^¬ access protected data storage in the ETCS vehicles and RBC require little extra effort on development and resource allocation. The additional network load can be minimized as a result of suitable update procedures. Traffic for the ETCS train control is not affected as a result of the process application.

According to claim 2, the transport key is stored encrypted in the entity with a entity-specific, provided by the manufacturer Personalisierungsschlüssel and decrypted only when used.

According to claim 3 it is provided that the transport keys are predetermined by the railway operator and are specific to the entity. This means that a specific transport key is used for over ^¬ mediation of authentication keys for each RBC and for each ETCS vehicle. DA with is the highest flexibility and security of Austau ^¬ MOORISH reached. Alternatively, the method according to claim 4 can also be realized with an operator-wide uniform transport key.

A further possible feature of the method according to the invention is the use of the manufacturer-specified and entity-specific personalization key as a transport key in order to save the additional generation and management of transport keys. However, this waives the independence of key production between manufacturer and operator.

According to claim 6 access to the key memory of the RBC for transmitting key data between RBC and vehicle on the basis of a transmission protocol to be introduced, ie update protocol vehicle - RBC created. The vehicle update protocol - RBC builds on the existing and standardized EURORADIO protocol and uses its services to set up, manage and initiate additional virtual connections between the vehicle and RBC. The update protocol is operator-specific set festzu ^¬.

According to claim 7, the RBC is provided with access to the key memory of the KMC for transmitting key data between KMC and RBC on the basis of a transmission protocol to be introduced, ie update protocol KMC-RBC. The update protocol KMC - RBC can build on ^¬ be arbitrary transmission services or protocols and train operator-specific set.

The invention will be explained in more detail with reference to figurative representations. Show it: FIG. 1 shows a first variant for key transmission,

FIG. 2 shows a second variant for key transmission,

FIG. 3 shows a third variant for key transmission;

FIG. 4 shows a first update method and

FIG. 5 shows a second update method.

The key management method according to the invention provides three different variants for key transmission from a key distribution center KMC to an ETCS vehicle:

a) Distribution of the keys via line center RBC according to FIG. 1

Distribution via RBC takes place in 3 stages.

In the first stage, the identification and provision of all necessary keys for all ETCS vehicles of a railway operator managed in the KMC takes place. The keys of an ETCS vehicle for domestic communication links are stored in the KMC and can be distributed immediately if required. The keys of an ETCS vehicle for foreign Kommuni ^¬ kationsverbindungen can be deposited when using the online data exchange between KMC in the foreign KMC and may need to be first transmitted from there to the domestic KMC. For this reason, the KMC of the various rail operators can be interconnected and share the keys of the international trains running ETCS vehicles un ^¬ behind the other. If the offline data exchange is used between the KMCs, this first step is eliminated because the keys for all foreign and domestic communications ^¬ connections must already be at KMC in this case.

In the second stage the distribution of the keys are managed al ler ETCS vehicles of a KMC to all be Schlos ^¬ Senen RBC a railway operator. Are distributed all poten tially ^¬ keys needed for all vehicles of Bahnbetrei ^¬ bers with communication needs in ETCS. For this purpose there is a communication protocol between the KMC and the RBC, over which regularly an update of the data stocks in the

RBC takes place. The update protocol can use existing Festnetzver ^¬ bonds between the KMC and the RBC. Since the key stocks are rarely changed and only changes are transferred over the there ^¬ tenleitung, the additional network load generated by the key distribution is ge ^¬ ring. There are no UNISIG specifications for the KMC - RBC update protocol so that every rail operator can use its own protocol. Key data for all ETCS vehicles managed by the KMC are kept as copies in all RBCs.

In the third stage, the keys are transferred between RBC and ETCS vehicles. For this purpose, the existing ETCS train control radio connection between ETCS vehicle and RBC is shared. The standardized EURORADIO- Protocol provides that additional data connections can be switched on the existing radio channel and the Da ^¬ th multiple applications are transmitted in the multiplex. For this purpose have ETCS vehicle and RBC next to the EURORADIO protocol another common communication protocol, ie an up ^¬ date protocol that allows the keys to the respective ETCS vehicle at existing radio link are transmitted from the RBC to the ETCS vehicle automatically and with low priority. The update log is not standardized and can be chosen freely by the respective railway operator. The respective ETCS vehicle of the operator is stored online and proprietary with all the ETCS keys present in the national key distribution center KMC of the operator, which are necessary for communication with all RBC trunk stations of the domestic and foreign railway operators. Based on the unique ETCS ID ETCS ID of the ETCS vehicle, the current RBC determines all potentially required keys for the ETCS vehicle and transmits them to the vehicle. The keys are already stored from a to ^¬ back lying transmission locally unless the ETCS vehicle, be ^¬ the transfer to a review of the timeliness and an update no longer restricts current key. If ^necessary , the selection of the keys to be transmitted can be restricted on the basis of further criteria, such as an identifier for the intended route. The Keyring ^¬ sel are stored locally in ETCS vehicle. This can be done for example in a preprocessing computer on the ETCS vehicle.

b) requesting keys through the ETCS vehicle according to FIG. 2

The variant of the request by the ETCS vehicle can be utilized loading when the ETCS on-board does not find a needed Keyring ^¬ sel in the local data storage. The request by the ETCS vehicle takes place in one to three stages.

In the first stage, the ETCS vehicle requests one or more keys directly from the RBC. For this purpose, an existing radio connection can be used or a new radio connection can be set up. By means of the ETCS vehicle update protocol - RBC, access is made to the key memory in the RBC and the transmission of the selected data to the ETCS vehicle. If the key (s) needed are or are not available in the database of the RBC, in the second stage, a connection is established between the RBC and the associated KMC. By means of the RBC - KMC update protocol, the RBC accesses the key basis of the KMC. The se ^¬ selected keys are first transmitted from the KMC to the RBC and then ^¬ from the RBC to the ETCS vehicle.

If keys are needed for foreign ETCS connections that are not deposited in the KMC, in the third stage the necessary connections are established between the participating KMCs and the keys are first transferred to the KMC before the keys are sent to and from the RBC be transferred to the ETCS vehicle. The third stage is only applied in the case of online data exchange between KMCs.

c) requesting keys at the KMC according to FIG. 3

In addition to the variants according to a) and b), there is also the possibility of a direct request of the required keys from the competent KMC by the ETCS vehicle. This variant is suitable as a fallback to a) and b). It is particularly useful in those cases where the ETCS vehicle can not perform an update protocol with the RBC, e.g. when traveling abroad.

There are no security requirements for storing the keys in the ETCS vehicle. The ETCS-keys can be advantageously stored in a non-access-protected environment because the key be unencrypted at any time of the ^¬ transmission and storage. The storage of a plurality of key data sets is by means of Mass storage of a communication computer in the ETCS vehicle easily possible.

Due to the railway operator-specific nature of the vehicle-RBC and RBC-KMC update protocols used, the proposed method of providing keys via RBC is only possible between ETCS vehicles and RBC, which belong to the same railway operator. Each ETCS vehicle distinguishes between cooperative RBCs, which allow key exchange, and non-cooperative RBCs, which can not be key exchanged due to incompatible transmission protocols.

In order for online key management to be effective in cross-border rail traffic as well, ETCS vehicles must also, in addition to the keys for domestic communication links, download the keys for the foreign communication links during their communication with cooperative RBCs. Downloading the key ER only when the ETCS vehicle is moving in a koopera ^¬ tive route infrastructure follows. The detection of cooperative RBC is done automatically by the update protocol vehicle - RBC. When the ETCS vehicle leaves the cooperative route infrastructure of the operator, it also has the key material to communicate with non-cooperative RBCs of other operators, if already transferred to the ETCS vehicle.

Transmission of the key held in the RBC occurs when an ETCS vehicle establishes an ETCS data link to the RBC. The keys are transmitted with a low priority, so that keys are only transmitted if the train control data to be transmitted do not exhaust the available capacity of the radio channel. carrying in the background. Changes the ETCS on-board radio ^¬ connection to RBC, ie at RBC handover, the download of the keys can be canceled. At the next established radio link to the cooperative neighbor RBC, key transmission can continue. The specific communication protocol for key update can be such opti ^¬ mized that only delta information is transferred and broken transmissions will resume automatically.

All keys are encrypted using a vehicle-specific transport ^¬ ^¬ key and use only vehicle internally Be decrypted. Both in the KMC, as well as in the RBC, the keys are only encrypted. Each key has a unique ETCS ID, to which this one belongs

Keys heard. On the basis of the ETCS-ID, the key needed for the current communication connection can be selected from the large number of keys. In addition to the ETCS ID for ETCS key can still Gültigkeitsda- growth, such as the date of the first validation belong, with the recognition of the relevance of a key mög ^¬ Lich. The ETCS IDs of the keys are unencrypted and form a data record together with the validity date and the corresponding key.

The key management method is applicable not only to the distribution of keys of the route infrastructure, but also to updates of keys of the RBC, as illustrated in FIG. By means of the local database in the RBC and the update protocol RBC - KMC, the keys of the ETCS vehicles required in the RBC can be kept up to date automatically. When new vehicles are added to the ETCS system, the key base in the KMC is updated. About the up ^¬ date protocol RBC - KMC be at the initiative of the KMC Key data is distributed to all assigned RBCs and stored there locally.

In addition, the update of the key data in the RBC can also take place at the request of the RBC, as FIG. 5 shows. In the local database of RBC also the key to the known vehicles that are used locally in the RBC in this case, in addition to the keys of the RBC which are übertra ^¬ gen in demand for ETCS vehicles, stored.

Various forms of the method according to the invention are possible. In addition to determining the cooperative infrastructure, this concerns the methods used to update the databases in RBC and ETCS vehicles as well as the application to different key types for mobile and / or fixed installations.

function Description

While driving, the ETCS vehicle communicates with several locally responsible RBCs in turn. This requires the specific authentication keys for this RBC.

If an ETCS vehicle requires a key for a secure connection to an RBC, access is first made to the local key memory in the ETCS vehicle. As a rule, the required ETCS key is stored in the local database of the ETCS vehicle in the store of stored keys. The selection is based on the transferred RBC ID. The selected key is transferred from the key ^memory , which may be located in a non-access-protected environment, to the secure vehicle computer and decrypted there by means of the transport key. With the decrypted authentication key of the RBC, the secure connection can be established according to the security protocol of the EURORADIO method.

After the establishment of the ETCS connection is initiated by the update protocol vehicle - ver ^¬ examined RBC by the ETCS on-board to build an additional virtual connection between RBC and ETCS vehicle in the existing radio channel. This is only possible with a cooperative RBC. If the ETCS vehicle communicates with a non-cooperative RBC, the connection establishment for the additional virtual connection for the key exchange fails. The existing ETCS connection is unaffected.

In the case of communication with a cooperative RBC, the connection to the key exchange is established. It automatically transfers all relevant for this ETCS vehicle key ^¬ data as update information from the cooperative RBC to the ETCS vehicle and its local Schlüsseldatenba- sis updated. If the dataset on the ETCS vehicle is up to date, the virtual connection to the key update is terminated. In order to optimize the communication effort, the key exchange protocol can time-repeat the request to the RBC for current key data.

In certain cases, a required key may not be present in the local keystore of the ETCS vehicle. This applies, for example, to ETCS vehicles whose local database has been exchanged for a repair abroad and which, during their journey in the

Abroad no cooperative RBC to download the key data find. If a key from the local data store in the ETCS vehicle can not be provided for a requested ETCS communication connection, alternative variants exist according to b) and c) to carry the key to the ETCS vehicle to ^¬.

The ETCS vehicle takes an unsecured connection to the RBC and requests the transmission of the required key to the RBC. This alternative is only possible if the ETCS vehicle is in communication with a cooperative RBC. The detection of cooperative RBC is done automatically by the update protocol of the ETCS vehicle. If it is a non-cooperative RBC, the key request is terminated with an error message. At the request of the ETCS vehicle to connect to Keyring comes ^¬ selaustausch with cooperative RBC. If the requested key is available in the RBC's local key database, it will be immediately sent to the ETCS vehicle. Is the required

Keys not available on RBC are made by the RBC via a landline connection to the competent KMC. The cooperative RBC responsible KMC transmits the key to the RBC, which forwards the key to the ETCS vehicle. By using the on-line data exchange between KMC, the KMC can request foreign authentication keys via inter-KMC connections. Keys selected by the ETCS vehicle or all keys valid for the ETCS vehicle may be requested from the RBC. After transmission of the key or the keys to the ETCS vehicle, the existing radio connection can be expanded immediately with the help of the key to a secure ETCS connection.

If the ETCS vehicle is in a non-cooperative

Infrastructure and therefore can not request a key from the RBC, the ETCS vehicle will establish a direct connection to the KMC responsible for the ETCS vehicle. In the competent KMC the required keys, possibly selected by means of inter-KMC connection and transmitted to the ETCS vehicle. Since this variant c) high connection ^¬ effort requires, they should be used only as a fallback the on ^¬ line key management.

Claims

claims

1. A method of ETCS on-line key management for Radio Train Control, which uses entity-specific authentication keys from a Key Center (KMC) to establish each new radio link between the Entities Route Control Center (RBC) and ETCS vehicle a data connection is transmitted to the entities, characterized in that the authentication keys are encrypted for transmission with a transport key.

2. The method according to claim 1, characterized in that the transport key stored encrypted in the entity with a unit-specific, given by the manufacturer personalization key and de ^¬ keyed only when in use.

3. Method according to one of the preceding claims, characterized in that a entity-specific transport key specified by the railroad operator is used.

4. A method according to claim 1 or 2, wherein a unitary one for all entities of a railway operator

Transport key is used.

5. The method according to claim 1, characterized in that is used as a transport key a entity-specific, specified by the manufacturer personalization key.

6. Method according to one of the preceding claims, characterized in that authentication keys stored in the line center (RBC) are transmitted to the ETCS vehicles by means of an update protocol on the basis of the EURORADIO protocol.

7. Method according to one of the preceding claims, wherein authentication keys stored in the key distribution center (KMC) are transmitted to the line centers (RBC) by means of an update protocol on the basis of any railway operator-specific data transmission protocol.