TRAKS: A Universal Key Management Scheme for ERTMSRichard J. �omas

University of BirminghamBirmingham, UK

R.J.�omas@cs.bham.ac.uk

Mihai OrdeanUniversity of Birmingham

Birmingham, UKM.Ordean@cs.bham.ac.uk

Tom ChothiaUniversity of Birmingham

Birmingham, UKT.P.Chothia@cs.bham.ac.uk

Joeri de RuiterRadboud University

Nijmegen, NLjoeri@cs.ru.nl

ABSTRACT�is paper presents a new Key Management and Distribution Schemefor use in the European Rail Tra�c Management System (ERTMS).Its aim is to simplify key management and improve cross-borderoperations through hierarchical partitioning. �e current schemeused in ERTMS involves the creation and distribution of 3DES keysto train and trackside entities, which are then used as part of the Eu-roRadio Protocol to provide message authentication. �is results inthe distribution of tens of thousands of keys using portable media,a prohibitively high burden on management and resourcing. Wepresent a symmetric key solution, TRAKS, which has the bene�t ofbeing backwards compatible with the current ERTMS standard andbeing post-quantum secure. �is new scheme reduces the numberof cryptographic keys in circulation, and maintains the current se-curity model. We achieve this by dynamically deriving unique keysfrom a shared secret, i.e. the line secret, which is combined withIDs of trains, and of signalling equipment. In addition to providingbe�er key management, our scheme also adds authentication tothe location data provided by EuroBalises.

CCS CONCEPTS•Security and privacy → Key management; Hash functionsand message authentication codes; Authorization; Mobileand wireless security;

1 INTRODUCTIONIn any Industrial Control System (ICS) that has safety-critical func-tionality, it is important for any message to be authenticated inorder to ensure that the message came from a genuine entity whohad appropriate authorisation to send that message, and to detectmalicious modi�cations by an a�acker.

�e European Rail Tra�c Management System (ERTMS) is asafety-critical ICS which provides a suite of protocols used to deliver

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor pro�t or commercial advantage and that copies bear this notice and the full citationon the �rst page. Copyrights for components of this work owned by others than theauthor(s) must be honored. Abstracting with credit is permi�ed. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior speci�c permissionand/or a fee. Request permissions from permissions@acm.org.ACSAC 2017, San Juan, PR, USA© 2017 Copyright held by the owner/author(s). Publication rights licensed to ACM.978-1-4503-5345-8/17/12. . .$15.00DOI: 10.1145/3134600.3134631

a modern train management and signalling platform1. �is standardis designed with the intention to enable trains to interoperate acrossborders and optimise the running operation of railways. At present,the system is being rolled out across Europe and also on high-speed lines around the world. ERTMS is de�ned as a protocol stackformed of the following three layers: GSM-R [9], EuroRadio andthe Application Layer Protocol. �e EuroRadio and the ApplicationLayer Protocol form ETCS, the European Train Control System [16].GSM-R, a rail-speci�c variant of the GSM protocol, is used forcommunications between the train and trackside infrastructuresuch as radio block controllers (RBCs), i.e. the trackside componentsthat manage trains in a geographical area. RBCs are responsible forissuing ‘movement authorities’, messages which permit a train tomove a speci�c distance at a given speed, and managing safe trainmovement in a geographic region of approximately 70km. Trainsperiodically provide location updates and the RBC would respondwith an updated movement authority. �e EuroRadio protocol layerprovides authentication and integrity of the communication usingcryptographic MACs. Messages which have a valid MAC (or arefrom a carefully selected subset of messages that may be sent at ahigh priority and not requiring a MAC) are passed to the applicationlayer. �e Application Layer Protocol [6] is a stateful protocol thatde�nes the ERTMS message standard and additionally implementschecks that help prevent message replays.

EuroBalises are devices placed between the tracks, typically ingroups of two or three, which are read by a train passing over them.�e train trusts the EuroBalise to provide accurate location (ratherthan using GPS) and track pro�le data, which can include speedlimits, gradients and tilt pro�les. Currently, the balise data is vali-dated using a CRC code, which is publicly known [21], and is onlyfor error detection but does not provide any integrity protection.

�e current ERTMS standard [18] states that key provisioningand management should be done based on geographical domains(e.g. Great Britain), where each domain has a Key Management Cen-tre (KMC) which is responsible for key generation and managementfor that domain. Additionally, the KMC also de�nes procedures toinstall the keys on train on-board units (OBUs) and RBCs. �rough-out the paper we will interchangeably use the terms train and OBUto refer to trains. �e current procedure requires that keys foran OBU or from an RBC are generated by the KMCs following arequest from a vendor (e.g. Siemens). A�er generation, the keys for

1h�p://www.ertms.net

ACSAC 2017, December 4–8, 2017, San Juan, PR, USA Richard J. Thomas, Mihai Ordean, Tom Chothia, and Joeri de Ruiter

the requesting OBU or RBC are sent in the clear on portable mediadevices [19], to be installed.

�is setup is highly ine�cient; using portable media devices tomove keys greatly increases the risk of compromise, especially dueto the fact that keys on the device are stored in cleartext. Addi-tionally, this makes deployment and management of keys di�cult(i.e. in order to update a key for an RBC, an engineer needs to phys-ically travel to the RBC’s location in order to install the key on theportable media device). Informal discussions with rail systems man-agers have highlighted that insecure strategies like (i) provisioningall (OBU, RBC) key pairs to each OBU and RBC, or simply (ii) havingKMCs extend the life of keys when they are due to expire are usedin practice. Cross-border operation is also challenging as keys needto be shared between geographical domains that are managed bydi�erent KMCs. Under the current scheme, additional burden isplaced on the foreign KMC operators (KMC owners who are outsideof the ‘home domain’ that the train is registered). Whenever a newOBU is to operate in their domain, they are required to establishthe appropriate keys to hand to the ‘home’ KMC, but they also haveto send an engineer to each of their RBCs to install the necessarykeys. In the case of a progressive national deployment, this burdenis high.

ICS environments are also designed with a long lifespan as akey feature. Any solutions presented must consider issues such aspost-quantum security, where quantum computers could rendersome encryption schemes insecure. It should, however, be notedthat there are current e�orts by NIST and ETSI to standardisepost-quantum cryptography. �e time required to standardise this,though, is past the intended start of ERTMS national deployment.For example in the United Kingdom, Crossrail and the East Coastmainline are expected to be complete by 2021.

In this paper, we give a formal de�nition of the security of theERTMS key generation. We continue by proposing a new key man-agement scheme for ERTMS comprised of a key generation scheme,which introduces line secrets to enforce an operational permissionsmodel, and, when combined with the train ID and RBC ID producesa key which can be used in the EuroRadio protocol to negotiatea session key for message MACs, and its corresponding key dis-tribution protocol. Our solution is backwards-compatible with thecurrent scheme allowing infrastructure managers to progressivelyimplement it into the standard.

1.1 Contributions�is paper proposes TRAKS (Train and RBC Authenticated KeyScheme), a key management scheme for ERTMS. Our main focuswith TRAKS is to reduce the management overhead, i.e. physicallytransport keys on portable media devices, an ine�cient processwhich has lead to insecure practices, while maintaining the same�exibility and security for the keys. As such, our contributions areas follows:

(1) Uni�ed ERTMS Key Management and DistributionProtocol. �e TRAKS key management scheme is de-signed to generate message authentication keys for com-munications between OBUs and RBCs, and for communi-cations between OBU and balises.

(2) Reduced deployment overhead. �e TRAKS schemeprovides support for dynamic key generation using pseudo-random functions (PRFs) and a shared secret. �e methodof producing long-term keys removes the need to physi-cally access RBC a�er deployment (RBCs are still provi-sioned with a secret during deployment).

(3) Backwards compatible andpost-quantumsecure. Ourprotocol is designed using symmetric key cryptography ina way that allows it to be fully backwards compatible withthe current scheme used by ERTMS. �is makes it possibleto gradually roll out this scheme in existing systems. Addi-tionally, TRAKS uses post-quantum secure PRFs to derivekeys.

