Developing a Framework to Address Performance ...

Proceedings of the 2012 Joint Rail Conference JRC2012 April 17-19, 2012, Philadelphia, Pennsylvania, USA

JRC2012-74113

DEVELOPING A FRAMEWORK TO ADDRESS PERFORMANCE AND SECURITY PROTOCOL CONCERNS IN IDENTITY MANAGEMENT FOR INTEROPERABLE POSITIVE TRAIN CONTROL SYSTEMS Damindra S. Bandara George Mason University Fairfax, Virginia, USA

Rajni Goel Howard University Washington, DC, USA

André B. Bondi Siemens Corporation, Corporate Research and Technology Princeton, New Jersey, USA

Nalin Pilapitiya Howard University Washington, DC, USA

ABSTRACT The timely delivery, correctness, integrity, and authenticity of signaling messages sent to trains running under Positive Train Control (PTC) are necessary to ensure safe train operations and to prevent the insertion of malicious messages or the alteration of authentic ones in transit in train control traffic. Mutual authentication of trains and messages must occur when a train enters a zone under PTC from dark territory, when a train moves from one railroad company’s network to another’s, when a train communicates with a Wayside Interface Unit, or when it communicates with the head of a work crew on the railroad line. We describe concerns about performance requirements and protocol security related to this process, and develop a framework for defining use cases, performance models, and secure methods to meet them.

Duminda Wijesekera George Mason University Fairfax, Virginia, USA

INTRODUCTION Positive Train Control (PTC) is a system for automatically enforcing movement and speed restrictions. It is overlaid on existing signaling and track control systems. In the USA, its complete implementation by the end of 2015 has been mandated by the Railroad Security Act of 2008 on railroad lines carrying more than specified volumes of passenger traffic or freight traffic. The corresponding requirements are mandated by subpart H and subpart I of Title 49 Code of Federal Regulations (CFR) Part 236.. To prevent trains from causing accidents by passing signals at DANGER or by exceeding speed restrictions, control messages must be passed to trains in a timely manner. Since the default action for a train is to stop in the absence of instructions to the contrary, it is also essential that messages giving clearance to proceed arrive soon enough to prevent unnecessary braking. Unnecessary braking should be avoided because it incurs energy costs, causes delays, and causes extra wear and tear on the wheels, brakes, and tracks alike [TseBross2009]. An identity management system is needed to enable trains to establish their identities with the railroads that admit them to their networks and to ensure that the trains are receiving correct signal messages from authentic sources. The delivery times of identity management messages could be long enough to cause trains to stop unnecessarily, to cause traffic delays, or to prevent stop signal messages from reaching trains early enough to enable smooth progress to a halt as prescribed by braking

1

Copyright © 2012 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/ on 04/11/2016 Terms of Use: http://www.asme.org/about-asme/terms-of-use

curves [Gropler2008]. In addition, the system must be cryptographically secure enough to enable efficient authentication and prevent message corruption. In this paper, we report on our initial efforts to develop a modeling framework to address security and performance concerns while responding to the requirements of 49 CFR Part 236 Subparts H and I. Our research covers several areas that must be considered to support identity management for PTC, including cryptographic key management for secure protocols, use and misuse cases for PTC identity management, performance requirements and performance modeling, bandwidth for message transfer, and the relationships between them. The goals of our research include (i) identifying the use cases and possible traffic patterns of message exchanges in PTC systems, and (ii) providing a framework for predicting the performance (including throughput and delay characteristics) of PTC systems. After describing related nomenclature, we shall consider each of these areas in turn, and then describe their relationship to one another. OVERVIEW OF PTC COMPONENTS In our study, we focus on three principal types of elements: Back Office Servers (BOS) (located in the dispatch center depicted in Figure 1 below), Wayside Interface Units (WIU), and On-Board Units (OBU). Each is implemented as a computer system whose size and power depend on the complexity of functionalities they have to perform. Each locomotive has an On-Board Unit to monitor signaling messages and enforce speed and movement restrictions. WIUs monitor the status and settings of signals, switches, and hazard control units (such as level crossing gates) along the line, and relay them to locomotives’ On-Board Units in a steady stream. The Back Office Server receives information about train movements and train requests for authority to enter segments from the OBUs via the Wayside Server (an entity that is separate from the WIUs), and uses the WIU to deliver responses to the OBU accordingly. The OBU receives signal and switch status information from the WIU responsible for the track segment it is traversing or about to enter. That information is the basis for the enforcement of speed restrictions and stop signals on which the locomotive driver might have failed to act. The BOS stores train positions and issues signal and switch commands to the WIUs, which forward them to the wayside devices directly. This is illustrated in Figure 1. A system reference architecture for PTC is given in [S9001].

