Abstract
Railway systems have evolved considerably in the last years with the adoption of new communication technologies. Aiming to achieve a single European railway network, the European Rail Traffic Management System (ERTMS) emerged in Europe to substitute multiple and noninteroperable national railway communication systems. This system and its security strategies were designed in late 1990s. Recent works have identified vulnerabilities related to integrity, authenticity, availability, and confidentiality. In the context of defining effective countermeasures to mitigate potential vulnerabilities, these vulnerabilities have to be analysed. In this article we introduce a framework that attempts to challenge ERTMS security by evaluating the exploitability of these vulnerabilities.
1. Introduction
The increased needs of transportation in a common market and the lack of interoperability between different railway operational styles in Europe brought up the need for a common rail management system in Europe. In the mid-1980s, the railway community began to search for a common European operation management for railways, called European Rail Traffic Management System (ERTMS) [1]. This solution was created to substitute the heterogeneous national train control landscape scenario.
The ERTMS communications are radio based communications and, thus, wireless systems are used to transmit the movement authorities from the Radio Block Centre (RBC), the entity in charge of managing trains operation, to the trains. Up to now, the wireless communication technology in use is the GSM-R (Global System for Mobile Railways), a specific version of GSM devoted to railway communications.
In order to guarantee the security of the communications, the GSM-R network has to ensure several security properties. On the one hand, the data transmitted should be kept confidential. Moreover, the data should not be changed by an attacker before arriving to the train, to ensure that the train does not receive fake movement authorities. On the other hand, the communication network should be always available for the exchange of needed messages. That is, the network has to ensure the CIA triad: confidentiality, integrity, and availability, which is a widely known model designed to guide information security policies within an organization and represents the most crucial security properties. Since safety is one of the most critical issues to be addressed in the railway context, in this work we focus on train movement authorization message exchanges, so our primary concern is data integrity, even if availability and confidentiality will also be affected.
With the goal of guaranteeing data confidentiality and integrity, different encryption systems are used in the different communication layers. For GSM and also for GSM-R, A5/1 encryption system is used. In addition, the EuroRadio protocol is used to ensure the authenticity and the integrity of the communications. However, it has been proved that both protocols have vulnerabilities [2, 3].
Finally, it should be taken into account that radio jamming devices could jam, block, or interference wireless communications, being able to break the availability of the network.
Apart from the aforementioned lack of security of GSM-R and EuroRadio, it is necessary to point out the evolution of the railway communications in the last years. Although in recent past railway systems were close systems, recently, a new trend of connecting all the elements of the railway network to the Internet is getting relevance. This fact results in exposing railway communications to intrinsic vulnerabilities of Internet and, thus, challenging the security in these scenarios.
Due to the easiness of not fulfilling the security properties defined in the CIA triad, the railway context can be considered a hostile environment and, hence, safety and security are demanded in these networks.
Many efforts have been done to provide safety in the railway scenario [4–6], but security is an emerging demand, and even if different research efforts have also been done for providing secure railway communications [7, 8], there are still several limitations. Moreover, methodologies used in safety analysis, based on probabilistic hazards, are not valid for it. That is, it is not feasible to calculate when an attacker will detect a vulnerability and/or exploit it. Therefore, it is necessary to design a vulnerability detection system, in order to try to avoid the exploitation of those vulnerabilities by means of defining countermeasures.
Our contribution focuses on presenting a framework that will be able to exploit the vulnerabilities of the ERTMS system regarding integrity and authenticity. By means of this framework, it will be possible to know if this attack can be done in real time or not.
The article is organized as follows; in Section 2, we describe the ERTMS protocol and analyse why the railway context is a hostile environment. In Section 3, we analyse the work done relating to this topic. We describe our framework in Section 4, emphasising the benefits of having a framework that attacks different vulnerabilities, describing it, with the limitations that it has, and finally describing the process we will follow to know if the described attack could succeed in real time; then we conclude in Section 5.
2. Overview of ERTMS
The ERTMS is composed of two elements: the European Train Control System (ETCS) for the signalling and the GSM-R for the communication.
2.1. ETCS
The ETCS has a great variety of possible configurations in the signalling equipment used on the existing or new lines. Because of this, ETCS has been conceived with several application levels: 0, NTC (national train control), which is the former STM (specific transmission module), 1, 2, and 3. Next, the different ETCS levels are described.
2.1.1. ETCS Level 0
ETCS level 0 covers the operation of ETCS equipped trains on lines that are not equipped with ETCS or national systems. On this lines, lineside signals are used to give movement authorities to the trains. This level has been defined to ensure the proper transition between ETCS equipped and nonequipped trains. The operation of this level is shown in Figure 1.
2.1.2. ETCS Level NTC
ETCS level NTC is used to run ETCS equipped trains on lines equipped with national train control and speed supervision systems. The train control information that is generated trackside by the national train control system is transmitted to the train via the communication channels of the underlying national system and transformed onboard into information interpretable by ETCS. Depending on the functionality and the configuration of the specific national system installed onboard, the ERTMS/ETCS onboard system may need to be interfaced to it, in order to perform the transitions from/to the national system and/or in order to give access to ERTMS/ETCS onboard resources. This can be achieved through a device called STM. The operation in this level is presented in Figure 2.
2.1.3. ETCS Level 1
In the application ETCS level 1, ETCS is overlaid to the traditional signalling equipment. The train position is detected by the traditional trackside devices, which are linked to the interlocking through the interface Lineside Encoder Unit (LEU). The interlocking is the wayside equipment control. Lineside signals are kept, and data is transmitted to the onboard equipment by means of Eurobalises, which are transponders placed between the rails of the railways. The operation of this level is shown in Figure 3.
2.1.4. ETCS Level 2
In application level 2, GSM-R radio is used to exchange data between the RBC and the trains. EuroRadio protocol is implemented in these communication channels, which is based on a 3DES cryptographic system. Movement authorities to the trains are sent via this channel, and besides a continuous speed supervision is made. For this communication, the Base Transceiver Station (BTS) of the Control Centre communicates with the onboard unit (OBU) of the onboard equipment.
However, the train detection is performed by the trackside equipment, so it is out of the scope of ERTMS/ETCS. In this level, lineside signals could be suppressed. The operation is described in Figure 4.
2.1.5. ETCS Level 3
Finally, the operation level 3 is a radio based train control system. Movement authorities are generated trackside and transmitted to the train via EuroRadio, as in level 2, but in this level, train position is also performed by the trackside RBC. Eurobalises are just used for location referencing. Lineside signals could be suppressed in this level too. The operation is described in Figure 5.
2.2. GSM-R
During the course of their standardization activities, the UNISIG group realized that in order to ensure security of the railways in GSM, certain spectrum bands needed to be allocated. However, GSM could not fulfil all the requirements needed for an efficient railway service, and therefore, some specific functional features were added to the GSM specifications.
The frequencies allocated in Europe for GSM-R are close to the GSM 900 band of the public operators. A 4 MHz spectrum with 19 frequencies is available for these communications.
In order to guarantee the confidentiality of the network, the A5/1 stream cipher is used in GSM (and GSM-R) networks. A stream cipher is a symmetric key cipher where plain-text digits are combined with a key stream.
2.3. Integrity and Authenticity in ERTMS
From the second level ETCS, integrity and authenticity in ERTMS are accomplished with two different security mechanisms: A5/1 for GSM-R and EuroRadio for ETCS. This is the target level of our framework.
Regarding A5/1, even if at the beginning the encryption system was kept in secret, it became public knowledge through leaks and reverse engineering [2]. A number of serious weaknesses in the cipher were identified [10]. Hence, rainbow tables able to decrypt encrypted messages are available on the Internet.
On the other hand, the EuroRadio protocol uses 3DES keys to encrypt the messages [11]. The keys used in the communications (KTRANS, K-KMC, KMAC, and KSMAC) are created by the KMC entity, with the exception of the session key, KSMAC. The KTRANS and K-KMC keys are transport keys used to ensure the safe distribution of the KMAC keys from the KMC to ERTMS entities. This distribution is made off-line; this means it requires personnel to manually deliver the messages.
The KMAC key is used in the session establishment process to negotiate the KSMAC session key between ERTMS entities. Three messages are exchanged between the ERTMS entities in this phase for the authentication of both entities and the key generation. In these messages, and random numbers are sent, which are used for computing the KSMAC key together with the KMAC key. Considering , the three 64-bit DES keys , and are calculated according to the following formulas:where means left and means right, and therefore, and .
The calling entity creates a random number and sends it to the called entity in plain text. Consequently, the entity creates a random number and computes the KSMAC key with both random numbers and the KMAC. Afterwards, the entity sends the created random number and a CBC-MAC code computed with the KSMAC and both random numbers to the entity. Finally, the entity computes the KSMAC key and verifies that it is correct, creating also a CBC-MAC with it, which is sent to the entity, for the complete authentication. Random numbers are exchanged in plain text and, thus, an attacker could save them.
3. Related Work
A lot of research and innovation projects are being completed with the funds of the European Union regarding the cybersecurity in railways. Some of those projects are described in [12].
Different analyses of the ERTMS protocol’s security have also been done. These analyses have pointed out vulnerabilities that the ERTMS cryptographic mechanisms have. A high-level security analysis of ERTMS is made in [13] but does not present the vulnerabilities of the EuroRadio protocol that will be exploited with this framework. Different vulnerabilities of the EuroRadio protocol are pointed out in [3] by performing an analysis of it with the ProVerif tool. These vulnerabilities include, for instance, the ability of including high-priority messages or deletion of messages, since the session establishment process does not use time-stamps and, therefore, these messages could be replicated. In this case, once the session is established, the train does not verify the identity of the RBC anymore, so a vulnerability that could be exploited exists.
Additionally, [14] pointed out that since the distribution of the KMAC key is made off-line and this requires personnel to manually deliver the keys from the KMC to the ERTMS entities, many operators decide to simplify the process by using the same KMAC for large train fleets, amplifying the risk of having an attack. Therefore, if the attack is performed during the session establishment process and the same key is shared between different parties, the whole system could be compromised: an attacker could take the identity of many trains in other session establishments.
On the other hand, [15] pointed out the ability of making a key collision attack to DES and [16] described how a Related-Key Attack (RKA) can be done in ERTMS. A method for doing these two attacks in ERTMS networks is presented in [17] and concludes that the EuroRadio protocol is not secure if large amounts of data and, therefore, long session lengths are used. Thus, the Meet-in-the-Middle attack presented in this article could be more feasible.
However, all of these analyses present vulnerabilities of the protocols used in ERTMS but do not describe how these vulnerabilities could be exploited in order to later find countermeasures for those vulnerabilities. This paper will contribute by presenting a framework that describes how an attack could be performed and figuring out if it is feasible to do it in real time.
4. Proposed Method for Vulnerability Detection
In this section, we present our framework and the method for vulnerability detection describing also its limitations. Finally, the process we will follow to know if an attack could be successful in real time is described.
4.1. Description of the Framework and Limitations
The scenario that this framework will consider is shown in Figure 6. The train is used to connect to the Control Centre in order to receive movement authorities, but first, the train sends a position report to the Control Centre.
In the scenario that we are considering, we force the train to connect to the malicious Control Centre, instead of the real one, but before doing this, we calculate the keys used in the communication between the train and the RBC, with the attacker presented in Figure 7.
Once we have gotten the keys and forced the train to connect to our malicious Control Centre, the position report that the train sends will arrive to the malicious Control Centre. This position report is encrypted by different encryption systems in different levels, but in this point, we have already obtained the keys used in the communication and, therefore, we are able to decrypt the message. Accordingly, we are able to change the position report and send it to the real Control Centre, by taking the identity of the train. The Control Centre receives the fake message and creates a movement authority depending on the position report, which is sent to the train.
The framework we have considered is described in Figure 7. It is composed of the malicious Control Centre, the train, an attacker that will eavesdrop, and the real Control Centre.
The malicious Control Centre is formed by the false RBC, which will be an industrial PC; the OpenBTS (Open Base Transceiver Station) software [18], which is composed of the SIPAuthServe, SMQueue, and Asterix servers; and the USRP N210 Software Defined Radio (SDR) [19].
The OpenBTS is a software-based GSM access point, allowing standard GSM-compatible mobile phones to be used as SIP endpoints in Voice over IP (VoIP) networks. The software controls the transceiver, makes calls, and sends SMSs. The SIPAuthServe is the server that processes SIP register requests that OpenBTS generates when a handset attempts to join the GSM network. It supports three types of authentication:(i)AUTH type 2: unauthenticated. The handset is connected to the OpenBTS network but it does not exist in the register server.(ii)AUTH type 1: cached authentication. The handset is connected to the network and it does exist in the register server, but a simple encryption method based on TMSI is used.(iii)AUTH type 0: full authentication. The SIM card is full authenticated in OpenBTS and, therefore, key is provided to the authentication server and used for the encryption. The is a 128-bit value used to authenticate the SIMs on a GSM mobile network. Each SIM holds a unique and secret Ki assigned by the operator. This authentication method uses proper GSM encryption over the network.
The other servers in OpenBTS are SMQueue and Asterisk, as it has been pointed out before. While the SMQueue processes SIP message requests that OpenBTS generates when a handset sends an SMS, Asterisk is a VoIP switch responsible for handling SIP INVITE requests, establishing the individual logs of the call, and connecting them together [20].
The hardware part of the OpenBTS software is a SDR, USRP N210 in our case, with two GSM antennas to create the network. USRP N210 has been chosen because it supports GSM-R networks and provides high-bandwidth and a high-dynamic range processing capability.
The train in the framework will be simulated with a PC, a Modem, and a programmable SIM card. A programmable SIM card [21] is needed because it is necessary to know the key of the SIM card in order to get the full authentication in OpenBTS and use a GSM encryption over the network. The Modem will be used for being able to connect the PC to the GSM network.
Finally, the attacker that will perform the eavesdropping attack in Figure 7 will be supplied by a TDT-SDR. It is a SDR that captures the traffic in the GSM network together with the Universal Radio Hacker (URH) software. With this SDR we will be able to investigate the wireless protocol, and with the rainbow tables we will be able to get the A5/1 keys used in the communication between the train and the real Control Centre. Thus, since the SIM card we use has a programmable , we will be able to configure the same A5/1 key and, therefore, once we force the train to connect to the malicious Control Centre, we will be able to decrypt the sent messages.
As mentioned before, our framework is composed of OpenBTS and USRP N210 and, therefore, since we use the OpenBTS software, we are able just to create GSM-R and GPRS networks. In the case railway networks evolve to LTE (Long Term Evolution) network, we could use OpenLTE open source project [22], but this project cannot be used in the hardware USRP N210 because of clock incompatibility reasons. Therefore, a sample rate conversion on the host would have to be done in the USRP.
4.2. Specification of the Procedure
The flow chart that this attack follows is described in Figure 8. As can be seen, after installing the framework we are able to get the data from the train to the real Control Centre. This traffic is ciphered by A5/1. Since we have the rainbow tables in the attacker performing the eavesdropping attack, we are able to decrypt the messages on GSM level.
The attack in the EuroRadio protocol will be performed against the DES KSMAC key and will be a Meet-in-the-Middle attack. In this attack, all possible keys are tested.
Since all the messages that are exchanged between the train and the RBC in ERTMS are defined in [11], we assume that we are able to obtain a known plain-text and a cipher-text pair (). The Meet-in-the-Middle (MTM) attack with in ciphers like works as follows:
We build a list containing the pair () for every possible value of , for DES. The values will be gotten by brute force, .
On the other hand, we will obtain values by performing . This operation is performed until the value matches a value that is stored in the table.
In order to be sure that the computed keys are correct, it is possible to obtain another known plain-text and a cipher-text pair () and calculate . If C and are equal, it means the we have find the correct keys.
In triple-DES systems where there are three different keys, the ciphers work following the next relation:
For the Meet-in-the-Middle attack in triple-DES with three different keys, we define , so we just need to apply this for the calculation of .
The calculation of needs operations, because it is a double-application of DES, and on the other hand, the calculation of needs operations. Thus, the attack requires operations.
Afterwards, if we are able to calculate the three keys we are going to obtain , we need to calculate the time we need for performing the whole attack, as Figure 8 describes. With the measured time, we know whether this attack could be performed in real time or not.
In the case the attack can be performed in real time, that is, if all the keys are obtained during the operation of the train, these keys could be used to carry out different attacks that involve the identity theft of the train or the RBC. The attacker, for instance, could pass himself off as the RBC in order to send false movement authorities to the train. On the other hand, the attacker could also falsify the trains position control that is made by the RBC in ERTMS level 3, by sending false position information to the RBC while he impersonates the train. All this false information created by the attacker could involve the collision between different trains.
The results obtained with the framework will help in looking for countermeasures, since the fact of acquiring the keys in real time means A5/1 and 3DES security mechanisms are not strong enough for railway environments. In consequence, those mechanisms should be enforced or changed in order to continue using ERTMS systems in a secure manner. A possible countermeasure for the system could be to update the 3DES security mechanism to a more secure system such as AES, since AES uses larger block sizes and longer keys. Therefore, it will be more costly to perform the attack in real time. In fact, 3DES keys length is 112 or 156 bits, whereas in AES, the length of the keys is variable: 128, 192, or 256 bits. However, the use of AES should be first evaluated by the framework presented in Figure 7.
5. Conclusions and Future Work
Different vulnerabilities in the security mechanisms of the ERTMS system have been described in this article, but even if they are identified, without an attacking framework we do not know whether they are exploitable in practice or not. In consequence, the presented framework will give information about the exploitability of the A5/1 and 3DES security mechanisms and, therefore, will determine if countermeasures should be applied to improve the security of the system or not. Moreover, the resulting information of the framework will constitute the basis of the countermeasures that should be applied to the system.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This research work was supported by the Spanish Government through the SAREMSIG TEC2013-47012-C2-1-R project, Proyectos de I+D+I Retos Investigación 2013, and by the Cyber Security on Rails project with Construcciones Auxiliar de Ferrocarriles, Investigación y Desarrollo, S.L. 2015-2016.