(4) Security analysis. To our knowledge, we provide the�rst security de�nition for the key generation protocol inERTMS. We also prove that TRAKS is at least as secure asthe current scheme while providing all additional bene�tswith respect to key management.

Issues with the existing ERTMS scheme and related work arediscussed in Section 2. We then provide a high-level overviewand intuition of the current o�ine ERTMS scheme and TRAKSin Section 3. In Section 4, we provide a generic formalism of theo�ine ERTMS scheme, followed by our scheme, TRAKS, in Sec-tion 6. A security analysis is provided in Section 7. We discussthe key management lifecycle and distribution in Sections � and8 respectively. Example applications of the scheme, showing itsuniversal application in ERTMS, including EuroBalises (EBs) arepresented in Section 9, and we conclude in Section 10.

2 BACKGROUND AND RELATEDWORKCurrently, ERTMS Key Management is de�ned as two standards,one o�ine, and a proposed online scheme [19, 20]. Some past workhas looked at ERTMS Key Management, for example in [7, 8], whereERTMS was taken as a case study in assessing the protection ofcritical infrastructure, with an introduction to a proposed ERTMSkey management hierarchy, and study of the use of symmetric andpublic key cryptography and their applicability to the problem.�ey advocate symmetric key solutions over public key solutions.Pepin and Viglio�i [12] perform an analysis of ERTMS Key Manage-ment from a cryptographic perspective, identifying that the currentscheme will fail when 3DES may be feasibly broken, but do notmake any recommendations on how to amend the scheme otherthan a change in cryptographic algorithms.

Since the development of the o�ine scheme and the introductionof the ETCS Level 3 baselines, an online solution has been proposedin [20]. �is involves the introduction of a PKI in which certi�-cates and keys are issued to trains and RBCs, where they can thencommunicate with the Key Management Centre. �is, however,relies on the assumption that GSM-R bandwidths are capable ofthese communications, and rely on the upgrade to GPRS support,which is not currently rati�ed for use in ERTMS. �e move to anonline scheme would be disruptive for infrastructure managers.�e only bene�t of this scheme it is that an engineer does not haveto interact with the train or RBC a�er initial setup, with the excep-tion of maintenance periods. Furthermore, the management of alarge-scale PKI for cross-border operation would become a burden

TRAKS: A Universal Key Management Scheme for ERTMS ACSAC 2017, December 4–8, 2017, San Juan, PR, USA

as all trains and RBCs will be required to regularly contact all keymanagement centres they are entitled to use to update their certi�-cates and keys. With the limiting bandwidths available by GSM-R,this is not a feasible solution, and places signi�cant overheads onthe train owner and infrastructure manager, especially given thelong lifespan of ERTMS will limit the cryptographic primitives thatcan be used. In a post-quantum world, however, with the use ofpublic-key cryptography de�ned in [20], the scheme would alsonot be secure, as it relies on RSA public key encryption. Both theo�ine and PKI-based schemes retain the same key hierarchy, aspresented in Table 1.

Di�erent solutions for key management have been proposedin the literature. For example, Biswas proposes a solution withmultiple two-party keys and one multi-party key, where base andextended keys are used to exchange keys across a large, staticgroup [2]. Other schemes, such as the Advanced Access ControlSystem (AACS) [? ], use pseudo-random functions to generatesymmetric keys which are used to derive the necessary keys todecrypt media content. �ese schemes are, however, not directlyapplicable to ERTMS, as groups cannot be statically set and theychange over time. �e AACS scheme is also establishes long-termkeys for decryption only and not for the authentication of payloads.Alternative proposals are based on Di�e-Hellman, which is notpost-quantum secure [11, 15].

Several proposals that have been made by the National Infras-tructure Managers to speci�cally improve ERTMS key manage-ment [1, 3, 13], as the current schemes either lacked de�nition onkey distribution2 or were not suitable for use. In the case of ProRailand OBB, keys are not issued equally, where ProRail tendered asolution which allowed one train to share the same key with manyRBCs, in addition to the one train sharing a key with exactly oneRBC. For OBB, an online scheme was required to distribute keyswith RBCs as no standard was available at the time. �ese solu-tions, however, whilst compliant with the current standard, shouldnot be deemed secure, as the compromise of one train key wouldcompromise its communications with all RBCs under that scheme.Furthermore, the other solutions advocate the use of public key en-cryption through its use of RSA, which is not post-quantum secure,with no rati�ed alternatives for use.

3 ERTMS KEY GENERATION OVERVIEWWithin the current implementation of ERTMS, long-term keys areinstalled on RBCs and OBUs, which are used to derive a session keyusing exchanged nonces through the EuroRadio protocol [18]. �issession key is used as the MAC key to authenticate and provideintegrity protection of transmi�ed messages. In this section, weprovide an overview of ERTMS and TRAKS Key Generation, beforeformally de�ning these schemes in Section 4.

In the current ERTMS Key Management scheme, the infrastruc-ture manager allocates a unique key for each RBC-OBU pair. �iskey is randomly generated by the Key Management Centre, andis encrypted and a MAC is computed for this. �is setup is pend-ing changes following a proposed modi�cation which is part ofthe ETCS Level 3 baseline standard that introduces a PKI, which

2�e SUBSET-114 speci�cations were �rst released a number of years a�er SUBSET-037was released

allows the trains and RBCs to communicate directly to the KMCover TCP/IP.

�e existing and proposed parallel scheme carry signi�cant op-erational overhead, and both present a security exposure due tothe potential to extend the validity of keys. In our solution, weo�er a fully backwards-compatible scheme, which allows the KMCto issue keys until such a time that the RBC may be updated tosupport dynamic key generation. �is reduces the overhead onnational KMC owners, improves interoperability for cross-borderoperation, and also reduces the requirement of the home infrastruc-ture manager to go out into the �eld to install keys on the RBCsfor each new entity introduced into the network. Furthermore, thescheme presented in this paper supports the authentication of dataon EuroBalises (EBs), such as the current location data. Currentlythis data is trusted and assumed to be accurate and authentic, butis sent without any form of authentication.

Security Requirements. Under the existing key key managementscheme, an implicit permissions model exists: a EuroRadio sessioncannot be established if there is no cryptographic relationship be-tween two entities denoted by id and id ′. �is is because a keykmid,id ′ does not exist between them. One bene�t of this schemeis that a train cannot be given signalling commands in an area it isnot authorised to operate in. An example a�ack which is preventedis GSM relaying, where the train tra�c is redirected to a distantGSM Base Station. Without this permissions model (assuming allkeys have been installed), the train would be given the commandto move forward until it has reached a balise to provide its location.�is could place the train in a potentially unsafe situation.

Informal A�acker Model. In our scheme, we investigate a�ackersthat have the ability to insert keys, intercept keys between the KMCand Train, and intercept keys between the KMC and RBC.

If an a�acker is able to install arbitrary keys onto either the trainor RBC, it can create a state of disassociation between what theKMC and train/RBC believes is the current set of loaded keys. Itis currently not clear in the ERTMS speci�cations what remedia-tion should take place if a key is a�empted to be installed and onealready exists. In the case of key interception, once the transportkeys, keys which are used to encrypt and provide integrity andauthentication of payloads between train/RBC and KMC, are in-stalled onto the train or RBC, the a�acker is not able to establishthe kmid,id ′ keys unless they know the appropriate secret used togenerate the keys. As the transport keys are installed in plaintext,an a�acker who obtains the transport key at the point of manufac-ture/commissioning is able to intercept all keys between a train orRBC.

We therefore consider an a�acker from the Dolev-Yao model,who operates in polynomial time, and is able to monitor communi-cations between the KMC and any train and RBC. In particular, thea�acker is also able to send arbitrary messages to any given train,RBC or KMC, and either delay, modify or delete messages beingsent between participants. Any proposed solution has to considerthe capabilities of such an a�acker.

ERTMS Parameters. In the ERTMS System Speci�cations [5], iden-tity variables, known as NID C, are assigned to speci�c ‘zones’ ofoperation, with varying scope, from an entire country to a speci�c

ACSAC 2017, December 4–8, 2017, San Juan, PR, USA Richard J. Thomas, Mihai Ordean, Tom Chothia, and Joeri de Ruiter

