WO2004100094A2 - System and method for using open apis to provide integrated security policies for flexible management and customization of payment instruments - Google Patents

Abstract

A system and method for improving the flexibility of payment instruments such as payment cards when used by enterprises enables a primary issuer to allow a secondary issuer and/or user of the payment card to develop specialized policies for use of the payment card. Such secondary policies do not need to be known or managed by the primary issuer because they are enforced by the payment card itself when it is used in an online payment system . The payment card is configured with open application programming interfaces (API) that allow a secondary issuer and/or user to add policy programs that can control the possible uses of the card. Refinement filters are implemented by the payment card's processor so as to disapprove of transactions that do not comply with at least one policy of the payment card.

Description

SYSTEM AND METHOD FOR USING OPEN APIS TO PROVIDE INTEGRATED SECURITY POLICIES FOR FLEXIBLE MANAGEMENT AND CUSTOMIZATION OF PAYMENT INSTRUMENTS

GOVERNMENT SUPPORT

[0001] The present invention was supported by the United States Government under Grant No. ARO DAAD- 19-01 -1-0473 and by the National Science Foundation under Grant Nos. NSF CCR02-08990 and NSF EIA00-88028. The government may have certain rights in the invention.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] The present patent application claims priority from U.S. Provisional Patent Application Nos. 60/476,073, filed May 1, 2003, and 60/488,313, filed July 18, 2003. The contents of these patent applications are hereby incorporated by reference in their entireties.

FIELD OF THE INVENTION

[0003] The present invention relates to systems and methods for managing the use of payment instruments, such as payment cards or smart cards, in an online payment system and, more particularly, to open application programming interfaces (APIs) and a model-based approach to integrating security policies for embedded systems such as those used, for example, in secure programmable payment cards.

BACKGROUND OF THE INVENTION

[0004] Payment cards are a ubiquitous means of purchase in the global economy. Payment cards reduce the need to carry cash and to write checks, thereby improving the efficiency of transactions. For example, enterprises may streamline purchase operations by obtaining payment cards for employees, who can then use these payment cards to carry out purchases necessary to their tasks within the enterprise, often without the need to route such purchase requests through a central purchasing organization. This empowerment of employees improves efficiency but also entails risks of abuse in which payment card users make unauthorized purchases. Card issuers sometimes aim to provide enterprises with broad collections of policy restrictions to aid them in managing these risks. For instance, an enterprise may obtain payment cards for employees that have limits that can be set and enforced by the issuer of the payment card. However, in many cases, the enterprise will have other policies associated with the use of its payment cards, such as a requirement that the payment cards be used only for official business of the enterprise or only for certain kinds of purchases. Unfortunately, such policies generally rely on the compliance of the users and cannot be enforced concurrently with the purchase by the enterprise or the card issuer.

[0005] A variety of protocols have been explored to enable the use of payment cards in digital payment transactions. For example, the Secure Electronic Transactions (SET) protocol provides the capability to use payment cards in digital payment transactions. The SET protocol has been implemented on payment cards such as the Java Card that supports programming extensions, but no one has previously proposed or developed a way to use this capability to create a platform for extensible policies for controlling policies in a commercial environment while maintaining privacy of the policies. Primary card issuers, such as banks, may offer enterprises some flexibility in creating policies for users and then to enforce these policies on behalf of the enterprise, but going through the card issuers for each policy creates a tremendous bottleneck and makes it impossible to keep the enterprises' policies private. Moreover, the primary card issuers would rather not be involved in such policy enforcement, particularly when the policy is unique to a particular enterprise.

[0006] Techniques are generally known for providing flexibility by delegating management of smart card applications. For example, U.S. Patent No. 6,481,632 describes an open platform architecture for a system in which the card issuer empowers application providers to initiate changes to the issuer's smart cards that are pre-approved by the card issuer. This pre-approval is intended to ensure that only card content changes that the card issuer has approved will be accepted and processed by a card manager of a smart card, thereby allowing application providers more flexibility in managing their own applications on the card issuer's cards. [0007] While such prior art systems may be used to implement loyalty applications, stored value applications, credit/debit applications, transit, health care, insurance, electronic ticketing, electronic hotel check-in, coupon applications and the like, such systems have not been used to implement policies for users of payment cards (smart cards) under control of the application providers. Such policies may include, for example, where the payment card may be used, how much may be spent, and what types of items may be purchased. It is desired to provide such capabilities by providing suitable application programming interfaces (APIs) to payment cards with embedded security processes.

[0008] Common software engineering practice leads software developers to create software in layers and such layered systems often provide an application programming interface (API) to aid software evolution. Servers and desktop computers typically offer the ability to add software from independent vendors to embedded systems through an open API. Such APIs also may enable the device vendor to work more easily with subcontractors to obtain application software for their platform. The key difference that is the subject of the present invention is what it takes to allow the API to be open so that application developers not under the direct control of the platform vendor may provide programs to customize the platform. Such open APIs have the advantage of greater flexibility and provide for independent vendor support. [0009] However, there are a collection of barriers that prevent the deployment of open APIs. Many of these barriers are commercial: platform vendors often consider it more profitable to write their own applications, or may be concerned about losing control of their platform if its API is open. Embedded computers with open APIs often have significant constraints on safety (vehicles) and/or security (key tokens). There are also many technical challenges relating to flexibility, portability, predictability and deliverability of applications via the open API. The present invention addresses ways in which control may be balanced between the embedded computer, its host device, and remote host devices using a model-based approach to integrating security policies for embedded devices.

[0010] Increasingly, embedded devices, such as smart cards and cell phones, are programmable, and offer an open application programming interface (API) for the stored software applications. While this offers the user the much coveted flexibility to customize and enhance functionality, it underscores the need for formal assurances about system operation as many embedded devices are used in safety-critical and security-critical contexts. A model-based design paradigm, with its promise for greater design automation and formal guarantees of reliability, is particularly relevant for this purpose, and such a model-based approach to adding policies to payment cards is desired. Such a model-based system is a subject of the present invention and will be described herein. SUMMARY OF THE INVENTION

[0011] The present invention relates to a system and method for improving the flexibility of payment instruments such as payment cards when used by enterprises. The invention enables a primary issuer to allow secondary issuers and or users to develop specialized policies for the use of the issued payment instruments. Such secondary policies do not need to be known or managed by the primary issuer because they are enforced by the instrument itself. This enforcement is achieved by configuring the payment instrument to allow the secondary issuers and/or users to add policy programs that can control the possible uses of the payment instruments by the users. Transactions are not permitted if they are not permitted by the added policies. The original policies provided by the primary issuer remain unaffected. Thus, multiple secondary issuers may provide the same payment instrument issued by a primary issuer to respective users, and the payment instruments from the secondary issuers may have different sets of restrictions depending upon the policies of the respective secondary issuers. Moreover, the techniques of the invention permit certain end users (such as parents) to customize their payment instruments to further restrict their use (e.g. adding additional restrictions before giving the payment instrument to children).

[0012] Such a payment instrument (e.g., payment card, smart card, PDA, cell phone, watch,

USB key, and the like) in accordance with the invention is configured to perform electronic payment transactions within an electronic payment system. In an exemplary embodiment, the payment instrument includes a memory that stores at least one policy description added by a secondary issuer and/or a user to express limits on use of the payment instrument. This policy extends the limits provided by a primary issuer and represents a further restriction the secondary issuer and/or the user would like to impose on purchases with the payment instrument. The payment instrument also includes a processor that runs a payment manager program implementing any policy descriptions stored in the memory. During operation, the payment manager program examines purchase information from a merchant and issues purchase approval data or credentials to the merchant only if its policy descriptions are satisfied by the purchase information provided by the merchant. The payment manager program may, for example, generate a digital signature after confirming that the policy descriptions are satisfied by the purchase information from the merchant.

[0013] In accordance with the exemplary embodiment, the payment instrument includes an application programming interface to the processor. The interface includes a refinement filter that disapproves a transaction represented by the purchase information from the merchant if the transaction does not comply with at least one payment policy of the payment instrument. For example, the application programming interface may limit resources available to the refinement filter to purchase information needed to transact an electronic payment. The application programming interface also enables the programming of the processor by the user and/or the secondary issuer of the payment instrument in accordance with a dynamic policy management framework that combines state machines with a non-monotonic logic engine that models dynamic integration of new modular policies into the refinement filter so as to cause the refinement filter to grant or deny the transaction based at least in part on the new policies. The logic engine also provides conflict resolution and redundancy checks for the policies of the refinement filter. In exemplary embodiments, the non-monotonic logic may implement the methodology of defeasible logic, default logic, abductive logic, deontic logic, and/or multivalued logic.

[0014] The processor of the payment instrument of the invention may also be programmed to implement graphical interface software that enables editing of the policy management framework, analysis engine software that checks for conflicts in policies to be implemented on the payment instrument, and code generation software that creates applets that are stored in the refinement filter to implement the new policies. In an exemplary embodiment, the applets include at least one manager applet containing the logic engine and at least one policy applet. During operation, the manager applet polls any policy applets for their votes concerning whether a transaction request should be approved, consolidates any votes received, and notifies the policy applets of approval or disapproval based on the consolidated vote. Once programmed, the payment manager program enables the payment instrument to take part in an electronic payment transaction with a purchase interface such as a remote website via a host if the refinement filter approves a purchase request from the purchase interface.

[0015] In accordance with the exemplary embodiment, the policy management framework includes at least one policy automaton that is a finite-state machine that examines the purchase information provided by the merchant and votes on whether or not to approve the transaction. The policy automaton represents the votes as rules in non-monotonic logic that represent which outcome the policy automaton prefers and how strong that preference is. The policy management framework also includes a decision rule that collects the votes of all policy automata to either approve a transaction represented by the purchase information from the merchant, reject the transaction, or declare a conflict. The policy automata also update their states to override existing policies based on the determination of the decision rule. [0016] The invention also includes methods of managing the use of a payment instrument designed in accordance with the invention to perform electronic payment transactions. An exemplary method in accordance with the invention includes the steps of: a secondary issuer and or a user adding at least one policy description to the payment instrument to express limits on use of the payment instrument in addition to those limits provided by a primary issuer of the payment instrument that the secondary issuer and/or the user would like to impose on purchases with the payment instrument, the at least one policy description being represented as a computer program implemented on the payment instrument so as to examine purchase information from a merchant for automated approval; and enabling the payment instrument to perform electronic payment transactions whereby when an attempt is made to use the payment instrument to pay for a transaction with a merchant, the payment instrument consults its policy descriptions and issues purchase approval data to the merchant only if its policy descriptions are satisfied by purchase information provided by the merchant.

[0017] In an exemplary embodiment, the step of adding at least one policy description includes the step of installing the computer program onto the payment instrument from a host computer, where the computer program includes a refinement filter that disapproves a transaction represented by the purchase information from the merchant if the transaction does not comply with at least one payment policy of the payment instrument. The step of installing the computer program, in turn, further includes the steps of: the host installing an approval applet having its own installation method with the aid of a manager of the payment instrument; the approval applet's installation method being invoked by the manager to initialize the approval applet; the approval applet obtaining an application identifier object of a transaction applet by providing a known reference value to the manager; the manager using the reference value to access a shared interface object of the transaction applet and invoking a registration method in the shared interface object to provide a reference that can be used by the transaction applet to later get the shared interface object from the approval applet; and if the registration method is successful, then success is indicated to the approval applet, the manager and the host computer.

[0018] The methods of using the payment instrument of the invention further includes a method of performing a secure transaction with the payment instrument, including the steps of: when the host computer attempts to send a payment message to the payment instrument, the host computer passes purchase information to a transaction applet on the payment instrument, the transaction applet invoking at least one approval applet on the payment instrument, each approval applet acting to approve/disapprove the transaction; if each invoked approval applet approves the transaction, the transaction applet creating a digital signature that the host computer needs to complete the transaction; and forwarding the digital signature to the host computer. [0019] Other methods of using and/or implementing the payment instrument of the invention will be apparent to those skilled in the art from the following detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The above and other characteristic features of the present invention will be apparent from the following detailed description of the invention taken in conjunction with the accompanying drawings, of which:

