Analysis of Security Models For Smart Cards

Transcription

1 Analysis of Security Models For Smart Cards Ganesh J Pai gpai@virginia.edu ECE Department, University of Virginia Abstract Smart cards are an old breed of ubiquitous embedded-computing devices that are increasingly gaining popularity for electronic business transactions. When these smart cards are used over networks that can be covertly snooped, such as the Internet, there is a potential threat to the security of these transactions. In this report, I describe and analyze security models for smart cards that are used for electronic commerce. An analysis of the security components of JavaCard technology, a relatively new software platform for running Java applications on smart cards, is also presented. I briefly introduce and analyze the concept of secure coprocessing and trusted co-servers which, when augmented with JavaCard, can guarantee security of electronic transactions. 1. Introduction Smart cards have been around for approximately 20 years but they have differed in their smarts over the years. Physically, it looks similar to a credit card, but differs from it by the way it stores and processes information. A smart card essentially has a microprocessor or a memory chip embedded in a rectangular plastic card. Those cards that have a memory chip alone can simply store information. Security logic is used to control access to the memory in the card. A microprocessor card, however, is more intelligent and offers read, write, calculating and information manipulating capabilities. One may think of a microprocessor card as an embedded computing device with IO capabilities, controlled by an operating system with security policies. Smart cards can have IO interfaces that are either contact based or contact-less. Contact smart cards need a smart card reader into which the cards are inserted. Contact-less smart cards, however, have an antenna embedded inside the card that enables communication with the reader without physical contact. All smart cards contain a persistent memory (ROM), a persistent but electrically mutable memory (EEPROM) and volatile memory (RAM). Smart cards and the Internet have co-operated to facilitate electronic banking and payment, and secure business-to-business (B2B) and business-to-consumer (B2C) e-commerce. Smart cards in conjunction with the GSM standard for mobile phones enable secure subscriber authentication, roaming facilities for mobile phones and secure value added mobile services [1]. Frequently, multiple applications can be stored on the card, enabling partnering of on card programs and pro-viding added convenience to the cardholder. In this report, I focus on the security aspect of such multifunctional smart cards used in electronic commerce. Clearly, if there is some way in which the information being passed between the parties doing business can be intercepted by an attacking party, there is a potential for fraud, theft and a compromise of privacy. There are two security aspects for smart cards first, at the level of the smart card itself, and secondly after information has left the smart card. This report looks primarily at security on the smart card. Section 2 describes a role and task based security model proposed by [2], and a formal - 1 -

2 security model for multifunctional smartcards suggested by [3]. In section 3, I present the JavaCard platform, which builds on the formal security model and allows applications written in a modified subset of the Java programming language, to run on smartcards. I briefly describe its elegant underlying security mechanism, and discuss potential disadvantages. Section 4 presents some conclusions of my analyses. 2. A Security Model for Smart Cards 2.1 A Role and Task Based Security Model The role and task-based (R&T) security model partitions the problem space into variables, rules and functions, on the variables, which allow the rules. The variables are expressed as sets of elements. At any time, there is a pre-defined universal set of which the active variables and authorized variables are subsets. It offers users, finer granularity in security levels and thus differs from the conventional models that offer either roles or tasks. Multiple applications are often desired on the same card to provide value addition to the cardholder. An oft-used (and a very real world 1 ) example in the literature is that of an electronic wallet application and another application that collaborates with the electronic wallet (for example, an application providing frequent flyer miles) that reside on the same card. In such multi-application cards, security between applications is desired. One would not want sensitive data being leaked among the applications residing on the same card, for want of the users and the application provider s right to privacy and informational self-determination i.e. secrecy and integrity among the applications should be guaranteed. If the application providers wish to add further levels of secrecy or protection to their data, the security model for the smart card should also guarantee these different levels of secrecy. A role and task-based model for interapplication security proposed by [2] while [3] present a more generalized but formal model for multi-applicative smart cards. 1 American Express Blue is a smart card that offers two applications on the same card for electronic money transactions In the smart card domain, the R&T model defines subjects, roles, tasks, procedures and objects as variables. Subjects are processes in the card, which are given tasks to perform in different roles. These are performed on objects using procedures. Tasks are hierarchical structures, while roles define how these tasks are done. A role task combination provides procedures which access well defined data objects stored on the card. The R&T model provides security levels that enforce policies and define how and what information is available to the procedures. The model permits a subject to have more than one role-task combination provided that these combinations are not mutually exclusive to each other. This implies that a subject can perform a newly added role-task combination if and only if this combination is not mutually exclusive with its already defined role-task combinations. This permits ease in authorization and revocation of roles and tasks for new user tasks. Thus, the concept fits very well with a smart card environment where one may want to add or remove applications on the card. The smart card operating system (SCOS) will act as the administrator in managing the security

