Security Extensions to ONERA HLA RTI Prototype1 Pierre Bieber Jacques Cazin Pierre Siron Guy Zanon ONERA-CERT Information Modelling and Processing Department 2 av. E. Belin, BP4025 F-31055 TOULOUSE Cedex
[email protected],
[email protected],
[email protected],
[email protected] Keywords: HLA, RTI, distributed architecture, security ABSTRACT: We present security extensions to the RTI prototype developed at ONERA (Office National d'Etudes et de Recherches Aérospatiales). These extensions are aimed at guaranteeing secure interoperation of simulations belonging to various mutually suspicious organizations. The paper describes the design of a security architecture for HLA/RTI and its implementation.
1
Introduction
An expected use of HLA/RTI [1] is to allow simulations developed by various companies to interoperate. But, some firms are reluctant to join an HLA federation because they fear that some confidential data could leak to their competitors. Hence, there is a need for a HLA/RTI that guarantees secure interoperation of simulations belonging to various mutually suspicious organizations. In the first part of the paper, we analyze the various threats to the security of ONERA/CERT implementation of HLA/RTI. We give a set of security objectives that address how the RTI should share data provided by federates belonging to various companies. Obviously, there is not a unique set of security objectives for HLA/RTI because it was designed as a multi-purpose application. In this paper, we restrict ourselves to a particular set of objectives that protects the confidentiality of data that federates regard as private. In the second part, we review various security functions that enforce the security objectives. And we propose a security architecture that assumes that companies will trust a special RTI component to distribute securely messages. The last part describes how we are implementing this security architecture. We propose to extend RTI services and federation descriptions in order to perform security checks on the messages exchanged by the federates.
1
This study was funded by DGA/STTC.
2 2.1
Security Analysis HLA/RTI Prototype Architecture
ONERA/CERT RTI architecture is illustrated by the following figure. A B
FedA1
FedA2
FedB1
libRTI
libRTI
libRTI
RTIA
RTIA
RTIA
RTIG Figure 1: RTI Architecture Each federate process interacts locally with a RTI Ambassador process (RTIA) through the libRTI library. The RTIA processes exchange messages over a network with the RTIG process in order to run the various distributed algorithms associated with RTI services. The architecture is comprehensively described in [2]. In this architecture, we distinguish three kinds of interactions between components: • internal interactions within a process: The federate
•
•
2.2
code calls libRTI functions in order to prepare the communication of service requests to the RTI Ambassador. And conversely, the federate functions are called when messages from the Ambassador are received. local interactions between processes: the federate process uses UNIX domain sockets to communicate with the RTI ambassador process that runs on the same host. global interactions between processes: the Ambassador process uses a TCP (or UDP) socket to communicate with the RTIG process. Hence the RTIG process could be located anywhere on the Internet. Threat Analysis
When a firm builds a simulator of some piece of equipment that it plans to manufacture it certainly includes in the simulator various parameters that are very sensitive. That firm would not want to reveal the value of these simulation parameters in order to protect its know-how. If this firm has to connect its simulator to a distributed simulation it might fear that the secret parameters get known by other firms participating to the simulation. One solution could be to build a new ad-hoc simulator without the sensitive parameters. It is not certain that this can always be done and this does not seem cost-effective to have to build and maintain two simulators for the same equipment. Another solution could be to trust a securityaware HLA/RTI to distribute properly the values of sensitive attributes. In the following, we define the security objectives of such a HLA/RTI. We first review threats to confidentiality of private simulation data.
FedA1
FedB1 3
libRTI
libRTI 2
RTIA
RTIG
RTIA
1 Figure 2: disclosure channels If we consider a federation composed of federates from company A and company B, we can distinguish three information channels that B federates can use to obtain A private information. The first disclosure channel describes attacks directed at interactions between components of the RTI. As these interactions are based on exchanging messages over a
network, subjects from company B might try to observe messages exchanged between the RTIG and a RTI ambassador connected to a company A federate. Similarly, subjects from company B might try to attack the interaction link between a federate and its ambassador. We can distinguish between passive threats where a malicious subject tries to illicitly observe data without sending any messages on the network and active threats where a malicious subject sends messages on the network in order to receive illicit data. The second channel is the leak of information via the RTI. As the RTI services were not specified with confidentiality requirements in mind, a malicious subject could try to use these services in order to gain knowledge about private attributes. Every family of services should be investigated in order to assess whether they are secure. We chose to focus on data transfer services as they provide the usual services to transfer information in the RTI. For example, the RTI could broadcast too widely the value of a private attribute of an object. Other services might also be used to transfer illicit information as timemanagement service (see [3]). We plan to study this family of services in the near future. Finally the third channel is a direct flow of private information. For instance, the code of a federate from company A contains an explicit sending of messages with confidential data to a subject of company B. There might also exist a Trojan horse inside the RTI components used by a federate (libRTI or RTIA) that sends private data in a covert fashion. 2.3
Security Objectives
We associate security objectives with each of the three disclosure channels we have identified. All these objectives are stated in terms of isolation between components of the RTI. By isolation we mean that some subject cannot alter or observe some piece of information. For the first disclosure channel the security objective is that the interactions between a RTIA and the RTIG and between a federate and its ambassador should be isolated from any other component (another federate or RTIA). For the second channel we first have to define what information the RTI is authorised or forbidden to transfer. In a military setting, it would be easy to define a confidentiality policy based on security levels. But, generally speaking, companies do not associate a security level with their information. Nevertheless, companies often have an informal policy that defines what information is to be considered as confidential. For instance, in the context of simulations, objects used by a
fine-grained simulation may be considered as confidential whereas coarser objects might be considered as public. So we define the following objective : RTI services should isolate private information of a company from federates from any another company. For the third channel, we associate a stronger objective in order to be sure that the RTI is the only way federates can gain knowledge about other federates attributes : any federate information should be isolated from any component from another company.
3 3.1
Security Architecture SAIDA Principles
“Security Assurance In Distributed Applications” (SAIDA) is a joint research project of DERA Malvern and ONERA/CERT. Its aim is to study how to secure distributed applications made of Commercial Off The Shelf software components. The major assumption that is made in the project is that we cannot rely on a multi-level secure operating system because no such operating system is available to us. Hence isolation constraints should be enforced by other means (i.e. physical, procedural or software-based protection). HLA/RTI was selected as a case-study for this project because it is an example of a complex distributed application. We plan to use the RTI in order to illustrate our techniques for the development of secure distributed applications. Our goal is not to propose a definitive account on HLA/RTI security. 3.2
Security Functions
We review the functions that could be used to define an architecture that enforces the security objectives described in the previous section. With regard to the first objective (network isolation), the security function needed should build a secure association between the federate and the RTIA, and between the RTIA and the RTIG. This association should guarantee authentication and confidentiality of the communication. Cryptographic protocol is the usual mechanism used to implement secure association.
capsule
capsule
FedA
FedB
libRTI RTIA
RTIG filter
libRTI RTIA
Secure association Figure 3: Security functions The second objective (isolation within the RTI) can be resolved by adding security filters to the RTIA and/or to the RTIG, these filters implementing a security policy. But, any requirement restricting information disclosure might be inconsistent with the HLA rule that states that every federate that subscribed to a class of the Federation Object Model (FOM) should receive all the information on this class. For instance, if we look at the RTI components that perform data transfer using operations RegisterObject and UpdateAttributeValues then, according to the previous HLA rule, there is no way to restrict the set of federates that can receive this data. To limit this disclosure of data, the concept of combined federation was proposed in [4]. A combined federation is made of several federations that are linked to each other by an inter-federation gateway. In our case, we could combine two federations: one for company A and the other for company B. The two federations work with two separate FOMs. Hence, a federate from B is not necessarily informed of all company A object updates. But this approach, relies heavily on inter-federation gateways. As no definition of these gateways was yet endorsed by the DMSO, we felt that it would be better to consider that there is a unique federation. We propose to extend the FOM with security attributes. Each class, attribute and federate is associated with a security domain. The RTI will “filter” the messages according to the security domains of the object and of the federate. Filters could range from a lax filter that would let the message unchanged to a rigid filter that would erase any message. For instance, the lax filter could be used to control messages exchanged by federates with the same security domain. Whereas, the rigid filter could be used to erase requests, such as subscribe to a class, whenever the security domains of the class and of the requesting federate are different. In that case, in accordance with HLA rule, any federate should be informed of the updates on any object belonging to a class it subscribed to, but it may not subscribe to any class in
the FOM. We could rely on physical encapsulation to enforce the third objective (isolation from other components). For instance, we could run on separate machines the federate processes from company A and company B. But of course, the federates process should interact with the RTIG. Software encapsulation of the federates could be used to forbid direct access to the network and to ensure that all the communications are made via the RTI. This objective cannot be met when the network is not totally dedicated to the simulation. A federate could access to a remote database for example. This communication channel is legal but it does go through the RTI. In this case, we cannot require that access to be cut. But, the company operating such a federate could be asked to secure the communications with the database. 3.3
require to change the existing architecture of ONERA HLA/RTI prototype. 3.4
Related Architecture Proposals
Several security architectures for HLA were defined in [4,5]. They range from short-term to long-term solutions according to the availability of the secure infrastructure. In the short-term architecture, HLA works at ``system high'', i.e. every federates, RTI processes and networks are supposed to handle data at a unique security level. In such a system every user is supposed to be authorised to observe objects of the highest security level. This architecture can be implemented now because it does not require any security functions from the infrastructure. In this framework, security objectives would be related to users (authentication, clearance,...) rather than related to entities of the computer system.
The Trusted Third Party Architecture
In a multi-company simulation context, we assume that each participating company uses the same implementation of the RTI. It can use the RTIG and RTIA processes developed by ONERA/CERT and the libRTI library could be provided to each company so that it can develop its federate processes. A company may trust the federate processes it has written to behave correctly with respect to security concerns. It might also trust some components of the RTI. But a company would certainly not trust federate components developed by other companies. The architecture we consider has a unique RTIG component that manages every communication from federates of one company to another. As the RTIG is unique, it also controls the communications between federates of the same company. In such an architecture, companies have total control over their federates and associated RTIA processes. It is a company responsibility to encapsulate these components and to establish a secure association with the RTIG. Sanitization filters are performed by the RTIG process. Hence companies should trust the RTIG to apply correctly the filters. We call this architecture, the Trusted Third Party (TTP) architecture. We suppose that the RTIG component is under the control of a third party that is not in competition with the companies owning the federates. For instance, this third party could be a public organization running a simulation facility. The major advantage of this architecture is that it does not
The mid-term architecture would allow simulations running at several security level to interoperate. For each security domain, federates running at that level are grouped together on a dedicated local area network. Two federates running at the same level can use a dedicated RTI to exchange information. When a federate needs to exchange information with another federate running at a different level, it should contact a guard that controls outgoing messages. A trusted agent enables the various mono-level RTIs to perform consistent data-transfers and consistent time-management. As the federates and the RTIs are mono-level the only security functions that should be developed in order to implement this architecture are the guards and the trusted agent. The long-term architecture is based on a multi-level distributed operating system such as Trusted Mach. In this architecture, federates could handle data at several levels, there would be no need for security guards. The TTP architecture is clearly related to the mid-term architecture with the RTIG playing the role of both the guard and the trusted agent.
4
Implementation Techniques
We are currently implementing the TTP security architecture. In this last section we describe the various mechanisms we selected to implement the security functions.
FedA1 libRTI
FedA2
FedB
RTIA
libRTI
libRTI
As the SMAC local network is operated by the trusted third party, protecting local communications with cryptographic functions does not seem compulsory.
G S S
RTIA
RTIA
4.2
SMAC RTIG + filter Figure 4: TTP security architecture 4.1
We can easily take advantage of the SMAC protocol to implement the TTP Local area network. Each company is associated with a level and the “lift” machine is the machine that hosts the RTIG process.
Capsule Implementation
At the core of the TTP architecture is a local area network operated by the trusted third party. The network is composed of various machines connected locally or remotely. One of the locally connected machines contains the RTIG process. Companies are free to connect locally or remotely the machines hosting their federates. But each machine should only host federates of the same company. There is no communication between company machines except communications that are mediated and authorised by the RTIG. We selected SMAC (Secure Medium Access Control) protocol [6] to build this secure simulation LAN. Following SMAC principles, medium interface devices, integrating a set of hardware and software resources, are added to each host and constitute the local Security SubSystems (SSS). This local SSS controls accesses to the medium and exchange security data. The whole network security is based on a consistent and synchronous functioning for the local SSS. We can view the global behaviour of the system as a temporal multiplexing of the medium by security levels with strict isolation between levels. A centralised security station ensures this property by managing and driving the SSS devices with a security protocol. Communications between different levels use a special trusted host that can receive and send messages at any level. This host acts as a lift by receiving messages at one level and, if allowed by the security policy, transmitting the message at the required level.
Filter Implementation
The description of the federation (FOM) must be completed to include security domains. For the sake of simplicity, we chose to associate security domains with classes rather than with attributes. Security domains we have considered include PrivateX where X is the name of a company and Public. Security domains may be organised hierarchically. For instance, security domain Public is dominated by security domain PrivateA. Inheritance links between classes should be consistent with that hierarchy : the security domain of a class should dominate or be equal to the security domain of its parent class. The extension to RTI services is very limited. We propose to add security domain filters for the publication and subscription services (messages PublishObjectClass, PublishInteractionClass, SubscribeObjectClass and SubscribeInteractionClass). These messages are erased whenever the security domain of the requesting federate does not dominate and is not equal to the security domain of the requested class. As the RTIG transmits UpdateAttributeValue messages only to authorised subscriber RTIA, a federate from one company will never receive ReflectAttributeValue messages for a private object of another company. 4.3
Secure association implementation
To secure communication between remote federates and the RTIG we use the Generic Security Services Application Program Interface (GSS-API) [7]. This interface hides from its callers the details of the specific underlying security mechanism, leading to better application portability, and moving generally in the direction of a better interworking capability. The GSS-API also completely separates the choice of security mechanism (Kerberos, DCE, Sesame, etc) from the choice of communications protocol. A GSS-API implementation is viable across virtually any communications method. GSS-API is an Internet and X/Open standard.
GSS-API was integrated to the RTIA and RTIG processes to secure their communication. Hence, there is no need to modify the federate code if it is moved from a remote machine to a local machine (or conversely).
5
Conclusion
Finally, we review the three identified threats related to confidentiality : Channel 1 (network listening): The SMAC protocol forbids the direct listening of the network by a malicious federate connected locally. The cryptographic tools complete SMAC when the federate is connected remotely. Channel 2 (leak of information via the RTI): We extend the federation description with security domains and we add access control mechanisms in the RTIG. In particular updated attributes are only routed to authorised and authenticated federates. Channel 3 (leakage inside the federate and Trojan horse): This threat is countered by the allocation of federates of different domains on different machines. The SMAC network completes the isolation. In the future we plan to use software based isolation such as static analysis of programs [8] in order to encapsulate components such as the libRTI library. We plan to have completed the implementation of the TTP security architecture at the end of 1998. We are beginning the implementation of a simulation application that will use and demonstrate the ONERA HLA/RTI prototype security extensions.
6
References
[1] Department of Defense, "High Level Architecture Interface Specification, Version 1.3 Draft 7", January 1998. [2] P. Siron, "Design and Implementation of a HLA RTI Prototype at ONERA", submitted to the Fall Simulation Interoperability Workshop, 1998. [3] P. Amman, S. Jajodia, “A Time Stamp Ordering Algorithm For Secure Single Version Multi-level Databases”, 5th IFIP Working Conference on Database Security, 1991. [4]
J. Filsinger, “HLA Secure Combined Federation Architecture (Part One)”, Technical report Trusted Information Systems, 1996.
[5] J. Filsinger, H.O. Lubbes “System Security Approach for the HLA”, 14th Workshop on Standards for Interoperability of Distributed Simulation (Winter),1996. [6] B. d’Ausbourg, P. Siron, “A Secure Medium Access Control Protocol: Security versus Performances”, European Symposium On Research In Computer Security (ESORICS94), 1994. [7] J. Linn, “Generic Security Service Application Programming Interface”, Internet RFC 2078, January 1997.. [8] J. Cazin, P. Girard, C. O'Halloran, C. Sennett, "Formal validation of software for secure systems", in Anglo french workshop on formal methods, modelling and simulation for system engineering, 1995.
Author Biographies PIERRE BIEBER is a Research Engineer at ONERA. He is a member of the Design and Validation of Computer Systems unit. He works on computer security. JACQUES CAZIN is a Research Engineer at ONERA. He heads the Design and Validation of Computer Systems unit. He works on software validation techniques. PIERRE SIRON is a Research Engineer at ONERA. He is a member of the Design and Validation of Computer Systems unit. He works on parallel and distributed systems and computer security. GUY ZANON is a Research Engineer at ONERA. He is a member of the Modelling and Requirement Engineering unit. He has been working on Distributed Interactive Simulation for the past four years.