ERTMS Entities Handshake MAC EncryptionOBU↔ RBC KMAC KSMAC ×

RBC↔ RBC KMAC KSMAC ×

KMC↔ RBC/OBU × kt1 kt2KMC↔ KMC × K-KMC1 K-KMC2

Figure 1: Current ERTMS Key Management Hierarchy [17],showing the speci�c keys used between ERTMS entitles inspeci�c applications: session handshake, message authenti-cation and encryption.

ERTMS Keys Current TRAKSNID C Secret × knid c

RBC Derivation Key × kmr id,nullTrain Key KMACr id,oid kmr id,oid

Balise Secret × km

Balise NID C Area Key × kmNID C,nullBalise MAC Key × kmNID C,bдid

Figure 2: Proposed TRAKS Key Management Hierarchy. Weintroduce the new notation used throughout this paper as: atrain with OBU ID 3, communicating with an RBC with ID 5would have the key kmr id5,oid3. Balise MAC Keys are boundby the NID C they are located in and their unique balise groupID, bдid .

line in a country. �ese are assigned by a central body, from a poolof available values. We leverage these variables to de�ne a per-missions model of where a train is allowed to operate, rather thanrelying on the direct pairing relationship that the current schemeuses. From this, the infrastructure manager derives a set of keysthat are allocated to RBCs in that speci�c area identi�ed by anNID C. If the infrastructure manager is not in a position to supportthe full capabilities of dynamic key-derivation at RBC level, theycan use the same functions to generate train keys for a RBC. �isis done by computing the RBC key, and applying this to the setof train IDs authorised to operate within the NID C. Train IDs andRBC IDs are allocated by the infrastructure manager from a centralERTMS ID database, EDB. �e result of this process is a set of keyswhich are backwards-compatible with the existing ERTMS scheme.We provide an example application of TRAKS in Section �.

For national infrastructure managers, this reduces the time takento allow a train to cross borders, as the pre-requisite step to installkeys on the RBC is no longer required, as the RBC is able to deriveany key required based on the �rst EuroRadio message receivedby the train (where the train ID is provided). Under this model, wealso enforce a permissions model, whereby, through partitioning ofthe rail network, we ensure that keys are not unnecessarily issued,where the operational zones are exactly de�ned and controlled.Trains may also be reallocated to new areas - in the current scheme,this would rely on an engineer going into the �eld to install therequisite keys on the train and RBCs, however, under our proposedscheme, TRAKS, this can be managed between the train and keymanagement centre, with no requirement to interact with the RBC.

Current Key Distribution. Key distribution in ERTMS is currently amanual process, where keys are generated by the KMC and thendistributed as required in response to a valid request. �is set ofkeys is then accompanied with a separate MAC and encrypted usingpre-shared symmetric keys referred to as transport keys. When anew train or RBC is added to the system, however, these transportkeys, used to encrypt and authenticate payloads to and from theOBU, RBC and KMC, are installed in cleartext. �e compromise ofthe transport media (e.g. USB stick or CD) would allow an a�ackerto forge their own valid messages which could compromise safety.Under TRAKS, we propose a new key distribution scheme, whereby

trains and RBCs instead generate their own transport keys in such away that an external a�acker would require knowledge of the keysin order to obtain the keying material. In our scheme, we proposea shared key between the key management centre and approvedvendors, which is used for vendor-KMC communications. Trainsand RBCs have a burnt-in key pair, installed by the vendor whichcan be used for train/RBC-vendor communications.

In the following we de�ne a framework for ERTMS key genera-tion, outlining the functions run by the Key Management Centre.Using this outline de�nition, we can de�ne a model of the currentERTMS Key Generation scheme in Algorithm 1 and TRAKS in Al-gorithm 2. Using these models, it is possible to prove the securityof these mathematical models against an a�acker, which gives uscon�dence that our proposed solution does not compromise thesecurity of ERTMS.

De�nition 3.1. An ERTMS key generation scheme KMAC =(SGen, INIT.ID,GEN.KMAC) over a ERTMS id database EDB isa tuple of three polynomial-time algorithms:

knid c ← SGen(1λ ) : is a probabilistic key generation algorithmrun by the KMC. It takes as input a security parameter λand outputs a random value s of length λ.

IDt ← INIT.ID(EDB, t ) : is a deterministic algorithm run by theKMC to retrieve a set of ids from an ERTMS database. Ittakes as input a database EDB and a ERTMS entity type tand outputs the set of ids corresponding to t . In the currentERTMS standard t ∈ {OBU ,RBC,EB}.

kmid,id ′ ← GEN.KMAC(id, id ′,knid c ) : is an algorithm run bythe KMC to generate a MAC derivation key. It takes asinput two ids id ∈ IDt and id ′ ∈ IDt ′ , and a secret knid c ,and outputs the key kmid,id ′ that is used to authenticatecommunication between id and id ′.

3.1 TRAKS Application ExampleWe present a high-level hierarchy of ERTMS Key Managementunder TRAKS in Figure 1. Key management operations whichallow trains to operate across borders remain unchanged, with asymmetric pair of keys shared between KMCs. From the currentERTMS scheme, we introduce an intermediary level, leveraging

TRAKS: A Universal Key Management Scheme for ERTMS ACSAC 2017, December 4–8, 2017, San Juan, PR, USA

NID C, denoted in Figure 1 by knid cx where x is the identity of theregion (NID C) of operation. NID C is an allocated ERTMS variablethat represents a speci�c region or line. �is has a unique secretkey allocated per NID C, representing a mapping from NID C to itsline secret.

For a given region or line, a number of RBCs may operate. Usingthe line secret knid cx , and the RBC identity, the RBC keys areestablished. In the �gure, we show two trains which are authorisedto operate over two NID C regions each. By applying De�nition 4.1and additionally supplying the identity of the train, the KMC al-locates the keys required to the OBUs. For the RBCs, however, asingle derivation function is required to establish the keys.

More concretely, let us consider an example national domainde�ned by Figure 1, with 4 NID C regions and 6 RBCs. For eachNID C in this domain, which have NID C values 1, 2, 3 and 4, theKey Management Centre will generate a line secret (based on afunction which produces random output, e.g. using a HardwareSecurity Module) for the regions. It stores the line secret outputknid c1, ...,knid c4. To provide RBC keys, the Key ManagementCentre will use the line secret for the given NID C and computethe individual key for that RBC by combining the ID of the RBCand the line secret. We discuss the speci�cs of generating keys inSection 9. As an example, for RBC2 and RBC3, the Key ManagementCentre will use the line secret for NID C2, knid c2, and compute theindividual RBC keys based on the IDs of RBC2 and RBC3 (i.e. rid2and rid3), producing kmr id2,null and kmr id3,null , which wouldthen be installed on the RBCs.

When train keys are required, the KMC will determine for whichRBCs a key is required, and, for each of these RBCs, it will derivethe corresponding RBC key, and output a key which is the result ofapplying the train ID to the RBC key using GEN.KMAC(rid,oid,knid cx ). �is results in a key which uniquely pairs a train to agiven RBC and can be installed on the train. When a train sendsthe �rst EuroRadio message, the RBC will use the ID of the trainto compute the key it requires using the key it has installed byapplying the train ID to the RBC key installed. As an example,for Train1, with ID oid1, which operates in NID Cs 1 and 2, it willreceive all the necessary keys to communicate with the RBCs in thatarea, i.e. kmr id1,oid1, kmr id2,oid1 and kmr id3,oid1 will be installedon the train.

In the rest of this paper, we formalise the de�nition of this schemeand prove its correctness, and discuss how it can be implementedand used. In Section 6, we consider the security requirements anda�acker model that TRAKS must work with, before de�ning the keylifecycle. We formally de�ne the current ERTMS key managementscheme in Section 4, presenting the TRAKS scheme in Section 6.We apply these formal de�nitions in Section 7 to prove that thecurrent ERTMS Key Management scheme and proposed TRAKSscheme are secure.

4 OFFLINE ERTMS KEY GENERATIONIn this section, the O�ine ERTMS key generation scheme that iscurrently in use is presented in more detail.