3 between these new applications. Therefore according to the model, one may say Authorized _Roles (S i ) Roles (1) Active_Tasks (S i ) Tasks (2) Where Roles and Tasks are the universal sets of all possible roles and tasks that are allowed in the model, for subject S i. Such relations are defined for possible roletask combinations that could be active and authorized, as well as for procedures and objects. Sets for active and allowed access are also defined as tuples with subjects, the roletask combination and procedure-object pairs. Similarly, the model also provides rules for role and task authorization, task hierarchy, static and dynamic separation of duty and object access. These rules set role-task contexts for the subject. Procedures can execute only if there are role-task contexts authorized for the subject. These role- task contexts provide access to the data objects required by the procedures. In a nutshell, subjects cannot perform tasks in roles unless the tasks have been authorized for the subjects and the roles have been authorized for the tasks. A more detailed explanation of all the variables and rules is given in [2]. An example representation of multiple applications in the R&T model is as shown in Fig.1 Subjects = {Cardholder, Bank, Airline}, Tasks = {Money transfer, Banking, Ticket Purchase, Administrating}, Roles = {Electronic wallet holder, Credit Card holder, Airline Customer, Bank administrator}, Procedures = {Read, Write, Append, Delete, Create, Add}, Objects = {Name, Account #, Bank information, Cash, Credit Card #, Limits, Flyer Miles} Fig. 1: Possible variables in a multi-application R&T security model for a Smart card In this example, it is clear which subjects can use the card and what role-task combinations they would use to manipulate data objects. It is also clear that if the cardholder wishes to pay the airline by credit card, then the airline application should only be allowed read access to this data object. No other unrelated information should be accessible to the airline application. The R&T model facilitates this inter-application security with a role-task context. The rules and variables, which form the context along with transition functions, define a state-machine based model. The SCOS thus allows different applications residing on the same card to securely access select data objects and different services using an application based security framework A More Formal and Generic Security Model In [3] a similar but more formal security model is described. An operating system (for the smart card), which executes system calls, is modeled. The applications running in user mode on the card make these calls to the operating system running in supervisor mode. The formal model is a more generic abstraction, based on intransitive noninterference [5] and authentication [3], that allows for modeling security for other smart card architectures. In this model, it is assumed that the operating system calls are atomic. Further, it addresses the issues of secrecy between programs of different applications, secure communication between these applications and secure downloading of new code on to the smart card. The formal model appears to be very similar to the R&T security model. It builds on the Bell/LaPadula security model [6] and uses an access matrix of levels and categories to define the integrity and secrecy classification of data objects and subjects. Again, as in the - 3 -

4 R&T model, subjects are host applications while the objects are usually data files that need to be manipulated by the subjects. While the access matrix provides a disjoint set of access categories for multiple applications (effectively isolating them from one another), communication between collaborating applications is enforced using a channel program. One of the noteworthy goals achieved in the formal model is secure communication with the outside world. Again, with respect to the smart card domain, such secure communication channels are desired not only between applications on the same card, but also between the card reader and the card. Authentication for applications is included in the model. If a new application were to be added to the card for example, a hotel application that collaborates with the banking application and the airline application it would have to be digitally signed and authenticated with a key that is already known to the card. Obviously, if this were enforced, then malicious applications cannot be downloaded on the card after the card has been issued. Therefore, this model guarantees not only total isolation of multiple applications; it also ensures that communication between two applications is possible if and only if the channel program has been authenticated by all the applications that are communicating. A relation based on clearances for the subject expresses the security policy and the rights for a subject executing commands on the card. If we express the relation as ~> then A ~> B implies that a subject with clearance A can pass information to another subject with clearance B. The clearance of a subject is based on an access class, and the relation ~> is equivalent to saying that a subject with lower clearance can pass information to one with higher clearance but not vice-versa. The modification to this relation that is the basis for this intransitive formal model is that a subject with clearance A can only pass information to a subject with clearance B via C but not directly. In terms of the relation, this is specified as A ~> C and C ~> B but A ~/> B (3) That is, the two subjects cannot communicate directly, except through C. If C is the SCOS, then effectively, this model achieves what the R&T model does. The intransitivity concept is therefore simply D = dom (c) where a command c can be executed only if it has clearance D defined by function dom. Therefore, for achieving property (3) i.e. security, the final state after executing a command list from initial state and command c should be the same as the state after executing the new command list whose clearance is the clearance of the state obtained after execution of the initial command list from initial state, and the command c. The data structure used in implementing this security model is system state, which comprises the permanent smart card key, an authentication store and a file system. The authentication store is the mapping of authentication information to applications that exist on the card. The file system modeled is classification of directories. At the simplest level, this model may be viewed as an operating system domain controlling (creating or deleting) application domains. This control is exercised using a domain definition table set according to the property (3). The formal proof and a more detailed explanation of this model are found in [3]

5 3. The JavaCard Platform In this section, I describe and analyze the security component of JavaCard technology, a stripped down version of the Java platform that is used for deploying architecture independent applications on smart cards. The application development platform truly implements (with some variations), the formal security model described in the previous section. [7] describes JavaCard technology as one that defines a runtime environment that supports smart card memory, communication, security, and application execution. The JCRE (Java card runtime environment) conforms to the smart card international standard ISO required in the model explained in section 2.2, the JCRE ensures atomic operations and is responsible for the creation of transient and persistent objects. Applications developed in JavaCard have a very small software footprint. The Java Virtual Machine (JVM), the interpreter that interprets machine independent bytecode is implemented in the ROM of the smart card. The advantage of machine independent code is simply that applications can be developed to run irrespective of the architecture of the smart card computing hardware. Moreover, this code is portable unlike the code obtained using hardware-specific assembly language. The runtime environment provides a precise segregation of the smart card system and the applications that run on it, encapsulating the underlying complexity [7], [10]. Fig.2 shows the architecture of the JVM and the JCRE. The JCRE is essentially the SCOS and is responsible for managing the network communications, resources, application (deployed as applets) execution, and interapplication security. The JVM on the card is responsible for the execution of bytecode, low-level communication protocols, cryptographic support, and memory management. Detailed descriptions and explanations of the JavaCard architecture are provided in [7], [8], [10] and [11]. As was Fig. 2: JavaCard System Architecture [7] 3.1 Applet Firewalls Two packages javacard.security and javacardx.crypto provide interfaces for cryptographic classes, keys and can be used to compute signatures; message digests, and generate random data. An application or applet on the card is identified by an applet ID or AID. Further, a resource identifier (RID) is used so that, in conjunction with the AID, it can be used for unique identification of applications and data files in the card file system. Applet or application isolation is achieved using an applet firewall [7]. Essentially, protected object spaces known as contexts are defined for each applet when it runs. The firewall confines the applet to its context or designated area in the memory space. It acts as the boundary between two applications. When an applet instance is created, the JCRE assigns it a context. Multiple applet instances for the same application are assigned group contexts, as shown in Fig. 3

6 Besides this, the JCRE has its own context, with special privileges. The JCRE context can access objects in any other context but not vice-versa. Similarly, other contexts cannot access objects that are not local to their context. This is similar to what was described in the formal model. Further, the JCRE ensures that there is only one active context at any point of time. When an object is created, it is assigned the currently active context so that all applets local to that context can access this new object. When objects are accessed by applets, their owning context (the context they were assigned at creation) is compared with the currently active context. A mismatch raises an exception and access is denied. Therefore, if an object were created with owning context B (Fig. 3) then an applet in package-a may not access this object because the owning context and the active context are not the same. Comparing this example with the formal model, we see that this property is nothing but a disjoint set of access classes or parameters. This mechanism achieves one of the objectives set in the formal model secrecy and isolation of programs and objects of different applications. JavaCard also permits object sharing across contexts by establishing a secure communication channel between the two contexts, through the OS context, that is the JCRE context. 3.2 Secure Communication among Applets across Contexts. Object sharing across contexts is achieved using secure sharing mechanisms such as privileges, entry point objects and shareable interfaces. Yet, the applet s actions are always confined to its own assigned context. Fig.3: Applet Firewalls and Context Partitioning in JavaCard [7] When objects need to be shared, the JCRE performs context switches so that the object being accessed has the same context as its owning context. When a method that causes a context switch is invoked (usually a method of a JCRE entry point object) the context switched to, is the JCRE context. The method therefore executes in the JCRE context. The JCRE defines entry-point objects, which can be accessed by any applet. However, only public methods in the entry-point objects are accessible. These methods are the ones that are used by applets to request privileged SCOS services. Primitive data are shared by using predefined global arrays. Besides entrypoint objects JavaCard defines shareable interfaces. This is simply an interface that extends directly or indirectly [7] Objects that implement shareable interfaces are called sharable interface objects (SIO). Therefore, to share data, an object must define a shareable interface with set of methods declared as public. Applets then communicate or access data objects using the public methods defined in this shareable interface

7 The shared secret may be protected using public-key encryption. Essentially, the AID and the shared secret are used to set up a secure communication channel between the applets that need to share objects. An object may implement more than one SIO and again the authentication decides which SIO is to be exported. Fig 4: Shareable Interface mechanism Across the Firewall Now, if there are three objects A, B and C such that all have shareable interfaces but A can share with B alone, and B shares with A and C. Conceivably, if shareable interfaces allow A and B to share data objects, there is nothing to prevent B from sharing this with C. A might not want to share this data with C. (Fig.4) Nevertheless, shareable interfaces are implemented so that request of shareable interfaces always passes through the JCRE. This permits authentication to see if the two contexts should be allowed to share objects are not. The JCRE uses the AID associated with each applet to authenticate a SIO object request. This object request contains the SIO for the object requested. Presumably, the only way this is possible, is if the requesting application shares a secret with the application it is requesting an object from. This shared secret is used as a token to authenticate the requesting applet. Further, the object, whose SIO is being requested also checks the AID of the requesting applet to see if it is authorized to send the SIO to the requesting application. Thus, authentication is done with the help of a shared secret and the AID. Therefore, even if the shared secret is known by an intruding application, its AID is unique and differs from the AID of the authorized application. The security components and implementation of the shareable interface should ensure that every time that it is invoked, it should authenticate the invoking applet. The shareable interface model could also be thought of as a client-server model where the client requests a shareable interface from the server that authenticates it. 4. Conclusions This report primarily described and analyzed security models for multiple applications on smart cards. It has not looked at the issue of securing information once it has left the smart card. The formal model and the R&T based model for smart cards provided a framework with which a secure smart card operating system may be designed. The JavaCard platform is one such implementation that adheres to many of the features of the formal model. JavaCard prevents dynamic class loading, and makes type safety easy to enforce. One of the major security concerns that is not addressed by JavaCard is the scenario described earlier that of an applet sharing data obtained from one application with a third party, with which it shares information legally. This security problem boils down to one of trust between the two applications. Another possible security issue not addressed by JavaCard is native methods in downloaded code. This may expose the card to dangerous code that exists outside the applet firewalls

8 However the new JavaCard specifications offer bytecode verification and code signing using a key that will be used to authenticate download of new applets on the smart card. Secure co-processing and trusted co-servers, two concepts proposed in [4], may guarantee security for Java card transactions once information has left the smart card. In a nutshell, secure co-processing is the augmentation of a coprocessor to the main processor. This processor is made tamper resistant (both against logical and physical attacks) using hardware techniques. Trusted co-servers are used as third parties at web servers and prevent against insider attack. Secure co-processing and trusted co-servers provide some solutions to nonrepudiable authentication of clients, servers, client activity, server activity and electronic transaction security. References [1] What's so smart about Smart Cards? Gemplus Corporation. Accessed 28 Jan 2001 [2] K. Schier, "Multifunctional Smartcards for Electronic Commerce - Application of the Role and Task Based Security model", In Proc. of 14th Annual Computer Security Applications Conference, Dec [5] John Rushby, "Noninterference, Transitivity, and Channel-Control Security Policies", Technical Report SRI-CSL-92-02, December Accessed Jan 30, 2001 [6] D. E. Bell and L. J. LaPadula, Secure Computer Systems: Unified Exposition and Multics Interpretation, Technical Report ESD TR , The MITRE Corporation, March pdf - Accessed Jan 30, 2001 [7] Zhiqun Chen, Java Card TM Technology for Smart Cards: Architecture and Programmer's Guide, Addison-Wesley, 1st Ed. June [8] Java Card Technology, Sun Microsystems - Accessed Jan 30, [9] G. McGraw, E. Felton, Securing Java, John Wiley & Sons, 2nd Ed. January [10] M. Baentsch, et al., JavaCard From Hype to Reality, pp IEEE Concurrency Vol. 7, No. 4, October-December 1999 [11] Rinaldo Di Giorgio, Zhiqun Chen, Understanding Java Card 2.0, front/javacard/understandjc.htm - Accessed Jan 30, 2001 [3] P. Karger, G. Schellhorn, et al., Verification of a Formal Security Model for Multiapplicative Smart Cards, Research Report RC 21809, IBM Zurich Research Laboratory, July 2000 [4] Sean W. Smith, "WebALPS: Using Trusted Co-Servers to Enhance Privacy and Security of Web Interactions", Research Report RC 21851, IBM T J Watson Research Center, October