Figure 1: PTC architecture SECURITY PROTOCOL AND USE CASES Use cases represent how one or more actors in the system interact with each other and with the system to fulfill the needs that are to be provided by the system. Use cases gather requirements and specifications of the system. By contrast, misuse cases represent how mal actors interact with the system to violate system operations. Misuse cases can be threats posed by the attackers or user errors [Damodaran2006]. Identifying use and misuse cases in the PTC system is necessary to model it and to identify the security threats and security requirements of the system. The modeling exercise can be used to determine which features to implement, possible threats and errors, and how to overcome identified threats and errors by providing added functionality (such as cryptography, challenge response system etc.) [V-ETMS2010, Whittle2008]. We consider the communication between BOS, OBU and WIU and the use and misuse cases scenarios corresponding to the following: • OBU initialization, • OBU-BOS synchronization, • Train entering a Foreign Territory • WIU communications A message sequence chart of the use and misuse case of a train entering a foreign territory is shown in Figure 2 and Figure 3 respectively. Suppose a train from company-A is going to enter railroad belonging to company-C. When OBU-A requests permission to enter railroad C, BOS-C will request BOS-A to authenticate OBU-A. Then, BOS-C checks for the availability of the requested block. If available, BOS-C will grant movement authority [Hartong2008, pp. 12-13]. The OBU will receive it via WIU it contacted. Then OBU-A will acknowledge that it received movement authority, by sending a ConfirmMovementAuthority message. The corresponding message sequence chart is shown in Figure 2. The message sequence charts in Figure 2 and Figure 3 do not conform to the OBU-BOS communication standard proposed by the American Association of Railroads [S-9352A]. Nevertheless, they serve to illustrate the security concerns issues related to identity management that we seek to address.

2



Figure 2: Use case corresponding to train entering a foreign territory If the number of consecutive failed authentication attempts exceeds the maximum number of consecutive permitted authentication attempts BOS-C will request OBU-A to apply the brakes and stop the train. The corresponding message sequence chart for this misuse case is shown in Figure 3.

Figure 3: Misuse case corresponding to train entering foreign territory IDENTITY MANAGEMENT CONCERNS The authentication and security concerns raised by the above use case must be addressed in compliance with the