�e key provisioning process begins with the vendor (e.g. Siemens,Alstom and Bombardier) of an entity (e.g. OBU) making a formalrequest for an identity (ETCS ID), followed by a request for keys.

National KMC (KMC-GB) Foreign KMC (KMC-FR)

Foreign KMC (KMC-DE)

RBC1

NID_C1

RBC2

RBC3

RBC4

RBC5

RBC6

NID_C2

NID_C3

NID_C4

Train1

Train2

Figure 3: TRAKS Key Hierarchy for ERTMS. TRAKS is com-posed of four layers: (1) the national infrastructure for the‘home domain’, which is responsible for liaising with for-eign KMCs. (2) Geographic regions within a country, knownas NID C. (3) RBCs, responsible for command and controlmessages to trains. (4) Trains, which operate across one ormore NID C regions.

�e KMC then responds by issuing the two transport keys, kt1 andkt2, used for authentication and encryption respectively. �e twokeys are sent in the clear on portable media devices [19], to beinstalled.

On successful installation of kt1 and kt2, the KMC will generateunique keys for each train and RBC pair with identi�ed throughtheir IDs oid and rid respectively. In order to authenticate messagesexchanged between them, each entity receives a collection of thesekeys. We will denote the set of keys with which OBUs and RBCsare provisioned as KM . KM may be initially empty (in the caseof a new train or RBC), but it keys will be added as the train isauthorised to communicate with relevant RBCs.

We provide an algorithm for theGEN.KMAC(id, id ′,knid c) func-tion from De�nition 4.1 in Algorithm 1. �is algorithm takes asinput two IDs, id and id ′ corresponding to the two entities whichare authorised to communicate with one-another and returns a ran-domly generated 3DES key to be used for message authenticationin the EuroRadio protocol. For example, the key between a trainwith oid and an RBC with rid is: kmr id,oid ← SGen(1λ ).

Algorithm 1: O�ine ERTMS key generationInput: id, id ′Output: kmid,id ′

1 function GEN.KMAC(id, id ′,null )2 kmid,id ′ ← SGen(1λ )3 return kmid,id ′

5 TRAKS - A UNIFIED ERTMS KEYMANAGEMENT SCHEME

In this section we propose TRAKS, our e�cient key generationscheme for ERTMS. Our scheme uses the existing partitioning ofthe rail network into individual zones of control, denoted by anational identi�er, which is announced to the train by EuroBalises.Using this partitioning, we enforce a permissions model whichensures that trains are not able to operate outside their agreed areas

ACSAC 2017, December 4–8, 2017, San Juan, PR, USA Richard J. Thomas, Mihai Ordean, Tom Chothia, and Joeri de Ruiter

of operation. TRAKS improves on the o�ine ERTMS scheme byallowing the key generation to be dynamic for RBCs thus improvingthe interoperability and reducing operational complexity for cross-border operations, while maintaining static key provisioning totrains. �is provides maximum backwards compatibility with thecurrent standards and practices.

In addition to the reduced management overheads, our schemealso provides authentication to messages both between OBUs andRBCs, and between OBUs and EuroBalises (EBs) making it univer-sally applicable to any rail entity.

5.1 Secret GenerationIn the rail network for a given country, there will be one or moreregions. Each is identi�ed through a public value, NID Ci for theregion with NID C value i . For each NID Ci , the KMC will generatea random knid ci secret. As such, multiple secrets can be producedby the KMC to partition the rail network into geographic zones,and/or to establish trust between entity types, e.g. keys betweenOBUs and RBCs are generated using knid c1 and keys betweenOBUs and RBCs are generated using knid c2 for zone NID C1 andNID C2 respectively’.

Similarly to the o�ine ERTMS scheme the TRACKS shared secretis generated using:

knid ci ← SGen(1λ )where SGen(1λ ) is a pseudo-random number generator (PRNG)with the security parameter λ. Unlike the o�ine ERTMS scheme,however, this secret is never given directly to OBUs or RBCs. It isinstead used together with IDs to generate the message authenti-cation keys. �is approach greatly enhances the usability of thescheme by reducing the overall management overhead (i.e. secretkey material storage, distribution and disposal). In the following,we will detail how we use this secret to generate the authenticationkeys for each ERTMS entity.

5.2 Key Generation

Algorithm 2: TRAKS key generationInput: id, id ′, sOutput: kmid,id ′

1 function GEN.KMAC(id, id ′, s )/* for computing keys using s = knid c */

2 if id , null then3 kmid,id ′ ← PRF (id, s );4 if id ′ , null then5 kmid,id ′ ← PRF (id ′,kmid,id ′ );

/* for computing OBU-RBC keys using

s = kmr id,null */

6 else if id = null then7 kmid,id ′ ← PRF (id ′, s );8 return kmid,id ′

Keys in TRAKS are generated using Algorithm 2, using knid cand the IDs of the communicating ERTMS entities. Algorithm 2 can

be used to generate both (1) static keys which can be used to directlyauthenticate messages between two entities with identities id , andid ′ and (2) dynamic keys which can be combined by the holderwith any id ′ to derive a static key. We continue with concretedescriptions of how keys are generated for OBUs, RBCs and EBsusing TRAKS.

OBUKeyGeneration. OBU keys are static keys which are entirelycomputed by the KMC. Similarly to the o�ine ERTMS scheme,when a train identi�ed by ID oid is authorised to operate on aspeci�c line it is provisioned with a set of keys KM = {kmr id1,oid ,kmr id2,oid , . . . ,kmr idn,oid }where rid1, . . . , ridn are the IDs of theRBCs which control the line.

Each key kmr id i,oid is computed using GEN.KMAC(ridi,oid,knid c ) detailed in Algorithm 2. First the secret knid c is combinedwith the RBC’s ID ridi using a PRF to generate an intermediatepseudo-random value (line �). �is intermediate value is subse-quently combined using the same PRF function with the oid tocreate the �nal kmr id i,oid key (line �).

�e PRF can be any secure, non-malleable function, which isproven secure against length-extension a�acks, such as HMAC-SHA-256 or AES-CMAC. It is easy to see that until now, our schemeis fully backwards-compatible, as there are no changes to how thekeys are managed by the train.

RBC Key Generation. In TRAKS, keys that are provisioned toRBCs are dynamic. �is means that RBCs are able to producekeys and communicate with any train for which they have anOBU ID. Under the current ERTMS implementation, trains arerequired to broadcast their oid in plaintext as part of the EuroRadiohandshake when communicating with a RBC. �is enables TRAKSto seamlessly replace the existing ERTMS scheme with only minormodi�cations to the RBCs internal programming.

Algorithm 2 is also used to generate RBC keys. Unlike in thecase of the trains where OBUs are provisioned with a set of keys,the RBCs only have one key, kmr id,null , computed by runningGEN.KMAC(rid,null ,knid c ), where rid is the RBC’s own ID. �evalue returned is the intermediate value computed in line �.

RBCs can use kmr id,null by running GEN.KMAC(null ,oid,kmr id,null ) for any broadcasted oid to compute the message au-thentication key kmr id,oid .

It is easy to observe that generating key kmr id,oid based onthe knid c secret can be used to enforce the permissions modelexplicitly. Any OBU and any RBC which are able to complete theEuroRadio handshake protocol must have been explicitly approvedto operate in a given NID C, as opposed to the current scheme,where this is implicit and therefore could be violated.

EuroBaliseKeyGeneration. Another signi�cant bene�t of TRAKSis that it can be used without modi�cations to generate authenti-cation keys for any pair of ERTMS entities. Here, we will try toexemplify this using EuroBalises (EB), however the scheme shouldwork with other, possibly not yet developed, rail entities. Currently,EuroBalises o�er no cryptographic protection of their payloads,and are implicitly trusted by the train for accuracy and validity.

�e process of generating the unique authentication keys forbalises is similar to the one used to generate the keys for the OBU-RBC pairs.

TRAKS: A Universal Key Management Scheme for ERTMS ACSAC 2017, December 4–8, 2017, San Juan, PR, USA