[0021] Figure 1 illustrates a conventional payment card scenario augmented by the concept of a distinction between a primary issuer such as a bank and a secondary issuer such as a small or large enterprise in accordance with the invention.

[0022] Figure 2 illustrates a payment transaction over a conventional Internet implemented payment card system architecture using the system of Figure 1.

[0023] Figure 3 generally illustrates the architecture of a payment card and terminal in a payment system in accordance with the invention.

[0024] Figure 4 illustrates communications options for delivering code to an embedded computer system.

[0025] Figures 5A and 5B illustrate the messages in a SET purchase request.

[0026] Figure 6 illustrates the GlobalPlatform architecture.

[0027] Figure 7 illustrates the steps in GlobalPlatform Provider loading.

[0028] Figure 8 illustrates the steps in an on-card byte code verification technique for smart cards.

[0029] Figures 9A-9H illustrate refinement filter installation in accordance with the invention.

[0030] Figure 10 illustrates messages used in filter refinement transactions in accordance with the invention.

[0031] Figure 11 graphically illustrates the process of using the payment card of the invention.

[0032] Figure 12 illustrates an exemplary embodiment that performs policy automata analysis and compilation in accordance with the invention. [0033] Figure 13 illustrates a screen shot of a policy automata editor in accordance with the invention.

[0034] Figure 14 illustrates five policy automata in a simplified form of the graphical language accepted by an exemplary embodiment.

[0035] Figure 15 illustrates the P_E emergency policy from Figure 14 after the code generator has translated it into Java code.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0036] The invention will be described in detail below with reference to Figures 1-15. Those skilled in the art will appreciate that the description given herein with respect to those figures is for exemplary purposes only and is not intended in any way to limit the scope of the invention.

All questions regarding the scope of the invention may be resolved by referring to the appended claims.

I. OVERVIEW

[0037] The present invention improves the ability of enterprises to manage policies for users of payment instruments such as payment cards issued to them on behalf of the enterprise. The present invention relies on the use of smart cards and an electronic payment system such as the

SET protocol. Key elements of the payment system protocol are carried out in the protected processing and memory of the smart card. As a result, the smart card is able to enforce certain kinds of policies as installed on the card by the enterprise or a user. As will be apparent from the following description, the invention is not limited to smart cards but may be applied to other types of payment instruments as well.

[0038] Figure 1 illustrates a typical payment card scenario augmented by the concept of a distinction between a primary issuer such as a bank 1 and a secondary issuer such as a small or large enterprise 2 in accordance with the invention. As illustrated, a primary issuer 1 creates a payment card, such as a smart card, capable of performing an electronic payment transaction and provides this payment card to a secondary issuer 2 that serves as a policy definition body for the enterprise 4. Secondary issuer 2 then adds policies to the payment card to express limits that enterprise 4 would like to impose on users 3 that will make purchases with the payment card from a merchant 5. To accomplish this, secondary issuer 2 adds one or more policy descriptions to the payment card before providing it to user 3. Such a policy may be represented as a computer program (applets) able to run on the payment card of user 3 that functions to examine purchase information for automated approval. Thus, when user 3 attempts to make a purchase from merchant 5, the payment card will consult this policy and will not issue purchase credentials (approval data) to merchant 5 unless the policy of enterprise 4, as expressed by the policy program placed on the payment card by secondary issuer 2, is satisfied. If the policy is satisfied, then a payment instruction can be created by user 3 and merchant 5 for the payment system 6 so that merchant 5 can be compensated for the goods or services delivered as a result of the transaction. This payment instruction may be based on a digital signature created by the payment card of user 3 after it has confirmed that the policy is satisfied by the purchase. On the other hand, if the policy is not satisfied, a payment instruction is not created and the purchase request is denied.

[0039] Figure 2 illustrates a payment transaction over the Internet using the system of Figure 1. As illustrated, the cardholder 3 uses a payment terminal 7 to access the Internet for making an online purchase from a merchant 5. The merchant 5 submits the payment to its bank 8 for clearance of the transaction in a secure financial network 9 that debits the primary issuer bank 1 and credits the merchant bank 8 by the amount of the transaction. As illustrated, the secure financial network 9 is also connected to the Internet via a payment gateway 10 so as to enable secure access to the secure financial network 9 by the cardholder 3 and/or the merchant 5 under designated circumstances.

[0040] Figure 3 generally illustrates the architecture of a payment card 11 and terminal 7 in a system in accordance with the invention. As illustrated, the payment card 11 includes a card manager 12 and a payment manager 13 that together implement policies 14 of, for example, the primary issuer (bank) 1 and/or the secondary issuer 2. The terminal 7 on the merchant side includes conventional software 15 that is modified as necessary to provide product and merchant information to the payment card 11 for comparison to the stored policies 14 for determining whether to issue a payment instruction or credentials (approval data). Those skilled in the art will appreciate that the invention may be extended to allow for a hierarchy of secondary issuers and users with different policies and rights under such policies.

[0041] The invention has the advantage that the secondary issuer may enforce policies on users of its payment cards without the participation or knowledge of the payment system 6 or primary issuer 1. Any policies 14 that may be adequately expressed in the card policy language may be enforced in a manner that is transparent to parties outside of the enterprise 4. For example, the payment gateway 10 need not be modified. This benefits the payment system 6 by providing a marketing edge because of more flexible cards and additional benefits such as added fraud protection. The invention also benefits the primary issuer 1 by providing enhanced risk protection since primary issuer 1 does not need to be involved in policy definition and enforcement. The invention further provides the secondary issuer 2 with the flexibility needed to enhance risk management and privacy for its policies. The card holder 3 gains empowerment since policy enforcement capability of the secondary issuer 2 enables more payment cards to be issued with reduced risk since the chance of accidental deviation from policy is improved. The use of a hierarchy of issuers further enables an organization to create policies based on its organizational structure without the need for centralized policy development. [0042] Those skilled in the art will appreciate that many factors limit the ability to provide open application programming interfaces (APIs) so that the payment cards 11 may be programmed by parties other than the primary issuer 1. For example, such factors include the existence of appropriate mechanisms for delivering code to the embedded system of the payment card 11, standards that would enable portability between platforms, means to assure desired properties when the programs of independent parties are combined, and architectures that would allow extensions of the basic device functionality. As will be described in detail below, the present invention implements techniques from formal methods and programming languages to address these concerns.

II. OPEN APIS FOR PROGRAMMABLE PAYMENT CARDS [0043] The present inventors have developed techniques for providing an open API for payment cards such as smart cards and the like for implementation of additional policies provided by secondary issuers 2. The present invention uses a refinement architecture in which hierarchical state machines are used to develop policies with provable properties. The invention may be part of an integrated system that works with the GlobalPlatform on Java Cards or a variation thereof and the payment card architecture may be that of Oberthur CosmopolIC Java Cards or similar cards known to those skilled in the art. For example, the invention may be implemented on Java Cards used with conventional GSM cell phones.

[0044] The following description of open APIs in accordance with the invention is divided into five sections. Section 1 considers various options for delivering code to an embedded device with an open API. Section 2 focuses on the tradeoffs in using remote control and illustrates this with smart cards implementing the SET payment protocol. Section 3 introduces an embodiment of a programmable payment card in accordance with the invention. Section 4 surveys technologies that could aid the implementation of the exemplary programmable payment card of the invention, while Section 5 introduces the refinement architecture and the filter implementation as a means of realizing the programmable payment cards of the invention. 1. Delivery Architectures

[0045] One of the challenges for open APIs is how to deliver code to the device. Because of the diverse nature of the contexts in which embedded systems are used, there is a similar diversity of challenges and options for delivery. Some of the basic options are shown in Figure 4. The primary components of the system are the embedded computer 20 and its user 3. The embedded computer 20 is contained within a host device 21, which could be a car, a vacuum cleaner, a cell phone, or many similar devices. The embedded computer 20 may be permanently encased in the host device 21, as in most appliances, or it may be removable, as in smart cards for financial transactions or cell phones. The host 21 may include a capable computer itself, or it may derive its intelligence from the embedded computer 20. If the embedded computer 20 has an open API and the user is able to program it, then it must have some way to access new programs. There are at least four common options.

[0046] First, the user may be able to customize the device in a rudimentary manner through some input interface provided by the host device 21. Second, for serious programming, the host device 21 could accept some kind of removable media 22 that carries programming. Third, the device could get its programming as remote data 23 across a network link 24. Fourth, in the networked case, the code could be derived from the remote data 23 and moved to the host device 21 or the program could reside elsewhere (e.g., at remote control device 25) and operate by remote control over network link 26. 2. Remote Control

[0047] In a sense, remote control is the anti-thesis of embedded control, since it shifts intelligence from the embedded computer 20 and its host 21 to a remote host 25. The effects of this shift can be particularly appreciated in the contrast between magnetic stripe tokens versus smart cards. Both of these are familiar contents of wallets, used for purposes like payment cards and loyalty programs. Magnetic stripe cards contain data and their processing is based solely on control from a local or remote host; smart cards contain a processor and are able to supply a limited amount of embedded control when inserted in a suitable host port. [0048] An example helps illustrate the distinction. One may carry a Starbucks card in her purse that is used to purchase drinks from participating branches of this coffee shop vendor. This is a magnetic stripe card that indexes an account with Starbucks. Money is periodically put into the account by giving the card and some cash to a clerk. The card works at branches other than the one that took the cash and acts as a kind of electronic wallet. When the user wants to make a purchase with the card, the index is used to determine the balance, from which the charges are deducted. By contrast, a smart card embedded into an ID card may serve as an electronic wallet, able to hold a digital representation of money for use with certain services, including, for instance, the vending machines in a particular building. The main difference between the magnetic stripe card and the smart card is where the processing is carried out. The magnetic stripe card has no embedded control; it provides only data, possibly encrypted to protect sensitive data like a Personal ID Number (PIN). The smart card, by contrast, is able to do some on-board processing and is able to protect cleartext data on the card by physical means and interface limits as well as encryption. The smart card is especially well-suited to offline operation since it cannot easily be duplicated, so this is a good fit for vending machines, which may not have the option of checking an account balance over a network link. Magnetic stripes are also more vulnerable to offline attack: if data is encrypted with a PIN on a magnetic stripe, it would be easy to check all possible PINs to determine the encrypted value. [0049] Network connectivity is a crucial factor in whether remote control is feasible. When it exists, it can contribute significantly to security and simplicity. Network connectivity may partially explain the wider use of smart cards in Europe compared to the United States. Balances for payment cards in the U.S. were initially checked by a telephone call, whereas European transactions commonly relied on the embedded control in a smart card. Models for payment card transactions will now be considered in more detail as a way to study tradeoffs between embedded and remote control.

