APPARATUS, SYSTEM, AND METHOD FOR OPERATING A DIGITAL TRANSACTION CARD

Abstract

Apparatus (512, 514, 516, 520) on a Digital Transaction Card (DTC) (518), the apparatus (512, 514, 516, 520) including a Digital Transaction Processing Unit (DTPU) (520) operable for executing an instruction from a standard command protocol, wherein the DTC (518) is operable to store one or more scripts (504), each script (504) including one or more instructions from the standard command protocol, the DTC (518) further operable to cause the DTPU (520) to execute the one or more instructions.

Claims

1. Apparatus on a Digital Transaction Card (DTC), the apparatus comprising: a Digital Transaction Processing Unit (DTPU) operable for executing an instruction from a standard command protocol, wherein the DTC is operable to store one or more scripts, each script including one or more instructions from the standard command protocol, the DTC further operable to cause the DTPU to execute the one or more instructions.

2. Apparatus of claim 1, further comprising: an off-card entity operable to provide at least one script to the DTC.

3. Apparatus of claim 2, wherein the off-card entity is a Trusted Service Manager (TSM).

4. Apparatus of claim 3, wherein the TSM is adapted to generate one or more scripts for a uniquely identified DTPU and provide scripts to the DTC including the uniquely identified DTPU.

5. Apparatus of claim 1, wherein the apparatus includes software operable to store one or more software packages, at least one of the one or more software packages representing a Virtual Card Profile (VCP), the apparatus operable with the VCP to cause the DTC to adopt the personality associated with the VCP.

6. Apparatus of claim 1, wherein the standard command protocol is the Global Platform Standard (GPS).

7. Apparatus of claim 1, wherein the DTC includes a Micro Controller Unit (MCU).

8. Apparatus of claim 7, wherein the MCU is configured to emulate at least some functions of a digital transaction device, such as an Automatic Teller Machine (ATM), a Point Of Sale (POS) terminal, or an Electronic Funds Transfer at Point Of Sale (EFTPOS) terminal.

9. Apparatus of claim 1, wherein the DTC is operable to refresh one or more scripts.

10. Apparatus of claim 9, wherein the DTC refreshes the one or more scripts by resetting an anti-replay counter on each of the one or more scripts.

11. Apparatus of claim 10, wherein the DTC obtains a current anti-replay counter value from the DTPU and uses the DTPU anti-replay counter value to calculate the anti-replay counter reset value for each of the one or more scripts.

12. Apparatus of claim 1, wherein the DTC is operable to be linked with a Data Assistance Device (DAD) for communication therebetween.

13. Apparatus of claim 12, wherein the DAD is any one of: a smartphone, a Personal Computer (PC), a tablet computing device, and a DTD adapted to operate as a DAD.

14. A method for operating an apparatus on a Digital Transaction Card (DTC), the apparatus comprising a Digital Transaction Processing Unit (DTPU) operable for executing an instruction from a standard command protocol, wherein the DTC is operable to store one or more scripts, each script including one or more instructions from the standard command protocol, the DTC further operable to cause the DTPU to execute the one or more instructions, the method comprising: operating the apparatus to cause the DTPU to execute the one or more instructions.

15. The method of claim 14, wherein the apparatus further comprises software operable to store one or more software packages, at least one of the one or more software packages representing a Virtual Card Profile (VCP), the apparatus operable with the VCP to cause the DTC to adopt the personality associated with the VCP, the method further comprising: operating the apparatus to cause the DTPU to execute the one or more instructions to cause the DTC to adopt the personality associated with the VCP.

16. Method of claim 14, further comprising: operating an off-card entity operable to provide at least one script to the DTC.

17. Method of claim 16, wherein the off-card entity is a Trusted Service Manager (TSM).

18. Method of claim 17, wherein the TSM is adapted to generate one or more scripts for a uniquely identified DTPU and provide scripts to the DTC including the uniquely identified DTPU.

19. Method of claim 14, wherein the apparatus includes software operable to store one or more software packages, at least one of the one or more software packages representing a Virtual Card Profile (VCP), the apparatus operable with the VCP to cause the DTC to adopt the personality associated with the VCP.

20. Method of claim 14, wherein the standard command protocol is the Global Platform Standard (GPS).

21. Method of claim 14, wherein the DTC includes a Micro Controller Unit (MCU).

22. Method of claim 21, wherein the MCU is configured to emulate at least some functions of a digital transaction device, such as an Automatic Teller Machine (ATM), a Point Of Sale (POS) terminal, or an Electronic Funds Transfer at Point Of Sale (EFTPOS) terminal.

23. Method of claim 14, wherein the DTC is operable to refresh one or more scripts.

24. Method of claim 23, wherein the DTC refreshes the one or more scripts by resetting an anti-replay counter on each of the one or more scripts.

25. Method of claim 24, wherein the DTC obtains a current anti-replay counter value from the DTPU and uses the DTPU anti-replay counter value to calculate the anti-replay counter reset value for each of the one or more scripts.

26. Method of claim 14, wherein the DTC is operable to be linked with a Data Assistance Device (DAD) for communication therebetween.

27. Method of claim 26, wherein the DAD is any one of: a smartphone, a Personal Computer (PC), a tablet computing device, and a DTD adapted to operate as a DAD.

28. Method of claim 14, further comprising receiving, from an issuing authority, the DTC configured to store the one or more scripts and to cause the DTPU to execute the one or more instructions.

29. Method of claim 14, further comprising including issuing, by an issuing authority, operating code, including software and/or firmware, to the DTC to enable the DTC to store the one or more scripts and to cause the DTPU to execute the one or more instructions.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0110] At least one embodiment of the invention will be described with reference to the following, non-limiting illustrations representing the at least one embodiment of the present invention, in which:

[0111] FIG. 1 is a diagrammatic representation of an example security hierarchy in accordance with an embodiment of the present invention;

[0112] FIG. 2 is a diagrammatic representation of an example implementation of scripts on a DTC in accordance with an embodiment of the present invention;

[0113] FIG. 3 is sequence diagram showing operations between an MCU and DTPU (EMV) in accordance with an embodiment of the present invention;

[0114] FIG. 4 is sequence diagram showing operations between an MCU and DTPU (EMV) in accordance with an embodiment of the present invention;

[0115] FIG. 5 is a diagrammatic representation of a communication pathway between a TSM and a DTC for delivering a script to the DTC from the TSM in accordance with an embodiment of the present invention;

[0116] FIG. 6 is a diagrammatic representation of a payment and DTC/virtual card issuing network) in accordance with an embodiment of the present invention;

[0117] FIG. 7 is a diagrammatic representation of an example operation for loading virtual cards onto a DTC in accordance with an embodiment of the present invention;

[0118] FIG. 7A is a diagrammatic representation of an example operation for loading virtual cards onto a DTC in accordance with an embodiment of the present invention, which differs from that shown in FIG. 7;

