Blockchain‐enabled balise data security for train control system

IET BlockchainEarly View INDUSTRY ARTICLEOpen Access Blockchain-enabled balise data security for train control system Ganesan Muniandi, Corresponding Author m.ganesan@alstomgroup.com orcid.org/0000-0003-4681-0167 Digital & Integrated Systems Technology Centre, ALSTOM Transport India Limited, Bengaluru, India Correspondence Ganesan Muniandi, 10th Floor, Block B, ITC GREEN CENTRE, Dodda Banaswadi Main Road, Jeevanhalli, Bengaluru 560005, India. Email: m.ganesan@alstomgroup.comSearch for more papers by this author Ganesan Muniandi, Corresponding Author m.ganesan@alstomgroup.com orcid.org/0000-0003-4681-0167 Digital & Integrated Systems Technology Centre, ALSTOM Transport India Limited, Bengaluru, India Correspondence Ganesan Muniandi, 10th Floor, Block B, ITC GREEN CENTRE, Dodda Banaswadi Main Road, Jeevanhalli, Bengaluru 560005, India. Email: m.ganesan@alstomgroup.comSearch for more papers by this author First published: 10 May 2021 https://doi.org/10.1049/blc2.12003AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onEmailFacebookTwitterLinked InRedditWechat Abstract The train control system is the railway system's brain, ensuring the train protection and the railway network's operating performance. This control system relies on the balise data received via near-field wireless communication to localize the train and update real-time operating conditions and constraints. The attackers can capture these data through their balise antenna and corrupt them through replay or false data injection attacks. This corrupted data can compromise train safety and jeopardize the entire train fleet operations. To overcome these attacks and to ensure the trustworthiness of balise and data integrity, this study proposes the permissioned blockchain-enabled two novel architectures for data transactions. Besides, each balise is equipped with a novel built-in blockchain cryptography algorithm to create its secret and public keys to provide the key integrity without needing third-party Certification Authority of conventional Public-Key Infrastructure based security systems. Each balise can create the unique signature using a 'nonce' signal sent by the train control system in the static architecture or using a self-generated 'k-once' secret key per train control system in dynamic architecture. Finally, the case studies are carried out to confirm the security sufficiency of the proposed architectures. 1 INTRODUCTION 1.1 Background The railway is considered one of the most important modes of environment-friendly and safer mobility for long-distance interstate and intercity travels. The railway operators worldwide are deploying European Railway Traffic Management System (ERTMS) Level 2 or Level 1 [9] to ensure interoperability, safety, and reliability in train operations. The European Train Control System (ETCS) [10] is the brain and the control, command, and signalling component of the ERTMS. In ETCS Level 1, trackside to onboard ETCS communication is established only through the track-mounted Euro-balises or Euro loops. The balises are used just for the train's precise localization on the railway track in ETCS Level 2. In this case, the trackside to ETCS communication is established by the Radio Block centre through Global System for Mobile Communications—Railway (GSM-R). The main difference between ETCS Level 3 [11] and level 2 is that there is no need for lineside signals or other trackside train detection systems than Euro-balises. In any of the ETCS, ranging from Level 1 to Level 3, Euro-balise [1, 22] is the primary component in which the train control system requires the train's immediate localization. Euro-balise is the passive or active wireless near field communication device that can send its data to ETCS whenever the train passes over it, as shown in Figure 1. The passive balises do not need any external power from the trackside [22]. Balise Transmission Module (BTM) with a balise antenna powers them radiofrequency energy broadcast to power them as shown in Figure 1. Euro-balise data [12] is composed of one or several telegrams. A Euro-balise telegram contains one header and an identified and coherent set of Packets. In ETCS L1, Lineside Electronic Units (LEU) [12] are electronic devices that generate telegrams sent by balises based on the interlocking subsystem's data. The interlocking subsystem is the safety-critical subsystem responsible for preventing trains' conflict movements and sets the railway route for the specific train. In this case, LEU powers the active balise. Irrespective of active or passive balises, the BTM of ETCS extracts the data by processing signals received by the onboard balise antenna. FIGURE 1Open in figure viewer Balise interaction with train control system The balise to ETCS transmission [16] can consist of critical data related to signalling data, control, geographical location, power collection, train target running, the route, permanent speed restrictions, temporary speed restrictions etc. The fixed obstructions such as buffer stops, movement authority, gradients, support to cable and radio in-fill functionality, linking data, other data, etc., are also included. Similarly, the ETCS to balise (Down-link) [16] may consist of the train's makeup, changes to train status that might affect the maximum safe speed, track to train adhesion, the status of the traction control, other data etc. In summary, Euro balise is one of the subsystems intended for use in all of the levels of applications defined within the ERTMS/ETCS called Level 1, Level 2, Level 3, respectively [13, 14, 16]. To ensure the interoperable deployment of balises with any onboard equipment, ETCS defined the detailed specifications in the form of SUBSET-036 [16] on balise telegram. As the transmitted data from the balises can also be the safety-relevant transmission, the balise data should be secured [17]. However, the balise requirements [16] do not specify any explicit security mechanism in the communication link [5]. Due to this shortcoming, any compromised balise data can affect the entire train safety and the train fleet's operational efficiency. The background about the possible security threats and how the proposed novel balise architectures overcome these threats are detailed in Section 1.2. 1.2 Motivation and key contributions ETCS SUBSET-041 defines the accuracy requirement of onboard distance measurement as "for every measured distance's, the accuracy shall be better or equal to ±(5+5% 's') meters" [15, 25]. If the train stops at a different location due to its location uncertainty induced by tampered balise data, it can lead to unnecessary travel time delays [2]. To do this, as shown in Figure 2, the attackers can capture the balise data through their antenna. Then, the attackers can replay or modify this data. Later, they can program this corrupted data into their attacker balise with an attacker balise programming tool. These attacker balises transmit the replayed or modified data to ETCS when placed within ±(5+5% 's') distance from the actual balise as shown in Figure 2, and ETCS will not be able to identify the valid balise. This kind of malicious tampering of the balise transmission in the form of a telegram replaying or replay attack [2, 3] or other forms of attacks such as physical replacement [17] of balises or the tampering of balise data [4, 6, 7, 18], i.e. false data injection attack is possible. The vital trackside infrastructure data, such as permanent or temporary speed restriction of the track section or the gradient data, can be corrupted by the attacker [2]. Such data corruptions can lead to train derailment or collision [5]. They can even produce discomfort to the passengers (for example, injury due to falling from the seat or standing place) [8]. FIGURE 2Open in figure viewer Possible data security-attack scenario For the effective and efficient prevention of replay attacks, the balise data containing the nonce-based random signals were introduced [2, 4]. The authors [5] introduced the one-time usable nonce code transmitted by the Train Control System (TCS) to the balise, and balise generates the variable data to improve security. The message authentication code with a timestamp and uniform crypto-key authentication process can also mitigate balise data attacks [5, 18]. The resilient control algorithm for train stop control applications was proposed in [6, 7, 8]. A TCS can share the security key with route LEUs and synchronize with all the LEUs before the train trip starts [5]. In such a case, both balise and TCS can use symmetric security keys [5, 19, 18]. The major drawback of all these solutions is that the integrity of symmetric security keys can be easily compromised as any entity can remember them. The various cryptographically enabled balises were well studied in the literature [2, 4–8, 18, 19]. Overall, these balise keys are one-time programmable using a dedicated balise data programming tool. The major drawback of these one-time programmable balises is that the key is locked, preventing further changes. Besides, these balises are programmed with the externally created keys that can compromise the key, i.e. they do not have the built-in key generation module. Due to this probably compromised key, it is possible to corrupt the balise data or duplicate the balise, later leading to potential security attacks. Compared to literature references, the motivational questions of this work are, Is it possible to maintain the "secrecy of the balise keys," i.e. key integrity? Is it possible to generate a "unique signature" for each TCS, i.e. data integrity? Is it possible to use a "unique security private key" for each TCS, i.e. identity/trustworthiness? The Public Key Infrastructure (PKI) with security private/public key pairs [34] can be the answer to these questions (b) and (c). In ERTMS [35], Key Management Centre (KMC) performs key management, and PKI supports data signature creation. The KMC can also play a Certification Authority (CA) role in PKI [36]. It can generate valid certificates that will guarantee the ERTMS entities' identity, for example, balise. The major drawback of the inclusion of balise PKI is it can introduce the additional complexity of key management in KMC by considering the tens of thousands of balises deployed across the country compared to few hundred trains. As there is another entity (KMC/PKI) than TCS and balise, the possible compromise of secret keys cannot be ruled out for question (a). Hence, the existing KMC and PKI approach will not solve the problem of balise data security completely. One way to overcome CA's dependency and the question of (a) is to have self-generated keys within balise itself in addition. All the concerns and questions linked with symmetric and asymmetric keys, PKI/CAs, i.e. (a), (b), and (c), can be addressed in an integrated way through the use of blockchain technology [20, 21]. Though the evolution of blockchain [20, 21], for similar applications [28, 29, 30, 31], especially in railway applications [26, 27] is well studied in the literature, still the adaptation into balise data security is the open problem. By considering the possible improvements in the balise data security and the concerns in KPI/CAs, this paper proposes a novel balise blockchain that incorporates the self-generation of balise keys and blockchain-based transactions between balise and TCS. Each balise is equipped with a built-in blockchain cryptography algorithm in this study. The significant advantage of this balise blockchain is the key integrity; the proposed solution does not need an external KMC like CAs to issue certificates [36]. Besides, the secret keys are not distributed. These equivalent certificates are self-generated by the balise themselves, and trust about the balise data has arrived from a network of validating train control systems in this study. Depending on the access right limits, the blockchain can be broadly categorized as permissionless or public, permissioned or private, and hybrid types [32]. In the case of permissionless blockchain, any participant can read, write, and participate in transactions and the consensus without the need for special authentication or authorization. Examples of permissionless blockchains are Bitcoin and Ethereum [32]. The major drawback is that it is more prone to attacks such that the anonymous participants can have several identities to influence the consensus. In the case of permissioned blockchains, the authentication is mandatory for any participant to gain access and to use the system resources; such examples include Multichain, Hyperlegder Fabric, Parity, BigChainDB, InterPlanetary, Corda, and Quorum [32]. Permissioned blockchains have a dedicated hardware module to manage the identity, privacy, and confidentiality within the system [32]. The hybrid blockchain is a combination of the public and private blockchain. In the context of balise and TCS, the permissioned blockchain is appropriate [34] due to (a) the participation of the balise in the data transaction with TCS is based on invite-only, i.e. the registered balises only can participate in the proposed method. Thus, each balise will be identified using the unique pair of private and public keys [34] in the permissioned blockchain. (b) As permissioned blockchains need their nodes to validate transactions, the proposed work involves the TCS to participate in the validation of balise data. Similarly, the built-in balise blockchain cryptography algorithm also must be compliant with the chosen permissioned blockchain. This study adopts one such cryptographic algorithm, i.e. Elliptic Curve Digital Signature Algorithm (ECDSA) [23], which is common in permissioned blockchains such as R3 Corda [39] and Multichain [37]. In Multichain [37], ECDSA ensures that only rightful owners can spend funds. It uses cryptographic elliptic curves (EC) to generate private/public key pairs [38]. The self-generated secure private key [24] is kept within balise and not disclosed to others. It is used only to sign the balise data digitally. A public key is an address of the balise blockchain [24] known to all others who want to access the balise data, i.e. TCS. Hence, the external system receives only the public key. Instead of sending the balise data alone, the proposed method also sends the blockchain-enabled balise data unique digital signature to TCS compared to the traditional way. Now, the problem of frequency of blockchain cryptographic key generation arises, i.e. one-time or for every transaction. This question leads to two novel solution variants such as static and dynamic balise blockchain architectures. As the name suggests, in static architecture, the private security key is generated once and permanently programmed as a 'static private security key.' Still, the unique signature is created based on a 'nonce' signal sent by the train control system. TCS generates a 'nonce signal' for each balise. The significant drawbacks of static architecture are: (a) each TCS needs to have "nonce" algorithm (b) as 'nonce' signal is tele-powered, it needs additional hardware at TCS and processing power at balise (c) TCS has to remember transmitted 'nonce' signal every time for the appropriate extraction of received balise data. The objective of dynamic balise blockchain is to overcome the disadvantages linked with static architecture. The dynamic balise blockchain is based on the balise self-generated one-time usable 'unique key,' i.e. 'k-once' ('key once') for each TCS to produce the unique balise digital signature every time. As there is no 'nonce' signal, the complexity at TCS is reduced relatively compared to static architecture. However, additional interfaces are required for the real-time transmission of keys to TCS. Overall, each balise can create a unique signature either using a 'nonce' signal sent by the train control system or using a self-generated 'k-once' secret key per train control system in the case of static and dynamic architectures respectively. One of the static and dynamic architectures can be chosen for the specific balise deployment by studying the pros and cons. In summary, the study's significant, novel contributions for balise data security in the context of the train control system are: Novel built-in blockchain key generation module inside a balise using a permissioned blockchain cryptographic algorithm, i.e. ECDSA, to maintain the "secrecy of the keys." The proposed solution ensures the integrity of the 'private security key' as these keys are not distributed to TCS when compared to conventional ERTMS. Also, each balise does not rely on third-party CAs, for example, KMC in ERTMS. Novel static balise blockchain architecture generates the "unique signature" for each TCS. The combination of self-generated 'one-time' balise secret private key and 'nonce' per transaction based unique balise signature ensures the balise data integrity and trustworthiness by avoiding replay and false data injection attacks. Novel dynamic balise blockchain architecture which generates the "unique signature" for each TCS. The self-generated balise 'secret private key' per TCS per data transaction ensures the balise data integrity and trustworthiness by avoiding replay and false data injection attacks. As there is no 'nonce' signal, the software and hardware complexities at TCS and balise processing are reduced relatively. 1.3 Paper organization The rest of the paper sections' organization is as follows: Section 2 introduces the static balise blockchain architecture. The dynamic balise blockchain architecture is detailed in Section 3. Sections 4 presents the case studies of the proposed balise blockchain architectures. Furthermore, the MATLAB simulation results are provided. The security analysis for replay, false data injection, and fake balise attacks are detailed in Section 5. Finally, Section 6 concludes the summary of this study. Throughout this paper, the terms such as ETCS and TCS are used invariably to cover both specific European TCS and generic TCS. 2 ARCHITECTURE OF STATIC BALISE BLOCKCHAIN 2.1 Description As the name suggests, in static balise blockchain, the Security private Key (SK or k s ) is fixed and stored permanently internal to balise to maintain its secrecy. As the k s is only known to balise, the k s is much secured compared to conventional methods. Since k s is static or one-time generated, the public key (PK or k p ) of the balise and its programmed data is also constant. With the static stored data and keys, the digital signature of data will also become static. With the static signature, the security attacks are still possible in the form of reply attacks or fake balises. However, the secured keys rule out the false data injection attack. The dynamic signature using well known 'nonce' signal from the TCS [2, 4] over the static balise blockchain mitigates reply attacks or fake balises. In summary, static balise blockchain uses the fixed k s , k p per balise, and for the signature, it adds the dynamic 'nonce' from the TCS to improve the overall data security. As per the proposed architecture, each balise consists of an in-house key generation module that generates a pair ( k s , k p ). Balise signs the transmitted data to TCS using k s . TCS uses the k p to verify the integrity of transmitted balise data. For this, TCS needs to know about the k p of each upcoming balise along its route. The balise sends the k p to Balise Data Programming Tool (BDPT) in the key distribution cycle, as shown in Figure 3. The BDPT acts as the k p distributor between balise and TCS through the traffic management system (TMS). The distribution of k p is managed either through the USB or other equivalent interfaces, as shown in Figure 3. The BDPT programs each balise once with its respective data. FIGURE 3Open in figure viewer Static balise blockchain TMS gets the k p of all the balises under its control, i.e. for the list of station/inter-station areas. TMS maintains the database of k p . Based on the train operator's request, TMS sends the list of k p of balises along the specific train route to TCS. TCS and TMS can use long-range communication to cover the hundreds/thousands of kilometres of the distance. After the reception of k p , TCS stores them into the onboard 'Balise Public key database.' Thanks to static balise blockchain k s and k p , the false data injection is directly ruled out as k s is kept as a secret within balise itself, as one needs to know ks to update the balise data. To overcome the replay attack and fake balises, as shown in Figure 3, the balise receives a 'nonce' modulated tele-powering signal from the TCS through the air gap [2, 4, 5]. It sends back the static data and dynamic signature through the near-field wireless communication link to the TCS. If the data is compromised, it will be rejected by TCS by verifying the dynamic signature. Figure 3 shows all the steps involved in the static balise blockchain in circles. Similarly, Figure 4 shows the steps in a sequence diagram. FIGURE 4Open in figure viewer Sequence diagram for static balise blockchain 2.2 Balise blockchain key distribution—offline The balise static key management steps are performed offline as below: Step-1: The built-in balise key generation module generates the static k s with 32 bytes or 256 bits using any "random number generator." Balise stores encrypted k s in its internal storage. Simultaneously, the PK, k p , with the size of 64 bytes or 512 bits is generated from k s using the Elliptic Curve Digital Signature Algorithm (ECDSA) by the same key generation module of balise. As similar to permissioned blockchain, for example, Multichain [38], ECDSA is currently used in this study. The expression for k p is as, k p = E C D S A k s (1) The significant advantage of using the pair of ( k s , k p ) is that the reverse generation of k s from k p is not possible, i.e. k s ≠ E C D S A k p (2) These two keys are mathematically related to each other so that the data that is digitally signed using k s can be verified using the corresponding k p . Step-2: Each balise sends its k p to Balise Data Programming Tool (BDPT). BDPT stores the k p into a "Balise public key database" (unique balise id, k p ) pair. At the same time, the respective balise data is sent from BDPT to balise for the programming. Later, BDPT interfaces with each balise to collect the static k p while programming the static data. Step-3: The entire database of the 'Balise Public Key Database' or the k p of specific balises can be shared with TMS using USB drives. Step-4: Based on the request from the train operator or the TCS, TMS sends the list of pairs of (balise ID, PK) through long-range communication links for a specific route of the train journey. 2.3 Balise data security—real-time Step-5: During the real-time operation, the TCS generates a "nonce" field (32-bit, i.e. 4-byte) using its "random number generation" function, with the anticipation of each balise. This nonce field is valid for a single transaction between TCS and balise. The nonce can be sent to balise in the form of the modulated tele-powering signal, for example. Step-6: On the reception of the 'nonce' signal, the balise extracts the 'nonce' data. A typical balise dynamic data D d is generated by balise for balise stored data Ds as, D d = D s + n o n c e (3) The secured H A S H ( D d ) is created by balise by calculating the double hash value, for example, SHA-256 (Secure Hash Algorithm-256) of D d . SHA-256 generates an almost-unique 256-bit (32-byte) signature for the security of the data. The secured hash is expressed as, b a l i s e H A S H D d = S H A _ 256 S H A _ 256 D d (4) Then, the hash of the data is signed using k s and is called Dynamic or Digital Signature. balise SIGN ( D d ) = E C D S A _ S i g n ( b a l i s e H A S H ( D d ) , k s ) (5) This b a l i s e S I G N ( D d ) is sent along with a D s by each balise to TCS through the uplink transmission shown in Figure 1. Even though the same D s will be sent; however, the b a l i s e S I G N ( D d ) will be different at every time due to the "nonce" code. Even the attacker can capture this data and signature, as shown in Figure 2, for a possible replay attack; thanks to "nonce," the TCS signature verification will fail since the 'nonce' sent by this train is different from the one in the signature. The confidential k s of balise rules out any modification of the balise signature, preventing the 'false data injection attack.' Step-7: The TCS verifies the "received balise data and its dynamic signature." At first, it recreates the hash of the final dynamic data as, TCS HASH ( D d ) = S H A _ 256 ( S H A _ 256 ( received D s + nonce ) ) (6) Later, it decrypts the signature using k p of the balise, T C S D E C _ H A S H D d = D e c r y p t i o n b a l i s e S I G N D d , k p (7) If the data's calculated hash T C S H A S H ( D d ) and the decrypted hash of data T C S D E C _ H A S H ( D d ) are the same, the data is verified as OK by the TCS. Else, the received balise data is marked as invalid in security attacks and reported back to the TMS for recording purposes. 3 ARCHITECTURE OF DYNAMIC BALISE BLOCKCHAIN 3.1 Description Like static blockchain architecture, in the dynamic balise blockchain architecture also, the k s / k p generation module is kept inside the balise. The significant differences in key distribution are (a) balise transmits the k p to Lineside Electronic Unit (LEU) as shown in Figures 5 and 6. (b) The received k p is forwarded to the Interlocking (IXL) subsystem and is stored into a balise public key database at IXL. (c) IXL manages the distribution of keys to the traffic management system via wireless communication or other equivalent interfaces. Thanks to LEU, it is possible to program the balise with static or dynamic data in real-time. Unlike the static balise blockchain architecture, this dynamic blockchain doesn't need a 'nonce' modulated tele-powering signal from the TCS; instead, it uses a one-time usable 'k-once' k s for a specific train or TCS. TMS gets the 'k-once' k p from IXL for all the balises associated with the train route by providing a station/inter-station IDs list. FIGURE 5Open in figure viewer Components involved in dynamic balise blockchain FIGURE 6Open in figure viewer Dynamic balise blockchain The key distribution from TMS to train is the same as static balise blockchain architecture: (a) TMS maintains the database of k p . (b) Based on the request from the train operator, TMS sends the list of public keys of the list of balises along with the train route. (c) TMS and train can use long-range communication such as GSM-R, 4G, 5G to send the k p of all the balises along the train route. (d) After the reception of k p , ETCS stores the decrypted k p into the onboard 'Balise Public key database.' The following databases or other equivalent are used as shown in Figures 5 and 6. "Balise database" at IXL: stores the list of (unique balise ids). "Balise Public Key database" at IXL/TMS: stores the list of pair of (unique balise ids, k p ) for all the routes "Balise Public Key database (Route)" at TCS: stores the list of pairs of (unique balise ids, k p ) along the specific train route. 3.2 Balise blockchain key distribution—real-time The steps involved in the balise real-time key management are shown in Figure 6 in circles. Similarly, Figure 7 shows the steps in the sequence diagram. FIGURE 7Open in figure viewer Sequence diagram for dynamic balise blockchain Step-1: The train operator or the TCS can request the TMS to send the information related to balises along a specific train route. Then, TMS connects with the list of IXLs along the route. The long-range communication link is used for this exchange. Step-2: Each IXL forwards the request to the respective one or multiple LEUs attached to it. LEU places the "Request new key for a specific TCS" to balise. Step-3: Balise Blockchain uses the same key generation module as static blockchain architecture to generate the pair of ( k s , k p ) using the ECDSA algorithm. The encrypted k s is stored at balise in its internal storage along with the train number. Step-4: Each balise sends its k p to LEU. LEU forwards it to IXL, which will store the keys from all the associated LEUs into the "Balise public key database" as (unique balise id, k p ) pair. Step-5: The entire database of the 'Balise Public Key Database' or the k p of specific balises can be shared with TMS from IXL through wireless communication. Step-6: Based on the request from the train operator or the TCS, TMS sends the list of encrypted pairs of (balise ID, k p ) through long-range communication links for a specific route of the train journey. 3.3 Balise data security—real-time Step-7: TMS informs IXL about the upcoming train with 'train Id.' IXL forwards the