[0050] Payment cards are a major means for carrying out consumer purchases, competing with other means such as cash and checks. They come in several flavors: credit cards provide a loan capability, demand cards allow for payments to be delayed for a month or so, and debit cards deduct costs immediately from a cardholder's bank account. They typically provide for three to five participants. A typical scenario is a cardholder visiting the premises of a merchant such as a department store. The user 3 has obtained her card from a primary issuer 1, typically a bank such as Citibank or MBNA. The card is inserted into a host (terminal) provided by the merchant 5, which contacts an entity known as the acquirer. As illustrated in Figure 2, the acquirer may be a computer operated by the bank 8 of the merchant 5. The acquirer contacts a payment system 6 with information like the amount of payment requested. Common payment systems 6 include secure financial networks 9 such as MasterCard and Visa. The payment system 6 may contact the primary issuer 1 of the card holder 3 to determine whether the cardholder 3 has enough money to make the payment. An approval propagates back through the acquirer to the merchant, who obtains an authorizing signature or PIN from the customer and provides her a receipt. There are a number of variations on this scenario. For instance, the primary issuer 1 may be a store, like Sears, rather than a bank, and the payment system 6 may be different. For example, when American Express is used as the payment system, the merchant 5 contacts the payment system 6 directly rather than contacting a merchant bank 8. For purposes of the invention, the main point is the fact that the transaction is distributed, online, in real-time, and the card 11 does not provide embedded control to the host 21 of the merchant 5. "[0051] ^' The basic scenario just described has changed in important ways with changes in buying habits. For instance, cardholder users 3 may not be physically present at the site of the merchant 5. At first this occurred primarily because of telephone purchases, but more recently consumers have used the Internet to make remote purchases, as illustrated in Figure 2. This has a significant impact not only on the convenience of the transaction for the consumer but also on the risks for the merchant 5 and payment system 6. In particular, fraud in Internet payment card purchases is a major cost. In response to this, a collection of organizations developed a standard for Secure Electronic Commerce (SET) to provide improved protections. In this approach, a user runs SET from a host computer, which may be her personal computer at home. SET can run from the host computer alone, but it may also be used with embedded control provided by a smart card for running (portions of) the SET protocol. The user host 21 and embedded system 20 exchange a series of messages over the Internet with the merchant 5. The merchant 5, in turn, exchanges SET protocol messages with a payment gateway 10, as shown in Figure 2, to ensure payment for the transaction.

[0052] In the SET protocol in which a user 3 makes a purchase from a merchant 5, who is paid by a payment gateway 10, before the protocol begins the user 3 and the merchant 5 negotiate a description OrderDesc of the item to be purchased and an amount PurchAmt to be paid for it. The aim of the protocol is to assure the merchant 5 that it will be paid for the order without revealing what it is to the payment gateway 10. At the same time, the user 3 and merchant 5 need to convince the payment gateway 10 that it is a legitimate purchase through the use of secret information, namely CardSecret and PANData. The PANData includes information such as the user's Primary Account Number (PAN) that should not be revealed to the merchant 5. The cryptographic technique is called a dual signature. It allows two parties (the merchant 5 and the payment gateway 10 in this case) to participate in (what they can prove to be) the same transaction without revealing all information to both parties. A simplified version of the purchase request protocol based on the formal treatment has been described by Bella et al. in a paper entitled "The verification of an industrial payment protocol," Proceedings of the 9^th ACM Conference on Computer and Communications Security, Washington, DC, November 2002, which, in turn, was derived from the SET Secure Electronic Transaction Specification: Formal Protocol Definition, May, 1997. SET uses PCKS envelopes and X.509 certificates. To keep things simple, one may omit information in messages about certificates and use a simplified notation. Herein, [X]s is used to denote message X together with a signature by subject S, and {X}s for message X encrypted for subject S, and H(X) for the hash of message X. [0053]^' The messages in an exemplary SET purchase request are given in Figures 5 A and 5B. In PInitReq, the user (C) 3 sends a challenge Chall_c to the merchant (M) 5, together with a local identifier LID_M. In PInitRes, the merchant 5 responds to this with a unique transaction identifier XID, a challenge Chall_M of its own, as well as the local identifier and challenge from the user 3, all signed with his private key. The third message in the protocol, PReq, is its essence. The user 3 sends the merchant 5 the dual signature. It consists of two parts. A first part, OIDualSign, contains information for the merchant 5. In particular, it includes the order instruction data, OIData, which connects the request to the agreed purchase item and payment amount. A second part, PIDualSign, contains information for the payment gateway. In particular, it connects the request to the payment instruction data PIData, which includes the PANData and a hash of the card secret. Both of these parts are sent to the merchant 5, who is able to check a signature in PIDualSign to connect the purchase and order information, but is unable to learn the purchase information because it is encrypted under the public key of the payment gateway 10. The merchant forwards PIDualSign to the payment gateway (P) 10, who then confirms the transaction. Variations of these purchase credentials may be used to validate the transaction using techniques known in the art. For example, while a payment card implementing a protocol like the SET protocol may issue cryptographically trusted credentials to indicate approval of a transaction, other types of approval messages may be sent by other electronic transaction protocols.

[0054] The SET protocol is characterized by a number of secrets and authentication operations. While the protocol could be implemented on a host PC and these secrets could be stored there, it is beneficial to keep some of the sensitive information on a tamper-resistant smart card. There have been a variety of attempts to support SET with embedded control provided by smart cards. The Chip Electronic Commerce (CEC) specification aimed to provide SET for Europay Mastercard Visa (EMV) smart cards. The Chip SET (C-SET) pilot from CyberCard provided a translator that enabled SET to work with a smart card. The vWALLET smart card was a SET card developed as part of the e-COMM pilot initiated by Gemplus, VISA International, France Telecom, BNP, Societe Generale and Credit Lyonnais. Recent work has produced a SET implementation for the Java Card. This work, and a number of related technologies for the Java Card, will be discussed further below. While SET implementation for the Java Card is described in the context of an exemplary embodiment of the invention, those skilled in the art will appreciate that other digital payment protocols may be used to implement the techniques of the invention. 3. Programmable Payment Cards "^"[0055] An architecture and application will now be introduced that provides a range of interesting challenges for open embedded control using the techniques of the invention. The application is a Programmable Payment Card (PPC). As noted above with respect to Figure 1, it is common for a primary issuer 1 , such as a bank, to provide payment cards to an enterprise 4 so the enterprise 4 may enable its employees 3 to make purchases with the cards. This improves efficiency by empowering employees. However, it does have the limitation that employees must be trusted to some extent to use the payment cards properly in accordance with policies 14 under which they were given the payment card. A simple policy would be to restrict the value of the purchases that can be made with a given payment card within a given time frame such as a month. Another possibility is to issue a payment card that is specific to a particular vendor, so an employee with a payment card may purchase only from the authorized vendor. Families also act like enterprises in this respect, offering payment cards to older children to be used in emergencies or for other purposes. Some policy can be enforced. For instance, a parent could open a bank account and obtain a debit card against this account to prevent a child from spending more than the balance of the account. In general, however, the policies 14 that govern payment cards in enterprises 4 and families are too complex to be enforced by the issuing bank 1 and the payment gateway 10. Moreover, issuers 1 and payment gateways 10 may not be eager to know or enforce policies of secondary issuers 2 such as enterprises 4 and parents since this adds transaction complexity and may create liabilities. Another factor is privacy: secondary issuers 2 may not want to communicate policies to banks, stores, payment gateways, and other external entities.

[0056] In accordance with the invention, it is possible to design a payment card that accepts policies from secondary issuers 2 after the payment card was originally issued. For instance, an enterprise 4 'creates' a payment card that is given a specific budget each month, or a family may "create' a payment card that may only be used to purchase hotel accommodations. To some extent issuers do try to distinguish their payment cards by offering special ways to customize them. For instance, there are payment cards targeted at small businesses that help the owner control risks for employees charged with card-based procurement. If, however, the owner of a small business wanted a policy that was not wanted by thousands of other similar businesses, then it is unlikely that a primary issuer 1 would be willing to create such a custom payment card. As is apparent from Figures 2 and 4, one possibility is to provide for some form of customizable remote control. For instance, one could augment Figure 2 so that the payment gateway 10 not only consulted the 'primary issuer' 1 (typically a bank) but also the secondary issuer 2. Suppose, for instance, that a secondary issuer 2, such as a university, wanted to issue payment cards to "employees 3 that could only be used to make purchases from a specified collection of merchants 5. When an employee attempted a purchase, the payment gateway 10 would contact a server at the university with information about the purchase. The university's server would need to approve the request before the payment gateway 10 would authorize the purchase. This approach, based on remote control, has a number of the desired benefits, including significant customizability. It complicates the approval process, however, and the merchant 5 and payment gateway 10 may consider it too cumbersome to include additional online checks involving a diverse range of parties.

[0057] Another idea is to use embedded control for policy. In this approach, policy is installed on the payment card itself by the secondary issuer 2. This has the significant limit that it only works for payment cards that are smart cards using a protocol like SET, with a sufficient amount of memory and protection to enforce the policy. The present invention includes embodiments of such a smart card as will be explained in further detail below. 4. PPC Technologies

[0058] The value of an open API for smart cards was recognized in the 1990's and, in particular, the Java Card is a widely accepted instantiation of this today. This section sketches background for some of the relevant technologies that could be used to develop Programmable Payment Cards (PPCs) in accordance with the invention. These technologies include, for example: smart cards, the Java Card, the GlobalPlatform, byte code verification on the Java Card, and payment protocols on the Java Card.

Smart Cards

[0059] Smart cards, also known as integrated circuit cards, were invented in the late 1960's and are now commonly used for personal identification, payment, communication, and physical access applications. There are many smart card vendors and the ISO 7816 series of standards provides an industry-wide baseline. There also are a number of kinds of smart cards. The focus of the present invention is on microprocessor contact cards. These include a tamper-resistant embedded microprocessor that enables the card to do certain kinds of calculations and a set of contacts that allow the card to get power and communicate through a Card Acceptance Device

(CAD). They are commonly distributed in a credit-card-sized plastic substrate and provide a degree of tamper-resistance against physical efforts to learn the contents of the card memory or subvert its computational functions. Aside from the ISO 7816 standards there are standards for smart card Subscriber Identity Modules (SIMs) in telephones series of standards that support the

Global System for Mobile Communications (GSM), as defined by the European

Telecommunications Standards Institute (ETSI), other standards include GSM 11.11 and GSM

11.14, which define interfaces and toolkits respectively, and GSM 03.19, which defines a SLM "API for the Java Card platform. Also, EMV provides standards for cards to suit the needs of the financial industry (www.emvco.com).

[0060] Smart cards typically provide three kinds of memory: Read Only Memory (ROM),

Electrical Erasable Programmable Read-Only Memory (EEPROM), and RAM (Random Access

Memory). ROM is used to store fixed programming and parameters. It holds data even without power, but cannot be written after the card is fabricated. ROM holds the operating system of the card and permanent applications. A typical card might have 64 kilobytes of ROM. EEPROM can also be preserved when the card has no power and, unlike ROM, it can be modified during the service life of the card. It can be used to hold data and applications that are added after the card is made. However, it is slow to write to EEPROM and EEPROM supports only a limited number of such writes, so EEPROM is not appropriate for often-changing variables. A typical card might have 16 kilobytes of EEPROM. RAM provides the necessary workspace for computation. RAM may be modified quickly, and RAM does not wear out with many modifications. However,

RAM is expensive on a smart card, and memory in RAM is lost when the card is not powered. A typical card may have only 1 kilobyte of RAM.

Java Cards

[0061] An API for using Java to program smart cards was introduced in 1996 by Slumberger.

This effort was expanded to include other companies in an industry consortium called the Java Card Forum. This has evolved to a collection of specifications supported by Sun (java.sun.com/products/javacard) covering the Java Card API, the Java Card Runtime Environment (JCRE), and the Java Card Virtual Machine (JCVM). The current specification is 2.2 and it offers a good platform for open embedded programming. In particular, it supports a restricted subset of Java that can be compiled to JCVM byte code and a run- time system that enables this code to run in a restricted context. The rules for communicating between contexts enables multi-application programming with a limited degree of sharing. [0062] The Java Card supports many of the familiar Java programming constructs such as packages, classes, interfaces, exceptions, inheritance, and dynamic object creation. It has a limited collection of data structures including booleans, bytes, short integers and one- dimensional arrays, but not long integers, double, float, characters, strings, or multi-dimensional arrays. There is no dynamic class loading, object serialization, or threads and no garbage collection. The Java Card does not support the Java Security Manager, but instead provides applet firewalls that protect distinct groups of applets through contexts. Other approaches to open multi-application smart cards include MultOS (www.multos.com) and Smart Card for Windows. GlobalPlatform [0063]^' Java Card programs are created by first making Java bytecode and then processing this to create a Converted APplet (CAP), which is then loaded and installed on the card. An especially important aspect of this process is the fact that type checking is carried out in these steps rather than on the card. This raises a challenge if the development environment is not trusted by the card. In a multi-application open card this is not an unusual state of affairs since applications from different vendors may not trust each other. One approach to deal with this problem is to rely on the primary issuer 1 to certify that programs are well-formed and secure. [0064] Visa developed an architecture in the 1990s to instantiate this approach. The architecture was first called the Open Platform and is now subsumed in an industry consortium called the GlobalPlatform (www.globalplatform.org). The architecture is intended to be independent of the underlying smart card runtime system but assumes that the system supports features like the ability to protect confidentiality and integrity between applications installed post-issuance by parties that do not wish to trust each other. It also aims to keep the primary issuer 1 in substantial control of the card while not requiring the primary issuer 1 to know all details of the providers. An example is illustrative. Suppose a merchant 5 would like to provide a loyalty application that gives the user 3 credit for shopping with that merchant. 5. If a patron is visiting the merchant 5, it would be convenient to use the terminal of the merchant 5 to download the new application to the patron's card without the need to contact the card issuer 1. In Figure 4, this approach enables software to be provided from the local host device 21 without the need to contact some kind of remote storage 23, or at least to contact remote storage 23 under the control of the party that owns the local host 21. Another class of examples that motivate the GlobalPlatform are applications that hold sensitive information. Examples include a car rental company that keeps information about a driver or a medical application that keeps health care and insurance records.

