Development of Smart Card Application - Essay Example

Java Card JAVA CARD Introduction The rapid advancement and spread of the Internet and wireless digital communication has almost totally changed the way people interact. Business has seen a paradigm shift from the traditional face-to-face transactions to on-line transactions where services can be accessed remotely by a simple mouse click. The high connectivity that makes the world a global village has resulted in spontaneous emergence of electronic businesses which have opened up new avenues of commerce and access to a wider market. Technologies such as the smart card have significantly eased the way business is conducted as they provide safe, reliable, convenient, and effective e-business services. This paper dwells greatly on the smart card technology focusing on Java Card as the case study. History of Smart Cards Merriam-Webster online dictionary defines a smart card as “a small plastic card that has a built-in microprocessor to store and process data and records1.” In 1968, two great German scientists first mooted the idea of incorporating an integrated circuit into a plastic card. Many other people worked on this technology with no notable progress until 1974-1979 when Roland Moreno filed patents on smart cards in 11 different countries. Late 1970 saw the first commercialization of the smart card and the introduction of the microprocessor smart card through the work of CII-Honeywell Bull. Initial trials on the smart card took place in France and Germany in the early 1980 where they were used as prepaid phone cards and secure debit/credit bank cards2. Currently, the power of smart cards has greatly advanced consequent of the existence of improved modern chip and cryptography technologies. They have diverse commercial applications such as banking, identification, ticketing as well as telecommunication applications where they are used as SIM cards on cell phones. Challenges in the development of smart card application Traditionally, the development of smart card applications is subject to a lengthy, rigorous and difficult process. Development tools are built by smart card manufacturers using generic assembly language tools and dedicated hardware emulators obtained from silicon chip vendors. These facilities are not readily available to third party application developers making the development of these applications exclusive to a few highly skilled developers who have specialized in a particular smart card hardware and software. Until recently there existed no standard high-level application interface thus compelling developers to deal with the always technical low-level programming of modules such as communication protocols, memory management and other hardware specific routines. In addition, difficulties in portability of the applications limited the functions and broader deployment of the smart cards because applications from different service providers could not coexist on the same card. Java on Smart Cards Java Card Technology offers a great way around the challenges that circumscribe the popularity of smart cards. It provides an enabling environment for smart cards and other memory-constrained devices to run their java applications (called applets). Java card technology is inherently a secure, portable and multi-application platform that exploits the many good features of java language3. The benefits wrapped up in this technology can be summarized into the following: ease of application development, ssecurity, hardware independence, ability to store and manage multiple applications and compatibility. History of java card technology The Java Card Application Programming Interfaces (APIs) were developed at the Shlumberger’s product centre in Austin, Texas, by a group of dedicated engineers. Their key objective was to bring smart card development into the mainstream while maintaining the security of the cards. Their research led to the realization that java programming language was their ultimate solution. They went ahead to propose the initial draft of the Java Card APIs and consequently made Shlumberger the first licensed Smart Card Company4. Bull and Gemplus then joined Schlumberger and together founded Java Card Forum, a company tasked with identifying and resolving issues concerning the Java Card Technology plus promoting its acceptance in the smart card industry. The first development was Java Card 1.0 which contained specifications for APIs only and it was not a platform that could be easily built upon. Java Card 2.0 specification which evolved from the work of Integrity Arts was announced by Sun in November 1997 after collaborative efforts with Java Card Forum and various players in the smart card industry. Java Card 2.0 specification was significantly different from Java Card 1.0 in that it provided object oriented approaches to developing applets. However, it suffered one set back as it did not make available a downloadable applet format. March 1999 saw the introduction of Java Card 2.1 version. This package comprised of three specifications: the Java Card 2.1 API Specification, the Java Card 2.1 Runtime Environment Specification, and the Java Card 2.1 Virtual Machine Specification. The APIs provided in this version were updated based on the 2.0 version and the applet runtime environment was further standardized. This version made an important addition to the Java Card Technology by explicitly defining the Java Card virtual machine architecture and applet-loading format that make possible the interoperability of true applets. Applet Isolation and Object Sharing Java Card Technology is a secure multi-application platform implying that many different applications from different vendors can exist together in the same card. For harmonious operation, each applet is assigned to an execution context that controls access to the objects assigned to it. One execution context is usually separated from the other by a boundary called applet firewall. When an applet is instantiated, the Java Card Runtime Environment (JCRE) assigns it a context – essentially a group context. Applet instances found in the same Java package are usually assigned the same context and this is the group context. Within a group context, no firewall exists between applet instances and applets are permitted to access each other freely. JCRE also maintains one dedicated super system context that has special privileges. This system context serves the function of overall control of all other contexts assigned to applets within the Java Card. At a particular instant, only a single context is active in the smart card, either the JCRE context or the applets group context. However, contexts can change at different steps of execution5. Applet Firewall An applet firewall is a Java Card runtime enhancement of the Java security concept of a sandbox, and combines the functionality of the class loader, java.ClassLoader, and the access controller, java.AccessController. Besides the firewall that gives Java Card security and protection from unauthorized access by applets from different firewalls, the Java Card Technology provides a well-defined security mechanism called Object Sharing Mechanism that makes it possible for applets within the same card but different contexts to communicate and exchange information but still guarantee security. This Object Sharing Mechanism is accomplished through the following: JCRE privileges, JCRE entry point objects, Global arrays and Sharable interfaces. Context Switch A context switch is a change from one context to another within an execution. The Java Card VM then facilitates Object Sharing Mechanism by performing context switches. At the time a context-switch method invocation is made, the current active context is saved and the new context becomes the currently active context. Upon exit of the method either from a normal return or an exception, the original context is restored as the current active context. It is also important to note that a Java Card Execution context currently has package scope such that when an object is created it is assigned to the execution context of the caller. JCRE Entry Point Objects Basically they are of two types: Temporary JCRE entry and Permanent JCRE entry point objects. Object Sharable Interface Mechanism Three areas are of interest in this discussion of object sharing mechanisms: The JCRE can access any object due to its privileged natures An applet gains access to system services via JCRE entry point objects The JCRE and applets share primitive data by using designated global arrays Sharable interface Sharable interface is simply an interface that extends, javacard.framework.Sharable. This interface borrows significantly from the concept of Remote interface used by the Remote Protocol Invocation (RMI) in Java. Sharable Interface Object A sharable Interface Object is an object of a class which implements a sharable interface. Fields and methods of the SIO object can be accessed by any other context. The sharable object interface can as well be described based on the client/server relationship where the applet that provides SIOs is called the server while the other applets which use the SIOs the client. Server applets behave differently to individual client applets implying that customizing the server applet and defining multiple interfaces results in a way that each interface declares methods that are suitable for a group of client applets Figure 1. Object Sharing A Wallet/Royal-card Demonstration of Object Sharing Mechanisms in Java Car This is an example that demonstrates how object sharing mechanisms are implemented in Java Cards. A Wallet applet which stores electronic cash and Royal-card applet which provides purchase incentives. Just like Wallet applet, Royal-card applet also stores some values mainly points which one got from each purchase. For each dollar a user spends by using the wallet applet, one Royal point is added to the Royal-card applet. We assume that wallet applet and Royalty applet are in different contexts. The following steps must be undertaken in order to hit our target: Royalty applet create a sharable interface object (SIO) The wallet applet request the SIO form the Royalty applet. The wallet applet requests points to be added by invoking a service methods of the SIO Create a sharable interface object (server applet) We then create a service provider class that implement sharable interface in the server applet. Then server applet can create one or more objects of the service provider class and share those with other applets in different contexts. Request a Sharable Interface Object First step in client applet is to get the AID object assigned to the server applet using the lookupAID method. This method returns the JCRE-owned AID object of the server applet or returns Null. The method below is used for this purpose. Second, the client applet calls the method JCSystem.getAppletShareableInterfaceObject using the AID object to identify the server. Second parameter in the method is used by server applet to identify SIO if the server has more than one object or to pass some secure parameter between the client and the server. The above method looks up the server applet by doing a comparison between server_aid and the AIDs of other applets registered with the JCRE. In the event that the looked for server is not found, JCRE will return null otherwise it invokes the server applets getShareableInterfaceObject method: Below is a summary of the steps followed when processing a request for a SIO represented in the following figure: Figure 2. SIO processing Use a Shareable Interface Object: It is important to note that both JCSystem.getAppletShareableInterfaceObject and Applet.getShareableInterfaceObject have the return type Shareable, which is the base type of all shareable interface objects, together with the client applet must cast the SIO returned to the appropriate sub-interface type in order to generate the desired action. This is how the cast is implemented in Java: Obviously, after the client applet receives the SIO it invokes the sharable interface methods so as to access services. It has been shown however, that the only methods visible to the client are those defined in the sharable interface Context Switches during Object Sharing The fact that client applets and server applets are placed in different contexts inside the Java Card, context switches must occur for the objects to share. The below steps outline how context switching inside the card occurs: The client applet calls the JCSystem.getAppletSharableInterfaceObject method to request a SIO. An internal mechanism in the method switches the client applet’s context to the JCRE context. Then, the JCRE invokes the getShareableInterfaceObject method from the server applet. Such invocation results in another context switch so that the server applet’s context becomes current. On return from both methods, the client applet’s context is restored. Sharable interface methods have limited support for passing objects as parameters or return values unlike in Java. For example in the sample code if the wallet applet passes one of its own objects as a parameter in the grantPoints method, the firewall prevents the Royal applet from accessing this object and similarly from Royal applet to the Wallet applet. In shareable interface methods the types of values below can be passed as parameters or return values: Primitive values, Static fields, JCRE entry point objects, Global arrays, SIOs Figure 3. Context Switching Passing Objects and Arrays across Firewall Authenticating a Client Applet There are many applets existing in a Java card and it definitely becomes a matter of importance to ensure that security is reinforced. This is done by server applet authenticate the client applet before granting SIO and before executing a service method on the SIO. This authentication is performed inside the client applet by checking the AID of client applet. Because some the original client applet may break the privacy and share the SIO with unauthenticated applets, it is necessary to authenticate the client applet again after sharable interface method is invoked. To do this the JCSystme.getPreviousContextAID method is used for getting the Client AID. Since the client applet cannot be trusted based only on its AID, further authentication measures need to be taken such as cryptographic exchange. To achieve this, we update the grantPoints method at the server side so that it takes two additional parameters, an authentication object and a buffer. Due to the fact that the authentication object is created and owned by the caller, in this case wallet-applet, applet firewall requires that such an object be SIO (sharable). In PointsApp class we can now call challenge method of passed authentication object as illustrated in the code below. It is a must to implement an authentication interface and methods in the wallet applet. In addition to that a client applet, as earlier explained, should first send the reference of the client object when calling grantPoints method in server applet. The client can then use this reference to call challenge method. The Java Card platform supports secure object sharing across firewalls. Diagram explained 1. Applet a requests access to Applet cs shareable interface by calling the systems JCSystem.getAppletShareableInterfaceObject() method. 2. JCRE asks Applet c for its sharable interface by invoking the applets getShareableInterfaceObject() method on behalf of Applet a. 3. If Applet c allows sharing, Applet a will obtain a reference to Applet cs shared objects. Applet a now has access to Applet c. Applet a will own any objects that it creates, even thosedefined in Applet c. Applets in the same execution context have access to each other by default6. Conclusion The Java Card Technology has seen momentous improvements since its invention. Data security has remained a conspicuously sensitive issue and has attracted a lot of research. The traditional data sharing enforced over files with secured access improved with Java Card 2.1 technique of sharable SIO that instead used applet authentication via AIDs. The SIO difficulties in passing data between applets will hopefully be mitigated by the new described approach to object sharing based on delegates. This new approach exposes only desired methods of an applet and also allowing each method to be protected by any security policy the applet wishes to implement. With such research and improvements in the Java Card Technology, the future promises a more secure, interoperable and reliable Java Card. References Chen, Zhiqun. Java Card Technology for Smart Cards.1969. “History of Smart Cards.” Card Work. Accessed May 1, 2014. http://www.cardwork.com/smartcards/smart-card_history.aspx. Montgomery Michael and Knshna. Secure Object Sharing in Java Card. Chicago: Illinois, 1999. http://static.usenix.org/events/smartcard99/full_papers/montgomery/montgomery.pdf‎ Ortiz, Enrique C. “An Introduction to Java Card Technology-Part 1.” Oracle. Accessed May 1, 2014. http://www.oracle.com/technetwork/java/javacard/javacard1-139251.html. “Smart Card.” Merriam Webster. Accessed1 May 1, 2014. http://www.merriam-webster.com Read More