requirements for PTC as documented in 49 CFR §236.1005; security is specified by regulation. Although the railroad operating in isolation may provide the security and consequently these safety requirements for its own equipment, an Identity Management System is needed to be able to mediate the admission of trains from other networks. Thus, a train coming from one railroad’s territory to another will need to be able to identify itself to the electronic system of the receiving railroad in order to meet safety requirements stipulated by the regulation. A set of refined requirements (derived from the regulation) for a suitable Identity Management System must detail security policy, credentials, access control, and authorization, allowing direct authorization of security critical actions in a distributed environment. This must all occur early enough to stop or slow a train if necessary, or early enough to avoid stopping by default if the signal the train is approaching is CLEAR. The following is an example of a requirement which would be refined to map to the detailed design of an identity management system: 1. 49 CFR §236.1033 b(3) states that if the cryptographic keys ( required for all wireless communications between the office, wayside, and onboard components in a PTC system providing cryptographic message integrity and authentication) is compromised by unauthorized disclosure of the clear text key, then the key must be revoked. The timing requirements are extracted from 49 CFR Part 236[CFR2011]. These requirements must then be used to create specifications that will allow the PTC system to meet the requirements of 49 CFR Part 236 while performing optimally in the physical world. Moreover, these timing requirements will influence the performance requirements of the elements of the PTC system. The potential models of identity management must avoid security compromises while ensuring that their supporting protocols are efficient enough to meet the stringent timing requirements of PTC systems needed to ensure safe train operation. The detailed design and implementation of a secure Identity Management System must address not only the selection of appropriate standard cryptographic protocols at the device level, but also the selection and management of the keying material, as well as the supporting operational and management infrastructure. The final framework must include details of a distributed authentication and authorization system - detailing the following components: certificates, policy decisions (admission and authentication, initializing cryptographic material, key management, survivability), and distribution protocols, along with the operational implications. These implications include creation of time overhead (affecting the PTC session) due to added challenge-response steps and space overhead due to expanded headers and padding in secure protocols. One issue that is central to safe interoperation of PTCcontrolled trains (such as a V-ETMS controlled train on an AMTRAK track in the Northeastern corridor, which is

3



controlled by ACSES II, and vice-versa) is that trains, wayside devices, and back office systems have to be introduced to each other in a manner that does not allow hackers and other potential mal-actors to impersonate any of these entities (misuses as described above). Potential ways of supporting interoperation that prevent impersonation and yet provide the signals and messages from wayside devices in a timely manner are essential when considering Identity Management models. In order to satisfy 49 CFR §236.1033 “Communications and Security Requirements,” the viable key management protocol that is developed must meet both the government approved standards and also meet the performance standards of the train’s operation on the railway. The key management protocol will be the driving force that determines the key negotiation algorithm, authentication, revocation, and time delay. Moreover, 49 CFR §236.1033(b1) specifies that the PTC system must, “Use an algorithm approved by the National Institute of Standards (NIST) or a similarly recognized and FRA approved standards body.” The choice of the NIST approved algorithm will drive the specifications, the key sizes, and the challenge/response steps. These steps will create an additional overhead that must be accounted for by the PTC system. Amongst these approved standards, OTAR, Kerberos, and PKI were considered for use in a PTC system. During the process for developing a system, following considerations are relevant: 1. Over the Air Rekeying (OTAR) is a NIST-approved standard for PTC development. However, for our performance model, this key management system was put aside because the protocol is proprietary information that is only accessible to people with the proper clearance. 2. Public Key Infrastructure (PKI) was considered for the PTC model. However, PKI, by itself, is not sufficient to implement a complete solution. Although PKI is capable of handling certificates, it does not specify a method to efficiently authenticate and manage clients requesting services in an efficient manner. 3. Kerberos was also considered for the PTC model. Kerberos is capable of efficiently managing clients requesting services with its ticketing protocol. However, Kerberos v5 is designed for closed, wired, systems, and the PTC system is open and wireless. Kerberos v5 has been extended to use the PKI for open wireless systems. The PKI backbone provides the public key support to secure an open system. The Certificate Authorities can manage the public and private keys. PKI can also use key revocation lists to manage revoked or stolen keys. The Kerberos component of the hybrid takes care of the distribution of keys and client management. The Kerberos ticketing system is adapted to a wireless infrastructure by using PKI certificates for authentication and Kerberos symmetric key tickets for subsequent access to servers within the realm [Zhu2006].