[0065] This GlobalPlatform architecture is illustrated in Figure 6. A Runtime Environment 30 underlies the system, and card functions are controlled by a Card Manager 31. The Card Manager 31 (same as Card Manager 12 in Figure 3) uses a collection of Provider Security Domains 32 to determine the rights of parties to add Provider Applications 33 to the card using the GlobalPlatform API 34. Each security domain 32 includes keys needed to authenticate the provider through a CAD before authorizing the installation of the provider's application. This authentication is carried out by the Card Manager 31 through the functions in the API 34. [0066] The problem of how to ensure that programs satisfy the necessary properties before they are installed and how to keep control in the hands of the primary issuer 1 is illustrated in the steps involved in how the secondary issuer 2 loads and installs an application. This process is illusfrated in Figure 7. In Step 41, the primary issuer 1 produces a payment card with a collection of security domains and, in Step 42, the payment card is activated. In Step 43 the secondary issuer (application provider) 2 creates an application and, in Step 44, obtains the rights to a security domain. In Step 45, the secondary issuer 2 obtains the necessary cryptographic keys to prove her rights. The secondary issuer 2 submits her program to a certifier in Step 46, who reviews it for security and other concerns. The submitted program does not need to contain private information of the party that will receive the payment card. Moreover, the certifier could be the primary issuer 1 or an independent certification authority. In Step 47, the certifier then supplies necessary authentication data such as a signature on the program that can be checked by the card manager. In Step 48, the secondary issuer 2 uses a CAD to download the approved application onto the card, which is installed in Step 49 once all of the security checks have succeeded.

Byte Code Verification on Java Cards

[0067] The use of certification by digital signature to ensure security features of provider applications has a number of drawbacks. In particular, it takes back some of the primary benefit of post-issuance installation of applications by making it contingent on Steps 44-47 indicated with dotted lines in Figure 7. Eliminating these steps by developing some form of practical on- card verification has been an interesting research objective for the last several years. One possibility is to use a defensive virtual machine on the card that checks types at runtime. This is expensive, however. If the types are checked statically off-card, then there is no way for the card to ensure security without repeating the checks, so on-card static verification is the only alternative. Static verification of Java programs in the JVM implementation is too expensive to perform on-card, so some alternative is needed. One approach is to augment the usual verification so that it provides 'hints' to aid re-verification on the card. This approach can be realized by providing type maps with additional type information for stack and register contents as a supplement to the usual Java byte code. Although generating the type maps may be expensive, it is easier to verify the code with them, so this can be exploited by the on-card verification. A practical way to structure this is shown in Figure 8.

[0068] As illustrated in Figure 8, the basic idea is to insert an 'assurance layer' at the end of the off-card code generation and before the on-card installation. Figure 8 depicts the following steps.

In Step 51 a Java compiler creates a class file, which is input in Step 52 to a CAP converter to create a standard CAP file. In Step 53 this CAP file is converted to include assurance information such as a type map that can be processed in Step 54 to confirm on-card that the code is well-typed. Step 54 uses the type map information to deal with the limitations of on-card verification. The verified CAP file is then used in Step 55 to create a verified applet that can be run in a non-defensive virtual machine 56. A similar strategy was developed for the Sun virtual machine for mobile devices, where a 'preverifier' was used to create the type maps. [0069] Another strategy for on-card verification based on the steps in Figure 8 is described by Leroy in an article entitled "Bytecode verification for Java smart card," Software Practice & Experience, Vol. 32; pp.319-340, 2002. The idea in this case is to transform the CAP file into a form where byte code verification can be carried out on-card. The basic observation is that two assumptions about the Java program to be processed and one assumption about the Java runtime environment suffice to eliminate the space overhead imposed by type maps. The runtime environment is assumed to initialize non-parameter registers on method entry to a safe value such as a null reference. Assuming that this is satisfied, the output of a standard Java compiler can be transformed to satisfy the two assumptions on programs: the operand stack is empty at all branch and branch target instructions, and, for each method evaluation, each register has only one type. If one accepts that the restriction on the runtime is acceptable for JCRE, then the main questions concern: (1) the overhead imposed by the transformations to achieve the other two assumptions, and (2) the cost of the on-card verifier in time and memory. Tests show that the transformation increases code sizes only slightly (less than 3%) if at all. The space required by the verifier code can be estimated at 10 kilobytes, and it is estimated that verification can be carried out on a Java Card at one kilobyte per second. This can be compared to an EEPROM budget of 32-64 kilobytes for all provider applications.

Payment Protocols for the Java Card

[0070] With the GlobalPlatform architecture and technologies for on-card verification there is a range of possibilities for ensuring the desired properties of post-issuance provider code. A question remains about the specifics of these guarantees when the card must share its processing with local and remote hosts, as it does, for example, in the SET protocol. There are many payment protocols other than the SET protocol, but the SET protocol is an interesting representative. Moreover, its specification is publicly available and has become a benchmark for academic case studies. Hence the focus on SET here: other payment protocols may be more interesting commercially, but the technologies required will be appreciated by those skilled in the art to be comparable to those needed for SET.

[0071] The SET protocol will now be examined with respect to the potential responsibilities of the embedded computer 20, that is, the smart card. The host device 21 provides network connectivity and power and can carry out parts of the computation that are not considered sensitive. The terminal 7 is likely to be chosen by the user 3 or the merchant 5, although it may sometimes be chosen by the primary issuer 1. For the current discussion, it will be assumed that the host device 21 consists of a PC and terminal chosen by the user 3 and that is trusted by the user"?, but that risk mitigation is desirable. For example, a corrupted PC should be unable to complete transactions if the payment card is not present in the reader and should not be able to confer the ability to make purchases to other machines. If the SET protocol is implemented entirely on the PC, then these guarantees cannot generally be made. If the PC has access to the keys that authorize transactions, then it can carry out transactions whenever it is attached to the network, and, if the physical security of the PC is lost, then the keys can be exported to other machines so they can make transactions. Given these risks, it is desirable to determine which of the steps in the SET Purchase Request Protocol of Figure 5 should be carried out on the smart card.

[0072] To see the challenge, the checking of certificates used to encrypt messages will be considered. In the PReq message the user (comprising both the host device 21 and embedded computer 20 for now), includes information for the payment gateway 10 such as the PANData, encrypted with the public key for the payment gateway 10. Suppose that the smart card is responsible for the signing and encrypting operations but checking of the certificate for the payment gateway 10 is carried out by the host PC. The host PC could substitute a fake certificate so that the card put the PANData in a message encrypted under a key selected by the host device 21, which could now obtain and store or distribute the PANData. It thus appears necessary to assign certificate checking to the card. However, checking certificates typically involves checking a chain of certificates starting from a root certificate and also checking revocation status by inspecting referenced Certificate Revocation Lists (CRLs). Full certificate checking is a complicated operation that requires significant memory and (if CRLs must be obtained remotely) network connectivity. Even assuming that the smart card could muster the space and computational capacity to do this, there is an more intrinsic problem: the lack of a clock with which to check expiration times.

[0073] Indeed, it is general challenge regarding the use of a smart cards to ask which parts of the protocols can run on the terminal under various models of the trust level for the terminal. Lyubich describes in a PhD thesis entitled "Architectural Concepts for Java Card Running a Payment Protocol and Their Application in a SET Wallet," University of Rostock, 2003, a general approach to this division based on a form of multi-level security. Sensitive values such as the private key for the card and the PAN are given high security level, while other data such as the OEData and XID are given low security level. The method partitions the code implementing the protocol into components that are assigned high and low values based on their treatment of sensitive values. High valued components must run on the card, whereas low valued components can be implemented on the terminal. There are also techniques to deal with the verification of certificates by the smart card. Lacking garbage collection, a Java Card is not able to do ordinary certificate checking, but it can engage the host in a sequence of messages that restrict the amount of memory the card needs to allocate at each step. Another idea is to entrust certificate checking to a remote control service, although this complicates the networking in transactions and raises questions about how the card knows what certificate is being checked given its inability to store and parse the certificate itself. It is possible to check the certificate locally in pieces while using a remote service to confirm the time. 5. Refinement Architecture

[0074] A variety of technologies have been described above that could contribute to developing the concept of 'programmable payment cards.' As noted above, smart cards provide the ability to embed some level of protected control in a host. In accordance with the invention, Java Cards provide the ability to add post-issuance programs that might serve as approval policies. Such programs can be checked by the card using a digital signature, if the card supports the GlobalPlatform API, or verified on-card, if the card supports the assurance architecture in Figure 8. Sensitive steps of the protocol can be protected by the card while letting the host deal with less sensitive steps to help address card limitations. However, an overall model for reasoning about the security objective of a programmable payment card is still missing. The architecture described by Lyubich provides a significant part of what is needed by modeling secrecy requirements. Secrecy is pivotal to controlling authorization, which is the main objective of the programmable payment card. However, it is not equivalent. For instance, a protocol that does not provide replay protection might allow an adversary to duplicate a transaction even if he is unable to decrypt the transaction messages.

[0075] The refinement architecture of the invention is based on the simple idea that the post- issuance programs on the card should always limit, and never expand, the sensitive transactions that a card is able to carry out. In a basic form, this is similar to a network firewall. Filtering firewalls examine packets and reject packets that match certain undesirable patterns. So, applying this concept to payment cards, one could impose a 'firewall' filter on the card that prevents undesirable messages from leaving the card. Communication units on smart cards are called Application Protocol Data Units (APDUs); they are classified into APDU commands and responses. However, it may make more sense to view communication units at a higher level. For instance, with a SET-based payment card, primary attention may be on filtering PReq (purchase request) messages, or, more precisely, preventing the host from sending PReq messages that do not satisfy the policy of secondary provider but would be accepted as valid by the merchant 5 and payment gateway 10. For example, suppose that merchants provide an OrderDesc (order description) that includes a service class such as whether the service is for accommodation or entertainment. Then the card filter could insist, for instance, that a PReq message will be created only with an OrderDesc for accommodation. This would refine the possible card events to include only acceptable accommodation purchases while eliminating unacceptable entertainment purchases. This approach makes at least two key assumptions that should be noted. First, message elements like OrderDesc must contain information on which policy can be based. If there is no service classification then it would be impossible for the card to make the necessary distinction. Second, the filter provider must trust that the merchant 5 and payment gateway 10 respect the payment protocol and the merchant 5 provides an honest OrderDesc. In particular, the user 3 should not be able to collaborate with the merchant 5 to formulate an order description that circumvents the filter. For instance, the merchant 5 must insist on classifying entertainment as such even if it might cause a lost sale because of the policy filter on the card. [0076] It is possible to implement the refinement architecture using the filtering concept. This can be done by assuming that all of the technologies discussed in the previous section are available. One must also assume some key trust relations. First, the user 3 trusts the host device 21 she uses. Since this is likely to be her PC, this is a credible assumption. Second, the primary issuer 1 and secondary provider 2 trust the merchants 5 and payment gateways 10 as far as this is required for the SET protocol. Trust in the merchants 5 includes trusting that OrderDesc provides an accurate description of the item being purchased. It does not include trusting the merchant 5 to use the same PurchAmt with the payment gateway 10 that it used with the user 3 since this is already ensured by the payment protocol, e.g., the SET protocol. Third, the card needs to protect its integrity against physical attack by the user 3, and against logical attacks from the host device 21, merchant 5, and other parties to whom the card could be connected by a network link. A variety of additional assumptions would needed to prove the security claims formally, but these give a good start. The idea is to formulate the refinement as a conjunction of filters that are registered by secondary providers and invoked by the program that creates the PReq message. These filters are applied to the pair (OrderDesc, PurchAmt) together with auxiliary data such as the identity of the merchant and the time of purchase. This is called the filter refinement implementation.

