AU2013248935A1

AU2013248935A1 - NFC card lock

Info

Publication number: AU2013248935A1
Application number: AU2013248935A
Authority: AU
Inventors: Constantin M. NICOLAU
Original assignee: SECURE NFC Pty Ltd
Current assignee: SECURE NFC Pty Ltd
Priority date: 2012-04-17
Filing date: 2013-04-17
Publication date: 2014-08-28
Also published as: WO2013155562A1

Abstract

A method of locking a smart card having a smart card chip, comprising a control device that is adapted to communicate with the smart card transmitting a lock command to the smart card, the command being adapted to control the smart card to block data communication responses of the smart card chip without disabling an RF antenna, magnetic field reception and monitoring circuitry of the smart card chip. A corresponding method of unlocking a smart card having a smart card chip, comprising a control device that is adapted to communicate with the smart card transmitting an unlock command to the smart card, the command being adapted to control the smart card to unblock data communication responses of the smart card chip.

Description

WO 2013/155562 PCT/AU2013/000399 NFC Card Lock Related Application This application is based on and claims the benefit of the filing and priority dates of AU application no. 2012901496 filed 17 April 2012, the content of which as filed is 5 incorporated herein by reference in its entirety. Field of the Invention The invention relates to the field of information technology security (ITS), and in particular-though not exclusively-to protecting contactless smart-cards (such as RFID and NFC cards) against the extraction by unauthorized parties of data when the cards are idle or 10 not in use, a practice sometimes referred to as 'e-Pickpocketing'. Background of the Invention The Near Field Communications (NFC) standard (18000-3) defines a communication protocol between peer to peer NFC active devices and also between NFC active devices and NFC passive 'tags' in terms of flow control, message formats, speed (106 Kbs/Miller 15 coding 100% modulation to 424 Kbs/Manchester coding 1% modulation) and frequency (13.56 MHz). However, it does not define a security methodology for protecting data against security attacks in general and e-Pickpocketing attacks in particular. NFC technology has a number of advantages, such as data transmission speed, communications protocol simplicity and the low cost of the NFC chips. However, it also has 20 security vulnerabilities that expose a user to eavesdropping by unauthorized parties ('snooping'), data modification or insertion, data manipulation, corruption and insertion by impersonators ('phishing'), and denial of service ('jamming') and virus attacks by "trusted" parties. For example, it has been demonstrated (see Forbes (trade mark) magazine, 30 January 2012) that it is a simple matter to steal NFC card information through clothes, from 25 pockets or from wallets of users, as RFID contactless cards in general and NFC cards in particular 'spit' data when powered on by a magnetic field. One existing technique for protecting NFC card data against illegal access and theft (i.e. e-Pickpocketing) is to cover the NFC cards, when not in use, with thick aluminium foil or the like, or store the NFC cards in metal-padded wallets. Alternatively, in principle an NFC 30 chip may be switched off. However, these approaches require software, hardware or mechanical changes to the NFC chip and/or the NFC card. Summary of the Invention According to a first broad aspect of the invention, there is provided a method of locking a smart card (such as an NFC card) having a smart card chip, comprising: 35 a control device (such as an NFC enabled device) that is adapted to communicate with the smart card transmitting, such as in response to a user inputted command to lock the NFC card, a lock command to the smart card, the command being adapted to control the WO 2013/155562 PCT/AU2013/000399 -2 smart card to block data communication responses of the smart card chip without disabling an RF antenna, magnetic field reception and monitoring circuitry of the smart card chip. The control device may include a record of (one or more) smart cards of a user of the control device, and the method further comprise: 5 the control device requesting that the smart card provide a smart card chip identifier; the smart card responding by transmitting the identifier of the smart card chip to the control device; the control device receiving the identity and comparing the identifier of the smart card chip with the record of smart cards; 10 the control device locating an entry in the record of smart cards that corresponds to the identifier of the smart card chip of the smart card; and the control device responding to locating the identity in the record of smart cards that corresponds to the identifier of the smart card chip by transmitting the lock command to the smart card. 15 The method may include the control device displaying to the user identities of one or more of the smart cards identified in the record of smart cards, prompting the user to input a selection of at least one of the smart cards identified in the record of smart cards that the user wishes to lock, and responding to the inputting of the selection by locking the smart card or smart cards identified by the selection inputted by the user. 20 In one embodiment, the method includes configuring the control device to require a password or other authorization from the user before accepting input for or modification of the record of smart cards. The method may include transmitting an access password to the smart card with a command adapted to control the smart card to store the password and to refuse access 25 requests that omit the password. The method may include the control device generating a random or pseudo-random smart card chip identifier, writing the random or pseudo-random smart card chip identifier to the record of smart cards associated with the identity of the smart card, and transmitting the random or pseudo-random smart card chip identifier to the smart card with a command 30 adapted to control the smart card to write the random or pseudo-random smart card chip identifier to the smart card chip. The method may include automatically locking the smart card after each transaction, after a user's pre-set time interval, or after a pre-defined number of transactions. According to a second broad aspect of the invention, there is provided a method of 35 unlocking a smart card having a smart card chip, comprising: a control device that is adapted to communicate with the smart card transmitting, such as in response to a user inputted command to unlock the NFC card, an unlock WO 2013/155562 PCT/AU2013/000399 -3 command to the smart card, the command being adapted to control the smart card to unblock data communication responses of the smart card chip. The control device may include a record of (one or more) smart cards of a user of the control device, and the method further comprise: 5 the control device requesting that the smart card provide a smart card chip identifier; the smart card responding by transmitting the identifier of the smart card chip to the control device; the control device receiving the identity and comparing the identifier of the smart card chip with the record of smart cards; 10 the control device locating an entry in the record of smart cards that corresponds to the identifier of the smart card chip of the smart card; and the control device locating an entry in the record of smart cards that corresponds to the identifier of the smart card chip of the smart card; and the control device responding to locating the entry in the record that corresponds to 15 the identifier of the smart card chip by transmitting the unlock command to the smart card. The method may include the control device displaying to the user identities of one or more of the smart cards identified in the record of smart cards, prompting the user to input a selection from the smart cards identified in the record of smart cards that the user wishes to unlock, and responding to the inputting of the selection by unlocking the smart card or smart 20 cards identified by the selection inputted by the user. The method may include configuring the control device to require a password or other authorization from the user before accepting input for or modification of the record of smart cards. The method may include the control device presenting to the smart card a verify 25 command (which may function as the unlock command) that includes a password identical with a previously stored password in a memory of the smart card, wherein the previously stored password was stored in locking the smart card. The method may include reading the smart card using an additional random or pseudo-random smart card chip identifier generated in association with a locking of the 30 smart card and stored in the record of smart cards in association with the identity of the smart card, and transmitting an original smart card chip identifier to the smart card with a command adapted to control the smart card to write the original smart card chip identifier to the smart card chip. The method may include automatically unlocking the smart card when the smart card 35 is presented to a control device identified in a list of trusted or preferential devices stored in the smart card by the control device (e.g. mobile phone, tablet computing device, EFTPOS terminal, etc.) or a comparable authorized device.