[0119] FIG. 8 is a diagrammatic representation of an example operation for loading virtual cards onto a DTC in accordance with an embodiment of the present invention different from that shown in FIG. 7;

[0120] FIG. 9 is a diagrammatic representation of an example operation of a DTC having its personality changed by a user.

[0121] FIG. 10 is a diagrammatic representation of an example implementation of scripts on a DTC in accordance with an embodiment of the present invention;

[0122] FIG. 11 is a diagrammatic representation of a method for generating session keys;

[0123] FIG. 12 is a diagrammatic representation of an example implementation using a single script on a DTC in accordance with an embodiment of the present invention;

[0124] FIG. 13 is a diagrammatic representation of an example security hierarchy in accordance with an embodiment of the present invention;

[0125] FIG. 14 is sequence diagram showing operations between an MCU and DTPU (EMV) in accordance with an embodiment of the present invention;

[0126] FIG. 15 is a diagrammatic representation of an example security hierarchy in accordance with an embodiment of the present invention;

[0127] FIG. 16 is sequence diagram showing operations between an MCU and DTPU (EMV) in accordance with an embodiment of the present invention;

[0128] FIG. 17 is a diagrammatic representation of an example security hierarchy in accordance with an embodiment of the present invention;

[0129] FIG. 18 is sequence diagram showing operations between an MCU and DTPU (EMV) in accordance with an embodiment of the present invention;

[0130] FIG. 19 is a diagrammatic representation of an example security hierarchy in accordance with an embodiment of the present invention;

[0131] FIG. 20 is sequence diagram showing operations between an MCU and DTPU (EMV) in accordance with an embodiment of the present invention; and,

[0132] FIG. 21 is a sequence diagram showing operations for replenishing scripts on a DTC, in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION

[0133] Referring to FIG. 1, an example security hierarchy 100 for a secure element in a DTPU is shown with the top of the hierarchy being the Issuer Security Domain (ISD) 102. The ISD is the owner of the secure element in a DTPU (for example, an EMV chip) on a DTC, and is responsible for content management on the DTC and assigning privileges. The owner of the secure element may be a card issuer, or another authorized third-party managing the secure element as a service. Alternatively, management of the secure element could be the responsibility of a customer (the cardholder), if given the appropriate security authorization and means to operate with that level of responsibility. DTC content management includes functions: LOAD packages, INSTALL applications, and DELETE applications and packages.

[0134] The hierarchy uses a Supplementary Security Domain (SSD) 110, which is managed by a third-party for the purposes of changing the personality with which the DTC operates. The third-party personality manager installs an application on the DTC for controlling some operations of the DTC, including operation of the PSE/PPSE and the DTPU (in particular, the secure element of the DTPU). The ability to operate the SSD is provided through the appropriate authorization 108, for example, by provision of keys. The third-party personality manager SSD 110 may also have authority for Global Locking 106.

[0135] The third-party personality manager SSD has control of one or more packages 124, which may be implemented as one or more applets. The packages, when called, instantiate one or more corresponding instances 126. In one example, there may be one package for a custom PPSE and another package for a custom PSE, instantiating, respectively, as a custom PPSE instance and a custom PSE instance. With this control under the SSD, the third-party personality manager is able to cause the PPSE and PSE applications to perform operations on the PSE/PPSE of the DTC. In one embodiment, the PPSE gets the Global Lock privilege allowing the LOCKing and UNLOCKing of other applications on the secure element.

[0136] According to GPS, the Global Lock privilege provides the right to initiate the locking and unlocking of any Application on the card, independent of its Security Domain association and hierarchy. It also provides the capability to restrict the Card Content Management functionality of OPEN. This allows a single entity on the Secure Element to implement the lock/unlock mechanisms. An off-card entity requiring the lock or unlock functions should be authenticated using the appropriate secure channel.

[0137] In one example implementation of a standard command protocol (or a general card and issuing/payment network operation protocol), the Global Platform Standards (GPS), mapping guidelines define which global platform privileges are recommended or optionally supported by the ISD and SSD or applications (for example, applets). In example implementation, each EMV chip can differ, with some EMV chips supporting an extended version of mapping guidelines (called Mapping Guidelines Plus). Some implementations of the GPS allow the global lock privilege to be assigned to applications. In embodiments of the present invention, software packages (applications), such as applets, could therefore contain global lock privilege. In other embodiments, global lock privilege could be assigned to a script (or a number of scripts). With such global lock privilege assignment, applets or scripts, when operated, may be enabled to perform LOCK/UNLOCK operations, and other operations requiring a high-level authorization according to the GPS security hierarchy.

[0138] The hierarchy 100 also includes an SSD utility 112, with appropriate authority 114 to operate a number of packages relating to various card profiles (VCPs) and their associated payment schemes. In this example embodiment, a first package 128 holds information for a Visa card profile, a second package 130 holds information for a MasterCard profile, and a third package 132 holds information for an Amex profile.

[0139] The hierarchy 100 includes two example bank SSDs 116, 120, with associated security 118, 122. The bank SSDs are each associated with a bank hosting applications for the VCPs 128, 130, and 132. In this example, the first bank SSD 116 is associated with the Visa application, and instantiates a Visa instance 134; the second bank SSD 120 is associated with the MasterCard application and instantiates a MasterCard instance 138. The keysets 136, 140 from these bank SSDs allows personalization of the banking applications. The owners of the bank SSDs 116, 120 are responsible for generating personalization scripts for the banking profile data.

[0140] As shown in FIG. 2, the security hierarchy 100 is implemented in the secure element of a DTPU 224 (an EMV chip) on a DTC 222. The DTC also has an external processing chip, a Micro Controller Unit (MCU) 220. The MCU is loaded with scripts 206, 208, and 210, which are generated 204 by a Trusted Service Manager 202 and sent through a Secure Socket Layer (SSL) 212 over the internet to a cardholder's mobile device (smartphone) 214. The smartphone 214 is loaded with an app 216 configured to securely accept the scripts generated by the TSM and to connect with the DTC 222 via Bluetooth 218, and to send the scripts via the Bluetooth link to the MCU 220.

[0141] With the scripts 206, 208, and 210 loaded into the MCU the cardholder can perform operations via an interface on the DTC (not shown in FIG. 2). The interface may include buttons operable to allow the cardholder to select a VCP to become the operating personality of the DTC, and a display showing the cardholder which personality has been selected and is operating. The scripts enable authentication by the MCU of one or more operations for the DTC, including operations in accordance with the security hierarchy 100. As scripts require a valid authentication to be executed by the secure element of the DTPU (EMV), and the information in the script is not confidential, ciphering the data is not required.

[0142] In an embodiment, each successful authentication operation disables (exhausts) the script used for that authentication. When a predefined number of scripts have been exhausted, or a predefined number of scripts remain unexhausted, and when the DTC is connected with the smartphone 214, it can notify the smartphone which scripts have been exhausted, and the smartphone (via the app 216) can request a new batch of scripts from the TSM. In this way, the scripts can remain synchronized between those on the DTC and those copies of scripts (or records of the scripts) retained by the TSM.