[0077] The steps in the filter refinement implementation may be divided into installation steps by which a secondary issuer (application provider) 2 adds a filter, and transaction steps in which a user creates a purchase message. Messages for installation are illustrated in Figure 9A. The host of the card issuer loads and installs a CAP for an approval applet (filter) with the aid of the card manager 31. The approval applet has its own installation method, which is invoked by the card manager 31 to initialize the approval applet. As part of this set-up, the approval applet obtains the Application IDentifier (AID) object of the transaction applet by providing a well- known reference value to the card manager 31. It uses this to access the Shared Interface Object (SIO) of the transaction applet. It invokes a registration method in this SIO to provide a reference that can be used by the transaction applet to later get the SIO of the approval applet. If this registration is successful, then this is indicated to the approval applet, the card manager 31, and, finally, the host computer.

[0078] Figures 9B-9H diagrammatically illustrate the card programming process in accordance with the invention. As illustrated in Figure 9B, the card issuer 58 issues a card 60 with predefined security domains. As illustrated in Figure 9C, the card 60 is then provided to the primary provider 1 for programming of the transaction applet (TApp). In Figure 9D, the transaction applet (TApp) code is certified by a certification server 62, and installation instructions for TApp are created. The certified CAP file is then obtained by the primary provider 1 from the certification server 62 as well as the authorized load and install instructions for TApp (Figure 9E). Then, as described above with respect to Figure 9A, TApp is installed in the card 60 by the primary provider 1 (Figure 9F). Then, as also noted above with respect to Figure 9A, the card is provided to the secondary provider 2 for the creation, certification and installation of the approval applet (AApp) (Figure 9G). The card 60 (with TApp and AApp installed) is then provided to the user 3 for use with a host device 7 including host code 15, as illustrated in Figure 9H, for a local merchant transaction or an Internet purchase transaction. [0079] The steps in the transaction process are shown in Figure 10. When the host 7 attempts to send a payment message, it needs to have the card 60 create the digital signatures. To do this, the host 7 passes purchase information D to the transaction applet TApp on the card 60. This information includes OrderDesc, PurchAmt and other information. The transaction applet TApp has a list of approval applets AApp that it developed as these applets registered themselves. It now and then invokes each of these and provides them with D to get approvals. In Figure 10, there are two approval applets AApp 1 and AApp 2 that have been installed by providers. They act as filters on the information D. Only if both of them approve of D will the transaction applet TApp create the digital signatures that the host needs to complete the purchase transaction. In particular, without the ability to create PReq, the user 3 and host 7 are unable to convince the merchant 5 and the payment gateway 10 to approve the purchase of the items in OrderDesc. The card use process, including the use of the transaction and approval applets to generate approvals, is illustrated graphically in Figure 11. [0080^"] Now, it must be determined what is needed to ensure the integrity of the refinement filters. For instance, could a user install her own filter and use this filter to force approval of unauthorized purchases? The protocols in Figures 9 and 10 do not allow a filter to do more than refine the set of allowed events unless either (1) they have been given access to keys and other data necessary to complete transactions themselves or (2) they can corrupt the card memory to obtain these keys or otherwise trick the card into creating needed parts of PReq messages. The first of these is handled by choosing the programming interface for the card 60 and transaction managers so that resources available to approval applets are limited to the purchase information they need. The second problem can be handled in either of two ways. In the GlobalPlatform approach, the approval applets can be inspected in advance by a certifying authority (Step 46 in Figure 7). The card will not load an approval applet without the necessary digital signatures. The certifier can perform checks such as showing that the CAP file is well-formed. In the method of Figure 8, the certifier is unnecessary and providers are able to place 'assurance transformed' CAP files on the card 60 without needing a digital signature. The card then verifies such applets (Step 55 in Figure 8) and they are subsequently invoked by the transaction applet to obtain approvals. [0081] There are some immediate questions that arise about the refinement filter implementation. What happens if someone installs a bad filter that prevents the card from performing any transactions? Or, what if two filters interact to have this effect? One can assume that someone in physical possession of the card 60 has the ability to destroy it, so the main threat arises if the primary issuers 1 are somehow able to gain unwelcome remote access to the card 60. Thus, it must be assumed that whoever is in possession of the card 60 uses a host 7 that is capable of checking the credentials of a provider before allowing the provider to make an installation. This is different from insisting that the card 60 must be able to do this (as it does in the GlobalPlatform architecture). This can be viewed as an aspect of the requirement that the cardholder trusts her terminal.

[0082] Another question concerns how a provider can know what refinement filters are already present to avoid redundancy. This raises also the question of what APDUs might be implemented by providers. It was argued above that one can prevent new APDUs from threatening the transactions that the card is able to make since the applet firewalls provided by the Java runtime will protect sensitive information. In the filter model as described above, the only SIO provided by the transaction applet is the one for registration, so there is a limited ability to usurp functions of the transaction applet. For convenience, filters could provide an APDU that allows them to be queried for some kind of description of what they filter. However, an applet with a rich set of APDUs (or SIOs) might risk its own security if the interface enabled tampering by some unexpected means.

[0083] The refinement filter implementation has the advantage that it can be used without certifying or authenticating the filter code if on-card verification is possible. If it is possible or necessary to certify provider policies offline, then there are ways to go beyond the filter implementation and exploit technologies for proving refinement relations between policies. There is a considerable body of work on refinement, including automated systems linked to programming languages. One example of a line of work on refinement breaks the process down into steps such as assume/guarantee reasoning, witness selection, and algorithmic state-space analysis to check transition invariants. Methods like execution monitoring will be challenged by the size and time limitations of cards, but an executable monitoring language such as NERL could be useful to define effective high-level monitoring.

[0084] A key challenge in the design of embedded control systems lies in deciding which functions should be performed in the embedded device 20 and which should be performed remotely or locally in a more capable host. This tradeoff becomes more complex when the embedded control offers an open API. Open smart cards provide an early insight into specific challenges in this area since they have advanced to widespread recognition of the value of open APIs for embedded systems. Programmable payment cards offer a case study for architectural and assurance issues. Existing platforms and technologies, combined with the refinement architecture and filter implementation described herein suggest that such cards are feasible even for comparatively complex transaction protocols. Platform support based on authenticated code also enables the use of more advanced refinement techniques.

III. MODEL-BASED APPROACH TO INTEGRATING SECURITY POLICIES [0085] This section focuses on the implementation of a specific form of programs called policies into a payment card for implementing refinement filters of the type described above. A policy specifies whether or not a transaction should be approved, possibly based on the history of transactions. The policies need not be strictly financial in nature. Sample policies include, for example: "the total amount of money spent during the past month should not exceed a specified limit" and "transactions involving a specified list of emergency services are always allowed." These policies can be written by multiple parties, and installed at any time. While this offers flexibility, it is necessary to detect and resolve conflicts among different policies. Also, a new policy needs to be integrated with existing policies, checked for conflict with existing policies, and possibly checked for redundancy since on-card memory is limited. The invention thus addresses the following problem: how can one create and integrate modular security policies securely and reliably in such a way that the policies can function in an embedded environment? As will be explained below, the Java Card platform provides the basic ability to combine policies that are implemented as applets written in Java. It would be possible to simply write the policies in Java and to use existing Java-specific tools (for example, Java editors, type-checkers and model-checkers) to assure that the policies will behave as intended. However, this approach is unsatisfactory for the following reasons:

Java Card applets contain much low-level boilerplate code that deals with the particulars of the Java Card platform; this low-level code, which is orthogonal to the access control behavior of an applet, makes it more difficult to reason about the access control behavior of interest.

• Java Card applets are capable of implementing a wide range of behaviors; this makes it easier for a developer to accidentally include unintended functionality that is not necessary for access control.

• General purpose Java tools cannot exploit domain-specific knowledge to make validating a policy more efficient; general purpose tools also are not aware of the specific problems of which a policy developer is concerned.

[0087] The solution described herein is a model-based approach using a new formal model, called "policy automata," to define and reason about the security policies. This formal model concisely expresses the behavior of interest, while leaving other functionality to be supplied by an automatic code generator. This focus on access control and policy integration allows the developer to concentrate on correctly implementing the core functionality of an applet. Similarly, analysis tools can be optimized to check domain-specific properties. This approach therefore retains the ability to integrate modular policies, but it allows one to do so securely and reliably. Finally, the model is designed so that policies can easily be translated from a formal notation to Java Card applets in an exemplary embodiment, thereby making the model suitable for embedded devices.

[0088] A policy automaton is an extended finite-state machine that examines the requested transaction, and votes on it. Votes are written as rules in non-monotonic logic, such as defeasible logic, that essentially say which outcome the policy automata prefers and how strong that preference is. The domain of votes is also equipped with a decision rule that collects the votes of all the policy automata to either approve the transaction, reject it, or declare a conflict. The individual policy automata update their states based on this global resolution. Using this framework one can specify policies in a modular fashion. The constraints imposed by these policies are non-monotonic (as policies are added approval of a transaction can switch from yes to no and back to yes), and stateful (approval of a transaction depends on decisions on previous transactions). It will be shown herein that static techniques such as model checking may be used to detect potential conflicts among a set of policy automata, and also to check whether a new policy is redundant with respect to a set of existing policy automata. Those skilled in the art will appreciate that the policy description framework used herein is relevant in other contexts such as firewall policies, where multiple parties wish to independently add rules governing approval of access requests.

[0089] The policy implementation technique of the invention will be described by first presenting a policy description language and then presenting a prototype implementation of the policy automata technique of the invention using the tool Polaris. Polaris provides a graphical editor for specifying policies as extended state machines, and an enumerative reachability checker to detect conflicts and redundancy. As will be explained below, the development kit from Oberthur Card Systems has been modified to allow for the installation of applets onto Java cards in accordance with the invention. To install a policy onto the card, Polaris compiles a policy automaton into a Java class instance, downloads it onto the card, and registers the new policy with the manager routine that polls all the registered policies before deciding on a transaction. This architecture thus allows one to dynamically add policies to a Java card. Those skilled in the art will appreciate that other tools besides Polaris may be used.

[0090] This section is organized as follows. Section 1 discusses the conflicts that arise when policies are merged and how this behavior can be modeled. Section 2 introduces a target application, programmable payment cards, and discusses the technology that makes such cards possible. Section 3 presents a formal model, while section 4 discusses a prototype tool for working with policy automata. 1. Policy merging and conflicts

[0091] A common task for computer systems is to guard access to a resource. The policy that is used to grant or deny access is often based on a diverse set of criteria, possibly representing the interests of many different stakeholders. Describing such a policy as a combination of sub- policies may aid a developer by allowing her to focus on one piece of a policy at a time. However, when the individual policies are combined there is potential for conflicts or other interactions that make the combined policy inappropriate for its intended purpose. [0092] For example, consider three policies regarding the use of a swimming pool, where each policy represents the interests of a separate stakeholder: Pι_g is the policy put in place by the lifeguard, P_b is the policy put in place by the business administrators of the pool, and P_c is the policy put in place by the pool cleaner.

Pι_g: In an emergency no one except the lifeguard may enter the pool. The lifeguard may always enter the pool. No more than 30 people should be in the pool at one time. P_b: Nobody but the owner may enter the pool between 5pm and 9am. P_c: When 100 people have used the pool, it should be closed and cleaned. [0093] The policies are simple to understand and are modular in the sense that each is solely concerned with the interests of the respective stakeholder. However, the policies contain potential conflicts. For example, can the lifeguard enter the pool at 6pm? A model-based approach to designing and implementing such policies will need some mechanism to reason about conflicts among stakeholders' interests.

[0094] Non-monotonic logics are a family of logics in which new information may lead to previously valid conclusions being retracted. These logics are partially motivated by a desire to capture real world common-sense reasoning. For example, if one is told that Tweety is a bird, one may tentatively conclude that Tweety can fly. However, if one later learns that Tweety is a penguin, the earlier conclusion will need to be retracted. Non-monotonic logics are one possible tool for representing and analyzing the kind of conflicting swimming pool policies noted above and which, as will be noted below, may be used to implement card policies in accordance with the invention. In the pool example, one may encode a rule such as "no one may enter the pool after 5pm" by marking it a tentative rule, possibly overridden if one learns more information — for example, the lifeguard needs to enter the pool.

[0095] The policies described above also have features that are more naturally represented as a reactive system. The decision to admit a swimmer depends on the previous events at the pool. Imagine a gatekeeper at the pool who has to decide when to let people in. If the gatekeeper cannot see the pool from where she sits she will have to keep track of how many people have entered and left the pool in order to keep the number of people in the pool below 31 (to satisfy the lifeguard) and to stop admitting people when 100 people have used the pool (so that the pool may be cleaned). Accordingly, the model must have some notion of storing information and making decisions based on the history of past events.

[0096] As noted above, embedded devices like smart cards have minimal space for storing information so it is undesirable to maintain a complete history of past transactions. However, one should not arbitrarily restrict what information can be used to make access control decisions. One should record exactly the minimal amount of information needed by the policies. In the framework described below7thϊs is accomplished by making the security policies responsible for collecting their own information.

[0097] In order to represent state and handle conflicts, a hybrid scheme may be used to model interacting policies. The model described herein uses classical finite state automata, extended with some high-level constructs like variables, to model how policies react to and store information about previous events. Policy automata are chosen because they allow straightforward analysis and it is simple to translate them into code suitable for a smart card. In an exemplary embodiment, these policy automata interact with each other using defeasible logic, a non-monotonic logic designed so that statements may be proved or disproved efficiently — an important consideration if the policies must be integrated in smart card with limited computational power. This hybrid approach has been found to succinctly model many policies that one might want to install on a programmable payment card. 2. Programmable Payment Cards

[0098] As noted above, users may obtain payment cards such as credit cards and debit cards directly from a primary issuer 1 such as a bank from a secondary issuer 2 such as an employer or parent. This secondary issuer 2 may have policies that extend those of the bank. For instance, an enterprise 4 may stipulate that a card for an employee 3 is used only for business expenses or a parent may stipulate that a card can only be used in an emergency. Such policies can be enforced in basically two ways in most systems. The bank or payment gateway can (and typically does) enforce certain basic restrictions such as an outstanding balance limit on the card. Other polices are enforced in a more reactive fashion by the secondary issuer when reconciling the purchase records with bills it receives. An employee can be fired or a child admonished for deviation from policy.

[0099] As used herein, a Programmable Payment Card (PPC) is a payment card that may be specialized with custom policies written by one or more secondary issuers, such as an enterprise, a family, or even the user of the card himself. PPC policies can provide privacy and risk management. For instance, in some kinds of PPC it is possible to disallow purchases before they are made on the basis of policies that are never revealed to the bank 1, payment gateway 10, or merchant 5. In these cases banks and payment gateways may benefit from PPCs because they shift liability for policy enforcement to the secondary issuer 2 and user 3. Secondary issuers 2 benefit by preventing some problems before admonishing or firing become necessary. [0100] As a case study for purposes of specific analysis for policy integration, the architecture and implementation of PPCs presented above will be sketched. This approach is based on the GlobalPlatform implemented on Java Cards and provides for policies written in Java. These policies control payment transactions based on the Secure Electronic Transactions (SET) protocol, and the PPC implementation is based on an implementation of SET by Mykhailo Lyubich in an article entitled "Die architekturen von SET mit der Java Card," ITG Fachericht, APC 2001 Arbeitzplatzcomputer, 2001. However, there are two primary extensions herein. First, that PPC implementation is ported to run on the GlobalPlatform for the IBM JCOP Java Card simulator or the Oberthur CosmopolIC cards and, second, it is extended by a basic policy integration technique called "simple conjunctive refinement." In "simple conjunctive refinement," a collection of policies are consulted by a transaction management applet. Policies provide a boolean result and a SET transaction is allowed if, and only if, it is approved by each of the policies based on the form of the purchase request (PReq) message in the SET protocol. After it is issued, the payment card allows parties to add such policies but not remove them. Consequently, each new policy allows no more payment transactions than the payment card allowed before it was added. Policies must be approved by a certification process to ensure that they do not violate the language-based protection mechanisms of the Java Card Runtime Environment (JCRE). It is possible in principle for the JCRE to run defensively so that this step may be omitted, but this is expensive for the card. Fortunately, the policy certification only requires verifying that the program is well-formed code.

[0101] Implementation of the simple conjunctive refinement technique was unsatisfactory for two reasons. First, policies could not be expressed to override other policies as each policy had veto power over a transaction request. Second, the policies were written in Java, which it made it difficult to formally analyze a policy's behavior. The next section describes a formal model in accordance with the invention that gives a more expressive policy integration mechanism and a rigorous description of policy behavior. 3. Formal framework

[0102] A policy model as used herein approves or rejects a transaction request based on the characteristics of the transaction request and the history of previous transactions. The model is composed of separate policy automata that vote individually as to whether a transaction request should be approved. The votes are coalesced into an approval or disapproval using a resolution function.

3.1 Votes and Conflicts [0103] D is used herein to denote the abstract set of possible votes. Associated with J⁾ is a function/, which resolves votes into yes, no, or-r-, representing accept, reject, and conflict (or error), respectively. As a simple example, D contains yes, no, and maybe, and/maps a set of votes to yes if the set contains yes and does not contain no; to no if the set contains no and does not contain yes; and to -γ otherwise.

[0104] For the payment card application of the invention, defeasible logic is used to describe and resolve votes. Defeasible logic will be briefly explained here. A more detailed explanation of defeasible logic may be found in an article by Maher entitled "Propositional defeasible logic has linear complexity," Theory and Practice of Logic Programming, Vol. 1, No. 6, pp. 691-711,

2001, and the content thereof is incorporated herein by reference.

[0105] Atomic formulas and their negations make up the literals of defeasible logic. For example, p, q, -p, -q are all literals. Defeasible logic has three kinds of rules:

Strict rules are like normal implication: penguin — > -fly The meaning of this rule is "if penguin is true then fly is not true" (or, in other words, penguins do not fly).

Defeasible rules are like strict rules except that they may be preempted by other information. For example, the rule bird =*fly says that "if bird is true then we conclude that fly is true unless we have some reason to think otherwise."

Defeater rules are used to block the tentative conclusions of defeasible rules. For example, the rule injured -* -fly will block a rule like bird => fly since the knowledge that a bird is injured counteracts one's intuition that birds tend to fly. However, the defeater rule (unlike a similar defeasible rule) does not lead to the conclusion -fly since one has no intuition about whether injured birds fly or not and a tentative conclusion should not be made either way.

[0106] Each of the rules can have a set of literals on the left hand side instead of just a single literal. In such a rule, all literals in the set must be true for the rule to apply. [0107] In defeasible logic there are two notions of provability. Given a set of literals that are known to be true, called facts, a literal is definitely provable if it can be proved using strict rules and facts. A literal is defeasibly provable if it can be proved using facts and any of the rules. A formal description of the algorithm used to determine if a literal is defeasibly provable may be found in the aforementioned Maher article.

[0108] In the policy framework of the invention, policies vote by giving rules that reason about a special literal yes which stands for "approve the transaction request." More precisely, there is a set of atomic formulas F that is fixed for an application. The atomic formula yes is one element of F. If R is the set all rules (strict, defeasible and defeater) made of elements of F, then the set D of votes is the set of subsets of R. In other words, every vote d e D is a list of zero or more rules. All the votes are combined by taking the union of all the sets of rules. This combined set of rules forms the defeasible logic theory that may be used to test the provability of the formula yes. If the votes yield a theory in which one can defeasibly prove yes without making -yes defeasibly provable, then the transaction request is approved. If yes is not defeasibly provable, then the transaction is rejected. If both es and -"yes are defeasibly provable (possible in defeasible logic) then there is a conflict.

3.2 Policy Models [0109] Let The the set of all transaction requests for a particular application domain. For example, in an e-commerce application, Tmay be a set of integer-string pairs that represent the price and the seller of the transaction request. Let D be a set of votes. Definition: A policy automaton P is a tuple (M, X, qo, R, δ). The components of P are: M: A finite set of modes;

X: A finite set of variables, each of which has a type. V_x is the set of possible tuples of values for all the variables in A state q of the policy automaton is a pair (m, v) with m e and v e V_x, and Q = M * V_x is used to denote the set of all possible states. (Variables could be omitted and the set M could simply denote all possible states; variables are used to make automaton descriptions more readable.) q_0: An initial state {mo, vo) that specifies the initial mode and initial values of all the variables. R: The rule-set of P. R is a function:

R : Q x T→ D which determines how the policy automaton votes in a given state to process a given transaction. R is called a "rule-set" because in practice R is specified by attaching "rules" to modes in a policy automaton, δ: The transition function, δ . Q x T x {yes, no} → Q which governs how the policy automaton updates its state when a transaction request has been approved or disapproved.

[0110] As discussed in the next section, a policy automaton may be specified using a graph over its modes. The edges are annotated by guards and assignments that refer to the variables and transaction parameters, and specify the transition function δ. The modes are annotated with rules that refer to the current state and the transaction parameters, and specify the function R. Definition: A policy model is a triple (II, D, f) where II is a set of policy automata, D is the set of votes, and/is a resolution function that maps a set of elements of D to {yes, no, -γ).

3.3 Semantics [0111] For a policy model (II, D, f), where II = {P,, ..., P_k), let 0 be the set of states of each policy automaton P₍. The state of the policy model at any point in time can be described by a vector {qi,..., q_k), where each q_t e Q_t. Initially, each policy automaton starts in its initial state. The following describes how transactions are processed and states are updated. [0112] Suppose the current state of the policy model is (qi,..., q_k) and the current transaction

→ request is t. For each policy automaton P_it its vote is d = R(q t). We then evaluate d ), where