WO 2013/155562 PCT/AU2013/000399 -4 The above aspects may include, respectively, service/application locking and unlocking. That is, another method to lock and unlock smart cards reserved for authorized parties such as Trusted Service Managers (TSM) and over-the-air (OTA) service providers is to temporarily suspend services (e.g. NFC services) or disable applications resident in the 5 Secure Elements (SE) of specific card issuers. * LOCK CARD: the Global Platform lock command is used to suspend a service or SE application. The command can only be used by parties authorized by the NFC card issuer or nominated by the service TSM. " UNLOCK CARD: the Global Platform unlock command is used to re-establish a 10 service or SE application. The command will revert the locked status of the service/application to the unlocked status and can only be used by parties authorized by the card issuer or nominated by the service TSM. The above aspects may be employed with any physical or virtual intelligent cards (smart-card) irrespective of their wireless (contactless, RFID) or wire-line interfaces or 15 resident applications (e.g. e-Passport, e-Ticketing, etc.). Further, more than one smart card's details may be loaded into a record in the device, in which case the smart cards may be placed, used and maintained into a multi-card record (such as an NFC card list), which will permit the selection and locking/unlocking of individual cards in the same manner as done for a single smart card on the device (such as 20 an NFC enabled device) or the simulation of the smart card by the device. This concept extends the type of smart card media type from payment cards to TAG enabled passports, public events, retail coupons, travel tickets, etc. It will be noted that these aspects of the invention may be implemented in mobile operating systems (e.g. Android

TM

, BlackBerry

TM

, Windows PhoneTM, Symbian

TM

, iOSTM, 25 etc.) and be used to lock smart cards in general and NFC card in particular, complaint with ISO7816, IS018000 and IS014443 standards, irrespective of the card issuer (i.e. VisaTM MasterCard

TM

, American Express

TM

, etc) or smart card operating system supplier (GoogleTM, BlackBerry

TM

, Microsoft

TM

, AppleTM, etc.) or smart-card technology developer (Gemalto T M , Schlumberger

TM

, Siemens

TM

, etc.) or NFC chip manufacturer (NXPTM, Samsung TM etc.). 30 Additionally, these aspects of the invention may are independent of the security algorithms (i.e. DES/3DES, AES, RSA, ECC, etc.) used by card issuers or (e.g. NFC) equipment suppliers to ensure the data storage and exchange privacy, integrity and non repudiation. According to a third broad aspect of the invention, there is provided a control device 35 (such as an NFC enabled device) that is configured to implement the first and/or second aspects of the invention described above. According to a fourth broad aspect of the invention, there is provided a computer program product executable on a control device (such as an NFC enabled device) that is WO 2013/155562 PCT/AU2013/000399 -5 adapted to communicate with a smart card, and which when executed on the control device implements the method described above. According to a fifth broad aspect of the invention, there is provided a computer readable medium having stored therein a computer program product executable on a control 5 device (such as an NFC enabled device) that is adapted to communicate with a smart card, and which when executed on the control device implements the method described above. It should be noted that any of the various individual features of each of the above aspects of the invention, and any of the various individual features of the embodiments described herein including in the claims, can be combined as suitable and desired. 10 Brief Description of the Drawinq In order that the invention may be more clearly ascertained, embodiments will now be described, by way of example, with reference to the accompanying drawing, in which: Figure 1 is a schematic block diagram of an NFC enabled smartphone according to an embodiment of the present invention; 15 Figure 2 is a block diagram of the architecture of the NFC lock (trade mark) application of the smartphone 10 of figure 1; Figure 3 is a flowchart of the operation of the NFC lock application of figure 2 when processing an NFC card, where the card is locked or unlocked, and when determining whether the card is new, lost or damaged; 20 Figure 4 is a flowchart of an alternative operation of the NFC lock application of figure 2 when automatically detecting the card status and ownership of an NFC card; Figure 5 is a schematic block diagram of some of the operational components of the operating system and the micro-SD of the smartphone of figure 1; Figure 6 is a schematic block diagram of the operating system and the micro-SD of 25 the smartphone of figure 1 and their relationship to the systems of various external parties; Figures 7A and 7B contain a schematic view of the NFC card Locking and Unlocking protocols employed by the NFC lock application of figure 2, which use the replacement of UID upon the successful modification of Access Conditions for Block Zero of sector 1; Figure 8 is a schematic block diagram of the network topology employed by the in 30 the development, certification and distribution of the NFC lock application of figure 2; Figure 9A is a schematic block diagram of an alternative NFC lock application architecture according to another embodiment of the present invention, employing an implicit key management methodology; Figure 9B is a schematic block diagram of the NFC locking mechanism of the 35 embodiment of figure 9A; and Figure 9C is a schematic block diagram of the NFC un-locking mechanism of the embodiment of figure 9A.

WO 2013/155562 PCT/AU2013/000399 -6 Detailed Descriptions of the Figures Figure 1 is a schematic block diagram of an NFC enabled device, in this example a smartphone 10, according to an embodiment of the present invention. For clarity, only features are particular relevance to understanding the present invention are illustrated in the 5 figure and described below. Smartphone 10 includes a processor 12, an operating system 14 (e.g. Android (trade mark), iOS (trade mark), Symbian (trade mark), BlackBerry OS (trade mark) or Windows 8 (trade mark)), and two forms of memory: device memory 16 and a removable micro-SD (secure digital) memory card 18 (hereafter 'micro-SD 18'). In addition, smartphone 10 10 includes a SIM card 20, which has some on-board memory, and a user interface shown schematically at 22, but which includes a touch screen 24, microphone 26a and speaker 26b. Smartphone 10 also includes an NFC chip 28, and device memory 16 includes an NFC lock (trade mark) application 30 that is executable by processor 12 to lock and unlock an NFC card. 15 Figure 2 is a block diagram of the architecture of the NFC lock application 30 of the smartphone 10 of figure 1, showing the principal functions of the application, including application settings, card processing and card maintenance functions of a system which uses standard commands to read, lock and unlock NFC chips on external NFC cards. NFC lock application 30 (referred to as the 'NFC lock APP' in the figure) includes modules that, 20 when executed by processor 12, control smartphone 10 to perform the following operations. F100: Select NFC lock application 30: NFC lock application 30 controls smartphone 10 to display an icon that, when selected, controls NFC lock application 30 to display a 'WELCOME' screen (from which several hyperlinks can be activated), or subsequently a 'HOME' screen. In this example, the WELCOME/HOME screen displays links to the 25 LOCK/UNLOCK modules, an application setting screen and a CARD settings screen. * WELCOME screen * APP settings * CARD settings * LOCK/UNLOCK processes 30 F110: access NFC lock application 30 settings controls or functions, F1 11 to F1 17. F111: Enable locking mode: Manual (on user's action) or Auto (after each transaction) F112: Enable unlocking mode: Manual (on user's action) or Auto (on detection of the preferred business sites). 35 F113: Set PIN (etc) fail counter: value 0 to 3. Indicates the number of times the entry of incorrect end user's ID is permitted, before the NFC card requires reactivation by the service Provider.