Furthermore, Identity Management may also be possibly one of two variations to the hybrid approach of using PKI with Kerberos, Kerberos PKINIT with PKCROSS and Kerberos PKTAPP, are also potential options to consider when selecting the most effective Identity Management system. Figure 4 graphically displays a detailed communication for a public-key Kerberos in a distributed environment. We note that the message sequence chart in Figure 4 does not conform to the AAR standard for OBU-WIU communication [S9352B]. The message set in [S9352B] only addresses communication between the OBU and WIU under the assumption that the HMAC key has not been compromised. The next step is to build performance models that describe message volume and processing loads for each of the identification models. The outputs of the traffic models would then be used as inputs to the performance models to predict whether the performance requirements could be met. The performance prediction models could also be used to help us identify performance bottlenecks and performance weaknesses in the protocols and identification procedures.

Figure 4. Message sequence chart for public‐key based Kerberos for distributed authentication (PKDA)

PERFORMANCE CONCERN: MESSAGE DELAY Our principal concern is that signal messages should be delivered to trains in a timely manner. To formulate performance requirements, we have to specify what we mean by “timely” and identify the throughput demands of the underlying PTC system and its components. The descriptions of the use cases discussed above enable us to quantify the amount

4



of message traffic per train movement. The overall system demand is derived from this information and the number of train movements through a track sector per hour, which in turn is derived from timetables. We map the use cases and deployment scenarios into performance models of each of the PTC components to determine message delivery times and other response times. Frequent train movements place a higher burden on all system components, including any component that is computer-controlled. Let us consider each of these aspects in turn. A message is timely if it is delivered to a train’s On-Board Unit (OBU) early enough to enable, and, if necessary, enforce a required action on the part of the locomotive. Because the default action for a train is to stop or slow down in the absence of an authority, a message permitting the train to proceed should be early enough to prevent the default application of brakes when it is not needed [TseBross2009]. If a train should stop or slow down, the message should arrive early enough to allow the train to respond to a change in the cab display, thus reducing the likelihood of an enforced braking action that would cause a train to slow down and stop abruptly. Enforced actions are undesirable because they cause wear and tear on the brakes and the tracks. In extreme cases, they can cause wheels to be flattened on one side. To predict the performance characteristics of a PTC control system before it is built, we need to understand both the throughput and the delay requirements. As mentioned above, the throughput requirements are driven by timetables and by the events occurring in the use cases that are invoked by each train movement. The delay requirements must be derived from braking curves. Braking curves prescribe the train speed as a function of the distance traveled from the point of brake application [Pachl2002]. Delay requirements are expressed terms of time, and hence are driven by the amount of time it takes a train to reduce speed to a specified level. That level is zero if the train is to be brought to a complete stop. Hence, we must convert the braking curve from the distance domain to the time domain to formulate a requirement for the average and maximum message delivery times. The time available for a train to respond to a command depends on the current distance from the train to the location at which the train must respond to a command, the reaction time of the locomotive driver, the speed at which the train is moving, the time taken for PTC to intervene if the driver has not acted upon a signal, and the shape of the braking curve. Figure 5 shows an example of a braking curve. The points shown on the X axis are as follows: • D is the desired stopping point. It is some distance before the home signal. • E is the actual stopping point. • R is the point at which the signal is shown to be at danger inside the cab. • M is the position of the distance signal mast. The distance signal indicates the aspect of the home signal.

•

A is the point at which the engine driver starts to activate the brakes. • P is the point at which PTC braking is activated if the engine driver has failed to stop the train after passing the distance signal mast M. Relative positions of these points are determined by the anticipated maximum speed of the train and the shape of the braking curve. The shape might be characterized by steepness, convexity, the number of points of inflection, and the area underneath it. The situation as depicted is undesirable, because the stopping point E is beyond the home signal. If a message arrives saying that the signal just after D is CLEAR when the train is between points A and P, PTC could be used to send a corresponding message to the cab and cancel the order to stop. This could result in shorter travel time and energy savings. On the other hand, if the home signal is at danger, the train must engage the corresponding WIU at point M and receive a RESTRICTED message while it is traveling between points M and R so that the brakes can be applied when the train reaches point A. The delay requirement for engagement and message receipt is bounded above by the time taken for the train to travel between M and R. it should be set to a lower value to allow for variations in message passing time and train movement time.