→ d = {d],...d_k}, and interpret the outcome as follows: yes the transaction request is approved. no the transaction request is rejected.

^■ _j- there is a conflict between two or more policies.

→ One desirable property for a policy model is that if votes d are produced by the individual

policies, thenfld ) =yes or no — in other words, policies do not conflict with each other when composed.

[0113] Once a transaction request is approved or rejected, each policy automaton updates its state. Intuitively, a policy automaton always has two possible transitions that it can follow — one to record approvals and another to record rejections. If a policy automaton is in state q and a transaction request t is approved, then the state is updated to δ(q, t, yes). Similarly, if the transaction request t is rejected, the state will be updated to be δ(q, t, no).

[0114] This update extends in the natural way to states of a policy model. For a state (q_/,..., q_k) of the policy model and a transaction t, let d = R(q_{, t) be the vote of the policy automaton R, and let a =f({d j,..., dk}). If a -yes or a = no, then: t (qι,..., q_k) => (q 'ι,..., q 'k) where q ', = δ(g,, t, a) gives the updated state of the automaton P_t. If α = -γ then there is a conflict between policies and the policy model moves into a special error state q_τ, essentially terminating the operation of all the automata. This case is denoted by:

<tτ {qi,..., q_k) => q_τ Once the policy model enters the eπor state it responds to all transaction requests with -r-, indicating an error:

tf_τ The update relation is now generalized to a sequence of transaction requests. Given a sequence of transaction requests T= tι,...,t_n, then:

→ rtα → q => q'

→ → if there exist model states , , ..., <?„_, , and α = a/, ..., a_n such that:

q => q_χ => ... => q_n__χ => q'

[0115] Given a policy model A and a sequence τ of transaction requests, A emits on x if for

→ . → the initial state q_Q of the model, there exists some q' such that:

_→ rtα →

<7o =* *' ^■

3.4 Conflicts

→ [0116] A policy model with initial state q_Q is conflict-free if for all sequences τ of transaction

requests, q_Q = q' implies q' ≠ q_τ It is easy to see that a conflict-free model will never emit - in response to a transaction request. Typically a developer will want to ensure that her policy model is conflict-free before deploying it.

3.5 Redundancy

[0117] Intuitively, a redundant policy automaton is one which has no effect on the responses to transaction requests.

Definition: Given a policy model A = (II, D,f) where II = {Pi, ..., P_k) and a model A' = (IF, D,f) where II' = II - {Pi}, then policy automaton Pj is redundant with respect to A' if for all sequences τ of transaction requests, A emits α on τ if and only if A' emits α on τ.

[0118] In some circumstances having a redundant policy automaton may be undesirable — it may be an indication that a policy is being overridden by other policies. At the very least, it indicates that a simpler, smaller model could be used to do the same job. If a device has a limited amount of memory in which to store programs, then a developer would want to avoid installing redundant policy automata. However, if a policy automaton P is redundant with respect to a policy model A - (II, D, f) it may not remain redundant if some policy automaton F is added to II. A developer may therefore want to install a redundant policy automaton on a device if she expects more policy automata to be installed on the device in the future. 4. Exemplary Embodiment

[0119] An exemplary embodiment that performs policy automata analysis and compilation in accordance with the invention includes a graphical interface for editing the automata, an analysis engine that checks for policy conflicts, and a code generator that creates Java Card applets that implement the policy automata. The architecture of such an exemplary embodiment is shown in Figure 12. The exemplary embodiment is implemented in Java using the Hermes code base. As illustrated in Figure 12, the embodiment has four modules:

Front end 70: A developer uses a graphical front-end to create, edit and save policy automata. The policy automata have the characteristics described above and are described using a graphical language made up of boxes and arrows that are annotated with small pieces of text; creating automata is much like using a graphics application like xfig or Adobe Illustrator. The automata arc stored as XML. The front end 70 must also interact with the analysis engine 72 to illustrate the outcome of any analysis procedures. Figure 13 shows a screen shot of the automata editor.

Analysis engine 72: The analysis engine 72 takes a policy model from the front end 70 and checks that the automata satisfy various properties the designer chooses: conflict-freedom, reachability of certain states or whether an automaton is redundant with respect to other automata. The analysis algorithms are discussed in more detail in Section 4.3 below.

Code generator 74: The code generator 74 converts a policy model into Java that is suitable for a Java Card. Each policy automaton is compiled into a separate applet that implements that policy. This architecture of separate applets allows new policy applets to be added to the card dynamically.

Payment card 76: The payment card 76 provides the run-time environment for the policy automata that have been compiled into Java Card applets by Java Card compiler 78. The payment card 76 takes part in a SET transaction with a remote website via a local PC that has a Java Card reader. Before the transaction takes place the policy model implementation must approve the purchase request.

4.1 Language [0120] Polaris uses a graphical language to describe policy automata. A policy model is created by drawing a number of rectangles, each of which represents a policy automaton. The set D of votes is fixed as lists of defeasible logic rules. Each of the policy rectangles can be annotated with a list of variables X that store information within the policy automata. Inside those rectangles, the developer can draw rounded rectangles that represent the policy automaton's modes. For example, Figure 13 shows a policy automaton with three modes being edited in Polaris.

[0121] The δ transition function is specified by drawing arrows from one mode to another. Each arrow is annotated withies or no, indicating whether the transition should apply to an accepted or rejected transaction request, a boolean expression involving the variables of the policy automaton and the transaction, and a list of updated values for the variables. The boolean expression is similar to the expressions in high-level programming languages like Java or C. For example, a transition from m to m' could be annotated withies and the expression "t .price<30 & count =1 ", where count is a variable and t is a transaction request, and variable update "count: = 2". Such a transition gives a partial description of δ, mapping ((m,v), t, yes) to (m', v¹) for all variable settings v where count = 1, for all t with a price under 30, and where v' has the same variable settings as v except that count is now 2.