[0143] Another means by which to retain synchronization is to reset the sequence counter after a script has been used for a successful authentication or another operation, which would otherwise exhaust the script. Using GPS, the sequence counter can be reset using a PUT_KEY command, which replaces the existing keyset with an identical keyset having the same key values. This results in the script being valid for further use without immediate replenishment from the TSM. The PUT_KEY command requires authentication to the SSD using the highest security level available, that is, AUTHentication+ENCryption+MAC. There are two types of script for this option: the selection update with security level AUTH, and the update keys script with AUTH+ENC+MAC security level.

[0144] Ultimately, when possible, an update from the TSM will still be required to provide a key update with new values. Updating key is a security requirement, and must be done regularly, or the security may be compromised. However, the update can occur as a background task when the DTC is connected with the smartphone.

[0145] Although embodiments described in this specification exemplify a smartphone as means to communicate data, including scripts, between a TSM and the DTC, other means may be suitable for this function, including computer tablets, smartwatches (and other wearable mobile communication devices), PCs, laptops and other devices which can be securely connected to a network for secure communication between the device and the TSM, and which can also be connected to the DTC via a suitable communication protocol such as Bluetooth. Further, the TSM and DTC can connect for secure data communication therebetween using digital transaction devices, such as ATMs and POS/EFTPOS terminals when the DTC is used for transactions with those types of device.

[0146] FIG. 3 is a sequence diagram 300 showing an example of how an MCU 304 can operate with scripts to establish a Secure Channel Protocol (in this example, SCP02) 302 for communication with an EMV secure element 318 to effect changes in accordance with the security hierarchy having the highest authority under the ISD 306, such as a change in personality of the EMV by enabling/disabling appropriate applications representing VCPs on the EMV.

[0147] The cardholder uses the DTC interface to select a card (for example, a Visa card) which is to be the new operating personality of the DTC to replace the presently operating personality (for example, an Amex card). The MCU launches the selection process by authentication 320, 322 to the SSD 308 through the PSE/PPSE application 310 using a third-party SSD keys (the third-party being one designated to manage personality changes on the DTC). The MCU then sends a Set Active Application 324 command to the PPSE (for contactless card transactions)the active application will be the Visa application. The PPSE operates to check the LOCK/UNLOCK state of the applications, LOCKS 326 the application to be deactivated (the Amex card application) using GPS APIs 314, UNLOCKS 328 the application to be activated (the Visa card application), then UPDATES FCI 332 of the PSE/PPSE FCI 316 to accord with the AID of the activated application. The PPSE updates the PSE payment directory. Finally, an OK 330 is sent to the MCU. When next used, the DTC's EMV will have the personality of the Visa card operating and will use the appropriate Visa banking applet 312 in a payment operation.

[0148] In the example depicted in FIG. 3, a script used in the operations contains Application Protocol Data Unit (ADPU) commands for authentication using a keyset from a third-party personality management SSD. The script command content may include, for example: [0149] SELECT PPSE; [0150] INITIALIZE UPDATE; [0151] EXTERNAL AUTHENTICATE; and [0152] SET ACTIVE APPLICATION
commands.

[0153] FIG. 4 is a sequence diagram showing another possible implementation of activating/deactivating (unlocking/locking) applications in an EMV secure element 402 on a DTC using scripts for managing authentication in accordance with the security hierarchy (including the ISD 408 and SSD 410). In this example implementation, the ISD 408 has the Global Lock (GL) authority. As with the example depicted in FIG. 3, the cardholder selects a card profile desired for the DTC via the DTC interface (buttons and display). In this example, the cardholder may desire to change the operating personality of the DTC from a MasterCard credit card to the cardholder's bank's debit card. The cardholder's selection causes the MCU 406 to launch a selection process by establishing a secure channel 404 and commences authentication 416 with the ISD 408, and, if successful, receiving an OK message 420 back from the ISD. Other secure channels 405, 407, and 409 are established during the selection process as needed for secure communication between the MCU and EMV. The MCU can then check the LOCK/UNLOCK status of the applications in the DTPU, and select which scripts should be run to effect the change desired by the cardholder. The MCU runs a suitable script with the LOCK command 420 to deactivate the MasterCard credit card, receiving an OK indicator 422 from the ISD 408. The MCU then performs another authentication with the ISD 424, receiving an OK 426, before running another suitable script with the UNLOCK command 428 to activate the cardholder's bank's debit card and receiving an OK indicator 430.

[0154] Following the UNLOCKING/LOCKING commands, the MCU selects the next available authentication script and runs this script for authentication 432, 434 before sending a SELECT PPSE command to the PPSE 412 to update 436, 438 the FCI of the PPSE according to the AID of the selected application (the cardholder's bank's debit card application). In a separate action, the MCU can update the PSE 414 payment directory with the activated application's AID. As both the PPSE and PSE are updated, the DTC can be used in contact and contactless transactions with digital transaction devices. The DTC can operate with the appropriate banking applet 415 to effect debit card transactions.

[0155] In the example depicted in FIG. 4, three of the script used may include, for example:

Script 1 (LOCK/UNLOCK Banking Applications):

[0156] SELECT SSD; [0157] INITIALIZE UPDATE; [0158] EXTERNAL AUTHENTICATE; [0159] SET STATUS (APPLICATION LOCKED); and [0160] SET STATUS (APPLICATION UNLOCKED).

Script 2 (UPDATE PPSE FCI):

[0161] SELECT PPSE; [0162] INITIALIZE UPDATE; [0163] EXTERNAL AUTHENTICATE; and [0164] UPDATE FCI (FCI CONTENT with AID).

Script 3 (UPDATE PSE PAYMENT DIRECTORY)

[0165] SELECT PSE; [0166] INITIALIZE UPDATE; [0167] EXTERNAL AUTHENTICATE; and [0168] UPDATE FCI PAYMENT DIRECTORY (AID).

[0169] Whilst the above examples illustrated in FIGS. 3 and 4 are addressed to changing the operating personality of a DTC, the range of operations which can be performed by using an MCU with appropriate scripts is much broader, and includes actions such as disabling the DTC entirely if a fraudulent or sufficiently suspicious transaction is detected. For example, a DTC may be presented to a digital transaction device, such as an EFTPOS terminal; during the attempted payment transaction, the payment network or the terminal itself detects suspicious activity, for example, multiple entries of an incorrect PIN; the terminal can signal the DTC, which has a script capable of deactivating all VCPs on the DTPU; and the DTC (MCU on the DTC) runs the script to render the DTC inactive.

[0170] Further, in other example embodiments, the DTPU of the DTC could store a wide variety of digital transaction documents, including passports, IDs, age verification documents, loyalty cards, travel cards, along with a range of financial transaction documents, such as credit and debit cards from various payment schemes. In one embodiment, the DTC can be operated via its interface to install any one of the documents as the operating personality of the DTC.

