CORBA and the Java Card – Connecting Small Devices to a Standard Event Service Klaus Bergner, Andreas Rausch, Marc Sihling, Christoph Vilsmeier Institut f¨ur Informatik Technische Universit¨at M¨unchen 80290 Munich, Germany E-Mail:
[email protected] Tel: +49-89-289-22685, Fax: +49-89-289-25310
Abstract Application development for tiny, intelligent devices has to deal with considerable hardware limitations, especially with regard to storage capacity and communication facilities. Furthermore, most devices offer only very limited low-level programming interfaces, complicating the integration of small devices into large-scale architectures. This paper shows an efficient software mechanism for connecting small devices to existing standard event and notification services. We show how the approach simplifies the communication with small devices and describe how security aspects are integrated. Keywords: smartcard, event service, ubiquitous computing, security, Java Card, CORBA
1 Introduction Presently, hardly a day passes without announcements of novel devices and applications made possible by the integration of cheap, miniature computers into small, mobile devices. Smartcards, for example, open up new possibilities for secure electronic commerce, creating a huge market in Europe and the rest of the world within the next years [10]. The upcoming of intelligent home devices with embedded processors is expected to raise the standard of living, and, at the same time, lower the energy consumption. Distributed, tiny processors and sensors will allow for asset tracking, proactive maintenance of vehicles, and secure access control, only to name a few [2]. As can be seen, the trend to tiny, but ubiquitous intelligent devices open up a host of chances for the computing industry. However, there are also some drawbacks. Due to technological and economical constraints, the available ressources of such devices are extremely restricted, not only with regard to storage and computing capacity, but also to bandwidth and reliability of communication con-
nections. This makes programming such devices very hard. The need to rely on proprietary, low-level mechanisms and interfaces delays the deployment of new applications and increases the necessary development costs. At the same time, the trend with large, distributed systems and architectures goes to reusable components and standard middleware infrastructures. Besides the usual communication facilities based on remote methods like CORBA [8] or Java Remote Method Invocation (RMI) [12], most approaches also offer asynchronous, event-based communication. Examples for such services are the OMG’s CORBA Event and Notification Services [7], SUN’s Jini Remote Event Service [13], and the Microsoft Message Queue Server (MSMQ) [6]. All of these systems enable programmers to send and receive asynchronous events by relying on a set of coherent, simple interfaces. For programmers of small devices, the situation is completely different: currently, there is no support at all for accessing standard event services, necessitating the realization of complicated ad-hoc adapters and bridges that are difficult to implement and maintain. The situation is further aggravated when secure communication is required— designing and implementing suitable protocols given the limited available ressources is not easy. In order to overcome these problems, we have invented 1 a novel technical solution for connecting small devices to a standard event service [1]. Our current implementation is based on smartcards following the Java Card standard [11] and on the CORBA Event Service [7]. However, the underlying principles and mechanisms are usable for all kinds of small devices and event services. In the next section, we outline the major requirements and features of our solution. Sections 3 and 4 explain the features of the overall architecture and the security concept, 1 A patent application for the developed technology has been filed to the German patent authorities, Deutsches Patent- und Markenamt. The reference number of the application is 199 06 134.3.
respectively. A brief discussion of the current implementation is presented in Section 5. Section 6 ends the paper, providing a short conclusion and an outlook.
2 Requirements and Features As described in the last section, the integration of small devices into a global distributed system leads to complex problems and requires dealing with many technical requirements and issues. Our solution offers the following features: Uniform Event Communication Interface: Instead of being forced to use proprietary low-level interfaces and mechanisms, programmers of small device applications can rely on a high-level event communication interface. This programming interface is a specialized, tailored version of the employed standard event service programming interface following familiar, straight-forward design principles. Marginal Ressource Allocation: As only a small part of the connection mechanism resides on the small device itself, the requirements for memory and computing ressources as well as communication bandwidth are very low, allowing to support extremely restricted devices. Compatibility with Standard Middleware: The mechanism doesn’t necessitate changes in the employed standard event service. Furthermore, the programmer can freely combine it with other communication middleware relying on a different paradigm. Support for Multiple Applications: The mechanism is able to support multiple, independent applications residing on a single device, enabling them to send and receive events to and from other applications on the small device or elsewhere. Support for Mobile Devices: Many small devices, like smartcards, are highly mobile. Typically, a user connects a smartcard to a global system, executes some operations, disconnects the smartcard, moves to another place, and reconnects again. The connection may happen explicitly, like with a traditional banking machine, but it may also happen implicitly, for example, when a wireless communication facility is used. Our connection mechanism supports mobile devices by automatically re-establishing a device’s connection state upon reconnection, and by optionally notifying device applications of (re-)connections and disconnections. Support for Active and Passive Devices: Most of the current smartcards are passive devices that can only react to commands sent by their environment. Our
connection mechanism is specially designed to overcome some of the deficiencies of such devices. Of course, it also supports active devices as well. Secure Communication: Especially with e-commerce applications, security is an important and technologically demanding issue. When necessary, our mechanism offers built-in security by restricting the communication according to several security levels, preventing eavesdropping and alteration of events as well as analysis of the event flow. Furthermore, the communication mechanism itself was carefully designed and implemented in order to prevent applications from communicating in unwanted ways by exploiting weaknesses. Java Compliance: The current Java reference implementation of the connection mechanism was designed for compliance with the Java platform, especially with respect to its integration with the Java Card interfaces [11]. This results in high portability to all kinds of embedded, Java-based small devices.
3 Overall Architecture In this section, we present a slightly simplified version of the connection mechanism’s overall architecture. An extended version of the mechanism is described in the German patent application [1]. The presentation follows our current reference implementation, which is based on a Java Card device and the standard CORBA event service. Figure 1 includes two kinds of communication partners: the left side shows some applications that are connected directly to the event service via its standard access interfaces, while the right side shows some applets residing on a smartcard. Both applications and applets may create and destroy event communication channels at the event service and register at these channels as event consumers and/or event suppliers. Messages sent by a supplier are distributed to all registered consumers [7]. To allow the applets to participate in the event service, it is necessary to abstract from the actual characteristics of the low-level connection protocol between the smartcard and the event service. For this reason, we have introduced two event brokers, one of which resides on the smartcard:
The Proxy Event Broker is located on the side of the event service. Incoming events are forwarded to the smartcard while events received from the smartcard are sent to the event mechanism. Quite similar, the Smartcard Event Broker on the smartcard represents the event service for all applets. They can directly send events to and receive events from this component.
Application a
Applet1
Physical Connection
SmartcardEvent Broker
Applet2 Proxy
ProxyEventBroker
CORBAEventService
Application b
Applet1 Proxy
Applet2
Appletn Proxy
Appletn Application z
SmartcardProxy
Smartcard
Figure 1: Overall Architecture This way, both brokers encapsulate the actual physical connection, shielding the applets as well as the event service from the low-level communication protocols used for this link. By doing so, both brokers act as multiplexers and demultiplexers, mapping the logical, bidirectional channel connections between applets and the event service onto the single physical connection. Furthermore, the brokers can deal with the re-establishment of connection state upon reconnection, and they may also inform applets about already happened or imminent changes of the connection state. For example, when a smartcard is released from an ATM machine due to a user command, an applet might want to make sure that a transaction is commited correctly before disconnecting. Moreover, our mechanism employs applet proxies which participate directly in the event mechanism on behalf of their counterparts on the smartcard. Applet proxies may be available for the event mechanism even if the physical connection is temporarily interrupted for a short period of time and the applets on the smart card are thus inaccessible. Applet proxies are managed by the smartcard proxy. When an applet decides to participate in the event mechanism, the proxy event broker creates a new applet proxy and binds it to the applet. This is shown in the upper part of Figure 2: the smartcard event broker forwards an applet’s request for registering at a channel to the proxy event broker. This broker in turn creates a corresponding applet proxy, which registers at the appropriate event channel. Furthermore, the figure demonstrates the procedures for managing disconnection and reconnection. Upon disconnection, the proxy event broker shuts down the applet proxy, which in turn unregisters from its channels. Note
that the smartcard is not involved in this procedure, as disconnection may imply the interruption of its power supply. When the smartcard is re-inserted into the smartcard reader, the connection is re-established, driven by the proxy event broker. As mentioned above, the actual version of our mechanism uses a slightly extended architecture. Following the OMG interfaces, communication relies on so-called ports as a means for connecting to a channel. This has the advantage that communication and security properties can be set on the level of single ports instead of whole applets.
4 Security Issues Many small devices, like smartcards, are mainly used for the purpose of authentication and authorization. Especially with respect to emerging application domains like e-commerce, security solutions are of vast importance as they help to avoid abuse and thus strengthen confidence and acceptance of the public. The proposed mechanism focuses on securing the connection between the small device and the event mechanism. This is especially important when wireless communication is used for establishing a connection. Our solution offers security at different levels, thus allowing less crucial applications to go without rather heavy-weight protocols. On the highest security level, communication between the system and the device is completely safeguarded against tampering, eavesdropping, and even the detection of ongoing communication. For each logical communication connection, an application may require a minimum level of security. If the ad-
CORBAEventService
proxy1 Applet : Proxy
proxy2 Applet : Proxy
ProxyEventBroker
SmartcardEventBroker
applet Applet :
register(channel) register(channel)
register(appletID,channel)
create(appletID,channel) disconnection
recognizedisconnection destroy unregister(channel) reconnection recognizereconnection
reconnect create(appletID,channel)
register(appletID,channel)
register(channel) reconnectionsucceeded
Figure 2: Transparent Reconnection dressed partner is not able to offer the needed security level or disagrees because of another reason, the connection is not established, and the sender might request communication at a lower security level. Logical connections at different security levels may coexist at the same time. Technically, the implementation uses a symmetric encryption protocol between the proxy event broker and the smartcard event broker to preclude eavesdropping. The corresponding key is initially negotiated and exchanged using an asymmetric encryption protocol. As common with this approach, each broker must have a way to authenticate its partner, for example by knowing its public key in advance or by accepting only public keys that have been signed by a known trust center. Our mechanism doesn’t rely on a special distribution scheme for such public keys. Moreover, the annotation of messages with a sequence number and a digital fingerprint is used in order to assure that messages are not repeated, and that their proper sequence is preserved. Finally, the highest security level also allows for “blind” communication—when there is no communication activity, randomly generated, encrypted messages are exchanged to mask the occurence of “real” communication activity. This way, the detection of ongoing communication activity by an intruder does not allow to draw conclusions with regard to the number of exchanged messages. Note that the described security mechanism may be freely combined with other mechanisms. Applications or event services may, for example, use additional authentication and encryption schemes in order to secure the communication on particular event channels.
5 Base Technologies and Current Implementation Our current reference implementation is based on the SUN JDK 1.1.5 [14], the CORBA object request broker Inprise VisiBroker for Java, the CORBA Event Service VisiBroker Event Service [4], and the Java Card implementation GemPlus GemXPresso [3]. Like all current smartcards, the GemXPresso card is extremely restricted. Most cards include a CPU, memory (RAM, ROM, and EEPROM), and I/O-Facilities (contactbased or wireless). Typical reference values are 256 Bytes to 1 kB RAM, 1 KB to 32 kB EEPROM, 6 kB to 32 kB ROM, and an 8-Bit CPU running at 5Mhz [9]. Java Cards are ISO-7816 [5] compliant smartcards running a special Java Virtual Machine (JVM) [11] with several limitations: it does not support threads, multidimensional arrays, garbage collection, strings, floats, and dynamic class loading, for example. Two additional restrictions of current smartcard technology need to be coped with:
Smartcards are passive devices (cf. Section 2), which means that they cannot send a message to the system by themselves without being triggered by a request of an external communication partner. During the processing of a request, most smartcards cannot communicate with the system. Moreover, they are not able to send more than a single response in return of a request. The actual implementation handles these limitations by a couple of workarounds which simulate almost natural
communication between system and smartcard by “piggybacking” additional messages sent by the smartcard on the response to an actual request. However, regarding the fast evolution of this technology, these limitations are probably abolished in the near future. Following the architecture described in the last section, we have implemented the Applet Proxies, the Proxy Event Broker, and the Smartcard Event Broker shown in Figure 1. Of these components, the Smartcard Event Broker is especially interesting, as it provides CORBA compliant interfaces for creating and deleting channels, for registering and unregistering applets as suppliers resp. consumers, and for sending and receiving events. The Proxy Event Broker and the Smartcard Event Broker perform the multiplexing and demultiplexing of logical, bidirectional n-to-m connections between the applets and the CORBA channels on the single physical connection by encoding and decoding the applet identifier, the channel identifier, the event identifier, and the event data itself. Note that the GemXpresso card is a purely passive device. To enable applets on the smartcard to participate in the communication actively, the Smartcard Event Broker is, therefore, driven and activated by the Proxy Event Broker. In case of disconnecting the smartcard from the smartcard reader, the Smartcard Event Broker stores all information about open channels and supplier/consumer registrations on the smartcard. Upon reconnection of the smartcard, registrations can then be automatically and transparently restored. Furthermore, our approach offers a sophisticated error handling scheme. Failed communication or re-connection attempts result in callbacks to standardized error routines, which may be adjusted by application developers according to their actual error-handling strategy.
6 Conclusion and Outlook In this work, we have presented a mechanism which allows small, mobile devices to participate in modern, standard event communication services. Although the implementation is based on the CORBA Event Service and the Java Card standards, the overall concept—as being applied for patent—is applicable to any small, processorbased device and any asynchronous event communication mechanism. Our next step will be to exploit the presented mechanism for applications by porting it to other platforms in the context of industrial projects.
References [1] The Smart-Event Website, http://smart event.informatik.tu-muenchen.de/, 1999. [2] Dallas. iButton Home Page: iButton Overview, http://www.ibutton.com/overview. html, 1999.
[3] Gemplus. Gemplus, http://www.gemplus. com, 1999. [4] Inprise. Inprise Home Page, http://www. inprise.com, 1998. [5] ISO. ISO/IEC 7816: Information technology - Identification cards - Integrated circuit(s) cards with contacts, 1998. [6] Microsoft. Microsoft Home Page: Microsoft Message Queue Server Overview, http://www. microsoft.com/msmq/, 1999. [7] OMG. CORBAservices: Common Object Services Specification. Object Management Group, December 1998. [8] OMG. The Common Object Request Broker: Architecture and Specification. Object Management Group, February 1998. [9] Steve Petri. Litronic Home Page: SmartcardEnabled Solutions for Enterprise, Extranet, and Intranet Security, http://www.litronic.com/ rsa98/tsld001.htm, 1998. [10] SCF. Smart Card Forum Home Page: Just the Facts, http://www.smartcrd.com/news/ factoids.htm, 1999. [11] Sun. Sun Home Page: Java Card Technology, http://java.sun.com/products/ javacard/, 1999. [12] Sun. Sun Home Page: Java Development Kit 1.2, http://java.sun.com/products/ jdk/1.2/, 1999. [13] Sun. Sun Home Page: Jini Technology, http:// java.sun.com/jini/, 1999. [14] Sun Microsystems. Sun Home Page, http:// www.sun.com, 1998.