[0122] The rule-set function R is specified by annotating the mode rectangles with rules. Each rule has a boolean expression (like the expressions attached to the transition arrows) referring to the current transaction request and the variables, and a vote d. If a policy automaton is in a mode m that is annotated with rule r and a transaction request arrives that, along with the current variable settings, makes the boolean expression true, then vote d becomes the policy automaton's vote. Votes are lists of defeasible logic rules written in the syntax of the Deimos defeasible logic query tool described by Maher et al. in an article entitled "Efficient defeasible reasoning systems," InternationalJournal on Artificial Intelligence Tools, 10(4), pp. 483-501, 2001. Each rule therefore gives a partial description of R. Figure 13 shows a list with one rule that has been attached to the "bonus purchase allowed" mode. The expression is "price < 100" and the vote is " {}=>yes", which is {} => yes written using ASCII characters. The rule essentially says "conclude yes tentatively unless others override."

[0123] Simple typing rules may be used to check if expressions involving policy automaton variables and the transaction requests are well typed. Each variable must be declared as a particular type (for example, a boolean, integer or enumerated type). Transaction requests are treated as records with a number of fields, each of which has a particular type. It is checked that types are only compared to or assigned to like types — for example, an integer is not compared to a symbol or a boolean variable is not set to 3. Checks are also performed on the graphical structure to ensure that the picture on the screen can be translated into a policy automaton.

4.2 Example of a payment card policy [0124] The following is an example of a policy model made up of the following policies: P₃: Allow up to 3 purchases per day. PE: Guarantee payment to emergency services twice.

P_cc: A cash card: spend no more than $500 total.

P_N: No alcohol may be purchased.

P_t: Prevent purchases of prescription drugs which conflict with the anti-depressant tofranil.

[0125] With respect to the last policy, P_t, it should be noted that tofranil is a prescription drug used to treat depression. It can be fatal when combined with a drug that is a monoamine oxidase inhibitor (MAOI). Policy P_t may be installed by a doctor or a pharmacist when the card holder begins taking tofranil. This policy will prevent purchases of drugs that conflict with tofranil, thereby reducing the risk that a mistake by a doctor or pharmacist that leads to a fatal drug interaction. Tofranil can also interact with another drug called albuterol, but the interaction is less severe so the policy automaton is not as insistent about rejecting purchases of albuterol.

Thus, the policies generally are not limited to financial constraints.

[0126] Figure 14 shows these five policy automata in a simplified form of the graphical language accepted by the exemplary embodiment. Variables are declared at the left of the diagram, along with the initial value of the variable. For example, the initial value of P_cc's variable total is 500. Modes are indicated by rectangles with solid lines. A mode's rules are contained in a rectangle with a dotted border within the mode. Rules are written in the form "if expression then vote". The expression E (t. seller) used in the rules of P_E is a predicate that is true if t.seller is contained in a set of approved emergency service sellers (for example, hospitals and ambulance companies). The word ALCOHOL in the rule of P_N refers to a standard product identifier that identifies a purchase as alcohol. Similarly, the words MAOI and ALBUTEROL in

P_t refer to standard identifiers for particular classes of drugs.

[0127] The rule's vote is written as a list of rules of defeasible logic. A few of the votes that appear in the example may be described as follows:

{}=>yes the transaction request should be approved tentatively but can be overridden

{} ~>~yes override a tentative approval

{}->yes; {}->e approve the transaction and assert that the literal e is true. Making e true signals to other automata that the transaction request is an emergency. ~e->~yes if e is not true then reject the transaction request. This vote allows P to override

P₃ and P_cc without conflicting with P_E- When no rule applies in a given state then an empty set of defeasible logic rules is used as the vote.

[0128] As described above, arrows represent transitions between modes. The annotation attached to the arrow has the form "expression ; update". The expression indicates when that transition is enabled and the update section determines how the variables are updated. For example, in P_cc the transition with an expression "yes & total=t .price" is enabled when a transaction request has been approved and the total is equal to the transaction price. If the update section is empty, then no change will be made to the variables. When there is no enabled arrow starting at a mode, then no update is made to variables or modes when the transaction request is approved or rejected. For example, if P_cc is in mode 0 and a transaction request is rejected, then the variable total is left unchanged and the automaton stays in mode 0.

4.3 Analysis

[0129] A policy model must be in one of a finite number of states. One may therefore use a conservative on-the-fly reachability analysis (using data abstraction when applicable) to look for states where conflicts occur. If none of the reachable states will emit -γ on any transaction request, then it can be determined that the model is conflict-free.

[0130] Checking a given state for conflicts involves evaluating the resolution function/on all possible combinations of votes in that state. In practice, the number of vote combinations is small as automata typically choose from two possible votes in a given state. Computing/may be done efficiently as Maher gives an algorithm for finding the consequences of a defeasible theory in time that is linear with respect to the number of literals and defeasible logic rules.

[0131] To check for redundant policies, for a given model state q let d-_ti be the vote that the

i-th policy automaton gives when processing transaction t in state q . The policy automaton Pi is redundant at q if:

V t T,f(D_q-_,^f(D '^- (1) where D _,, = {d^ _,,_„, 1 1 = 1 ... k) and D' _,, = D _ξ ,, - {d^ _,,_,/}.

[0132] Pi is redundant with respect to {P₂, . . .Pk} if it is redundant at each reachable model state. Redundancy may be checked by finding all reachable model states and verifying that each state satisfies equation (1). As discussed above, evaluating/^" for all transactions may be done efficiently.

4.4 Code Generation and the Java Card Platform

[0133] There are two types of Java Card applets that need to be generated: the manager applet and the policy applet. The manager applet is responsible for polling the policy applets for their votes, consolidating the votes to decide whether the transaction request should be approved, and then notifying the policy applets about the approval or disapproval. There is one manager applet on a programmable payment card and it must be installed before any of the policy applets. The applet is based on the Lyubich's SET implementation described above and most of the applet is concerned with the details of SET protocol. However, a defeasible logic engine has been added to the applet in accordance with the invention so that it can process the votes of the policy applets. Most of the manager applet's code deals with Java Card and SET protocols and is therefore static; the only code that needs to be generated dynamically implements the procedures for packaging the transaction request (whose type may vary between applications) and initializing the defeasible logic engine (since the resolution function/may be customized to some extent for an application).

[0134] The Java Card platform imposes certain constraints on the applet design. Garbage collection is not available on most cards, so care must be taken to allocate the minimal memory necessary. All data must be stored as 8 or 16 bit values. Unlike the standard Java platform available on desktops and servers, a Java Card has two kinds of memory: RAM and EEPROM. RAM is like the RAM in most computers - it can be read from and written to quickly, and it loses its data when power is cut off (for example, when a card is withdrawn from a card reading terminal). Due to cost and size constraints, RAM is limited to 1 or 2K in the most advanced cards. EEPROM will retain data when power is lost, and it is cheaper than RAM so it feasible to put as much as 64K on a single card. However, EEPROM can only be written to a limited number of times (typically on the order of 100,000) and writes are slow, so EEPROM should not be used for memory that is updated frequently.

[0135] The on-card defeasible logic engine (DLE) needs to account for these restrictions. The DLE needs to compute all the literals that are defeasibly provable given a defeasible logic theory. The memory required for the algorithm is partitioned into two parts: stable and volatile. Stable memory is kept in EEPROM and volatile data is kept in RAM. The algorithm keeps the rules of the theory in stable memory, while using volatile memory to track the proof status of each of the literals in the theory. While the total memory required by the DLE is proportional to the size of the theory, the volatile memory required is proportional to the number of literals in the theory. To conserve EEPROM memory, only a single copy of the rules is kept in the defeasible logic theory. This copy is maintained by the policy applet that is supplying the vote that contains the rule.

[0136] A policy applet implements a single policy automaton. Many policy applets may be installed on the same card. Starting from a template applet, the code generator 74 adds two methods get Vote and update, which return a vote and update the state of the applet, respectively. The set of all possible votes is computed by the code generator 74 and each vote is instantiated as a member variable stored in EEPROM. This set of votes is pre-computed to minimize the amount of RAM required at runtime. [0137] Figure 15 illustrates the P_E emergency policy from Figure 14 after the code generator 74 has translated it into Java code. Some of the code that deals with the Java Card platform has been deleted as this is common to all applets and would make the figure much larger. [0138] A smart card's limited memory makes code size an important consideration. Table 1 shows how much the code size increased for the Java Card implementation of the SET protocol when extended to use the policy integration architecture of the invention. The second column of the table shows the size of the converted applet (CAP) file. CAP files are the standard package format for Java Card applets. The Table 1 also shows the number of bytes required to represent the methods (executable code) and static fields (persistent data) of the applet; these two components are the largest components of the CAP files. As illustrated, after extending the SET applet with a defeasible logic engine and the code necessary to manage policy applets, the total applet size is only 38% larger.

Table 1 : Code size for original and modified SET manager applet 4.5 Adding policies dynamically [0139] The policy model described herein gives developers and users a formal framework for combining the policies of different stakeholders. Different departments in an enteφrise may each create their own modular policies and when these policies are installed on a card they may be checked against each other to ensure they are, for example, conflict-free. This increases the assurance that a payment card will behave properly when given to a user. However, the Java Card/GlobalPlatform architecture allows new applets to be installed after the card has been issued. In this section, it will be discussed how the framework may be adapted for the case where arbitrary parties, who may not be affiliated with the enteφrise that issued the card, wish to add new policies. The set of policies that are initially installed are called the base policies. The policies added later are called the supplemental policies.

[0140] In order to allow new policy automata to be checked with respect to previously- installed policies, it is required that an installed policy provide a way to access its policy automaton. This can be stored on the card or referenced by a URL. A developer will compose these policy automata with her new policy automaton and check that the new approval automata is conflict-free (or whatever property is desired). If the desired properties hold, the developer follows the steps described above to exploit the GlobalPlatform security model. As noted above with respect to Figure 9, the developer generates valid JCVM byte code and supplies it to a certification authority, who uses it to generate a CAP file with a digital signature. The CAP file, together with signed load and install instructions, are then supplied to the developer who uses them to load and install the new applet onto the card. The digital signatures protect the card from the installation of invalid CAP files. When the new applet is selected (a basic Java Card operation that chooses a particular applet for execution), it registers itself with the manager applet installed by the primary issuer. If the applet is subsequently removed, the manager applet disables the card.

[0141] In order to protect the functionality of the base policies from policies that were not analyzed, the resolution function is modified slightly. If the updated set of applets generates a -p, then the base automata is used to evaluate/using only the votes from the base policies. Since the base policies were installed before the card was issued, one may be confident that they are conflict-free. Once the transaction request is approved or rejected, all policy automata (base and supplemental) update their state and continue as if the conflict had not occurred. [0142] Those skilled in the art will appreciate that the techniques of the invention are applicable for guarding access to network resources. In particular, the policy model described herein may be used to adequately express the policies governing network packet processing and forwarding in firewalls. Similarly, policy automata may be used as a model for representing HTTP access policies. In addition, policy automata may be used to program cards for insertion into GSM phones to, for example, limit the use of the GSM phone.

[0143] The policy model also may be extended so that transactions requests would yield more than yes and no answers. For example, a request to access a file might yield yes-read-only as an answer in addition to yes and no. Policy automata as described herein get only one chance to react to a transaction request. However, there are applications where a policy automaton may want to react to the outcome of a transaction that has been approved. For example, a cell phone policy governing what phone numbers may be called may want to react one way for an outgoing call where the other party fails to pick up the phone, and another way when the other party picks up the phone and has a conversation. Also, the set of votes D and the resolution function/are abstract parameters in the definition of a policy model. Defeasible logic is used for D and/but one skilled in the art could replace them with some another voting system based on a more expressive non-monotonic logic (such as default logic or abductive logic), deontic logic, or multi-valued logic.

[0144] Although implementations of the invention have been described in detail above, those skilled in the art will readily appreciate that many additional modifications are possible without materially departing from the novel teachings and advantages of the invention. For example, the invention may be applied to other platforms, such as GSM, and the refinement architecture may be extended beyond the conjunctive filter and policy automata implementations described herein. The extended system of the invention may also be applied in other contexts based on a common specification language and implementation. This permits the invention to encompass policy conditions that can be overridden such as where access "should" or "must" be permitted or denied. Such policies may be implemented in firewalls and the like so that the restrictions may implement non-monotonic logic in the policy decisions rather than finite state analysis. Also, as noted above, the payment card may be modified to operate with other electronic payment protocols besides SET. Moreover, the techniques of the invention need not be limited to use with a payment card. The techniques of the invention may be used in purchase systems that use something other than a payment card, such as a USB key, a watch, a PDS, and the like. The system of the invention also allows the user to program her payment card to implement personal budget restrictions and the like. Any such modifications are intended to be included within the scope of the invention as defined in the following claims.

Claims

What is Claimed:

1. A method of managing the use of a payment instrument, the payment instrument being issued by a primary issuer and being capable of performing an electronic payment transaction, comprising the steps of: at least one of a secondary issuer and a user adding at least one policy description to the payment instrument to express limits on use of the payment instrument in addition to those limits provided by the primary issuer that the secondary issuer and/or the user would like to impose on purchases with the payment instrument, the at least one policy description being represented as a computer program implemented on the payment instrument so as to examine purchase information from a merchant for automated approval; and enabling the payment instrument to perform electronic payment transactions whereby when an attempt is made to use the payment instrument to pay for a transaction with a merchant, the payment instrument consults its policy descriptions and issues purchase approval data to the merchant only if its policy descriptions are satisfied by purchase information provided by the merchant.

2. The method of claim 1, comprising the further step of generating a digital signature created by the payment instrument after the payment instrument has confirmed that its policy descriptions are satisfied by the purchase information from the merchant.

3. The method of claim 1 , wherein the step of adding at least one policy description comprises the step of installing said computer program onto the payment instrument from a host computer, said computer program including a refinement filter that disapproves a transaction represented by the purchase information from the merchant if the transaction does not comply with at least one payment policy of the payment instrument.

4. The method of claim 3, wherein the step of installing said computer program comprises the steps of: said host installing an approval applet having its own installation method with the aid of a manager of the payment instrument; said approval applet's installation method being invoked by the manager to initialize the approval applet; said approval applet obtaining an application identifier object of a transaction applet by providing a known reference value to the manager; said manager using the reference value to access a shared interface object of the transaction applet and invoking a registration method in the shared interface object to provide a reference that can be used by the transaction applet to later get the shared interface object from the approval applet; and if the registration method is successful, then success is indicated to the approval applet, the manager and the host computer.

5. The method of claim 4, comprising the further step of performing a secure transaction with the payment instrument, comprising the steps of: when the host computer attempts to send a payment message to said payment instrument, the host computer passes purchase information to the transaction applet on the payment instrument, said transaction applet invoking at least one approval applet on the payment instrument, each approval applet acting to approve/disapprove the transaction; if each invoked approval applet approves the transaction, the transaction applet creating a digital signature that the host computer needs to complete the transaction; and forwarding the digital signature to the host computer.

6. A method of performing a secure transaction with a payment instrument, comprising the steps of: when a host computer attempts to send a payment message to said payment instrument, the host computer passes purchase information to a transaction applet on the payment instrument, said transaction applet invoking at least one approval applet on the payment instrument, each approval applet acting to approve/disapprove a transaction represented by the purchase information; if each invoked approval applet approves the purchase information, the transaction applet creating a digital signature that the host computer needs to complete the purchase transaction; and forwarding the digital signature to the host computer.

7. A payment instrument capable of performing an electronic payment transaction, said payment instrument comprising: a memory that stores at least one policy description added by at least one of a secondary issuer and a user to express limits on use of the payment instrument in addition to those limits provided by a primary issuer that the secondary issuer and/or the user would like to impose on purchases with the payment instrument; and a processor that runs a payment manager program implementing any policy descriptions stored in the memory, the payment manager program examining purchase information from a merchant and issuing purchase approval data to the merchant only if its policy descriptions are satisfied by purchase information provided by the merchant.

8. The payment instrument of claim 7, wherein the payment instrument is one of a payment card, a smart card, a PDA, a cell phone, a watch and a USB key.

9. The payment instrument of claim 7, wherein the payment manager program further generates a digital signature after confirming that the policy descriptions are satisfied by the purchase information from the merchant.

10. The payment instrument of claim 7, further comprising an application programming interface to said processor, said interface including a refinement filter that disapproves a transaction represented by the purchase information from the merchant if the transaction does not comply with at least one payment policy of the payment instrument.

11. The payment instrument of claim 10, wherein the application programming interface limits resources available to the refinement filter to purchase information needed to transact an electronic payment.

12. The payment instrument of claim 10, said application programming interface further enabling the programming of the processor by at least one of the user and the secondary issuer of the payment instrument in accordance with a policy management framework that combines state machines with a non-monotonic logic engine that models dynamic integration of new policies into the refinement filter so as to cause said refinement filter to grant or deny the transaction based at least in part on said new policies.

13. The payment instrument of claim 12, wherein said logic engine further provides conflict resolution amongst policies of the refinement filter.

14. The payment instrument of claim 12, wherein said logic engine further checks for redundancy amongst policies of the refinement filter.

15. The payment instrument of claim 12, wherein said logic engine implements a methodology of one of defeasible logic, default logic, abductive logic, deontic logic, and multivalued logic.

16. The payment instrument of claim 12, wherein said processor further implements graphical interface software that enables editing of the policy management framework, analysis engine software that checks for conflicts in policies to be implemented on said payment instrument, and code generation software that creates applets that are stored in said refinement filter to implement the new policies.

17. The payment instrument of claim 16, wherein the payment manager program enables the payment instrument to take part in an electronic payment transaction with a purchase interface of a remote website via a host if the refinement filter approves a purchase request from the purchase interface.

18. The payment instrument of claim 16, wherein the applets comprise at least one manager applet containing said logic engine and at least one policy applet, wherein the manager applet polls any policy applets for their votes concerning whether a transaction request should be approved, consolidates any votes received, and notifies the policy applets of approval or disapproval based on the consolidated vote.

19. The payment instrument of claim 12, wherein the policy management framework includes at least one policy automaton, wherein said policy automaton is a finite-state machine that examines the purchase information provided by the merchant and votes on whether or not to approve the transaction, said votes being represented as rules in non-monotonic logic that represent which outcome the policy automaton prefers and how strong that preference is.

20. The payment instrument of claim 19, wherein the policy management framework further includes a decision rule that collects the votes of all policy automata to either approve a transaction represented by the purchase information from the merchant, reject the transaction, or declare a conflict.

21. The payment instrument of claim 20, wherein said policy automata update their states to override existing policies based on the determination of the decision rule.

22. The payment instrument of claim 7, wherein said at least one policy description relates to drug interaction data and said payment manager program examines the purchase information from the merchant to determine if the purchase information relates to the purchase of a drug that is prohibited by the drug interaction data.

23. The payment instrument of claim 8, wherein the payment instrument is a cell phone and said policy description relates to use of the cell phone to place calls.