�e KMC generates a balise speci�c shared secret as kbls ←SGen(1λ ) which ensures that the shared keys between EBs andOBUs are completely separate from the ones shared between OBUsand RBCs and are generated by each the KMC responsible foreach country. However, unlike messages sent by trains or RBCs,messages sent by EBs are �xed. Furthermore EuroBalises are unableto perform any cryptographic operations. As such, when usingTRAKS between OBUs and EBs, the balises will be provisionedwith their �xed messages concatenated with the correspondingMAC. �e MAC will be computed using a static authenticationkey generated by running GEN.KMAC(NID C,bдidi,kbls ) for eachbalise group bдidi under the control of NID C. A balise group is acollection of balises concentrated in a common geographical area,for example, deployed along a rail line. We recommend the useof groups of balises instead of single balises to ease deployment.However, we note that the scheme would work similarly if balisegroup IDs would be replaced with balise IDs. More details areprovided in Section 9.2.

Following key provisioning to a balise, the corresponding keysfor NID C, which are used for provisioning OBUs, can be computedas follows:

kmNID C,null = GEN.KMAC(NID C,null ,kbls ).

�is allows trains to use kmNID C,null to generate keys correspond-ing to any balise group created using the key kbls and NID C bycomputing kmNID C,bдid as:

kmNID C,bдid = GEN.KMAC(null ,bдid,kmNID C,null ).

6 SECURITY ANALYSISIn this section, we formally discuss the security of ERTMS keygeneration using a game-based approach.

We begin by stating that the a�acker is given access to all IDsthat can be generated from EDB. �e a�acker wins if it is able togenerate a valid key kmid,id ′ for any pair (id, id ′) for the typest and t ′, where id ∈ INIT.ID(EDB, t ) and id ′ ∈ INIT.ID(EDB, t ′).We de�ne the ERTMS KMAC security with a game played betweena challenger C and an adversary A as follows.

De�nition 6.1 (Key indistinguishably from random). Let KMAC =(SGen, INIT.ID,GEN.KMAC) be a scheme over a database EDBwith security parameter λ, t and t ′ are entity types with t , t ′, andb ∈ {0, 1}. We consider Expb

A(KMAC) (see Fig. 2), a probabilistic

experiment played between an adversary A and a challenger Cconsisting of:

(1) Get IDs. C runs INIT.ID for types t and t ′ to generate the setsID and ID ′.

(2) Generate keys. C generates a new random secret s and uses itto generate unique keys by running GEN.KMAC(id, id ′, s ) forall pairs (id, id ′) ∈ ID × ID ′ except for (last (ID), last (ID ′)).�e function last (X ) returns the last element from a set X .

(3) Challenge. If b = 0 then the last key is generated askmlast (ID ),last (ID′) ← GEN.KMAC(last (ID), last (ID ′), s ).If b = 1 then kmlast (ID ),last (ID′) is sampled randomly fromthe keyspace K .

(4) Guess. A is given access to all the identi�ers in ID and ID ′

and to all the generated keys kmid,id ′ , where (id, id ′) ∈ ID ×

ExpbA(KMAC)

ID ← {i |i ∈ INIT.ID(EDB, t )}ID ′ ← {i |i ∈ INIT.ID(EDB, t ′)}

sR←− SGen(1λ )

for id ∈ ID, id ′ ∈ ID ′ do :if (id, id ′) , (last (ID), last (ID ′)) :kmid,id ′ ← GEN.KMAC(id, id ′, s )

endifendforif b = 0 :kmlast (ID ),last (ID′) ← GEN.KMAC(last (ID), last (ID ′), s )

else :kmlast (ID ),last (ID′)

R←− K

endifb ′ ← A

((kmid,id ′ )id ∈ID,id ′∈ID′ , ID, ID

′)

return b ′

Figure 4: ERTMS key derivation security game for an adver-sary A.

ID ′, and computes a guess b ′ ∈ {0, 1}. �e output of theexperiment is b ′.

�e advantage of an adversary A against the security of thekeys generated in ERTMS is de�ned as:

AdvA =����Pr

[Exp0

A(KMAC) = 1

]− Pr

[Exp1

A(KMAC) = 1

] �����e key is indistinguishable from random if the advantage is

negligible in λ.In the following, we will show that both the current ERTMS

scheme KMACERTMS , and our proposed scheme KMACTRAKS ,produce keys that are indistinguishable from random.

Key Indistinguishably for KMACERTMS . It is easy to observethat the advantage of the adversary is based on its ability to dis-tinguish the output produced by GEN.KMAC from random. How-ever, the protocol speci�cation (see Algorithm 1) shows that thekey kmid,id ′ for any pair (id, id ′) is already randomly sampled.�us, the advantage of A to distinguish kmid,id ′ from random,|Pr[Exp0

A(KMACERTMS ) = 1] − Pr[Exp1

A(KMACERTMS ) = 1]|,

is negligible in λ.

Key Indistinguishably for KMACTRAKS . Based on the protocolspeci�cation (presented in Algorithm 2) there are three cases forGEN.KMAC.

Case 2. If two identi�ers id and id ′ are provided as inputs toGEN.KMAC then the key kmid,id ′ is generated as follows:

(1) An intermediary key is generated by running the PRF withthe secret s and input id . As shown in Case 1, this is indis-tinguishable from random.

(2) �e previously generated intermediary key is used as asecret in a second PRF run that also takes as input id ′. If thePRF is secure then this output will also be indistinguishablefrom random.

ACSAC 2017, December 4–8, 2017, San Juan, PR, USA Richard J. Thomas, Mihai Ordean, Tom Chothia, and Joeri de Ruiter

Case 3. If identi�er id ′ is provided together with the secretkmid,null as inputs to GEN.KMAC then the key kmid,id ′ is gener-ated as in the Case 2.2 above, i.e. the value kmid,null is used as aninput, together with id ′ to a PRF. As kmid,null is indistinguishablefrom random (see Case 1), if this PRF is also secure then the outputwill be indistinguishable from random.

�us, the advantage ofA to distinguish any kmid,id ′ for TRAKS,|Pr[Exp0

A(KMACTRAKS ) = 1] − Pr[Exp1

A(KMACTRAKS ) = 1]|

will also be negligible in λ for any pair (id, id ′).

7 THE TRAKS KEY MANAGEMENTLIFECYCLE

In this section, we outline the key lifecycle for TRAKS, beginningwith how the keys will be used and the changes required to supportTRAKS. We then look at other aspects, for example key revocationand disposal of RBCs and trains.

Key Usage. Under our proposal, the RBC will be in an improvedposition, whereby it does not require individual keys to be assignedto it for a particular train. It is now able to derive its own symmetrickeys based on some public information broadcast by the train,namely the ETCS ID. As a result, an RBC only requires a single keyto be installed on it, which it uses to derive the keys which willcorrespond to those of the train. In the event that the RBC so�waredoes not support dynamic key generation, it may proceed using thesame set of keys that would be allocated to trains for that RBC ID.Within the EuroRadio protocol, no changes are required to the coreprotocol that takes place, other than the way that the lookup of thekey takes place. Currently, the RBC will use its ETCS ID and lookfor a corresponding entry that pairs the RBC to the Train ETCSID and vice versa for the train. If an entry exists, it will use thatkey, otherwise, the EuroRadio protocol will fail as no key could befound. For our proposal, the RBC instead uses the kmr id,null key,to derive the key which it can then use to compute a symmetricsession key for the MAC authentication in EuroRadio.

For the train, when keys are allocated, the KMC will look upa set of the RBCs within the NID Cs speci�ed as authorised, andcarry out the computation of kmr id,oid for each RBC. As with thecurrent scheme [19], the train will receive a set of keys, which, uponthe receipt of the the �rst response message from the RBC in theEuroRadio handshake (the AU2 message), can select the appropriatekmr id,oid key to use.

Revocation. In this scheme, trains may have their keys revokedusing the ‘DELETE KEY’ command, issued by the KMC, and likewisefor the RBC. A blacklist, which would be made available for entitiesto download during maintenance or stabling would inform the trainof RBCs it may no longer engage with, and vice versa for the RBC.However, if there is cause to ‘reintroduce’ that particular ETCS ID,there is no solution but either to generate a new knid c , which is anintensive process to rekey all existing entities, or change the ETCSID of the a�ected entity. �is, however, should be considered a veryrare event. Validity of keys would be governed under the validityof knid c , ensuring that keys are refreshed on a regular, enforcedbasis. In the event that a train or RBC are to be reintroduced, a newETCS ID should be introduced, as we consider all keys issued to theoriginal ID to be compromised and should not be eligible for reuse.