WO 2013/155562 PCT/AU2013/000399 -7 F114: Select locking type: to expedite the card locking/unlocking process, the user has four options to identify himself/herself: enter a password (PSW), key in a personal identification number (PIN), scan his or her fingertip (FPR) or scan his or her face (FSR) if smartphone 10 is equipped with a keypad, or a finger print recognition device or with a face 5 scanning camera. F115: Select unlocking type: the user can select to use a different identification for unlocking the card or the same identification as for locking. To expedite the card unlocking process, the user has four options for identifying him- or herself: enter a password (PSW), or key in a personal identification number (PIN), or scan his or her fingertip (FPR) or scan his 10 or her face (FSR) if smartphone 10 is equipped with either a keypad, or a finger print recognition scanner, or a face scanning camera. F116: Select business limits: the user has the option of setting card payment limits (transaction, daily, etc.) equal or lower than the limits set by card issuers or merchants. F117: PIN maintenance: the personal identifier (PIN, PSW, FPR or FSR), if used, 15 can be changed by the user by re-entering the old identifier followed by the new identifier twice. The user can re-construct a forgotten identifier (PIN or PSW) by answering an associated, preselected secret question. If both the personal identifier and the answer to the secret question are forgotten, the user will be required to repurchase NFC lock application 30. 20 F120: access NFC maintenance controls or functions, F121 to F125, for maintaining a list of cards stored in smartphone 10; the list of cards contains details of those of the user's NFC cards whose details have been entered into smartphone 10 by the user, using function F121. F121: ADD card: firstly, the user is prompted to select the card issuer (e.g. VISATM 25 AMEX T M , MasterCard T M , etc.) and if necessary enter a card reference number (e.g. 1, 2, etc.) and card details (as a user may have a plurality of NFC cards from the same issuer). Alternatively, the user may tap the NFC card on smartphone 10 when a HOME icon is displayed and enter manually the card CVV EXP DATE and the second set of 4 digits from the card primary account number (PAN) once the card details (truncated PAN and hidden 30 EXP DATE) are displayed, then press a Save Key to save card details or Cancel key to delete card record. F122: REMOVE card: press Home icon to display the NFC cards loaded by the user into smartphone 10; select card to be deleted and press Remove Key. F123: Enter an APP locking key (to lock NFC lock application 30): the locking key 35 can be a PIN or a PASSWORD or your finger print or any other biometric identifier your NFC mobile phone may accept. Once the APP locking key is active, NFC lock application 30 can be accessed only upon the presentation of a valid locking key (PI, password, etc). If the user has forgotten the locking key, NFC lock application 30 prompts the user to provide a WO 2013/155562 PCT/AU2013/000399 -8 valid response to one of the secret questions whose responses have previously been stored in smartphone 10 by NFC lock application 30. Upon entering a valid response to a secret question, NFC lock application 30 prompts the user to enter a new PIN and to selected another secret question and answer or to deactivate the locking mechanism. 5 F124: Changing an APP locking key: the user may, if desired, change the locking key for locking NFC lock application 30 by selecting the application Settings icon and the PIN set-up function before entering sequentially the old key followed by the new key and the confirmation of the new key, and by selecting a secret question from the list of questions and entering an answer. 10 F125: Resetting a locking key: this procedure is only used when the user has forgotten both the locking key and the answer to the secret question, and exhausted the number of valid tries; the user purchases another copy of the NFC lock application, uses functions F121 and F122, after which the previous NFC lock application 30 resident in the NFC card is replaced by the new copy. In addition, if smartphone 10 and the user's NFC 15 card have been stolen, lost or damaged, the user is given 24 hours to report the theft, loss or damage to the network carrier (TELCO) and request that smartphone 10 be disabled, and to request that the card issuer cancel the NFC card and place it on a "hot list" of compromised NFC cards. Meanwhile, the LOCKED card cannot be used until the user receives (such as at his or her email address or by SMS on his or her mobile phone) a temporary Reset Code 20 to unlock the locked NFC locked that are present (that is, on hand). F130: use functions of NFC lock application 30, F131 to F135. F131: Reading an NFC card: once activated in reader or peer mode, NFC chip 28 of smartphone 10 polls for any NFC chips in its proximity. The magnetic field generated by NFC chip 28 of smartphone 10 is detected by the antenna of a nearby NFC chip and 25 transformed into current to activate the nearby NFC chip, which responds by generating and emitting an "answer to request" (ATR), which is detected by NFC chip 28 of smartphone 10. After negotiating the radio frequency and validating the manufacturing access code, the nearby NFC chip sends its contents (i.e. card primary account number (PAN), expiry date (EXP DATE) and optionally the cardholder's name) to NFC chip 28 of smartphone 10. 30 Smartphone 10 then displays the identities of the nearby NFC card or cards that have been matched to a card or cards in an "NFC card list" of the user's NFC cards, stored previously by the user as a record in smartphone 10. An icon is displayed beside the identity of each such card, which is selected by NFC lock application 30 according to whether the respective NFC card has been found by NFC lock application 30 to be locked or unlocked. If unlocked, 35 NFC lock application 30 controls smartphone 10 to display a green circle or an OPEN LOCK icon (comprising a picture of an open padlock and also, in some embodiments, the words "OPEN LOCK"). If the NFC card is locked, the icon is a red circle or a CLOSED LOCK icon WO 2013/155562 PCT/AU2013/000399 -9 (comprising a picture of a locked padlock and also, in some embodiments, the words "CLOSED LOCK"). F132: Locking an NFC card: to protect NFC card information against theft, the user can-once the NFC card list is displayed by smartphone 10 (see F1 31)-LOCK any of those 5 NFC cards by pressing the green circle or OPEN LOCK icon displayed adjacent the selected NFC card and tapping the selected NFC card on smartphone 10; next, the red circle or CLOSED LOCK icon replaces the green circle or OPEN LOCK icon adjacent to that NFC card's entry. On some mobile operating systems (e.g. iOSTM), the same result is achieved by sliding a lock symbol across the card's line. Alternatively, a switch or slider may be 10 displayed (for each listed NFC card) with locked and unlocked positions, and which can be toggled or slid from the unlocked to the locked position to effect locking. This function operates by controlling the NFC chip of the NFC card to temporarily block any data communication responses of the NFC chip without disabling its RF antenna or magnetic field reception and monitoring circuitry, or requiring changes to the resident application software 15 or hardware or mechanical components of the NFC chip. F133: Locking primitive: virtual cards stored in the user's virtual card list can be locked using one of the methods described above (UID, PAN, Password/Access Code). GlobalPlatformTM specifies the NFC card protocol to be used on the current NFC communication platforms (MIFARE, FELICA). The NFC chip specifications provide standard 20 commands for locking the NFC chip either in hardware or in its firmware (embedded software). F134: Unlocking an NFC card: to use a NFC card (plastic smart-card, micro-SD 18 or embedded-virtual card), the user must firstly unlock it. Once the NFC card list is displayed, with an adjacent red circle or CLOSED LOCK icon beside each locked NFC card, the user 25 can UNLOCK any locked card by pressing the corresponding red circle or CLOSED LOCK icon and tapping the NFC card against smartphone 10; the green circle or OPEN LOCK icon replaces the red circle or CLOSED LOCK icon adjacent to that NFC card's entry. On some mobile operating systems (e.g. iOS), the same result is achieved by sliding an unlock symbol across the card's entry. Alternatively, a switch or slider may be displayed (for each 30 listed NFC card) with locked and unlocked positions, and which can be toggled or slid from the locked to the unlocked position to effect unlocking. This function operates by controlling the NFC chip of the NFC card to unblock previously blocked data communication responses. F135: Unlocking primitive: virtual cards stored in a virtual card list can be unlocked using one of the methods described above (UID, PAN, Password/Access Code). 35 GlobalPlatformTM specifies the NFC card protocol to be used on the current NFC communication platforms (MILFARE, FELICA). The NFC chip specifications provide standard commands for unlocking the NFC chip either in hardware or in its firmware WO 2013/155562 PCT/AU2013/000399 -10 (embedded software). The developer is required to use the most effective NFC commands to unlock the NFC card. These functions of NFC lock application 30 may be implemented using commands compliant with industry standards such as: 5 0 IS07816 (1, 2, 3, 4) - smart-card standards - lock/unlock NFC chip firmware, 0 ISO14443 (3, 4) - proximity contactless cards (13.56MHz, 4 to 10 cm) - locklunlock NFC communications responses, 0 IS015693 - vicinity contactless cards (13.56 MHz, 1 to 1.5 m) - locklunlock NFC file/field Read/Write functions, and 10 0 IS018000 - NFC GlobalPlatform specifications - lock/unlock applications or services. Locking and unlocking can be effected, for example, by a "password access" technique, in which: " LOCK CARD: NFC lock application 30 writes a temporary access password onto the 15 selected NFC card to prevent access to the NFC card's contents by third parties (i.e. those unaware of the password) and saves the password into the NFC enabled devices (such as smartphone 10) to enable the reading of the NFC card only by the device which has generated the access password. " UNLOCK CARD: NFC lock application 30 reads NFC card's contents by presenting a 20 string containing a valid password identical with the one already stored in the NFC card's memory and restore the default password if any to enable the subsequent NFC card reading by any third party devices. Alternatively, locking and unlocking can be effected by a technique involving UID replacement. According to this approach, NFC lock application 30 replaces the NFC card's 25 manufacturer's NFC chip unit identifier (UID) with a randomly generated UID, and thereby hides the identity of the NFC chip from other NFC readers. Thus: " LOCK CARD: the user taps the NFC card to activate the magnetic field and power up the NFC card. Smartphone 10 reads the NFC card and matches it to the corresponding UID stored in the NFC card list. Upon selection of the LOCK function, 30 NFC lock application 30 generates a random or pseudo-random new UID, which it stores alongside the manufacturer's UID in the NFC card list, and writes the new UID onto the NFC card. The NFC card cannot now be accessed by other parties as its new UID is unknown to other parties. " UNLOCK CARD: the user taps the NFC card to activate the magnetic field and power 35 up the NFC card. Smartphone 10 reads the NFC card with the matching 'new' UID previously stored in the NFC device when the NFC card was locked. Upon selection of the UNLOCK function, NFC lock application 30 rewrites the old UID onto the NFC WO 2013/155562 PCT/AU2013/000399 - 11 card and destroy the temporary 'new' UID. The NFC card can now be accessed, as its old UID is known to parties authorized by the NFC card issuer. As examples, NFC lock application 30 employs the following commands: PSW ACCESS 5 0 Lock TAG: write tag.write(byte, "PSW", getBytes (encodedName like US-ASCII)) 0 Unlock TAG: read string(byte, encodedName like US-ASCII) UID REPLACEMENT * Lock TAG: HALT (SLPREQ (50)) * Unlock TAG: WUPA (ALLREQ (52)) or RTQA (ATQA (26)) 10 PAN REPLACEMENT * Lock TAG: WRITE (RN#, CCF XOR PAN) TO PAN * Unlock TAG: WRITE (PAN) SERVICE/APPLICATION ACCESS * Lock NFC service/application: SetStatusCommand 15 * Unlock NFC service/application: SetStatusCommand Figure 3 is a flowchart 40 of the operational logic of NFC lock application 30 when processing an NFC card, where the card is locked or unlocked, and when determining whether the card is new, lost or damaged. Firstly, at step 42 the NFC card is powered up by being located in the proximity of 20 smartphone 10. At step 44, the NFC card details are read by smartphone 10 and, at step 44, NFC lock application 30 authenticates the NFC card's details. At step 46, NFC lock application 30 determines whether the details were correctly read. If so, processing continues at step 48 where NFC lock application 30 controls smartphone 10 to read the list of NFC cards in the NFC card list 50 stored in smartphone 10, then at step 52 NFC lock 25 application 30 checks whether the read NFC card details are in the NFC card list 50. If the card details are in the NFC card list, the NFC card is indeed the user's and processing continues at step 54 where the NFC card is processed according to the user's command(s) (such as to lock or unlock the NFC card), after which processing ends. If the NFC card's details are found not to be in the NFC card list at step 52, 30 processing continues at step 56 where NFC lock application 30 prompts the user to indicate whether the NFC card is indeed the user's (but not yet in the NFC card list). If the user selects "no", the NFC card is presumably an unlocked NFC card of another party and processing ends. If the user selects "yes", processing continues at step 58, where the user is prompted to add the NFC card's details to the NFC card list 50, after processing continues 35 at step 54 (see above).

WO 2013/155562 PCT/AU2013/000399 -12 If at step 46 NFC lock application 30 determines that the card's details were not correctly read, the NFC card may be locked, damaged or a lost card. In this context the description "lost" is used for personal NFC cards locked by an NFC device that is not available (i.e. sold, lost, stolen, damaged, etc.). Hence, processing continues at step 62 5 where NFC lock application 30 displays the NFC card list from NFC card list 50 so that the user can visually inspect 64 the NFC card's details and thus check the NFC card list's contents to determine whether the NFC card is listed. At step 66, NFC lock application 30 prompts the user to indicate whether the NFC card is listed and, if the user enters "yes" (i.e. indicating that the NFC card is indeed listed), 10 processing continues at step 68 card where NFC lock application 30 unlocks the NFC card. At step 70, NFC lock application 30 controls smartphone 10 to again attempt to read the NFC card. At step 72, NFC lock application 30 determines whether the NFC card's details were correctly read and, if so, processing continues at step 54. If not, processing continues at step 74 where NFC lock application 30 controls smartphone 10 to display "NFC Card 15 Damaged" and processing ends. If, in response to being prompted to indicate whether the NFC card is listed in the NFC card list 50 at step 66, the user enters "no" (indicating that the NFC card is not listed), processing continues at step 76 card where NFC lock application 30 prompts the user to indicate whether the NFC card is a lost card of the user or not. If, in response, the user 20 enters "no" (indicating that the NFC card is not the user's), processing ends. If the user enters "yes" (indicating that the NFC card is the user's), processing continues at step 78 where the user is prompted to enter the NFC card's details into the NFC card list 50. Processing then continues at step 68, where the NFC card is unlocked, and then step 70 where NFC lock application 30 controls smartphone 10 to again attempt to read the NFC 25 card. At step 72, NFC lock application 30 determines whether the NFC card's details were correctly read and, if so, processing continues at step 54. If not, processing continues at step 74 where NFC lock application 30 controls smartphone 10 to display "NFC Card Damaged" and processing ends. Figure 4 is a flowchart 80 of an alternative operation of the NFC lock application of 30 figure 2 when detecting the card status and ownership of an NFC card, in which an automated check is performed. That is, the visual check (see step 64 of figure 3) is replaced with an automated check by NFC lock application 30. Steps 42 to 58 are as described above. However, if at step 46 NFC lock application 30 determines that the NFC card's details were not correctly read, processing continues at 35 step 82 where NFC lock application 30 unlocks the NFC and, at step 84, controls smartphone 10 to attempt to read the NFC card's details again. Then, at step 86, NFC lock application 30 determines whether the NFC card's details were correctly read and, if not, WO 2013/155562 PCT/AU2013/000399 -13 processing continues at step 88 where NFC lock application 30 controls smartphone 10 to display "NFC Card Damaged" and processing ends. However, if at step 86 NFC lock application 30 determines that the NFC card's details were correctly read, processing continues at step 90 where NFC lock application 30 5 checks the NFC card's details against the contents of NFC card list 50. If NFC lock application 30 determines at step 92 that the NFC card is listed, processing continues at step 54 (see above). If, however, If NFC lock application 30 determines at step 92 that the NFC card is not listed, processing continues at step 94 and NFC lock application 30 controls smartphone 10 to prompt the cardholder to indicate whether the NFC card is his or hers. If 10 the user enters "no", processing continues at step 96 (the NFC card evidently being that of a third party card), whether NFC lock application 30 locks the NFC card and processing ends. If the user enters "yes", processing continues at step 98 (the NFC card being a lost card of the user), whether NFC lock application 30 prompts the user to re-enter the lost NFC card's details into the NFC card list 50, then processing continues at step 54 (see above). 15 Figure 5 is a schematic block diagram of some of the operational components of operating system 14 and micro-SD 18 according to a variation of the present embodiment, illustrating a secure element software architecture in which NFC lock application 30 is integrated into the Secure Elements of the respective Card issuers that have adopted NFC lock application 30. This means that different versions of NFC lock application 30 may be 20 resident in the Security Domain allocated to NFC lock application 30 by some Card Issuers within their Security Elements, and may coexist with the standard version of NFC lock application 30 (which does not require secure ID activation). Referring to figure 5, operating system 14 includes an operating system (OS) kernel 100, which includes one or more device applications 102 (of which only a first exemplary 25 device application is shown for clarity), an application manager 104, utility services module 106, communications services module 108 and an secure element (SE) access API 110. Each device application 102 includes a digital signature 112 and a digital certificate 114, and is in data communication with application manager 104, utility services module 106 and communications services module 108. SE access API 110 includes an access control 30 enforcer 116 (an API defined by GlobalPlatform (trade mark)), an SE partition manager 118, whose main role is to identify and select the SE partition allocated in a specific card to a specific card issuer, an SE partition loader 120, whose main role is to either update (or replace) or load executable code and data (rules, SCST, etc.) into the selected SE partition, and an SE partition cryptographic module 122, whose main role is to ensure only authorized 35 access to the security domain (SD) access rules and SCST loaded into the selected card issuer's ARA-M of the specific SE partition. Micro-SD 18 includes one or more multi-partition secure elements (SEs) 130 (of which only a first exemplary multi-partition SE is shown for clarity). Each multi-partition SE WO 2013/155562 PCT/AU2013/000399 -14 130 is partitioned into a plurality of secure element (SE) partitions 132(1), 132(2),..., 132(n); each SE partition 132(1), 132(2)...132(n) is allocated to a respective card-issuer 1, 2,..., n. In this embodiment, each SE 130 has-in this embodiment-8, 16 or 32 SE partitions 132(1), 132(2),..., 132(n). 5 Each SE partition 132(1), 132(2),..., 132(n) has an access rule application master (ARA-M) 134 that includes, in the example of SE partition 132(1), a first register 136 that stores access rules and control data of the respective card issuer and a second register 138 that stores a unique smart-card security table (SCST) of random keys generated by the respective card issuer to protect that card issuer's NFC cards. Each SE partition 132(1), 10 132(2),..., 132(n) also has an SCST version no. register (indicated at 139 for SE partition 132(1)) with the SCST version number used by the respective card issuer. Each NFC card released by a card issuer is initialized with the unique SCST in the second register of that card issuer, so each NFC device is loaded with the respective SCSTs and SCST version numbers associated to the NFC cards expected to be used with the device (in this example, 15 smartphone 10). Each card issuer can thus stipulate, with its respective access rules and control data, its own set of access rules for the management and control of data in its dedicated SE partition within the multi-partition SE 130. Access control enforcer (ACE) 116 of operating system 14 controls access to ARA-M 134. 20 The SCST in each SE partition 132(1), 132(2),..., 132(n) holds different sets of security keys for securing the data in each respective SE partition 132(1), 132(2),..., 132(n). Any suitable technique may be employed to generate security keys, but in this embodiment each SCST is generated-by the respective card issuer-and employed using implicit key management (IKM) module 140, according to the IKM method disclosed in Australian patent 25 application no. 2012901149 filed 22 March 2012 and international patent application no. PCT/AU2013/000299 filed 22 March 2013, the content of both of which is incorporated herein by reference in its entirety. Thus, the SCST in SE partition 132(1) contains 256 random byte keys of 8 bits each, employed to encrypt/decrypt data stored in the respective SE partition as described in those patent applications according to IKM module 140 to 30 provide data integrity, privacy and non-repudiation for messages exchanged with other active (peer smart-phones, EFTPOS and other devices) or passive devices (such as contact and contactless smart-cards and TAGs). The other SE partitions contain comparable SCSTs, with different sets of keys. In addition, each SE partition 132(1), 132(2),..., 132(n) can use one or more 35 application security domains (SDs). Each application SD on a particular SE partition 132(1), 132(2),..., 132(n) may contain an application authorized by the card issuer to which the corresponding SE partition is allocated; each application is provided by a respective application provider.

WO 2013/155562 PCT/AU2013/000399 -15 Figure 5 depicts examples of application SDs 142(1), 142(2),..., 142(i) associated with SE partition 132(1) of card issuer 1, but it will be understood that each of SE partitions 132(1), 132(2),..., 132(n) may have none, one or more than one application SDs. In this embodiment, each SE partition 132(1), 132(2),..., 132(n) contains 2, 4 or 8 application SDs 5 142(1), 142(2),..., 142(i) and hence generally 2, 4 or 8 applications (though in other embodiments there may be more application SDs per SE partition and hence correspondingly more applications). As with the number of card issuer SE partitions per SE, the number of application SDs per card issuer SE partition is limited by the memory size of the medium used to store the SEs, in this example micro-SD 18, and it is envisaged that 10 greater numbers of card issuer SE partitions per SE and of application SDs per card issuer SE partition will be possible as the memory size of available media increases. Application SD 142(1) of SE partition 132(1) is described below as an example, but the other application SDs of SE partition 132(1) have comparable features (though different respective applications). In this example, the application stored in application SD 142(1) is 15 NFC lock application 30. Application SD 142(1) also includes an access rule applications client (ARA-C) 146 that is managed by ARA-M 134 of card issuer SE partition 132(1), and an application register 147 that contains the IlDs of any other card issuers that share NFC lock application 30 with the card issuer to whom SE partition 132(1) is allocated. ARA-C 146 includes a set of access rules and control data 148. 20 Application register 147 of shared applications (and the corresponding application registers in the other application SDs) are maintained by SE partition manager 118. As mentioned above, these application registers include data indicative of the other authorized card issuers, so that access control enforcer 116, which-as described above-controls access to ARA-M 134 of SE partition 132(1) and to the ARA-Ms of the other card issuer SE 25 partitions, can ensure that only authorized (other) card issuers can use such applications including, in this embodiment, NFC lock application 30. In this example, application SD 142(2) of SE partition 132(1) contains EMV (which stands for 'Europay

TM

, MasterCard

TM

, VisaTM,), an application that provides enhanced security for credit and/or debit payment smart-cards. Application SD 142(2) includes its own 30 access rule applications client (cf. ARA-C 146 of application SD 142(1)) that includes a set of access rules and control data and that is also managed by ARA-M 134 of card issuer SE partition 132(1), and an application register (cf. application register of application SD 142(1)) that contains the IlDs of the card issuers that share this application with the card issuer to whom SE partition 132(1) is allocated. 35 One or more additional application SDs may be created for further applications as desired.

WO 2013/155562 PCT/AU2013/000399 -16 In this embodiment, SEs 130 are contained in micro-SD 18, but they may in other embodiments be located on SIM card 20, in a device cache (such as in device memory 16) or in some other PCI PED security module. Figure 6 is a schematic block diagram of operating system 14 and micro-SD 18 (of 5 the variant embodiment of figure 5) and their relationship to the systems of various parties, such as the card issuers, and components (indicated by 'APP' in the figure) of figure 5 including SE partition manager 118, SE partition loader 120, SE partition cryptographic module 122 and NFC lock application 30. Referring to figure 6, it will be noted that a controlling authority (CA) 150 issues certificates to NFC application provider 152 that 10 provides the program modules (and who receive them from an NFC application developer or owner 154). The NFC application provider 152 provide the program modules, certificates and cryptographic keys (for the SCST in second register 138) to NFC enables devices via a device transaction acquirer (which performs SSD management) or card enabler 156, under the control of a NFC card issuer 158 (which also gives authority to NFC application 15 developer or owner 154 of the program modules). Figures 7A and 7B contain a schematic view of the NFC card Locking and Unlocking protocols employed by NFC lock application 30 of figure 2, which employ the replacement of the UID upon the successful modification of Access Conditions for Block Zero of sector 1. Figures 7A and 7B illustrate flow between an NFC enabled device such as 20 smartphone 10 (see figure 7A) and an NFC Card or TAG (see figure 7B) of the messages required for reading and locking or for reading and unlocking NFC cards from various card issuers. The locking mechanism of NFC lock application 30 requires the selection and reading of an NFC card with the desired UID, and implements the following steps: 25 a. Save in smartphone 10 an original UID of the NFC card, known to all parties; b. Generated a random (temporary) UID and store it in smartphone 10; c. Write new UID onto the NFC card after changing Access Conditions to Read/Write for Block Zero. The unlocking mechanism of NFC lock application 30 requires selecting and reading 30 an NFC card with the desired UID, and implements the following steps: a. Read original UID of the NFC card from device memory 16 of smartphone 10; b. Erase new UID from device memory 16 of smartphone 10; c. Write original UID onto the NFC card after changing Access Conditions to read-Only for Block Zero. 35 Figure 8 is a schematic block diagram 160 of the network topology employed by the in the development, certification and distribution of NFC lock application 30 of figure 2.

WO 2013/155562 PCT/AU2013/000399 -17 It will be appreciated that there will be two classes of users of NFC lock application 30, each with its own privileges and characteristics and types of relationship with the application owner. End Users class (B2C). End Users are individuals (business or private) equipped 5 with NFC mobile phones (or tablets), such as smartphone 10, and NFC cards. They use the NFC lock application 30 to protect their NFC cards against NFC pickpocketing by locking their NFC cards when not in use and unlocking them for use. NFC cards are generally used for: * Micro-payments 10 0 Access to physical sites, IT computer equipment and resources and personal records (medical, driving licences, education, passports, etc.) * Ticketing (transportation, sport events, etc.) Card Issuers class (B2B). NFC card issuers have additional privileges that enable them to customize the user Interface of NFC lock application 30 in accordance with 15 their business requirements (i.e. branding, limits, etc.). NFC card issuers include the following groups: * Financial card issuers (e.g. AMEX T M , VISATM, MasterCard T M , etc.) * Operating System suppliers/Wallets (e.g. GOOGLE T M , AppleTM, Microsoft T M , etc.) * Equipment manufacturers/Wallets (e.g. Samsung

TM

, Nokia

TM

, GOOGLE

TM

, Apple, 20 etc.). F161: B2B function 161: customize NFC lock application 30 for a mobile Operating System: a development kit is implemented by the developer and provided by the application's owner to card issuers to customize NFC lock application 30. Function F161 allows the card issuers to: 25 0 Un-sign NFC lock application 30 to validate Source ID. * Select NFC lock application 30 source code file (Java or .Net). * Add card issuer's Brand/Logo (Icon) and Welcome message (Advertising Line). * Select O.S. software development kit (SDK) to create screen templates and O.S. "family feeling" (colours, sounds, etc.). 30 * Compile NFC lock application 30 to create Applet or Module to be linked at runtime. F162: B2C function 162: deliver customized and certified NFC lock application 30: certify customized NFC lock application 30 with selected Certification Authority (i.e. itself), and deliver NFC lock application 30 to selected APP store, Service Providers (GOOGLE TM 35 YAHOOTM, etc.). The developer that develops NFC lock application 30 is issued with a unique identifier by a trusted organization (Certification Authority or CA 164) to sign its applications.

WO 2013/155562 PCT/AU2013/000399 -18 CA 164 reviews and certifies NFC lock application 30 in terms of potential security effects on other applications, operating systems and equipment and issue a compliance certificate. The certificate is validated by the recipients in terms of authenticity and identity prior to allowing the download, linking and execution of NFC lock application 30. NFC lock application 30, in 5 its various versions (e.g. trial, production, upgrades), can be retrieved from an application or cyber store via the developer's "landing" page using either key words on a search engine (such as GOOGLE

TM

) or from using the URL address of NFC lock application 30 received as a promotion via other Internet information providers (such as YAHOO!TM). Figure 9A is a schematic block diagram of the architecture of an alternative NFC 10 lock method according to another embodiment of the present invention, employing the implicit key management method referred to above by reference to figures 5 and 6. Instead of using an ACCESS CODE or PASSWORD or a temporary UID (described by reference to figures 7A and 7B) to lock and unlock NFC cards, the NFC lock application of this embodiment uses this implicit key management method to replace the NFC card personal 15 account number (PAN) with a protected PAN. This implicit key management method is disclosed in Australian patent application no. 2012901149 filed 22 March 2012 and international patent application no. PCTIAU2013/000299 filed 22 March 2013, the content of both of which is incorporated herein by reference in its entirety. Figure 9A illustrates the effects of locking and unlocking on a user's card protected 20 by the NFC lock application of this embodiment, on third party cards protected by the NFC lock application of this embodiment and on third party cards not protected by the NFC lock application of this embodiment. This embodiment: a. Permits a user's own NFC cards loaded into his or her device to be locked or unlocked; 25 b. Permits third party locked NFC cards present to be unlocked with the owner's permission; c. Prevents third party NFC cards not present being locked by the NFC lock application of this embodiment. In this figure, a locked card is denoted with a circle having dark shading 30 (representing RED status), while an unlocked card is denoted with a circle having light shading (representing GREEN status). Figure 9B is a schematic block diagram of the NFC locking mechanism of the embodiment of figure 9A, using the implicit key management method referred above. The implicit key management method is used, according to this embodiment, to replace the 35 original PAN value with an enciphered value of the PAN XOR-ed with a Card Code Function (CCF) argument generated from a number of keys combined temporarily in accordance with the on-time value of a randomly generated number (RN#).