Figure 5: An example of a braking curve. Braking curves depend on train consists and are sometimes proprietary. Therefore, to illustrate the notion of how to formulate a delay requirement from a braking curve, we construct a synthetic braking curve by fitting a quadratic function with the train speed at brake application to 40 mph and 0 mph 6,000 feet down the line with zero acceleration just before brake application and after the train has stopped. The function is shown in Figure 6. The origin corresponds to the brake application point A. Suppose points M and A are 500 feet apart. The allowed time before driver intervention or PTC application of the brakes at A begins at point M. At 40 mph =5280*40/3600 feet per second, the train will take less than10 seconds to reach A. Therefore, the performance requirement for the transmission of a CLEAR or DANGER signal after the train passes M would be less than 9 seconds.

5



To allow for variability, we could set the average delay requirement to approximately 7 seconds, depending on what we know about the standard deviation of the message processing and transfer times.

Train Speed (mph)

Train Speed (mph) 50.0 40.0 30.0 20.0 10.0 0.0 0

2000

4000

6000

Distance (feet) Figure 6. A synthetic braking curve. Using numerical methods [DahlBjork1974], we obtain the train speed as an approximate function of the time since brake application, as shown in Figure 7. It takes about 5 minutes for this particular train to come to a complete stop from 40 mph. This is not uncommon for very long freight trains. If a message must arrive at the OBU before the train has traveled 2,000 feet after the first brake application (when the speed is about 35 mph), it must occur approximately 50 seconds after that brake application at the very latest. In this case, our delay requirement might be set to 30 seconds to allow for an error margin. Train Speed (mph) Train Speed (mph)

50 40 30 20 10 0 0

100

200

300

Cumulative Time (sec) Figure 7. Train speed vs. time for the synthetic braking curve. In Figure 7, we see that the speed has a point of inflection with respect to time. This is to be expected, because the acceleration is zero by construction before the brakes are applied, zero when the train has come to a stop, and negative in between. Because the acceleration is continuous function of time, it must attain a local minimum between the brake application and stopping instances. The local minimum of the acceleration is the point of inflection of the speed.

A comparison of braking curves with initial speeds of 100 mph and 40 mph shows that the predicted braking time is much shorter (~116.3 sec) at the higher speed. This is to be expected, because the faster train has to brake much more abruptly to stop within the same distance. Because the stopping time is so much shorter, the time within which a signal message should be delivered will be much shorter as well, given that the positions of the distance and home signals are the same in both cases. Thus, high-speed passenger traffic will have much more stringent signal handling time requirements than freight traffic. The WIU is a point at which message handling delay could occur. The load on the WIU is determined by the frequency with which trains interact with it and the number of wayside devices (i.e., hazard warning devices, signals, and switches) with which the WIU must interact for every train movement. The larger the number of wayside devices controlled by a WIU and the more frequently trains communicate with it, the higher the delay is likely to be. The number of wayside devices connected to a WIU could be quite large. Alstom has recently announced that Amtrak will acquire 250 WIUs for its Northeast Corridor (NEC) line [Alstom2011]. Since the NEC has multiple parallel tracks in several places between Boston MA and Washington DC, it is clear that there is more than one device per WIU. Guidelines are needed to specify combinations of the maximum number of wayside devices and train movements per hour that a WIU can handle to ensure its message forwarding delays are not so large as to jeopardize safety. We note in passing that the communications protocol between the Wayside, Locomotive, and Office Segments only loosely restricts the number of devices that interface to a WIU. Every train movement through a block involves the following activities: 1. Authentication of the train by the WIU and vice versa, 2. Setting the signal controlling entry to the block to DANGER once the train has entered it, 3. Resetting the signal to CLEAR once the train has left the block or interlocking. 4. Changing the settings of switches for the next train to pass through, if necessary. Each of these steps incurs a particular cost. The cost of authentication depends on the number of steps involved in verifying the identity of the train, which in turn depends on the level of security needed. Without loss of generality, suppose that there are objects . For modeling in the ith of L interlockings, for 1 purposes, we treat a block of track without switches guarded by a signal as an interlocking with only one object. Suppose further that interlocking has trains coming through it in unit time during the peak hour, or the designated peak period of shorter duration (e.g., 5 minutes). Then, the WIU should be interlocking engineered to support authentications and 2 is the number of devices that changes in unit time, where must be changed in the ith interlocking. By “support,” we mean

