The Java Card 2.2 introduced an object sharing scheme to allow client applets to access to the server applet methods using a sharable interface object.
A Secure Object Sharing Scheme for Java Card Junqi Zhang, Vijay Varadharajan, and Yi Mu Department of Computing, Macquarie University Sydney, Australia {janson,vijay,ymu}@ics.mq.edu.au
Abstract. Code and data sharing is an important issue in Java Card. The Java Card 2.2 introduced an object sharing scheme to allow client applets to access to the server applet methods using a sharable interface object. This method suffers from some security problems such as Applet Identifier impersonation. For solving those problems, we propose two secure object sharing schemes based on the delegate model introduced by Montgomery and Krishna. Our schemes have some significant improvement over the original model in that a client applet in our system needs only one key.
1
Introduction
Java Card can be referred to as a smart card that can run Java programs.[1,2] As showed in Figure 1, a Java Card contains an operation system, Java Card Virtual Machine (JCVM), Java Card Framework, and Industry add-on Classes in Read-Only Memory (ROM). Java Card Framework implements the Application Programming Interface (API). The applications are java packets that are located in Electrical Erasable Programmable Read Only Memory (EEROM). Every application consists of one or more applets. Firewall partitions the Java Card platform object system into separates protected object spaces called context. All applets within same Java packet share the same context. The Java Card Runtime Environment (JCRE) has its own JCRE context, and this context has special system privileges and can perform operations. Some existing secure issues in Java Card 2.1 (same in Java Card 2.2) have been addressed by Montgomery and Krishna[3]. In order to solve the secure problems, they introduced a delegate model where each of applets (client or server) has a delegate. To invoke a method in the server applet For each sharable, a client shares a secret key with the server; therefore the client can be authenticated by the server with a simple challenge-response protocol. It is noted that in their scheme the number of secret keys for a client applet is proportional to the number of sharable methods in the server applet. In this paper, based on the delegate concept, we introduce two alternative object sharing schemes for Java Card 2.2[4]. Our schemes are also based on a distributed encryption that allows an encryption key to map multiple decryption keys. Using this property, in our system each client applet needs only one secret key, which shows a significant improvement over the previously proposed model. R. Deng et al. (Eds.): ICICS 2002, LNCS 2513, pp. 243–251, 2002. c Springer-Verlag Berlin Heidelberg 2002
244
Junqi Zhang, Vijay Varadharajan, and Yi Mu O.S & Native Function Industry Add on Classes JCRE Java Card Framework
Java Card VM Packet
Packet applet applet
……
applet applet
Applet firewall
Fig. 1. Java Card architecture.
The rest of this paper is organized as follows. In Section 2, we introduce the object sharing mechanism in Java Card 2.2 and discuss some major security issues in Java Card 2.2. In Section 3, we present two new object sharing schemes. In Section 4, we conclude the paper.
2
Object Sharing Mechanism in Java Card 2.2
Java Card 2.2 specification[5] introduces four mechanisms to enable applets to interact with each other and with the JCRE, so one context can access an object belonging to another context. These mechanisms are JCRE Entry point Objects, Global Arrays, JCRE Privileges and Sharable Interfaces. Here we discuss the Sharable Interface. 2.1
Applet Isolation
Applet isolation means that one applet can not access the objects or fields in another context unless the other applets provide an interface for access. For security concern, except the Java technology protection, Java Card uses the Applet Firewall to enforce the VM, and allows the VM to automatically perform additional security checks at runtime. This is because the applet entry points are public; other applets may obtain an object reference to access the applet and might cause the sensitive data to be leaked. The only method the JCRE provided to access other applets is through the SIO mechanism. 2.2
The Applet Context
The Java Card platform object system is partitioned into separate protected object space by the firewalls. These partitions are referred to as contexts. As shown in Figure 2, all applets in the same package share the same context. There is no firewall between the applets within the same package. The JCRE has its own context and has special privileges to perform operations that are denied to the context of applets. There is only one active context within the Virtual Machine (VM). The VM determines if the context switch is required.
A Secure Object Sharing Scheme for Java Card
245
O.S & Native Function System space JCRE context
Industry Add on Classes JCRE
Applet space
Java Card 1Framework context
context Java Card n VM applet x1
applet a1
……
Packet
Packet
applet x2
applet a2
applet
applet
……
applet
applet
Package A
Package X Applet firewall Applet firewall
Fig. 2. Contexts with the Java Card Platform’s Object System. Sharable interface SI (m1, m2) (1) Defines
Server (2) Defines Applet A
(3) Creates
Implements the methods (m1, m2)
Class C Object instance
Object O
Fig. 3. Server Applet create Sharable Interface Object (SIO).
2.3
Sharable Interfaces and Sharable Interface Object (SIO)
A sharable interface was introduced in the Java card 2.1 API[6]. It defines a set of methods that are available to other applets. A class can implement any number of sharable interfaces and can extend other classes that implement sharable interfaces. A sharable interface object is an object class that implements a sharable interface. Only the methods defined in sharable interface can be accessed by applets in other contexts, other methods and fields in SIO only can be accessed in the same context. The applets that provide the SIO are server applets and the applets that use the SIO are client applets. The applet can be a server to some applets and a client to other applets. 2.4
Creating a SIO
Figure 3 illustrates how to create a SIO. To create a sharable interface object, the server applet first defines a sharable interface SI that includes the method the server applet supplied to other client applets and then defines a service provider class C that can implement the methods defined in the SI. After that, the server
246
Junqi Zhang, Vijay Varadharajan, and Yi Mu JCRE
(1)
(4)
Client applet B
(3)
(2)
Server applet A
Fig. 4. The client applet requests the sever SIO. (1) Request a SIO, Jcsystem.getAppletShareable InterfaceObject (Server AID,byte), (2) Receive AID of B, getAppletShareable InterfaceObject (Client AID,byte), (3) Return reference of O or null and (4) Receive reference of O or null and store it in object reference variable SIO.
applet creates an object of the service provider class C. When the applet instance is created, it is registered in the JCRE using the Applet Identifier (AID). During the object sharing, this AID is used to identify the applet. 2.5
Requesting and Using a SIO
The Figure 4 shows the process that the client applet requests the server SIO. The client applet can invoke the any methods from the sharable interface. During the invocation the Java Card VM performs a context switch, the context of the server applet becomes the currently active. At this time, the firewall allows the client applet to access all the methods and fields in the SIO, and prevents it from accessing all other methods and fields in non-shared object in the server applet context. The context of the client applet is not visible at all, and the firewall prevents the server applet to access the context of the client context. 2.6
The Issues with the SIO
There are some security issues in Java Card 2.1/2.2 having been addressed.[7]. We summarise the important issues as follows: – The JCRE security protection mechanisms do not prevent interfaces from being cast into other kinds of interfaces that might exist for given object. If one client applet is granted to use any sharable interface, it can cast into other interface. So it is possible to for this client applet to access all of the sharable interface methods of an object. – In the sharable interface mechanism, the sever applet provides the sharable interface to some particular applets, which solely depends on the AID of the clients applet. In other words, the server determines whether to provide the service to a particular client applet, just checking the AID of the client applet. In this case, a rogue applet may maliciously set the AID to be the
A Secure Object Sharing Scheme for Java Card
247
same AID of a client applet, which is known to have access to the server applet particular sharable interface, and then request the service from the server. The server applet only has the AID of the client for reference and this request AID match it, so it will grant this request. Then the rogue applet can freely access the server sharable interface for any purpose. – It is hard for future reference to a shared object. In this mechanism the server applet that has sharable interfaces must have a list of AID of client that have granted to access the sharable interface. This is not a problem for the new written and late loaded applet that legitimately needs to access the server applet sharable interface. This is because the server applet grants the access only based on the AID of the client applet, and the AID of such applets is excluded from this server list. The server applet must be rewritten and reissued if the client applet have to share the interface.
3
New Object Sharing Schemes
In this section, we propose two object sharing schemes. We refer to them as Scheme 1 and Scheme 2. Scheme 1 is simple, but it satisfies the important authentication requirements for Java Card. Scheme 2 gives an alterative for authentication, but it has some additional features that the privilege can be granted and removed from a client applet. The most important improvement of these systems over the existing one is that a client applet needs only one secret key. 3.1
Construction of Keys
Our model is a variant of the scheme given in Ref. [8]. Basically, we want to create a “public key” system such that several private keys are mapping to a single “public key”. By “public key” we actually mean “encryption key”. We should avoid using the term “public key” because all keys in our system are private! Let p be a large prime, Z∗p be a multiplicative group of order q = p − 1, and g ∈R Z∗p be a generator. To construct an encryption key for Method j associated with n decryption keys, we need to construct a the polynomial function of order n n, f (x) = i=1 (x − xi ) mod q, here (x1 , ..., xn ) are decryption keys. Clearly, if We can write the we set f (x) = 0, then x1 , ..., xn are solutions to the equation. n polynomial function into a general form: f (x) = i=0 ai xi mod q. The unique encryption key can be then constructed as an (n + 1)-tuple (g a0 , g a1 , ..., g an ). For simplicity, we denote by (g0 , g1 , ..., gn ) the encryption key tuple. To encrypt a message M ∈ Zp , we select a number r ∈R Zq set ui = gir for i = 1, ..., n, and compute C = m(g0 )r . The ciphertext consists of (u1 , ..., un , C). To decrypt the message, you must have one of decryption keys associated with the public key. For xj , you can decrypt the message as follows: x
x2
xn
Cu1 j u2 j · · · unj = M g r
n
i=0
ai xij
=M
248
Junqi Zhang, Vijay Varadharajan, and Yi Mu JCRE (2)
Client Applet
(3) (4)
(1)
Server Applet
Fig. 5. Invoking a method in the server applet.
3.2
The Java Card Object Sharing Model
Let us have a quick review of object sharing in Ref. [3]. The simplified illustration is given in Figure 5 and described as follows: – The server applet has the sharable methods. All the sharable methods must register in the JCRE system using the method and AID as parameter, register(Method, Server AID). This is referred to as Step 1. – In Step 2, the client applet obtains access to the server applet via JCRE using JCSystem.getDelegate(Server AID, byte) – In Step 3, the server applet delegate object is sent to the client. – In Step 4, the client accesses the shared method in the server applet. Prior to this step, there should be an authentication process that will be given in the main protocols later. Note that the JCRE has been changed by adding two system methods: register(Method, Server AID) and JCSystem.getDelegate(Server AID, byte). 3.3
Scheme 1
For convenience in our presentation, we denote by y(x1 , ..., xn ) an encryption key wrt decryption keys x1 , ..., xn . Assume that M1 , ..., Ml ∈ M are sharable methods in the server applet. Each of these methods is assigned with a private decryption key, xj . On the other hand, each of client applets is assigned with a unique private encryption key, yj (.), which can be referred to as a certificate. In general, a client applet could have the right to access to several methods. For example, yj (x2 , x4 ) represents the encryption key associated with methods M2 , M4 . In other words, Client j can have access to M2 and M4 with its private encryption key yj (x2 , x4 ). Following Figure 6, the protocol is described as follows (assume that the client has an index j): 1: CD → SD: The Request for service (this can be done by invoking the methods in the server)
A Secure Object Sharing Scheme for Java Card JCRE
249
(3)
(2) (7) Client Delegate (6) Client Applet
(5)
Server Delegate challenge()
(4) (1) service() (10) (9)
(8)
Server applet
Fig. 6. Applet delegate approach to object sharing.
2: SD → JCRE: The Request for the client applet’s AID. The server delegate has to determine the security lever of protecting the sharing method. If the method or the data is public to every context, the SD will provide the service to the client straightaway. If it is a sharable method, the client must be validated before provideing the service. 3: JCRE → SD: AID of CD 4: SD → CD: a random Challenge, c 5: CD → CA: The random Challenge c 6: CA → CD: The Response encrypted with yj . Note that CA has a unique encryption key that is also served as its certificate. As an example, we assume that y(x1 , x5 ) is the encryption key and the CD wants to invoke Method M5 . 7: CD → SD: The Response encrypted with yj . 8: SD → SA: The Response encrypted with yj and the Service request by the CD (i.e., M5 in the example). SA then checks whether the response can be decrypted using x5 . A positive result indicates that the CA has the privilege to access the method (M5 ). 9: SA → SD: The Response for the Service (if the CD Response can be decrypted using proper decryption keys associated with the requested methods) 10: SD → CA: The Response for the Service. SD can now invoke the method (M5 ). 3.4
Scheme 2
We now give the second scheme that is opposite to Scheme 1. Each method in SD is assigned with an encryption key and each of client applets is assigned with a unique decryption key, xi . In general, a client applet could have the privilege to access several methods, so we denote by yi (.) the encryption key associated
250
Junqi Zhang, Vijay Varadharajan, and Yi Mu
with method i. For example, y2 (x2 , x4 ) is the public key for Method 2, so only Client Applet 2 and Client Applet 4 can invoke the method. The encryption keys of all methods are stored in a special directory in JCRE that is only readable to the server applets. These encryption keys can be updated by an access control software called AC in JCRE. Updating happens when a client applet leaves or joins the Java card and when the access right of a client applet needs to update. Following Figure 6, we give the protocol below: 1: CA → SD: The Request for service (we assume that Client Applet 5 is the CA and that Method M3 is intended to invoke.) 2: SD → JCRE: The Request for the AID of the client applet, CD, and for the encryption key related to the shared method requested by the client (noting that the server delegate has to determine the security level the shared methods. If the method is public to every context, the CD will provide the service to the client straightaway.) 3: JCRE → SD: AID and the encryption key (say, y3 (x3 , x5 , x6 )) 4: SD → CD: a random Challenge, c, encrypted using the matching encryption key (i.e., y3 (x3 , x5 , x6 ) in the example) 5: CD → CA: The encrypted Challenge, c. CA decrypts it using its decryption key (x5 ). 6: CA → CD: The Response wrt c (this can be done after the decryption of the challenge, c, is successful.) 7: CD → SD: The Response wrt c. SD checks whether or not c matches the one sent to CD in Step 4. 8: SD → SA: The Service request by the CD. 9: SA → SD: The Response for the Service request. 10: SD → CA: The Response for the Service request. CA is now able to invoke M3 . In comparison with Scheme 1, Scheme 2 has an additional feature for revocation. A client applet’s access rights can be changed by modifying the encryption keys stored in the special directory in JCRE without changing the private decryption key of the client applet.
4
Conclusion
We have proposed two schemes for securing object sharing in Java Card, using the concept of Delegate. Our schemes eliminates the security problems mentioned in Section 2; therefore only legitimate client applets can have access to the specific sharable methods. Our schemes are based on a distributed asymmetric key system where an encryption key maps to multiple decryption keys. This property naturally fits into the Java Card environment such that in our system a client applet needs only a single key exhibiting significant improvement over the previously proposed system.
A Secure Object Sharing Scheme for Java Card
251
References 1. “Java card special interest group.,” http://www.javacard.org/others/what-is-java-card.html. 2. “Java card applet developer’s guide,” tech. rep., July 17, 1998. 3. M. Montgomery and K. Krishna, “Secure object sharing in java card,” in USENIX Workshop on Smart card Technology, May 10-11 1999. 4. “Java card 2.2 virtual machine specification,” tech. rep., 2002. //java.sun.com/products/javacard/JCVMSpec.pdf. 5. “Java card 2.2 paltform specification,” tech. rep., 2002. //java.sun.com/products/javacard/. 6. “Java card 2.2 application programming interfaces specification,” tech. rep., 2002. //java.sun.com/products/javacard. 7. “Java card 2.2 runtime environment specification,” tech. rep., 2002. //java.sun.com/products/javacard/JCRESpec.pdf. 8. Y.Mu, V. Varadharajan, and K. Q. Nguyen, “Delegated decryption,” in Cryptography and Code, Lecture Notes in Computer Science, Springer Verlag, 1999.