WO 2013/155562 PCT/AU2013/000399 -19 Figure 9B illustrates the effects of locking with the NFC locking mechanism of this embodiment on new and existing NFC cards already loaded in the NFC card list stored in smartphone 10. The locking process, which applies only to NFC cards stored in device memory 16 of smartphone 10, has the following steps: 5 1. Generate random number RN#; 2. Use RN# digits to extract keys (CCF arguments) from SCST 68; 3. XOR the first CCF argument with the PAN, the second CCF argument with the result of the first XOR operation, and so on until all CCF arguments have been used; 4. Build message to be written onto the NFC card by combining the RN# and the final 10 XOR-ed value into a temporary enciphered PAN, where the last 3 bytes are an asterisk delimiter followed by 2 byte RN# in hex as trailer; 5. Change NFC card semaphore status from GREEN (unlocked) to RED (locked); 6. Replace the original PAN value with the temporary enciphered PAN value and trailer. Figure 9C is a schematic block diagram of the NFC un-locking mechanism of the 15 embodiment of figure 9A, which uses the implicit key management method referred to above to recalculate the original PAN by XOR-ing the XOR-ed PAN value with a Card Code Function (CCF) argument reconstructed from a number of keys combined temporarily in accordance with the on-time value of a randomly generated number (RN#) read from the card. 20 Figure 9C illustrates the effects of unlocking on new NFC cards and existing NFC cards already loaded in the NFC card list stored in smartphone 10 the NFC un-locking mechanism of this embodiment. The unlocking process, which applies only to NFC cards stored in device memory 16 of smartphone 10, has the following steps: 1. Read NFC card and get random number RN#, if the card was previously locked; 25 2. Use RN# digits to extract keys (CCF arguments) from the SCST; 3. XOR the first CCF argument with the PAN, the second CCF argument with the result of the first XOR operation, and so on until all CCF arguments have been used; 4. Build message to be written onto the NFC card restoring the original PAN value, where the last 3 bytes of the trailer are now empty. 30 5. Change NFC card semaphore status from RED (locked) to GREEN (unlocked); 6. Replace the temporary PAN value with the original PAN value and empty trailer. Thus, the present embodiment provides a simple method and software product for locking and unlocking contactless smart-cards (including RFID and NFC cards) at cardholder's discretion. 35 NFC lock application 30 and its variants described herein can be loaded onto an NFC enabled NFC mobile device, and permit the loading of NFC card details by "tapping" an NFC card on the NFC mobile device and entering the NFC card's EXP DATE and the WO 2013/155562 PCT/AU2013/000399 -20 second set of 4 PAN digits, already stored on the card, once the NFC card's details (e.g. PAN, EXP DATE and optionally the cardholder's name) have been read and partially displayed. By pressing (or sliding) the LOCK button displayed by NFC lock application 30 for 5 each NFC card resident in the NFC card list of the NFC mobile device, the NFC card's current status will be changed from Lock to Unlock or the opposite. The NFC card's details can be removed from the NFC card list at the user's discretion. The embodiments of the invention described above have applications in many areas where secure data storage and security of communications between two RFID devices 10 (such as NFC devices) is required. A typical example is the protection of electronic passports (e-Pass) or electronic health cards or electronic licences against illegal access. Such passports contain contactless smart-cards which store the personal information of the passport holder, including the biometrics and digital signature. As with other types of contactless smart-cards, NFC lock application 30 will lock the e-Pass when not used upon 15 the optical reading/scanning and presentation of valid access data enciphered with the Passport Issuer's public key stored in the MRZ. Modifications within the scope of the invention may be readily effected by those skilled in the art. It is to be understood, therefore, that this invention is not limited to the particular embodiments described by way of example hereinabove. 20 In the claims that follow and in the preceding description of the invention, except where the context requires otherwise owing to express language or necessary implication, the word "comprise" or variations such as "comprises" or "comprising" is used in an inclusive sense, that is, to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention. 25 Further, any reference herein to prior art is not intended to imply that such prior art forms or formed a part of the common general knowledge in any country.