Disposal and End-of-Life. Keys should have a set lifetime, whichis subject to further discussion and scoping. However, at the endof a key’s validity, a ‘DELETE KEY’ command should be issued tothe entity to remove the key, and a con�rmation received thatthe key has been deleted. At the point of end-of-life, in order toprevent cryptographic material being leaked, a ‘DELETE ALL KEYS’command should be issued by the KMC, where the entity con�rmsreceipt of the command, prior to deleting its kt keys. During thisprocess, the KMC should retain a copy of the keys, but mark themas invalid, to prevent any keys pertaining to that entity from beingissued. If the entity operates across borders, the appropriate KeyManagement Authorities responsible for cross-border keys shouldbe requested to initiate their appropriate ‘DELETE ALL KEYS’ com-mand. A�er this point, the entity in question may be disposedof.

7.1 Discussion�e solution presented in this section has been engineered to bebackwards-compatible, such that infrastructure managers may im-mediately begin to shi� to this alternative solution with no changesto the internal way in which EuroRadio operates. All changes heremay be performed in so�ware, with most of the code changes lyingon the Key Management Centre and RBC interfaces.

�at said, our solution can work in both o�ine and online situa-tions, where in the o�ine mode, the RBC requires one initialisationand installation of its derivation and kt keys, compared to a visitby an engineer each time a train is introduced to the network andrequires ‘approval’ to communicate with this particular RBC. Fortrains, however, the keys at the point of manufacture may be in-stalled at the same time, whilst updates may take place whilst thetrain is stabled and undergoing maintenance. If a train were to be‘moved’ and made operational in a di�erent geographic region3,then the blacklist for the ‘previous’ RBCs should be updated tocontain that train unless it was going to continue operating in thatregion. Likewise, a ‘DELETE ALL KEYS’ command should be issuedif the train will no longer operate in a given area.

In the online method, when an RBC comes online for the �rsttime and has carried out the appropriate TLS handshake and clientauthentication with the KMC, the KMC will simply issue the deriva-tion key and appropriate constraints, as set out in SUBSET-038[17]. For a new train, however, the process simply is an onlineversion of the o�ine system, where instead of physical media beingused, an online connection is used. Overall, this solution providesthe additional protection that if the Key Management Centre wento�ine, the entities still retain su�cient keying material to carryout the EuroRadio Handshake. A train should not be allowed tomake a journey for which it does not have the appropriate keyingmaterial to proceed. �is prevents a situation where the GSM con-nection between the train and RBC is instead redirected to an RBCin another area, where an unsafe instruction may be issued.

We should also consider the case of existing trains which arecurrently operational. Under the existing o�ine model, each trainhas a unique key shared with the appropriate RBC on its ‘allowedroutes’. �is provides an challenging operational concept, where

3For example, the West Midlands franchise in the United Kingdom is likely to receive17 of the former Northern franchise British Rail Class 323 electrical multiple units.

TRAKS: A Universal Key Management Scheme for ERTMS ACSAC 2017, December 4–8, 2017, San Juan, PR, USA

during the process of national deployment, the line secret may beset up and appropriate derivation keys established. �is means thatas RBCs are introduced, no additional keys need to be introduced totrains, and they may immediately be in a position to communicatewith the RBC. However, once a national deployment is complete,the process of adding additional keys is expensive, and there arefew storage bene�ts to having few keys. �us, the KMC may beable to ‘precompute’ the keys for the train, where the RBC is stillrequired to carry out the appropriate calculations.

For existing lines and entities, their keys will remain valid untilthe validity period expires, in which course, a replacement key willbe issued based on this speci�cation.

Identi�ed changes to the EuroRadio Protocol (in so�ware) andunderlying infrastructure are:

• Modi�cation of the way that an RBC looks up keys: it willnot perform a lookup, rather it will simply carry out theappropriate key generation computation (as per Algorithm2) for the key that will allow it to communicate with thetrain. Trains will continue to be statically keyed, with nochanges required.

• Establishing ‘line secrets’ that correspond to a speci�cNID C and appropriately generating kmr id,oid keys forRBCs and trains based on this principle.

8 KEY DISTRIBUTIONIn the current ERTMS distribution scheme, the transport key isissued by the KMC in the clear, with a requirement on the inter-mediary to use trusted media (ranging from CD to USB storage).During national deployment, there will be a signi�cant number oftransport keys being issued, with the risk that multiple transportkey payloads will be stored on the same media4. As the transportkey is installed in the clear, an a�acker could intercept the transportkeys at the point of installation.

Once the a�acker has the transport keys, they are able to inter-cept the encrypted keys from the Key Management Centre whenthey are installed on the train or RBC. For a train, this means thatthe a�acker can determine the session key with relative ease if theyobserve the EuroRadio handshake protocol between the train andan RBC. In the case of an RBC, however, this means that an a�ackercould initiate arbitrary EuroRadio sessions with valid MACs, oreven worse, send arbitrary messages to a train with a valid MAC,once the nonces have been obtained which the train would accept.�e current scheme is not secure due to this threat, and we proposea new key distribution scheme as follows:

Manufacture/Commissioning. �e train/RBC creates its ownpair of transport keys, kt1 and kt2, using a hardware security mod-ule, exported using a pair of symmetric keys, kv1 and kv2, burntinto the module by the vendor or operator to encrypt and MACthe payload containing the transport keys and the ERTMS identityof the train or RBC. We place a requirement that the vendor hasa secure supply chain and the keys are securely generated andhandled. If the vendor keys are compromised, new trusted keyswould need to be installed onto every train/RBC from that vendorthrough their update mechanism.4�e RBC and OBU selects a speci�c �le from the media for its payloads, typicallybound using its ETCS ID[19].

Key Requesting from Infrastructure Manager. �e vendor/op-erator generates a request to the national infrastructure manager(KMC) for the appropriate keys to be installed, providing the trans-port keys generated by the train or RBC. �is request is encryptedand MACed with a pair of symmetric keys issued by the KMC tothe ‘approved’ vendor or operator, kv,kmc1 and kv,kmc2. As a ven-dor may be responsible for manufacturing trains and RBCs for usein di�erent countries, they determine the appropriate countriesthat keys are required for and submit requests to the appropriateinfrastructure managers.

KMC Processes Request. �e KMC veri�es the request, as pernationally agreed procedures and, if valid, generates the appropriatekmr id,oid keys as required, encrypted and accompanied by a MACusing the transport keys given and stored as part of the request.�e scheme accounts for two cases, dynamic key generation abilityand static key usage. For each case:

• Ability to dynamically generate keys. �e Key Man-agement Centre computes a ‘master derivation key’, i.e.kmr id,null as per Algorithm 2, with no additional identityparameter included. It then encrypts and generates a MACusing the transport keys, before issuing the result to thevendor/operator.

• Static key usage. �e Key Management Centre identi�esthe keys required, and generates a set of keys based onthe NID Cs provided in the request. �is is done through re-peated runs of Algorithm 2, with the appropriatekmr id,nullfor the set of RBCs located in the appropriate NID C thatthe train requires keys to authenticate to them. �ese keysare encrypted then MACed using the transport keys, priorto issuing them to the vendor/operator.

Key Installation. �e vendor/operator then installs the payloadof km keys onto the train/RBC where it will verify the MAC anddecrypt the keys before installing/performing the maintenance in-struction as required. As part of this, the train or RBC will generatea response to con�rm the keys are installed, “KEYS INSTALLED”,which includes a hash of the database of keys installed on thatentity, and encrypts then MACs the response with the transportkeys shared between the train/RBC and KMC.

Vendor Commissioning Con�rmation. �e vendor/operatorprovides the response to the KMC which veri�es it using the trans-port keys and compares its local key database hash (correspondingto the train/RBC) to ensure that it matches the one in the response.If there is a mismatch, the protocol will require the issuance of keysto take place again.