[0171] In other embodiments, it is envisaged that, for example, multiple personalities could operate where such personalities have some relationship, such as a credit card and a loyalty card. In such scenarios, the PPSE/PSE may only present the credit card personality for selection by a transaction device, but the DTC could operate an associated loyalty card (a different VCP on the DTC) to recognise transactions made with the credit card when it is the active card profile.

[0172] In other variations, a single script may be suitable for completing a number of operations for changing a DTC's operating personality. For example, the script may implement a number of authentications and commands required. This would increase the efficiency of each script, thus requiring a smaller number of scripts to be installed on the MCU for executing each personality change operation.

[0173] FIG. 5 shows an example embodiment of a communication pathway 500 between a TSM 502 and a DTC 518 for delivering a script 504 from the TSM to the DTC. In one example embodiment, the script is delivered to the MCU 514 on the DTC as an end-point of the communication pathway. In another example embodiment, the script is delivered to the secure memory 516 on the DTC as an end-point of the communication pathway.

[0174] The TSM generates the script with a keyset unique to a chosen set of parameters of the DTC. The set of parameters could include, for example, one or more of the following: a DTC unique ID, a MCU unique ID, a key (or keyset) stored in secure memory 516 of the DTC, and a unique ID for the DTPU 520 (in some examples, an EMV chip). The generated script contains commands (ADPU commands) in accordance with, for example, the GPS. As the script is generated with a keyset unique to the chosen parameters, the script cannot be used with other DTCs or other devices (such as mobile payment devices).

[0175] The TSM 502 sends the generated script 504 to a mobile device 508 (for example, a DAD or a mobile phone). The TSM can send the script via a secure communication channel, or in the clear. The communication path between the TSM and the mobile device can Over The Air (OTA) 506, or by some other pathway.

[0176] The mobile device is then able to transfer the script to the DTC 518 via a contactless communication channel 510 to a communication chip 512. Examples of the contactless communication channel are an NFC connection or a Bluetooth connection.

[0177] Once transferred to the communication chip 512, the script can be passed to the MCU 514 or further transferred to the secure memory 516. When the script has been received by its designated end-point, an acknowledgement of receipt can be sent back through the same or a different communication pathway to confirm to the TSM that the script has been safely received and stored on the correct DTC or other payment device.

[0178] In various embodiments, the communication pathway 500, or parts of the communication pathway can be secured to prevent fraudulent activity, such as man-in-the-middle attacks. However, it will be appreciated that a script is generated for a specific device, and cannot be used in other devices, so that a secure communication pathway may not always be required or desired.

[0179] It will also be appreciated that the communication pathway 500 could be established as an end-to-end pathway between the TSM 502 and the end-point (for example, the MCU 514, or the secure memory 516). Such a pathway requires maintenance of all connections between points along the pathway for the entirety of the communication process.

[0180] In other embodiments, the communication pathway 500 may be comprised of a series of asynchronous communication points. In such embodiments, a script 504 can be delivered from the TSM 502 to a mid-point device, such as the mobile device 508 via a first communication channel part-pathway. The first communication channel part-pathway could then be dropped. The mobile device, being a temporary holder of the script, can then establish a second communication channel part-pathway with the DTC's communication chip 512, which part-pathway has a synchronous connection with the MCU 514, and can also have a synchronous connection with the secure memory 516. The script can be delivered to the end-point, and an acknowledgement can be sent back through a same mix of synchronous and asynchronous communication channel part-pathways.

[0181] In embodiments including asynchronous communication channel part-pathways, the entire communication process (including delivery of the script from the TSM to the end-point, and delivery of the acknowledgement back to the TSM) could be time-limited to reduce the risk of fraudulent interception and use of the script. In some examples, the time limit could be 5 minutes, although it will be appreciated that other time limits could be chosen.

[0182] FIG. 6 shows and example environment 600 for issuing a DTC 602, issuing VCPs to the DTC, issuing scripts for the DTC, along with a payment environment for facilitating digital transactions using the DTC when operating with a personality according to one of the VCPs which is activated on the DTC. Typical operating dependencies between each of the entities in this environment are indicated by arrowed lines.

[0183] The DTC 602 depicted in FIG. 6 is capable of adopting one of a number of available personalities and once a particular personality has been selected and activated, the DTC may be used to perform digital transactions with an existing digital transaction infrastructure including a merchant terminal 614 and may be used to conduct the transaction with existing digital transaction infrastructure according to the available modes of use of a DTC with a merchant terminal including use of NFC/contactless capabilities 612 for contactless payment 620, physical contact with the EMV contacts 618 or a magnetic stripe on the rear of the DTC 616.

[0184] Further, in FIG. 6, an arrangement is depicted wherein the personality adopted by the DTC 602 relates to the selected VCP of a credit card and transactions effected by using the DTC with the adopted personality use tokens to improve the security of the credit card transaction.

[0185] In this regard, in the embodiment detailed in FIG. 6, an issuer 626 initially issues the credit or debit card and creates an account for the account holder. The account is identified by a Primary Account Number (PAN) that identifies the issuer and the particular card holder account. Alternatively, the issuer may issue a blank card for subsequent installation of all personalities (represented by VCPs) required by the user. Further, the issuer could also issue a card with a single virtual card installed that is supplied by a TSM 622.

[0186] When a consumer uses their DTC 602 in a credit card transaction with a merchant terminal 614, the merchant terminal interacts with an acquirer 632 and passes payment data and the token to the acquirer for authorisation of the transaction.

[0187] The acquirer 632 is an entity that processes credit or debit card payments on behalf of a merchant. The merchant acquires a credit card payment from the card issuer 626 within a payment scheme 630. The acquirer exchanges funds with an issuer on behalf of the merchant. With respect to the process associated with the transaction, the acquirer passes the payment data and token received from the merchant to the payment scheme. The payment scheme then requests that a token service provider 624 convert the token collected by the merchant and received from the acquirer back to the associated PAN. The token service provider provides the original PAN to the payment scheme and the payment scheme passes the PAN to the issuer and receives an account number for the payment. The issuer verifies the availability of funds and either authorises or declines the payment and communicates the authorisation or otherwise to the payment scheme. In turn, the payment scheme provides authorisation, or declines to provide authorisation, to the acquirer and the authorisation is provided from the acquirer to the merchant terminal 614. If payment is authorised, the merchant provides the goods and/or services to the user of the DTC and the merchant is assured that it, he or she will receive funds in return for the goods and/or services provided.

[0188] Optionally, at the time the issuer 626 issues a credit or debit card and creates an account for the account holder, the issuer provides a request to a TSP 624 to generate tokens for the PAN that identifies the issuer and the particular account holder. In the instance of FIG. 5, since the DTC 602 is operable to adopt one of many different personalities, it can behave in a similar manner to a digital wallet without the constraints that are normally encountered when operating a digital wallet.