Claims

1. A method of locking a smart card having a smart card chip, comprising: a control device that is adapted to communicate with the smart card transmitting a lock command to the smart card, the command being adapted to control the smart card to 5 block data communication responses of the smart card chip without disabling an RF antenna, magnetic field reception and monitoring circuitry of the smart card chip.

2. A method as claimed in claim 1, wherein the control device includes a record of smart cards of a user of the control device, and the method further comprises: the control device requesting that the smart card provide a smart card chip identifier; 10 the smart card responding by transmitting the identifier of the smart card chip to the control device; the control device receiving the identity and comparing the identifier of the smart card chip with the record of smart cards; the control device locating an identity in the record that corresponds to the identifier 15 of the smart card chip of the smart card; and the control device responding to locating the identity in the record that corresponds to the identifier of the smart card chip by transmitting the lock command to the smart card.

3. A method as claimed in claim 1, including the control device displaying to the user identities of one or more of the smart cards identified in the record, prompting the user to 20 input a selection of at least one of the smart cards identified in the record that the user wishes to lock, and responding to the inputting of the selection by locking the smart card identified by the selection inputted by the user.

4. A method as claimed in claim 1, including configuring the control device to require a password or other authorization from the user before accepting input for or modification of 25 the record of smart cards.

5. A method as claimed in claim 1, including transmitting an access password to the smart card with a command adapted to control the smart card to store the password and to refuse access requests that omit the password.