6



(a) that no resource within the WIU will have more than 50% utilization, including bandwidth in and out, (b) that authentication and interlocking the combination of message passing and processing delays communication delays with signals and the BOS will have a designated average value or less, and that 95% individual delays will be below some chosen upper bound. The load on the PTC system is also influenced by track layout and the frequency of train movements through, into, or out of a sector controlled by a BOS. Additional load on the system, including the associated network bandwidth, occurs because WIUs, OBUs, and BOSs are synchronized via messages transmitted at regular intervals known as heartbeats. Failure to deliver heartbeats soon enough could result in service disruptions, because a missed or delayed heartbeat could signify that corresponding segments are out of order or otherwise not communicating with one another. The timetable describes the frequency of train movements from particular directions, while track maps show how many wayside devices are traversed each time a train goes through an interlocking. Knowing how WIUs are deployed and which devices will be controlled by them will aid in devising guidelines for the loads the WIUs are meant to sustain. PERFORMANCE PREDICTION APPROACH In developing the framework to predict the performance of a PTC system, first we need to identify a straw architecture, straw hardware platforms for the OBU, WIU, BOS, and network elements, together with a straw message mix for each train movement, based on the UML sequence diagrams, such as those in Figure 2 and Figure 3 [Duarte2008]. The straw hardware platforms are postulated simple configurations for each host. Once all of this has been done, a queueing network analysis model can be built to predict component utilizations and approximate response times. The input models might be derived from laboratory benchmarks [HarbMen2001] or be based on “expert intent.” This will help determine whether it is feasible to meet delay requirements under various traffic conditions and assumptions about authentication methods and network protocols. This is the subject of ongoing work, while we formulate the precise tradeoffs between performance and design. DISCUSSION To meet the federal regulations and reduce the risk of malicious interference with train control messages, Positive Train Control must be implemented with secure protocols that ensure message authenticity, while considering the bandwidth limitations. The train control messages must be delivered within restricted amounts of time to ensure safety of operations. Authentication during the setup of communications between a Wayside Interface Unit and an approaching train must occur early enough to permit the delivery of a control message to the train well before the train has to act on it. Thus, the choice of secure protocols and authentication procedures will be

determined not only be security concerns, but also by performance considerations and expectations. Understanding PTC use cases, misuse cases and secure protocol to support identity management is a necessary step to determining the factors that are likely to impede message delivery. In this paper, we have described a series of concerns that must be addressed to make PTC communications secure and timely. Secure communication is needed to prevent malicious actions, while message delivery time requirements are determined by the train’s braking properties. CONCLUSIONS AND NEXT STEPS Thus far, our research has focused on investigating and developing a procedure for identifying how to derive the performance requirements on the individual steps (issuance of temporary ID, key introduction, communication, signal translation, etc.) for each train various interaction models (use cases). The timing requirement may be more stringent if one or more trains are moving quickly; they must be met whether the volume of train movements between carriers is heavy or light. The next step is to build and test performance models that describe message volume and processing loads for each of the identification models. Outputs of the traffic models (track charts and scheduling charts) would then be used as inputs to models to predict whether the performance requirements could be met. The prediction models could also be used to help us identify performance bottlenecks and performance weaknesses in the protocols and identification procedures. The prediction models could take the form of analytical models; i.e., those based on equations and/or algorithms derived from those equations or simulation models that mimic the individual steps of the protocols at rates determined by the traffic models. Different performance models would be derived for different interaction models where necessary. Bottlenecks, foci of overload, and places where buffer overflow is likely would be identified from the outputs of the model, and recommendations about the choice of protocol models made accordingly.