[0189] FIG. 6 also details a Trusted Service Manager (TSM) 622 which receives tokens from the token service provider 624 for the purpose of creating a virtual card. The TSM securely distributes virtual card data to an account holder's mobile device 604. The role of the TSM is to ensure that virtual card data is securely packaged and transferred to the secure element of a mobile device. The mobile payment data may be secured by keys. In the example of FIG. 5, the TSM generates a virtual card in the form of a CAP file for installation into the mobile device 604 and for transfer onto the DTC 602. CAP files containing virtual card data are transmitted wirelessly to the secure element of a user's mobile device. The TSM is also responsible, in this embodiment, for issuing scripts which allow the DTC to perform operations requiring authorization in accordance with the security hierarchy, including the operations required for changing the operating personality adopted by the DTC 602.

[0190] The user's mobile device 604 may be identified by various pieces of information regarding the device, that when considered in combination, form a mobile device fingerprint. The mobile device executes a digital wallet application and communicates 608 with the DTC 602 preferably by use of a wireless communication protocol such as NFC or Bluetooth 606.

[0191] The user may download a wallet application from a wallet service provider 628 for installation on their mobile device 604 wherein the wallet service provider digital wallet application allows the user to carry virtual credit cards, virtual debit cards or other virtual card information in a digital form on their mobile device. In the instance of FIG. 6, the digital wallet application also includes a module that provides the functionality for the digital wallet application to communicate and interact with the DTC 602. Once the digital wallet application has been downloaded from the wallet service provider to the mobile device, the TSM can identify the mobile device by the mobile device fingerprint and can download virtual cards (sometimes in the form of CAP files) for installation into the digital wallet application and hence, becomes available for transfer onto the DTC for use in an existing digital transaction network according to the personality encapsulated within the VCP file.

[0192] FIG. 7 shows one possible arrangement 700 for providing a VCP 704 to a DTC 736, in this example, via a mobile device such as a smartphone 708. A TSM 702 generates a VCP in cooperation with other card profile issuing entities, such as issuers (which may also be referred to as banks), and transmits the profile securely over the air 706 to a cardholder's smartphone 708. An encrypted profile with EMV ISD keys held within the TSM is linked/matched with EMV ISD keys held within the EMV (738). The VCP is transmitted via a SSL link or similar. The smartphone optionally establishes an end-to-end secure communication link 710, 716 with a communication chip 717 (for example, using NFC or Bluetooth). The communication chip 717 establishes an end-to-end secure communication link with an MCU 718 on the DTC 736 for secure transfer of an encrypted file 712 (same as 704) relating to the VCP. The file is encrypted using key pairs or SCP 714 in accordance with the security hierarchy.

[0193] The MCU transfers the virtual card to the DTC's DPTU 738, an EMV chip in this example, by splitting the VCP into ADPUs 720 and transferring 722 each of the ADPUs to the EMV optionally via a secure session 724. In this example, the secure session comprises 4 ADPUs 728, 730, 732, and 734, each transmitted through the tunnel to the EMV.

[0194] FIG. 7A shows an alternative arrangement 750 to that shown in FIG. 7, for providing a VCP 754 to a DTC 786, in this example, via a mobile device such as a smartphone 758. A TSM 752 generates a VCP in cooperation with other card profile issuing entities, such as banks, and transmits the profile securely over the air 756 to a cardholder's smartphone 758. The smartphone communicates with an MCU 768 on the DTC 786 for secure transfer of the file 754 (in this example, for a Visa card 755) relating to the VCP.

[0195] The MCU transfers the virtual card to the DTC's DPTU 788, an EMV chip in this example, by splitting the VCP into ADPUs 770 and transferring 772 each of the ADPUs to the EMV optionally via a secure session 774. In this example, the secure session comprises 4 packets 778, 780, 782, and 784, each transmitted through the tunnel to the EMV.

[0196] The communication between the smartphone and the MCU without further encryption (in the clear) is possible because the VCP is sent from the TSM to the smartphone as an encrypted file. Further, though the file contains information to verify that the VCP is being installed on the correct DTC, the information is encrypted with keys between the TSM and the EMV chip with checks and balances including device fingerprints and challenge responses to ensure encrypted information is forwarded only to the correct EMV chip. The codified information is associated with the actual data, such as PAN, cardholder's name, etc, in another location. As such, even if the VCP file is intercepted and decrypted, the information contained therein is not immediately useful for identifying the DTC, the cardholder or other critical information.

[0197] FIG. 8 shows an alternative arrangement 800 to that depicted in FIG. 7 where the VCP 804 is transmitted from the TSM 802 as an end-to-end encrypted (via SCP) VCP file 806 to the cardholder's mobile device 808 and is transferred directly to the DTPU 828 of the cardholder's DTC 826, rather than being transferred through an MCU as depicted in FIG. 7. Similar to the process shown in FIG. 7, the encrypted VCP file 810 stored on the mobile device is split into ADPUs 812 and transmitted, optionally via a secure session 814, with a tunnel 816, the transmission comprising 4 packets 818, 820, 822, and 824, each transmitted through the tunnel to the EMV. It will be appreciated that, in this embodiment, the VCP file is already encrypted with end-to-end by using SCP, optionally the VCP file can be double encrypted with a secure session between phone and EMV chip.

[0198] FIG. 9 shows and example scenario 900 where a cardholder 910 changes the operating personality of a DTC 902 using the DTC's interface including card buttons 904 and a display 906. In the example, the DTC starts with a NULL personality, in which case the DTC will not be able to perform any transactions. The cardholder selects a personality desired for a next digital transaction, in this example, a Visa credit card personality 912. After using the DTC for one or more payment transactions, the cardholder may wish to change 924 the DTC's operating personality to that of a MasterCard credit card 916, so the cardholder presses the up and down scroll buttons 920, 914 until the display shows the MasterCard personality, the cardholder then presses a select button to cause the DTC to activate that personality. For security, the DTC can be reverted to a NULL personality 922 until the cardholder wishes to use the DTC for another payment.

[0199] FIG. 10 shows another embodiment 1000 of a DTC in accordance with and embodiment of the present invention. The DTC 1002 (sometimes referred to as a Companion Card) includes an EMV chip (DTPU) 1004, the MCU 1006 and a digital screen 1008 with touch controls 1010 to select the payment application (the personality of the DTC presented to a digital transaction device as represented by a VCP loaded on the DTC). The DTC also has a wireless interface (for example, Bluetooth or NFC) 1011 for communication with a user's mobile device 1014. The EMV operates with a PPSE applet 1001, a PSE applet 1003, and has various payment applications installed 1005 . . . 1007.

[0200] The DTC operated mobile application 1012 on the user's mobile device 1014 provides management features of the DTC for the user. The library included in the mobile application may include the following features: [0201] An HTTPS Administration Agent to receive a connection from a TSM and forward APDUs to the DTC; [0202] APIs for triggering the DTC remote management from the TSM; and, [0203] Bluetooth interface with the DTC using MCU capabilities.