6. A method as claimed in claim 1, including the control device generating a random or 30 pseudo-random smart card chip identifier, writing the random or pseudo-random smart card chip identifier to the record of smart cards associated with the identity of the smart card, and transmitting the random or pseudo-random smart card chip identifier to the smart card with a command adapted to control the smart card to write the random or pseudo-random smart card chip identifier to the smart card chip. WO 2013/155562 PCT/AU2013/000399 -22

7. A method as claimed in claim 1, including automatically locking the smart card after each transaction or after a user's pre-set time interval, or after a pre-defined number of transactions.

8. A method of unlocking a smart card having a smart card chip, comprising: 5 a control device that is adapted to communicate with the smart card transmitting an unlock command to the smart card, the command being adapted to control the smart card to unblock data communication responses of the smart card chip.

9. A method as claimed in claim 8, wherein the control device includes a record of smart cards of a user of the control device, and the method further comprises: 10 the control device requesting that the smart card provide a smart card chip identifier; the smart card responding by transmitting the identifier of the smart card chip to the control device; the control device receiving the identifier and comparing the identifier of the smart card chip with the record of smart cards; 15 the control device locating an entry in the record of smart cards that corresponds to the identifier of the smart card chip of the smart card; and the control device responding to locating the entry in the record that corresponds to the identifier of the smart card chip by transmitting the unlock command to the smart card.