We provide an example issuance protocol for a new train underthe TRAKS scheme in Figure 3.

8.1 ConsiderationsIn TRAKS, revocation is considered to be an exceptionally rareevent, compared to the regular revocation process we see in public-key revocation with certi�cates. In the event that a key becomescompromised on a train, the infrastructure manager would be re-quired to allocate a new ETCS ID to the train in question and providenew keys. For an RBC, the same process would take place, where

ACSAC 2017, December 4–8, 2017, San Juan, PR, USA Richard J. Thomas, Mihai Ordean, Tom Chothia, and Joeri de Ruiter

Train Vendor KMC

kt1,kt2 ← SGen(1λ)

enc(oidt | |kt1 | |kt2,kv1) | | MAC(enc(oidt | |kt1 | |kt2,kv1),kv2)

Generate KMAC-REQ request for oidt

enc(KMAC-REQoidt | |kt1 | |kt2),kv,kmc1) | |MAC(enc(KMAC-REQoidt | |kt1 | |kt2),kv,kmc2))

Process KMAC-REQ from Vendor.kmr idi,oidt ← GEN.KMAC(oidt ,kmr idi,null ),for every relevant RBC i

enc(((rid1,kmr id1,oidt ), … , (ridn,kmr idn,oidt )),kt1) | |MAC(enc(((rid1,kmr id1,oidt ), … , (ridn,kmr idn,oidt )),kt1),kt2)

enc(((rid1,kmr id1,oidt ), … , (ridn,kmr idn,oidt )),kt1) | |MAC(enc(((rid1,kmr id1,oidt ), … , (ridn,kmr idn,oidt )),kt1),kt2)

enc(“KEYS INSTALLED”| |Key DB HASH,kt1) | |MAC(enc(“KEYS INSTALLED”| |Key DB HASH),kt1),kt2)

enc(“KEYS INSTALLED”| |Key DB HASH,kt1) | |MAC(enc(“KEYS INSTALLED”| |Key DB HASH),kt1),kt2)

Figure 5: TRAKS Key Issuance Protocol for a new train t . �e train is responsible for generating its own transport keys beforeencrypting and calculating a MAC using keys kv1 and kv2 respectively. �e payload is submitted to the vendor as part of thekey request to the KMC. �e KMC processes the request, generating the necessary keys, where they are then installed on thetrain. �e train is required to submit a checksum of the key database to ensure that the keys held on the train/RBC matchwhat the KMC asserts should be installed. A similar process is run for new RBCs, as described in Section 8.

an engineer interacting with the a�ected unit is an acceptable over-head. �at said, the current ERTMS speci�cation and guidance fromNational Standards Bodies, for example RSSB [14] does not recom-mend quantitatively how long keys should be valid for, beyond ‘themost time the key is required’. As part of TRAKS, we recommend aregular rekeying interval to prevent a�acks, such as those presentedin [4]. Rekeying can be performed during maintenance intervals,with trains at depots to ensure safe installation of keying material.We do not see the blacklist, maintained and distributed by the KMC,to impose considerable burdens on infrastructure managers andtrain owners.

For RBCs, which are already connected to a network to allowintercommunication with other RBCs, it may be possible to movethe RBCs to communicate with the KMC online, and at regularintervals, whereas for trains, the maintenance would happen o�ineat the depot.

9 APPLICATIONS OF TRAKS IN A SECUREARCHITECTURE

In this section, we present applications where TRAKS may be usedand the considerations when implementing the scheme. We demon-strate how TRAKS may be used in EuroRadio, before showinghow EuroBalises, which are trusted for location and speed/trackpro�le data can be protected with a cryptographic MAC, beforehighlighting other applications outside of ERTMS.

9.1 EuroRadio MAC KeyingIn this subsection, we will discuss the implementation considera-tions of the TRAKS scheme for the EuroRadio handshake protocol.

We require the use of a pseudo-random function, PRF , in theTRAKS framework. For a National Infrastructure Manager, thiscould be an HMAC function, such as HMAC-SHA-256, which is be-lieved to be post-quantum secure. For key management operations,where the keys are in transit, a similar keying mechanism should beused between the KMC and approved organisations. For examplewith vendors and train operators, to ensure that the security of thekeying material is never compromised. Given the current schemerelies on 3DES keys, a subset of the 256-bit output can be used asthe 3DES key, until support for 256-bit keys is implemented.

We also recommend the use of a blacklist, which should be signedor have an accompanying MAC which can be retrieved on a regularbasis, to ensure that, in the event of revocation, RBCs and trains donot interact with possibly compromised infrastructure.

9.2 EuroBalise Payload SecurityCurrently, the data held on EuroBalises is protected with a CRC [21],which allows an a�acker to de�ne their own balise payload, in-creasing line speeds or creating a ‘virtual’ block which overlaystwo sets of balise groups (BGs). �is data is trusted by the train tobe accurate and is used in position reports to the RBC, which inturn is used for the safe supervision of the network.

TRAKS: A Universal Key Management Scheme for ERTMS ACSAC 2017, December 4–8, 2017, San Juan, PR, USA

Generally, ‘read-o�’ components are secure in providing broad-cast information in plaintext when used in conjunction with averi�ed component. However, when used as part of a trusted net-work to make safety-critical decisions, it is not acceptable to haveonly add a checksum to the data. �is only provides error-detectionand does not defend against an a�acker who is capable of either ma-nipulating or emulating a balise, as they can be arbitrarily forged.�erefore, the payloads on the balises should be authenticated.Balise payloads, with the exception of ETCS Level 1 deployments,are static in data, which can therefore be signed or be accompaniedwith a MAC. We use the TRAKS framework to de�ne a Key Man-agement Scheme, which provides a ‘per-balise’ MAC Key, ensuringthat the compromise of one balise-speci�c key does not enable thea�acker to impersonate other balises in the network.

At the root of TRAKS, the Key Management Centre generates anational balise secret, e.g. for Great Britain, kmGB , which is usedto generate all subkeys which are linked to the NID C of the line.�is produces kmNID C,bдid which is installed on all OBUs allowedto operate within a given NID C. When the train passses over thebalise and reads the telegrams from it, it can derive the MAC Keyusing the Balise Group ID, and verify the MAC. In the case the MACfails veri�cation, a ‘violation’ is recorded, so that the infrastructuremanager can a�end to the faulty balise. In the event that the trainis at fault, recording erroneous ‘violations’, it is expected that issueis referred to the vendor for reactive maintenance.

Under this scheme, we add the requirement that all OBU unitsmust have a trusted execution environment installed, for exampleIntel SGX and ARM TrustZone. �is is necessary to prevent thatthe set of kmNID C,bдid keys can be extracted from the OBU and toensure only authorised cryptographic operations can be performedusing the keys. Balises do not have the kmNID C,bдid key installedon them at any time - the key is made available to the encodingunits during maintenance periods, with the balise only containingthe (plaintext, MAC) payload. No changes are required to the balise,as it does not carry out any computation.

While balise keys are always derived and never stored on anysystem, balise-speci�c keys provide defence in depth. �is ensuresthat the compromise of one balise MAC does not compromise otherbalises, as the MAC key is speci�c to that particular balise. It shouldbe noted, however, that EuroBalises can still be moved.

An alternative solution would be to implement a protocol wherethe train and balises are able to communicate in which MAC arecomputed in real-time. However, when considering the speed con-siderations at which balises are read, in excess of 300km/h, wherethree ‘telegrams’ from the balise group must be successfully read,implementing such a protocol would be di�cult and an interactiveauthentication protocol would be infeasible. �erefore, providing astatic payload with a MAC is far more e�cient and less prone toerrors in transmission. Assuming reading an unauthenticated/CRC-encoded 1023-bit balise message takes t milliseconds to read andprocess (e.g. 1.81ms for a train running at 500km/h, with no readfailures, average conditions and data rates), adding TRAKS authen-tication would only increase this time by 6%. �is e�ectively meansthat the impact is 1.92ms or 26.6cm by the time the train has read,derived the balise MAC key, and validated the MAC, which can befurther mitigated with be�er hardware. �at said, the bene�ts areconsiderable with minimal cost in time.