[0204] A Trusted Service Manager (TSM) 1016 may be responsible for: [0205] Hosting the Card Content Management Keys (according to Global Platform definition); and, [0206] Managing the DTC lifecycle.

[0207] The MCU is a controller with the following functions: [0208] Control the embedded screen; [0209] Provide a Bluetooth connection with the mobile phone; and, [0210] Be able to transfer APDUs from the phone to the EMV chip.

[0211] The EMV chips hosts one or more payment application and a customized PSE/PPSE application. The EMV relies GPS for application management.

[0212] As shown in FIG. 11 in a diagrammatic representation 1100, the MCU must authenticate to the Receiving Entity with the appropriate set of GPS keys. In one example circumstance, the authentication required by SCP02 is mutual and requires the exchange of challenges between the host and the card. In another example circumstance, using SCP02i55 allows using a Pseudo Random Value as a card Challenge.

[0213] In FIG. 11, there is depicted elements of generating a session key 1114, including the Secure Channel base key (16 bytes) 1102, and the derivation data (16 bytes) 1104 (made up from a Constant (2 bytes) 1106, a Sequence Counter (2 bytes) 1108, and 00 Padding (12 bytes) 1110), the Secure Channel base key and the Derivation data are fed into a CBC encryption process 1112 to produce the Session Key (16 bytes) 1114.

[0214] The pseudo Random is calculated as follows: [0215] The AID of the application requesting opening of a secure channel is padded (in the example shown in FIG. 11, the receiving entity application AID); [0216] A MAC is calculated across the padded dataSingle DES Plus Final Triple DES MAC, using the C-MAC session key and an ICV of binary zeroes; and [0217] The six leftmost bytes of the resultant MAC constitute the card challenge.

[0218] The MCU and the Secure Element can generate the same well-known pseudo random number if they have the following information: [0219] The SSD base keys; [0220] The AID of the application (on a Java Card, this will be an applet) requesting to open the SCP; and, [0221] The sequence counter used in session keys calculation.

[0222] The MCU stores scripts that are generated by the TSM using SCP02i55: [0223] Keys are securely hosted by the TSM; [0224] The script contains APDUs for authentication; and, [0225] Commands required for LOCK mechanisms.

[0226] The last step describes the resultant action: activating one application at a time. To do so, the receiving entity: [0227] LOCKS previously activated application [0228] UNLOCKS the application to activate,
using GPS SSD APIs.

[0229] Furthermore, the FCI of the PPSE and the PSE applications are updated with activated application AID. To apply such a resultant action, the receiving entity registers all the applications which should have their state modified.

[0230] FIG. 12 shows another example embodiment 1200 of the invention using a single script 1202 which can be refreshed by resetting its sequence counter (an alternative to loading a DTC with a number of scripts, each exhausted after performing a given action).

[0231] Similar to the example shown in FIG. 2, a script 1202 is stored on the MCU 1208 and is downloaded from the TSM 1204 after the DTC 1210 initiation. To avoid losing synchronization, the sequence counter is reset at the end of each script use by means of a PUT KEY command (a GPS command). The PUT KEY command replaces the existing keyset a with an identical keyset with the same key values, and the script in the MCU remains valid for further use without any update from the TSM. An Update from the TSM will be required on a key update with new values. Updating the key is required on regular basis, as security is compromised the longer a script is not updated. This can be done as a transparent task when the DTC is connected to the user's phone 1212 or another capable device, such as a digital transaction device (ATMs, POS/EFTPOS terminals, etc.).

[0232] Also shown in FIG. 12 is a security hierarchy 1700 (refer to FIGS. 13 and 17 for details of the nodes in the hierarchy), in which the custom SSD 1702 has the Global Lock (GL) privilege.

[0233] In another example embodiment, Global Lock privileges (from GPS standards) are assigned to the PPSE as shown in FIG. 13, which shows a security hierarchy 1300 for such embodiment. The hierarchy introduces a SSD 1302, dedicated to customizing payment environment applications 1304. The following applies for this implementation: [0234] The PPSE is the receiving entity; [0235] SCP02 scripts target the PPSE with AUTHENTICATED security level; [0236] The PPSE manages the selection process; [0237] The MCU builds the scripts using the SET ACTIVATED APPLICATION command; and [0238] PSE is updated by PPSE.

[0239] Further implications of the embodiment shown in FIG. 13 include the custom PPSE/PSE applications being stored under this SSD responsibility; the PPSE gets a Global Lock privilege that allows LOCKing/UNLOCKing of other applications on the secure element; and, the keyset for this SSD is used only for LOCKing/UNLOCKing.

[0240] In FIG. 13, the custom PPSE is installed under the SSD 1302 as a PPSE package 1306, which is instantiated 1310 with Global Lock privileges. A PSE package 1308 is also installed, and can be instantiated 1312, but without Global Lock privileges.

[0241] Under a different SSD for utilities 1303, there are installed payment packages for various schemes (for example, Visa, MasterCard, Amex) 1314. The payment packages are instantiated under various SSDs associated with a financial institution, for example, a bank. In FIG. 13, a Visa payment package 1316 is instantiated under a first SSD 1305 for a first bank, and a MasterCard payment package 1318 is instantiated under a second SSD 1307 for a second bank.

[0242] The sequence diagram 1400 shown in FIG. 14 indicates an example process using the security hierarchy of FIG. 13, and includes the following steps: [0243] Step 1: The user operates the embedded screen to select the new active application (App 3); [0244] Step 2: MCU 1404 launches the selection process (in operation with the EMV 1402) by: authenticating 1424/1426 to the SSD through the PSE/PPSE application using custom SSD keys 1302 (see FIG. 13), and sending the Set Active Application command 1428 to the PPSE 1412; [0245] Step 3: the PPSE runs the selection business rule to check the state (LOCK/UNLOCK) 1430/1432 of applications, LOCKs 1430 the deactivated application using GPS APIs 1420, UNLOCKs the application to be activated, and UPDATEs 1434 the FCI 1422 according to the activated application AID; and, [0246] Step 4: the PPSE updates 1436 the PSE 1414 payment directory.

[0247] In FIG. 14, the PPSE 1412 has GP Global LOCK privilege. Also shown in FIG. 14 are the ISD 1408, the SSD 1410, and a banking applet 1416. The process shown in FIG. 14 uses a secure channel 1418 for communication between the MCU and the EMV.

[0248] In the embodiment shown in FIG. 14, the PPSE 1412 and the PSE 1414 share the same list of AIDS. The sequence counter is shared between all scripts, which implies that each time a script execution is successful, the scripts of other applications that have been generated with the same counter are disabled. Further, each time a selection is performed, one script per banking application installed is disabled.