ACKNOWLEDGMENTS AND DISCLAIMERS We would like to acknowledge the work of the ITC PTC committee in drafting the standards documents cited below. We would also like to acknowledge valuable discussions with Daniel Paulish and Michael Smith of Siemens. This material is based upon work supported by the Federal Rail Road Administration under Grant No. FR-TEC-0006-1101-00/20.321. Any opinions, findings, and conclusions or recommendations expressed in this material reflects the views of the authors, who are responsible for the facts and the accuracy of the data presented herein. The contents do not necessarily reflect the official view or policies of the Federal Railroad Administration, the US Department of Transportation, or the United States Government and shall not be used for advertising or product endorsement purposes. Neither the United States Government, nor any of their employees, makes any warranty, express or implied, including the

7



warranties of merchantability and fitness for a particular purpose, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights REFERENCES [Alstom2011] “Amtrak Introduces Alstom PTC Wayside Interface Unit along Northeast Corridor”, http://www.alstom.com/us/products-andservices/transport/usptcmilestones/amtrakWIU2011/. [CFR2011] 49 C.F.R. § 236 (2009) [DahlBjork1974] Dahlquist, G., and Ake Bjork: Numerical Methods, Prentice Hall, 1974. [Damodaran2006] Damodaran, Meledath:, Secure software development using use cases and misuse cases, Issues in Information Systems , Volume VII, No. 1, 2006. [Duarte2008] F. Duarte, W. Hasling, W. Sherman, D. Paulish, R. Leao, E. de Souza e Silva, and V. Cortellessa, Extending Model Transformations in the Performance Domain with a Node Modeling Library. Proc. WOSP 2008, 157-164, 2008. [Gropler2008] Gropler, O.: ETCS braking distances and safety margins (Bremswege und Bremswegsicherheit bei ETCS), ZEV Rail Glasers Annalen, 2008 [HarbMen2001] Harbitter, A. H., and D. A. Menascé, Performance of Public-Key-Enabled Kerberos Authentication in Large Networks, Proc. IEEE Symp. Security and Privacy, pp 170-185, May 2001. [Hartong2008] Mark Hartong, Rajni Goel and Duminda Wijesekera, Trust based secure positive train control

interoperation, J. Transp. Secur. (2008) 1:211–228 DOI 10.1007/s12198-008-0019-7. [Pachl2002] Pachl, Joern, Railway Operations and Control, Mountlake Terrace: VTD Rail Publishing, 2002. [S9001] S9001 ITC – System Reference Architecture, Version 1.4, Interoperable Train Control Architecture Team, August 2011. [S3452A] S-9352A Interoperable Train Control (ITC) OfficeLocomotive Interface Control Document, Version DRAFT 2.6, 11 December 2010. [S9352B] S-9352B Interoperable Train Control (ITC) Wayside Locomotive Interface Control Document, Version 1.0, 10/17/2011. [TseBross2009] Tse, T., and Brosseau, J., Development of an Adaptive Enforcement Braking Algorithm for PTC Systems. FRA Presentation to the TRB, December 2009. File TRB_DEC09 available at http://www.fra.dot.gov. [V-ETMS2010] Vital Electronic Train Management System(VETMS)-Concept of Operations, 24 March 2010, version 1.0. [Whittle2008] Jon Whittle, Duminda Wijesekera, Mark Hartong, "Executable misuse cases for modeling security concerns," Proceedings of the 30th International Conference on Software Engineering (ICSE '08), pp.121130, 2008 [Zhu2006] L. Zhu and B. Tung, Public Key Cryptography for Initial Authentication in Kerberos, Network Working Group, Request for Comments: 4556, 2006.

8