10. A method as claimed in claim 8, including the control device displaying to the user 20 identities of one or more of the smart cards identified in the record of smart cards, prompting the user to input a selection from the smart cards identified in the record of smart cards that the user wishes to unlock, and responding to the inputting of the selection by unlocking the smart card or smart cards identified by the selection inputted by the user.

11. A method as claimed in claim 8, including configuring the control device to require a 25 password or other authorization from the user before accepting input for or modification of the record of smart cards.

12. A method as claimed in claim 8, including the control device presenting to the smart card a command that includes a password identical with a previously stored password in a memory of the smart card, wherein the previously stored password was stored in locking the 30 smart card.

13. A method as claimed in claim 8, including reading the smart card using an additional random or pseudo-random smart card chip identifier generated in association with a locking of the smart card and stored in the record of smart cards in association with the identity of the smart card, and transmitting an original smart card chip identifier to the smart card with a 35 command adapted to control the smart card to write the original smart card chip identifier to the smart card chip. WO 2013/155562 PCT/AU2013/000399 -23

14. A method as claimed in claim 8, including automatically unlocking the smart card when the smart card is presented to a control device identified in a list of trusted or preferential devices stored in the smart card by the control device or a comparable authorized device.

15. A method as claimed in any one of claims 1 to 14, wherein the smart card is an NFC 5 card, the control device is an NFC enabled device, and the smart card chip is an NFC chip.

16. A control device adapted to communicate with a smart card and configured to implement the method of any one of claims 1 to 15.

17. A computer program product executable on a control device that is adapted to communicate with a smart card, and which when executed on the device implements the 10 method described above.

18. A computer readable medium having stored therein a computer program product executable on a control device that is adapted to communicate with a smart card, and which when executed on the control device implements the method described above.