[0249] In the example shown in FIGS. 13 and 14, the MCU is responsible for: [0250] keeping track of the banking application AIDS; [0251] creating the SET ACTIVE APPLICATION command with the target application AID; [0252] appending the SET ACTIVE APPLICATION command to the authentication script; and, [0253] pushing the script to the secure element.

[0254] The script contains the APDU commands for Authentication using the SSD 1302 keyset. The secure channel used is SCP02i55. The security level is set to AUTHENTICATED to allow the MCU to add the SET ACTIVE APPLICATION command at the end of the script.

[0255] The PPSE implements the business rule for selection processes for all banking applications, both for contact and contactless transactions. FIG. 15 shows an embodiment of a security hierarchy 1500 where the Global Lock privilege is assigned to the PPSE 1502 and the PSE 1504 with the following consequences: [0256] There are 2 receiving entities: the PPSE and the PSE; [0257] SCP02 scripts target the PPSE and the PSE with AUTHENTICATED security level; [0258] The selection process of contact and contactless payment applications are separated; [0259] The MCU builds the scripts using the SET ACTIVATED APPLICATION command; and, [0260] The MCU sends a script to the PPSE and to the PSE for each selection.

[0261] Further, Both the PSE and the PPSE have Global Lock privilege, and they both require authentication to use the lock features.

[0262] FIG. 16 shows a sequence diagram 1600 which exemplifies a process using the security hierarchy (with the ISD 1608, being atop the hierarchy) shown in FIG. 14, which is implemented in the EMV (DTPU) 1602. The process includes the following steps: [0263] Step 1: The user operates the embedded screen to select the new active application; [0264] Step 2: the MCU 1604 launches the selection process by authenticating 1628 to the SSD 1610 through the PPSE 1612 application using custom SSD keys, and sending the SET ACTIVATED APPLICATION GPS 1630, 1632 command to the PPSE (in this implementation, the PPSE has the Global Lock (GL) privilege); [0265] Step 3: the PPSE runs the selection business rule for contactless cards checking the state (LOCK/UNLOCK) of applications, LOCKing 1634 the deactivated application using GPS API 1624 (which have the state of being OPEN 1606), UNLOCKing 1636 the application to be activated, and UPDATEing the FCI 1638 according to the activated application AID; [0266] Step 4: the PSE 1614 runs the selection business rule for contact cards checking the state (LOCK/UNLOCK) of applications 1644, 1646, 1648, LOCKing 1650 the deactivated application using GPS API 1626, UNLOCKing 1652 the application to be activated, and UPDATEing the payment directory 1654 according to the activated application AID.

[0267] The impact on the MCU for the process shown in FIG. 16 is similar to that shown in FIG. 14. However, the number of required scripts is doubled to account for actions performed with the PPSE and the PSE. The scripts contain the APDU commands for authentication using the custom SSD keyset. The secure channel used is SCP02i55 1620, 1622. Both the PPSE and the PSE support authentication. The security level is set to AUTHENTICATED to allow the MCU to add the SET ACTIVE APPLICATION command at the end of the script. The PPSE implements the business rule for selection process for contactless banking applications. The PSE implements the business rule for selection process for contact applications.

[0268] Throughout the process shown in FIG. 16, a number of confirmation steps are implemented, whereby OK messages 1630, 1642, 1646, 1656 are sent by various actors to confirm a step in the process has been completed successfully. It will also be seen that the PPSE can communicate 1640 with the PSE for updating. Also shown in FIG. 16 is a Banking Applet 1618.

[0269] In an example embodiment, as shown in FIG. 17 depicting an example security hierarchy 1700, the Global Lock privilege may be assigned to a custom SSD 1702 with the following implications: [0270] The receiving entity is the custom SSD; [0271] SCP02 scripts target the custom SSD with the AUTHENTICATED security level; [0272] The custom SSD receives only standard commands; [0273] The MCU implements the business logic and generates LOCK/UNLOCK commands; and, [0274] The PPSE and the PSE implement custom commands, respectively, to update their FCI and payment directory.

[0275] In the example embodiment shown in FIG. 17, the PPSE 1704 and the PSE 1706 do not have Global Lock (GL) privilege.

[0276] FIG. 18 shows a sequence diagram 1800 which exemplifies a process using the security hierarchy shown in FIG. 17, implemented on the EMV (DTPU) 1802, including an ISD 1852 and an SSD 1806 (the SSD having Global Lock (GL) privilege). The process includes the following steps: [0277] Step 1: The user operates the embedded screen to select the new active application [0278] Step 2: the MCU 1804 runs the selection business rule to check 1812 the state (LOCK/UNLOCK) of applications, select the next available authentication script, append the LOCK command 1820, 1824 to deactivate the presently active application, and, to append the UNLOCK command 1816 to activate the application selected by the user; [0279] Step 3: the MCU updates PPSE 1808 FCI, selects the next available authentication script 1828, and sends a SELECT PPSE command, and UPDATES FCI 1832 according to activated application AID; [0280] Step 4: the MCU updates PSE 1810 payment directory, selects the next available authentication script 1836, and sends a SELECT PSE command, and UPDATES the payment directory 1840 according to activated application AID.

[0281] In the embodiment depicted in FIGS. 17 and 18, the MCU implements the business rules, which implies having an up-to-date registry of the activated/deactivated applications. It also implies having the MCU building scripts for both LOCK/UNLOCK mechanisms and the PPSE and the PSE update. However, if the MCU is not a secured device, having such responsibilities may require additional security checks.

[0282] Throughout the process shown in FIG. 18, a number of confirmation steps are implemented, whereby OK messages 1814, 1818, 1822, 1826, 1830, 1834, 1838, and 1842 are sent by various actors to confirm a step in the process has been completed successfully. Also shown in FIG. 18 is a Banking Applet 1854, and the OPEN state 1850.

[0283] The script stored contains the APDU commands for authentication using the custom SSD keyset. The secure channel 1844, 1846, 1848 used is SCP02i55. The security level is set to AUTHENTICATED to allow the MCU to add appropriate set of commands. As the AID of the targeted application enters in the computation of SCP02, 4 different types of scripts are maintained: [0284] For LOCKing [0285] For UNLOCKing; [0286] For UPDATING the PPSE FCI; and [0287] For UPDATING the PSE payment directory.

[0288] All 4 scripts may be sent in the same sequence: [0289] 1st Script content: (LOCK/deselected banking app): [0290] SELECT SSD [0291] INITIALIZE UPDATE [0292] EXTERNAL AUTHENTICATE [0293] SET STATUS (APPLICATION LOCKED); [0294] 2nd Script content: (UNLOCK/Selected banking app): [0295] SELECT SSD [0296] INITIALIZE UPDATE [0297] EXTERNAL AUTHENTICATE [0298] SET STATUS (APPLICATION UNLOCKED); [0299] 3rd Script content: (UPDATE PPSE FCI): [0300] SELECT PPSE [0301] INITIALIZE UPDATE [0302] EXTERNAL AUTHENTICATE [0303] UPDATE FCI (FCI CONTENT with AID); [0304] 4th Script content: (UPDATE PSE PAYMENT DIRECTORY): [0305] SELECT PSE [0306] INITIALIZE UPDATE [0307] EXTERNAL AUTHENTICATE [0308] UPDATE PAYMENT DIRECTORY (AID).