Currently, the CRC as well as other data used in integrity veri�-cation uses 110 bits of the total balise payload. If we replace thisdata with a 128-bit MAC, the available balise payload is reducedby only 18 bits. For the majority of balises ,this should not pose aproblem, as Packet 44, used to send non-ERTMS messages from abalise to the train, is de�ned by the infrastructure manager, andtypically will not �ll all 1023 bits of balise payload.

9.3 ICS PLC Environments�e TRAKS framework may also be applied to other ICS environ-ments, where a number of programmable logic controllers (PLC)devices in ICS/SCADA environments may communicate with eachother and the communication protocol is not protected. �is is, forexample, the case with MODBUS/PROFIBUS. �is lack of protec-tion allows an a�acker to carry out a man-in-the-middle a�ack anda�ect the operation of the system, potentially pu�ing it into anunsafe situation.

A simple solution to this a�ack vector is to apply MACs to eachmessage sent by a PLC. However, for an ICS owner, pu�ing one keyacross the network achieves li�le security, where the keys couldbe extracted. �erefore, a partitioning of the system would allowspeci�c ‘zones’ of control to be drawn, analogous to the NID Cvariable that is used in ERTMS to de�ne regions and lines. Withthis, a centralised key could be de�ned per zone and installed ontothe appropriate hardware. A derivation step is then included onthe controllers which would allow a per-device key to be used inthe actual communications.

10 CONCLUSIONIn this paper, we have presented a new key management solutionwhich may be applied to a number of industrial control system en-vironments. Using proven cryptographic techniques, we achieve aninteroperable, backwards-compatible solution that can be used inERTMS. It reduces management overheads for National Infrastruc-ture Managers, and delivers post-quantum security. �is schemehas further applications beyond EuroRadio, including EuroBalises,to ensure safety through security. By applying a partitioned systemprinciple to ERTMS, we have been able to develop a key distri-bution scheme which maintains the same level of security in thesystem, whilst delivering signi�cant bene�ts to the ICS owners andoperators.

Acknowledgements. We would like to thank the UK’s NationalCyber Security Centre (NCSC) and the Birmingham Centre for RailResearch and Education (BCRRE) for their helpful discussion ontechnical and standardisation aspects. Funding for this paper wasprovided by the UK’s Centre for the Protection of National Infras-tructure (CPNI) and Engineering and Physical Sciences ResearchCouncil (EPSRC) via the SCEPTICS: A SystematiC Evaluation Pro-cess for �reats to Industrial Control Systems project.

ACSAC 2017, December 4–8, 2017, San Juan, PR, USA Richard J. Thomas, Mihai Ordean, Tom Chothia, and Joeri de Ruiter

REFERENCES[1] banedanmark. 2011. Fjernbane Infrastructure Easst/West BAFO Tender Document

/ Appendix 3.1 – A� 11 Online Key Management Concept. Technical Report.Banedanmark. h�p://uk.bane.dk/db/�larkiv/9893/SP-12-041120-103.0111App 3.1 A�achment 11.docx

[2] GP Biswas. 2008. Di�e-Hellman technique: extended to multiple two-party keysand one multi-party key. IET Information Security 2, 1 (2008), 12–18.

[3] David Brandenburg, Erick Grunberger, and Manfred Grandits. 2010. E�ec-tive ETCS Key Management with KEY.connect. Technical Report. SIGNAL +DRAHT. h�p://www.tuev-sued.de/uploads/images/1347442379238610830293/article-keyconnect.pdf

[4] Tom Chothia, Mihai Ordean, Joeri de Ruiter, and Richard J. �omas. 2017. AnA�ack Against Message Authentication in the ERTMS Train to Trackside Com-munication Protocols. In Proceedings of the 2017 ACM on Asia Conference onComputer and Communications Security (ASIA CCS ’17). ACM, New York, NY,USA, 743–756. h�ps://doi.org/10.1145/3052973.3053027

[5] ERA. 2015. Assignment of Values to ETCS Variables–v1.21. Technical Report. Euro-pean Union Agency for Railways. h�p://www.era.europa.eu/Document-Register/Documents/ERA ERTMS 040001 v1.21.pdf

[6] ERA. 2015. SUBSET-026: System Requirements Speci�cation, version 3.5.0. Techni-cal Report. European Union Agency for Railways. h�p://www.era.europa.eu/Document-Register/Documents/SUBSET-026%20v350.zip

[7] Shailendra Fuloria, Ross Anderson, Fernando Alvarez, and Kevin McGrath. 2011.Key management for substations: Symmetric keys, public keys or no keys?. InPower Systems Conference and Exposition (PSCE), 2011 IEEE/PES. IEEE, 1–6.

[8] Shailendra Fuloria, Ross Anderson, Kevin McGrath, Kai Hansen, and FernandoAlvarez. 2010. �e protection of substation communications. In Proceedings ofSCADA Security Scienti�c Symposium.

[9] GSM-R Functional Group. 2014. EIRENE System Requirements Speci�cation, ver-sion 15.4.0. Technical Report. European Union Agency for Railways. h�p://www.era.europa.eu/Document-Register/Documents/P0028D004.3r0.5-15.4.0.pdf

[10] Ra�ullah Khan, Peter Maynard, Kieran McLaughlin, David Laverty, and SakirSezer. 2016. �reat Analysis of BlackEnergy Malware for Synchrophasor basedReal-time Control and Monitoring in Smart Grid. In 4th Int’l Symposium ICS &SCADA Cyber Security Research. BCS. 53–63.

[11] Kenji Koyama and Kazuo Ohta. 1987. Identity-based conference key distributionsystems. In Conference on the �eory and Application of Cryptographic Techniques.Springer, 175–184.

[12] Florent Pepin and Maria Grazia Viglio�i. 2016. Risk Assessment of the 3Des inERTMS. Springer International Publishing, Cham, 79–92. h�ps://doi.org/10.1007/978-3-319-33951-1 6

[13] Prorail. 2012. Gebruiksvoorschri� – ERTMS Key Management. Technical Re-port. Prorail. h�ps://www.prorail.nl/sites/default/�les/gebruiksvoorschri� ectskeymanagement.pdf

[14] RSSB. 2017. Rail Industry Standard RIS-0743-CCS – ERTMS Key Management.Technical Report. h�ps://www.rssb.co.uk/rgs/standards/RIS-0743-CCS%20Iss1.pdf

[15] Wen-Guey Tzeng and Zhi-Jia Tzeng. 2000. Round-e�cient conference keyagreement protocols with provable security. In International Conference on the�eory and Application of Cryptology and Information Security. Springer, 614–627.

[16] UIC. 2015. UIC ERTMS Projects - UIC. (2015). h�p://www.uic.org/spip.php?article383

[17] UNISIG. 2012. SUBSET-038 - O�-line Key Management FIS, version 3.0.0. Techni-cal Report. European Union Agency for Railways. h�p://www.era.europa.eu/Document-Register/Documents/Set-2-Index011-SUBSET-038%20v300.pdf

[18] UNISIG. 2015. SUBSET-037 - EuroRadio FIS, version 3.2.0. Technical Report. Euro-pean Union Agency for Railways. h�p://www.era.europa.eu/Document-Register/Documents/SUBSET-037%20v320.pdf

[19] UNISIG. 2015. SUBSET-114 - KMC-ETCS Entity O�-line KM FIS, version 1.1.0.Technical Report. European Union Agency for Railways. h�p://www.era.europa.eu/Document-Register/Documents/Set-2-Index079-SUBSET-114%20v100.pdf

[20] UNISIG. 2015. SUBSET-137 - KMC-ETCS Entity On-line KM FIS, version 1.0.0.Technical Report. European Union Agency for Railways. h�p://www.era.europa.eu/Document-Register/Documents/SUBSET-137%20v100.pdf

[21] UNISIG. 2016. SUBSET-036 - FFFIS for Eurobalise, version 3.1.0. TechnicalReport. European Union Agency for Railways. h�p://www.era.europa.eu/Document-Register/Documents/SUBSET-036%20v310.pdf