Design and Implementation of a Distributed Interactive Simulation Security Architecture Pierre Bieber, Pierre Siron ONERA-CERT
[email protected],
[email protected] Abstract The paper describes the design and implementation of a security architecture for a HLA/RTI prototype developed at ONERA/CERT. The major security objective is to protect the intellectual property of firms participating to a distributed interactive simulation. We describe the techniques used to implement the security services: controlled subscription lists and secure associations. We report the impact of these new services on the real-time behavior of our distributed interactive simulation environment.
1
Introduction
It is an usual practice for a firm to build a simulation of some piece of equipment that it intends to manufacture. By using the simulations, a firm can gain knowledge of how the equipment will behave, this will help the firm to make design decisions. When various firms are participating to the cooperative design of a system made of several pieces of equipment, it is also important to know how these pieces of equipment will relate with each other. One promising solution is offered by distributed interactive simulation environments (such as the one conforming to the HLA standard [1]) that let a group of simulations to interoperate. Firms generally include in the simulation attributes that they regard as very sensitive. In order to protect their "intellectual property", firms would not want to reveal the value of these simulation attributes. If firms have to connect their simulation to a distributed simulation they might fear that the secret attributes get known by other firms participating to the simulation. So, some firms might be reluctant to join a federation of simulations. To overcome this problem, we propose to develop a securityaware distributed interactive simulation environment that could be trusted to distribute properly the values of sensitive attributes. ONERA/CERT has developed a prototype of HLA/RTI (see [2]) that has been extended with security services (see [3]). In this paper, we describe the
techniques used to implement these security services. Several security architectures can be designed for distributed simulations (see [4]) that address various security requirements. But, when designing such an architecture, one should also have in mind that companies have other requirements such as good real-time performances. One of our goals was to limit the overhead caused by the security controls. For that reason we have focused on an architecture that deals with security within the HLA/RTI implementation. This solution seems more efficient with respect to performances than building a new layer devoted to security on top of simulation services. Furthermore, this approach leads to an architecture with a limited number of trusted software components. This last point is a good feature with respect to security. In the first section, we briefly describe the architecture of CERTI the HLA/RTI prototype we have developed. We also summarize the various security threats that should be addressed. Then, in the following sections, we review the three major security services that we have added to secure CERTI. For each of these security services we detail the threat they counter, how they are implemented and we report what is the impact of these new services on the real-time behavior of CERTI. In the following of the paper we assume that the reader is familiar with HLA/RTI standard (see [5] for an introduction). For instance, we will use federate to denote an individual simulation and federation to denote a group of federates.
2 2.1
Development of CERTI A prototype architecture
A small team at ONERA/CERT produced a RTI prototype implementing a significant subset of HLA services. As in the Familiarization version of the RTI [6], we implemented object-management and timemanagement services but we did not implement data distribution management and ownership management. Our prototype is made of several communicating processes: a local one (RTIA) and a global one (RTIG), and a library
(libRTI) linked with each federate process. The RTI architecture is depicted by Figure 1. Federate 1
Federate 2
Federate 3
libRTI
libRTI
HLA Interface libRTI
2.2
Unix Socket RTIA 1
RTIA 2
RTIA 3 TCP Socket
RTIG
WAN
Figure 1: RTI architecture
Each federate process interacts locally with a RTI Ambassador process (RTIA) through a Unix-domain socket. The RTIA processes exchange messages over the network, in particular with the RTIG process, via TCP (and UDP) sockets, in order to run the various distributed algorithms associated with the RTI services. The RTIA manages message queues and it is always listening to both the federate and the network (the RTIG). The RTI Gateway (RTIG) is a centralization point in the architecture. It manages the creation and destruction of federation executions and the Federation Object Model (FOM) that describes the classes of data that federates can exchange during an execution. The RTIG records the identity of federates willing to publish data belonging to a class of the FOM or subscribe to a class of the FOM. The RTIG uses this information to forward messages in a multicast approach. Federate 1
RTIA
RTIG
forwarded to the RTIG. The RTIG forwards this message to the RTIA of federates that subscribed to this class. If federate 2 has subscribed to this class, its ambassador will send it a RAV message as soon as the delivery condition holds.
RTIA
Federate 2
UAV UAV UAV
RAV
Figure 2: Data-transfer scenario
Figure 2 illustrates the message exchanges involved by the data transfer service UpdateAttributeValues. We suppose that in a previous step, not shown on figure 2, federate 1 informed the federation that it was willing to publish values for an attribute of a class of the FOM. When federate 1 wants to inform other federates of the new value of this attribute, an UAV message (we use UAV as an acronym of UpdateAttributeValues, and RAV refers to ReflectAttributeValues) is sent to the RTIA and
A Security Architecture for CERTI
We are considering a federation where simulations of at least two competing firms (Company A and Company B) interoperate. The RTI should allow various federates of Company A to share private data but it should forbid federates from Company B to learn these data. We use this basic policy to illustrate the security needs that should be addresses by the security architecture for CERTI Of course more complex policies should be taken into account. For instance, it should be possible for federates form Company C to learn Company A private data because the two companies signed a non-disclosure agreement. We assume that the federation is implemented using CERTI. Firms can execute locally the RTIA processes and the libRTI library could be provided to each company so that it can develop its federate processes. We suppose that the RTIG process 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. Firms are generally reluctant to use uncertified software such as the libRTI or RTIA that it did not develop and that has the ability to communicate with its competitors, because this software might leak confidential data. Of course, it would be possible to certify the CERTI components with respect to security evaluation criteria such as the ITSEC or the TCSEC but this would be very expensive. In this situation it is important to know what piece of software a firm is ready to trust to behave correctly with respect to security requirements. A firm may trust the federate processes it has written, it might also trust some components of the RTI such as RTIA or RTIG. But a company would certainly not trust federate components developed by other companies, so we should analyze how a federate from company B could learn private information belonging to another company.
FedA
FedA
FedB
CERTI Figure 3: Multi-company federation
A detailed security analysis was performed, it is described in [3]. We distinguish two channels that B federates can use to obtain A private information. The first disclosure channel is related to attacks directed at the communication links between components of the RTI. For instance, federate B might try to eavesdrop the communication medium between the RTIA process associated with federate A and the RTIG. The second channel is the leak of information via the RTI services. For instance, the RTI could inappropriately forward a private data from federate A to federate B. With regard to the first threat, 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. The second threat can be resolved by adding access controls within the RTI services that should restrict the message exchanged between federates of two companies.
2.3
Related security architectures
Several architectures for multi-level secure HLA federations were defined in [4]. They range from shortterm 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 handle data at a unique security level. In such a system every federate is supposed to be authorised to observe the same data. So this architecture cannot take into account the fact that in a multi-company federation some data are private to company A, other are private to company B. The mid-term architecture would allow simulations running at several security level to interoperate. For each security level, 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. 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. The long-term architecture is based on a multi-level distributed operating system such as Trusted Mach that are not available to us by now. Our architecture is clearly related to the mid-term architecture with the RTIG playing the role of both the guard and the trusted agent.
3 3.1
Publish/subscribe access controls Threat
The threat to be countered is the leak of information via RTI services. As services of HLA/RTI were not specified with confidentiality requirements in mind, a malicious federate could try to use HLA/RTI services in order to gain knowledge about a private attribute. Every family of services should be investigated to assess whether they are secure. So far, we have looked at data-transfer services (declaration management and object management). One insecure scenario occurs when federate B subscribes to an attribute that happens to be regarded as private by company A. The normal behaviour of CERTI will be to forward the private attribute values to federate B. So HLA/RTI data transfer services could be used to disclose confidential data.
3.2
Security Labels
Our goal is to limit data exchanged using HLA/RTI data transfer services such as UpdateAttributeValue / ReflectAttributeValue or SendInteraction / ReceiveInteraction. We propose to associate a security label with objects and federates of the federation. The RTI will control the messages according to the security labels of the object and of the federate. Security labels we have considered include PrivateX where X is the name of a company and Public. As in the multi-level security policy(see []), security labels may be organised hierarchically. For instance, security label Public is dominated by PrivateA or by PrivateB, PrivateA and PrivateB are not comparable. If we want to allow federates from Company C to learn private information from company A, then PrivateC should dominate PrivateA. We chose to associate the same security label with each attribute defined by a class. Inheritance links between classes should be consistent with the security label hierarchy :the security label of attributes defined by a class should dominate or be equal to the security label of attributes defined by its parent class. So the security label of top-level class attributes is generally public otherwise all attributes defined by its descendants would have to be
considered as private. Federates are also associated with a security label, The description of the federation must be completed with Federation Execution Data that include security label information. Figure 4 gives an example of security label association. In this federation, class Aircraft attributes are public whereas sub-class Fighter attributes are regarded as Private by the Mil organization. We consider two federates: one modelling an air traffic controller with security label Public and another one that models a military controller with security label PrivateMil. (fed (objects (class "Aircraft" (sec_level "Public") (attribute "Xposition") (attribute "Yposition") (class "Fighter" (sec_level "PrivateMil") (attribute "WeaponLoad") …))) (federate "AirTrafControl" "Public") (federate "MilControl" "PrivateMil") …) Figure 4: Federation security labels
Our goal is that CERTI allows a possibly malicious Air Traffic Controller federate to observe the current position of a fighter because its attributes Xposition and Yposition are public. CERTI should not authorize this federate to know the current status of the weapon loaded on the fighter because attribute WeaponLoad has security label PrivateMil. We do not require the CERTI to hide to this federate that an attribute called "WeaponLoad" exist in class "Fighter". Attribute values are protected and attribute names are not. With a classical RTI, a malicious Air Traffic Controller would first subscribe to the Fighter class and then the RTI would inform it of the current value of the weapon load.
3.3
Access Control Implementation
Restricting information disclosure within HLA/RTI might be inconsistent with the HLA rule that states that every federate that subscribed to a class of the Federation Object Model should receive all the information on this class. So we have decided to control publication and subscription messages (PublishObjectClass, PublishInteractionClass, SubscribeObjectClass and SubscribeInteractionClass) rather than data-transfer messages (UpdateAttributeValue, ReflectAttributeValue, SendInteraction, ReceiveInteraction). A federate will be authorized to subscribe to a class if its security label dominates or is equal to the security label of the requested class.
This control is performed by the RTIG because, in our architecture, this component is already in charge of recording the publication and subscription. So the RTIG will now check the security labels of the federate and of the class whenever this federate has sent a subscription message for this class. The RTIG will record for each published class a list of authorized subscribers. As the RTIG transmits UpdateAttributeValue messages only to authorized subscriber RTIA, a federate from one company will never receive ReflectAttributeValue messages for a private object of another company because its subscription request are blocked by the security label control in the RTIG. In that case, in accordance with HLA rule, any federate are be informed of the updates on any object belonging to a class it subscribed to, but federates may not subscribe to any class in the FOM. The RTIG is extended with new services that manage the security labels. These services use the Federation Execution Data to associate security labels with federates as they join a federation, and with the classes in the FOM. Furthermore, a function comparing two security labels has been implemented, it is used to check whether a message SubscribeInteractionClass or SubscribeObjectClass should be discarded. In this case, an exception is generated (a conventional HLA/RTI exception as RTIinternalError or an ad-hoc exception as SecurityError).
3.4
Impact on the federation real-time behaviour
As security label controls are only performed during the subscription stage of a federation, they have no influence on the main stage of a federation that generally involves a lot of data-transfer message exchanges. So we have not observed any significant decrease of real-time performances when we added the security label controls. We used a toy federation modelling three aircraft trajectories. The federation is time-coordinated and includes a lot of interactions between the aircraft federates. We could imagine another architecture where we would keep on having a centralized management of subscription in the RTIG. But the RTIG would distribute the list of authorized subscribers to all the RTIA. The RTIA would be in charge of multicasting data-transfer messages. As data-transfer messages would not be forwarded by the RTIG, the number of exchanged messages would be lowered. This architecture would increase the performances of CERTI but it raises new security problems. Every RTIA component should be trusted to perform properly the multicasting, and the transmission of authorized subscribers lists between RTIG and the RTIAs should use a secured channel.
4 4.1
Remote Secure Association Threat
It is likely that firms will prefer that their federates run on hosts that belong to their local area network. These federates have to use a Wide Area Network such as the Internet to exchange messages with the RTIG. So during their transit on the Internet the simulation messages are subject to possible eavesdropping, or even worse blocking, replaying or forging. As the communication between a federate and its RTIA is local to a host, we should only protect the communication link between an RTIA and the RTIG. Our goal is to isolate the messages on this communication link from the actions performed by malicious entities.
4.2
GSS-API Security Services
In a WAN context, protecting communication links can be done by using cryptographic techniques. Rather than developing a new cryptographic protocol, we selected the Generic Security Services Application Programming Interface (GSS-API) [7]. It is an Internet Engineering Task Force standard that defines cryptographic services that are useful to secure a clientserver application. The services include the management of encryption keys, the distribution of shared key or using distributed keys to enforce the confidentiality, authentication or integrity of exchanged messages. The GSS-API interface hides the details of the underlying security mechanism leading to better application portability. In particular, this would allow to change the underlying security mechanism if a security flaw is encountered in it. Several popular security protocols offer a GSS-API interface such as Kerberos [8] or SESAME [9].
4.3
Implementation
We used the GSS-API implementation developed at DTSC in Australia [10]. 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 and no longer needs to protect the communication link between its ambassador and RTIG. As we also wanted to have as little as possible differences between the code of a local federate ambassador and a remote federate ambassador, we developed a Socket class that is used to exchange any messages within CERTI. Ambassadors of remote federate will use sub-class SecureSocket that includes the
appropriate calls to the GSS-API services whereas Ambassadors of local federates will use class Socket. The SecureSocket class hides several steps that should be performed to protect a communication link. Prior to the execution of a federation, every federate ambassador has to contact the Authentication server that will provide the ambassador with credentials (an encryption key tied together with the identity of the federate and a date). When a federate wants to join a federation its RTIA has to contact the RTIG and authenticate itself using the credentials. This involves several exchanges of messages between RTIA and RTIG. If this step succeeds, a security association is created between RTIA and RTIG (a session key is distributed to both processes). Then, RTIA and RTIG can protect the HLA/RTI messages they exchange by using cryptographic functions. For instance, if integrity has to be enforced an elaborate message digest (the MD5 algorithm is used) will be appended to each message, if confidentiality has to be enforced all exchanged messages will be encrypted (the DES algorithm is used) with the distributed session key.
4.4
Impact on the federation real-time behavior
The first experiments we made showed a 25% decrease of the performances when integrity is protected and much more when confidentiality is protected. To obtain this result, we compared the number of simulation steps that our toy federation was able to reach in a given amount of time with various kind of communication protection. The federation is executed on a non-dedicated LAN with low-end workstations. The federates use very simple trajectory computation and communicate a lot, so the performance of SecureSocket functions have a huge impact on the overall performance of the federation. So we expect that performance decrease would not be as great in a realistic simulation with federates performing more complex computations. Nevertheless this first result is quite disappointing. To improve this situation we could use a more efficient implementation of GSS-API or, at least, use GSS-API in a less naive way. In our security architecture we tried to protect in the same way all the messages exchanged between RTIA and RTIG. Messages as datatransfer acknowledgement or time-management messages might need less protection than UAV messages, so we could save some costly cryptographic computations. We could also use the architecture improvement described in the previous chapter where ambassadors directly multicast messages to other ambassadors. This means that there are less messages to protect but we might have to change the underlying cryptographic techniques. In the improved
architecture we would have to establish secure associations between ambassadors. So we would have to manage a key for each pair of ambassadors, this is much more than a key for each ambassador as in the current architecture. An alternative would be to use public-key cryptographic computations, but they are known to be slow. New techniques devoted to group cryptography appeared recently but they are not already available as GSS-API services.
5 5.1
Local Secure association Threat
At the core of our simulation architecture is a local area network operated by an organization trusted by all the firms in a federation. The network is composed of various hosts 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. As the local network is operated by the trusted organization and federates have not a direct access to the LAN, we consider that it is unlikely that they perform attacks such as listening, blocking, replaying or forging messages on the LAN. But a malicious piece of software running on one of company A host could still try to use the LAN to directly disclose private information to federate B. So we should build a secure simulation LAN such that there is no communication between company hosts except communications that are mediated and authorized by the RTIG.
5.2
SMAC Security Protocol
We selected the SMAC (Secure Medium Access Control) protocol [12] to build the secure simulation LAN. Each host can use the LAN through a Trusted Network Interface (TNI). It is a hardware device that controls accesses to the communication medium according to the security label of the host and the current security label of the medium. The TNI receives security labels from a Central Security Server. The LAN security is enforced by the consistent and synchronous behavior of the set of TNI. The global behavior of the network can be regarded as a temporal multiplexing of the medium by security labels with strict isolation between hosts of different labels. The hosts are associated with a unique security label, they only communicate with hosts that have the same security label just as if we had several Ethernet LANs. Communication between hosts with different security labels uses a special trusted host that can receive and send
messages at any label. This host acts as a lift by receiving messages from a host with one security label and, if allowed by the security policy, transmitting the message to a host with another security label. We can easily take advantage of the SMAC protocol to implement a simulation LAN. Each company is associated with a label and the “lift” machine is the machine that hosts the RTIG process. The development of a SMAC LAN is almost completed. Our goal is to use a multi-company federation as a test application of this LAN.
5.3
Impact on the federation real-time behavior
In the case where every federate is connected locally we would not have to rely on cryptographic functions to secure the communications. So we expect to have better performances than in the previous chapter. This has to be confirmed when the SMAC LAN will work. We have studied the performances of the SMAC protocol by simulation (see [13]). We observed, that for applications with great communication load, performances are good with respect to a conventional Ethernet LAN. They can even be better than a standard protocol because security controls tend to decrease the number of collisions. Performances are generally worse than with a standard protocol for applications with small communication load.
6
Conclusion FedA1 libRTI
FedA2
FedB
RTIA
libRTI
libRTI
G S S
RTIA
RTIA
SMAC RTIG + access controls Figure 4: CERTI security architecture
We have described a security architecture for distributed interactive simulations that is based on three security functions. We think that this architecture can address a large class of security policies, as we could
adapt the security labels for the publish/subscribe controls or change the SMAC controls and we could switch to another GSS-API implementation. We tried to evaluate the impact of these functions on the real-time behavior of simulations. The impact ranges from undistinguishable for publish/subscribe controls to very embarrassing but classical for GSS-API services. The proposed architectures relies on the RTIG process. It has an important role with respect to security: it performs subscription controls, it securely multicast messages and it manages secure association with the ambassadors. It is not certain that this architecture scales very well. But, it is not easy to achieve the right balance between performances and security because an improvement of the architecture with respect to performances can lead to an insecure system. We have proposed an improved architecture where ambassadors directly multicast messages to other ambassadors. We have seen that we would need to secure the distribution of authorized subscribers lists. Furthermore, we have seen that this would require to use more time-consuming cryptographic computations. We tried to base the communication mechanisms within CERTI on standard and largely available techniques such as TCP/IP or GSS-API. But we think that we could gain a lot by using communication libraries that would deal efficiently with group communication as the Horus system [14] or bypass the conventional TCP protocol as in [15]. In this paper we dealt with security problems in HLA/RTI data-transfer services, in the future we would like to study threats related to other families of HLA/RTI services such as the ownership management, datadistribution management and time-management services.
[4] J. Filsinger, H.O. Lubbes “System Security Approach for the HLA”, 14th Workshop on Standards for Interoperability of Distributed Simulation (Winter),1996.
7
[13] B. d’Ausbourg, P. Siron, “A Secure Medium Access Control Protocol: Security versus Performances”, European Symposium On Research In Computer Security (ESORICS94), 1994.
Acknowledgements This study was funded by DGA/STTC.
8
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", the Fall Simulation Interoperability Workshop, 1998. [3] P. Bieber, J. Cazin, P. Siron, G. Zanon "Security extensions to ONERA HLA RTI Prototype", the Fall Simulation Interoperability Workshop, 1998.
[5] DMSO, "HLA/RTI web page", http://hla.dmso.mil [6] R. A. Briggs, R. M. Weatherly, R. Richardson, J. Olszewski, T. Stark, "RTI F.0 integrated product team", Proceedings of the Spring Simulation Interoperability Workshop, 1997. [7] J. Linn, “Generic Security Service Application Programming Interface”, Internet RFC 2078, January 1997. [8] J.Steiner, B. Neuman, J. Schiller, "Kerberos: An Authentication Service for Open Network Systems", proceedings of The USENIX Winter Conference, February 1988. [9] P. Kaijser, J. Parker, D. Pinkas, "SESAME: The solution to security for Open Distributed Systems", Computer Communications, July 1994. [10] D.P. Barton, L.J. O'Connor, "Implementing Generic Security Services in a Distributed Environment", Technical Report, CRC for Distributed Technology, Brisbane, Australia, April 1995. [12] B. d’Ausbourg “Implementing Secure Dependencies over a Network by Designing a Distributed SubSystem”, European Symposium On Research In Computer Security (ESORICS94), 1994.
[14] R. Fujimoto, P. Hoare, “HLA RTI Performance in High Speed LAN Environment”, proceedings of the fal Simulation Interoperability Workshop, September 1998. [15] R. van Renesse, K. Birman, S. Maffeis, "Horus: a Flexible Group Communication System", Communications of the ACM, April 1996. [16] M. Gasser, "Building a Secure Computer System", Van Nostrand - Reinhold, 1988