[0309] FIG. 19 shows an embodiment of a security hierarchy 1900 where the Global Lock privilege is assigned to the ISD 1902, with the following implications: [0310] The receiving entity is the ISD 1902; [0311] SCP02 scripts target the ISD with AUTHENTICATED+MAC+ENCRYPTED security level: this is the ISD minimum security level; [0312] A specific keyset is created for selection process; [0313] The ISD receives only standard commands; [0314] The MCU implements the business logic; [0315] Commands cannot be appended by the MCU without cryptographic computations; and, [0316] The PPSE 1904 and the PSE 1906 implement custom commands, respectively, to update their FCI and payment directory.

[0317] Example of script to use for 4 selections:

TABLE-US-00001 Script 3 Script 4 Counter Script 1 Script 2 (UPDATE (UPDATE Value (LOCK) (UNLOCK) PPSE) PSE) 1st selection 1 2.sup.nd selection 2 3.sup.rd selection 3 4.sup.th selection 4

[0318] Every script is used.

[0319] In another example, it is possible for the scripts to share the same keyset. In such circumstances, the sequence counter is shared by all the scripts so each script needs to have a sequence counter increased by 1.

TABLE-US-00002 Script 3 Script 4 Counter Script 1 Script 2 (UPDATE (UPDATE Value (LOCK) (UNLOCK) PPSE) PSE) 1st selection 1 X X X 2 X X X 3 X X X 4 X X X 2nd selection 5 X X X 6 X X X 7 X X X 8 X X X

[0320] Scripts marked with a X are discarded (or not generated by the TSM) because the sequence counter is not applicable.

[0321] Performing one selection consumes 8 scripts (4 LOCKs and 4 UNLOCKs) per banking application and 8 scripts per selection app (4 PPSE and 4 PSE).

[0322] FIG. 20 shows a sequence diagram 2000 which exemplifies a process using the security hierarchy shown in FIG. 19, which is implemented on the EMV (DTPU) 2002. The process includes the following steps: [0323] Step 1: The user uses the embedded screen to select the new active application; [0324] Step 2: the MCU 2004 runs the selection business rule, checks the state (LOCK/UNLOCK) of applications 2024, 2032, selects the set of scripts to run, runs the script with LOCK command 2036 to deactivate the presently active application, and runs the script with UNLOCK command 2028 to activate the application selected by the user; [0325] Step 3: the MCU updates PPSE 2010 FCI, selects the next available authentication script 2040, and sends a SELECT PPSE command and UPDATES FCI 2044 according to activated application AID; [0326] Step 4: the MCU updates the PSE 2012 payment directory, selects the next available authentication script 2048, and sends a SELECT PSE command and UPDATES the Payment Directory 2052 according to activated application AID.

[0327] The MCU implements the business rule, which implies having an up-to-date registry of the activated/deactivated applications, and implies having the MCU building scripts for both LOCK/UNLOCK mechanisms and the PPSE and PSE update. The authentication scripts use ISD keys, which are the most sensitive keys of the secure element as they can grant card content management capabilities. In GPS, the minimum security level of the ISD mandates that the script is obtained only from the TSM and not appended in the MCU. Further, a large number of scripts may need to be stored for this example implementation. However, if the MCU is not a secured device, having such responsibilities may require additional security checks.

[0328] The script stored contains the APDU commands for Authentication using the custom SSD 2008 keyset. The secure channel 2016, 2018, 2020, 2022 used is SCP02i55. The security level is set to AUTHENTICATED+MAC+ENCRYPTION by the ISD 2006 (which has the Global Lock (GL) privilege). The MCU is not capable of appending the script with new commands, so the LOCK and UNLOCK commands need to be generated by the TSM.

[0329] Throughout the process shown in FIG. 20, a number of confirmation steps are implemented, whereby OK messages 2026, 2030, 2034, 2038, 2042, 2046, 2050, and 2054 are sent by various actors to confirm a step in the process has been completed successfully. Also shown in FIG. 20 is a Banking Applet 2014.

[0330] As previously discussed, in embodiments, scripts which are used to perform a selection of a VCP cannot be reused, and may be discarded. This requires replenishment of the scripts to allow a user of a DTC with a plurality of VCPs to change between personalities represented by the VCPs.

[0331] In an embodiment, scripts are replenished when the number of available scripts falls to a predetermined threshold. The cardholder can be notified by a warning signal on the DTC, such as an icon on the DTC display, or by an audible alarm. The cardholder may also be warned by means off the card, such as an SMS to their mobile phone.

[0332] The cardholder can replenish scripts by sending a request to a TSM via a mobile phone, an ATM, an EFTPOS/POS terminal, or some other suitable means, whereupon the TSM can use a keyset specific to the cardholder's DTC (for example, the keyset may be specific to the EMV on the DTC) to generate new scripts. The scripts can be sent securely via the means (mobile phone, ATM, EFTPOS/POS) to be downloaded into the MCU of the DTC.

[0333] It will be appreciated that the scripts, having been created with the keyset specific to the cardholder's DTC, cannot be used with another DTC. In this regard, scripts which are intercepted by a third party cannot be maliciously used to operate other VCPs on another DTC.

[0334] FIG. 21 shows an example replenishment functional sequence 2100, operating with a DTC having an EMV (DTPU) 2110 and a security hierarchy including an ISD 2112, and a custom SSD 2114, along with a PPSE 2116, A PSE 2118 and a Banking Applet 2120, wherein: [0335] Step 1: The user performs a selection. The number of available offline selection (sequence counter threshold) is exceeded; [0336] Step 2: On the next connection to the mobile phone 2104: [0337] The MCU 2106 selects 2122 the custom SSD 2114 sends the INITIALIZE UPDATE APDU command 2124 to get the sequence counter value from the custom SSD, with the state of the MCU to EMV communication channel being OPEN 2108, [0338] The MCU pushes to the phone a request 2128 to replenish the scripts, including the counter value; [0339] Step 3: The phone forwards 2130 this request to the TSM 2102; [0340] Step 4: The TSM generates N new scripts for the MCU: [0341] Using SCP02i55 with the custom SSD SCP keys and the sequence counter received in the request, [0342] Forwards 2132 the script to the MCU through the phone connectivity. Using SCP02i55 with the custom SSD SCP keys and the sequence counter received in the request, [0343] Forwards 2134 the script to the MCU through a mobile phone connection.

[0344] Throughout this specification and the claims which follow, unless the context requires otherwise, the word comprise, and variations such as comprises and comprising, will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

[0345] The reference to any prior art in this specification is not and should not be taken as an acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge.