US20120238206A1 - Communications device providing near field communication (nfc) secure element disabling features related methods - Google Patents

Abstract

A communications device may include a near field communication (NFC) device, at least one memory configured to store secure application data to be communicated via the NFC device and a secure element (SE) application programming interface (API) associated with the secure application data, and a processor coupled with the NFC device and the at least one memory. The processor may be configured to disable the SE API to prevent access to the secure application data based upon a security condition, and enable the SE API to allow access to the secure application data based upon a security restore event.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application claims the benefit of provisional application no. 61/452,511, filed Mar. 14, 2011, which is hereby incorporated herein in its entirety by reference.
TECHNICAL FIELD
• This application relates to the field of communications, and more particularly, to wireless communications systems and related methods.
BACKGROUND
• Mobile communication systems continue to grow in popularity and have become an integral part of both personal and business communications. Various mobile devices now incorporate Personal Digital Assistant (PDA) features such as calendars, address books, task lists, calculators, memo and writing programs, media players, games, etc. These multi-function devices usually allow electronic mail (email) messages to be sent and received wirelessly, as well as access the internet via a cellular network and/or a wireless local area network (WLAN), for example.
• Some mobile devices incorporate contactless card technology and/or near field communication (NFC) chips. NFC technology is commonly used for contactless short-range communications based on radio frequency identification (RFID) standards, using magnetic field induction to enable communication between electronic devices, including mobile wireless communications devices. This short-range high frequency wireless communications technology exchanges data between devices over a short distance, such as only a few centimeters.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is a schematic block diagram of a communications system in accordance with an example embodiment.
• FIG. 2 is a schematic diagram of the communications system ofFIG. 1 showing the display of the mobile device.
• FIG. 3 is a more detailed schematic diagram of the communications system ofFIG. 1.
• FIG. 4 is a flow diagram illustrating example method aspects associated with the systems ofFIGS. 1-3.
• FIG. 5 is a schematic block diagram of a communications system in accordance with another example embodiment.
• FIG. 6 is a flow diagram illustrating example method aspects associated with the system ofFIG. 5.
• FIG. 7 is a schematic block diagram illustrating example mobile wireless communications device components that may be used with the devices ofFIGS. 1-3 and5.
DETAILED DESCRIPTION
• The present description is made with reference to the accompanying drawings, in which embodiments are shown. However, many different embodiments may be used, and thus the description should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete. Like numbers refer to like elements throughout.
• Generally speaking, a communications device is provided herein which may include a near field communication (NFC) device, at least one memory configured to store secure application data to be communicated via the NFC device and a secure element (SE) application programming interface (API) associated with the secure application data, and a processor coupled with the NFC device and with the at least one memory. The processor may be configured to disable the SE API to prevent access to the secure application data based upon a security condition, and enable the SE API to allow access to the secure application data based upon a security restore event. Accordingly, the processor may advantageously prevent access to the secure application data without having to wait for a trusted service manager (TSM) to authorize deletion of the secure application data, for example.
• More particularly, the communications device may further include a wireless transceiver coupled with the processor, and the security condition may comprise initiation of a wipe while the wireless transceiver is not in communication with a wireless communications network. In accordance with other examples, the communications device may further include an input device coupled with the processor, and the security condition may comprise a threshold number of unsuccessful device authentication attempts via the input device, or a security command entered via the input device. Also by way of example, the security restore event may comprise receiving a secure application data delete command via the wireless transceiver, or receiving a security restore command via the input device.
• The NFC device may also have an NFC API associated therewith. As such, the processor may be further configured to enable the NFC API for NFC communication while the SE API is disabled. Additionally, the processor may be further configured to prevent write access to the memory based upon the occurrence of the security condition.
• A related communications system may include a NFC terminal and a communications device, such as the one described briefly above. A related method for operating a communications device, such as the one described briefly above, may include disabling the SE API to prevent access to the secure application data based upon a security condition, and enabling the SE API to allow access to the secure application data based upon a security restore event.
• A related non-transitory computer-readable medium is for a communications device such as the one described briefly above. The non-transitory computer-readable medium may have computer-executable instructions for causing the communications device to perform steps comprising disabling the SE API to prevent access to the secure application data based upon a security condition, and enabling the SE API to allow access to the secure application data based upon a security restore event.
• Referring initially toFIGS. 1-2, acommunications system30 illustratively includes a near field communication (NEC)terminal31 associated with an object, and a mobile wireless communications device32 (also referred to as a “mobile device” herein). Example mobile wireless communications devices may include portable or personal media players (e.g., music or MP3 players, video players, electronic book readers, etc.), portable gaming devices, portable or mobile telephones, smartphones, tablet computers, digital cameras, etc.
• Themobile device32 illustratively includes aportable housing33 and awireless transceiver34 carried by theportable housing33. Thewireless transceiver34 may comprise a cellular transceiver or other type of wireless communications transceiver, and may communicate any combination of voice and data, such as, for example, email. Thewireless transceiver34 may communicate with asecurity server36 that may provide one or more of remote instructions and provisioning operations to themobile device32.
• Themobile device32 includes adisplay46 carried by theportable housing33. Thedisplay46 may comprise a liquid crystal display (LCD), for example, and may be configured to display information relating to data or voice communications. Thedisplay46 may be in the form of an active display that includes a backlight, for example. Thedisplay46 may display email information, contact information, or call information. Thedisplay46 may be another type of display, for example, a passive display, and may display other information.
• Themobile device32 also includes aninput device45. Theinput device45 may be a keypad, touch-screen display, or other input device, for example.
• Themobile device32 also includes aprocessor35 that is carried by theportable housing33 and coupled with thewireless transceiver circuitry34, theinput device45, and thedisplay46. Theprocessor35 may be implemented using hardware (e.g., memory, etc.) and software components, i.e., computer-readable instructions for causing themobile device32 to perform the various functions or operations described herein.
• Themobile device32 also includes anNFC device40 carried by the portable housing and coupled with theprocessor35. TheNFC device40 includes aNFC controller41 and aNFC transceiver42 coupled with theNFC controller41. TheNFC controller41 and theNFC transceiver42 advantageously cooperate to perform at least one NFC communication function. For example, theNFC device40 may communicate with theNFC terminal31 based upon proximity thereto using NFC communication. TheNFC terminal31 may be a NFC tag, a NFC-enabled mobile device, a smart poster, etc.
• By way of background, NFC is a short-range wireless communications technology in which NFC-enabled devices are “swiped,” “bumped” or otherwise moved in close proximity to communicate. In one non-limiting example implementation, NFC may operate at 13.56 MHz and with an effective range of several centimeters, typically 4 cm or less, but other suitable versions of near-field communication which may have different operating frequencies, effective ranges, etc., for example, may also be used.
• TheNFC device40 also includes afirst memory43 coupled to theNFC controller41. More particularly, thefirst memory43 may be embedded within the NFC device hardware or within the NFC integrated circuit (IC). Thefirst memory43 may be tamper resistant, for example. In other words, thefirst memory43 may comprise a secure element. Thefirst memory43 or secure element, may store applications relating to NFC communications, or contactless applications for communicating with theNFC terminal31. For example, the applications may include financial payment applications, secure access system applications, loyalty card applications, and other applications, and may be encrypted. In some example embodiments, thefirst memory43 may store only one application.
• Themobile device32 also includes asecond memory44. Thesecond memory44 may comprise the device memory, for example. In other words, thesecond memory44 may include operating system files, applications, and other device data. In some example embodiments, thesecond memory44 may be part of the universal integrated circuit card (UICC), for example. Thesecond memory44 may also be removable, and may be a secure-digital (SD) card or a subscriber identity module (SIM) card, for example. Thesecond memory44 may comprise another type of memory, for example a flash memory. While first andsecond memories43,44 are described herein, more than two memories may be used. In other words, applications, or secure elements, may be stored in or spread over various memory devices. It should also be noted that a secure element may be implemented in a dedicated or secure area of a common memory, for example. In addition, multiple secure elements may be used.
• Theprocessor35 may be configured to disable theNFC transceiver42 based upon a security condition. A security condition may occur when a user of thedevice32 cannot be authenticated, for example, as a result of thedevice32 receiving too many incorrect password entries via theinput device45. Alternatively, the security condition may occur when thedevice32 receives, via theinput device45, a command to perform operations associated with a security condition. This may occur, for example, in the context of a user who will no longer be using thedevice32 and is preparing to give away thedevice32 to another user or trade in thedevice32 for a new device, for example. These operations may be collectively referred to as a “wipe”. Still further, a security condition may occur when thedevice32 receives a remote command, e.g., a remote wipe command, indicating a security condition, for example, from a system administrator. This may occur, for example, in the context of a lost or stolen or otherwise compromised device. However, a user-initiated wipe may also occur when themobile device32 is not in communication with a network, i.e., it is out of coverage (e.g., wireless coverage, data coverage, radio coverage, etc., for example.
• If a security condition is detected, theprocessor35 may be configured to disable access to the applications on thefirst memory43, e.g., secure payment applications. Disabling is performed since themobile device32 typically does not have unlimited read/write access to thefirst memory43 since the first memory does not inherently “trust” themobile device32. That is, secure data or applications stored on thefirst memory43 typically may not be modified except by a trusted third party source, as will be discussed further below. Thus, thesecurity server36 is able to initiate a wipe of thefirst memory43 based upon communication therewith, as will be described in further detail below. That is, the ability for a mobile device application to interact with an application on a secure element may be disabled via the baseband interface. Another example approach is to use a mobile device application to disable the ability of an application on the secure element to communicate via theNFC transceiver42.
• After disabling access to the applications on thefirst memory43, theprocessor35 is configured to erase the contents, or second application from thesecond memory44, or device memory. In other words, themobile device32 is wiped.
• Theprocessor35 performs a reset operation after successfully erasing the applications from thesecond memory44. In other words, the reset operation may be based upon a successful wipe. The reset operation may be performed by selectively disabling apower source37 carried by thehousing33 and coupled to theprocessor35. In other words, the reset operation may comprise a power down/power up cycle of themobile device32. Thepower source37 may comprise a battery cell, for example. In some example embodiments, a reset operation may not be performed.
• Theprocessor35 is also configured to erase the applications from thefirst memory43 after the reset operation. Theprocessor35 may erase the applications based upon a command received from thesecurity server36 via thewireless transceiver34 after the reset operation. Theprocessor35, after the applications are deleted or wiped from thefirst memory44, is configured to enable access to the NFC transceiver.
• In some example embodiments, the contents, or second application from thesecond memory44, may not be erased based upon a security condition. Based upon a security condition, the application on thefirst memory43 may be erased while selectively maintaining the second application on thesecond memory44. In other words, theprocessor35 may be configured to erase the application from thefirst memory43 without performing the steps of erasing the second application and resetting.
• Referring now toFIG. 3, in one advantageous example embodiment, thefirst memory43 may comprise an embedded secure element (eSE). An eSE comprises an integrated circuit (IC) that manages and includes credentials (e.g., credentials associated with various credit cards, bank cards, gift cards, access cards, transit passes, etc.) that have been provisioned to themobile device32. In an example embodiment, theeSE43 may run based upon a GlobalPlatform card specification and be compatible with a Java Card Platform Specification, for example. TheeSE43 may run or be compatible with other or additional platforms.
• Within theeSE43, GlobalPlatform is responsible for managing the lifecycle of other applets, and for providing them with security services (e.g., allowing application security domains to be created). Security domains maintain a lifecycle state for each applet (e.g., active, locked, etc.), manage the keys for authenticated access to an applet, and serve as an endpoint when a secure channel is established between asecurity server36, i.e., trusted service manager (TSM) and an applet. Thesecurity server36 or TSM is typically responsible for provisioning and managing the applets within its security domain on thefirst memory43.
• RF readers, and more particularly, NFC readers, for example, theNFC terminal31 may communicate with the applets that are installed on theeSE43 via theNFC controller41 andNFC transceiver43. A reader, orNFC terminal31 first selects an applet by its applet identifier (AID), GlobalPlatform checks for the existence of the applet in question (and verifies that the applet is in the correct lifecycle state), and then further application protocol data units (APDUs) sent by the reader are routed to the applet by GlobalPlatform. Generally, the RF readers, for example, theNFC terminal31, do not open secure channels to the security domains, and any authentication that occurs with the NFC terminal is the responsibility of the specific applet that gets selected.
• TheTSM36 may open a secure channel to the issuer security domain (ISD) via themobile device32, by authenticating itself using the appropriate ISD keys. An ISD is considered the security endpoint that communicates with the root TSM and allow for installation of applets and management of application security domains (ASDs). To themobile device32, this secure channel is entirely opaque. TheTSM36 may then manage applets (e.g., install and delete them, change their lifecycle states) and manage the application security domains on theeSE43. After establishing a secure channel with a security domain, theTSM36 can then send APDUs to the applets that belong to that security domain. The applet can determine that it is communicating with itsTSM36 over a secure channel, and can thus allow access to privileged or “administrative” commands.
• TheeSE43 typically does not “trust” themobile device32 to the same degree as theTSM36, since GlobalPlatform may not intend for a mobile device to have access to the keys that are needed to open a secure channel. However, an applet can determine that it is communicating over the baseband interface and thus allow access to commands that would not otherwise be available. The baseband interface generally refers to an interface for communications between theprocessor35 and theeSE43, or first memory, (via the NFC controller41). This may include commands that are sent from thewireless transceiver34, for example, that are then sent to theeSE43 across the baseband interface.
• For example, a credit card applet may allow the baseband interface to place it in a “visible” or “hidden” state, while allowing access to the necessary commands for a typical financial transaction over theNFC transceiver42 or RF interface. It should be noted that due to this restriction, themobile device32 may not “wipe” theeSE43 in a conventional sense. Based on the interfaces and application programming interfaces (APIs) provided by GlobalPlatform, there is typically no way for themobile device32 to delete an applet or, for that matter, even to enumerate the applets that are installed/instantiated on theeSE43.
• Based on the restrictions described earlier, it may be increasingly difficult for themobile device32 to directly delete applets from theeSE43. However, it may be unacceptable for a mobile device to delay a wipe until such time that theTSM36 could be contacted to wipe theeSE43, especially given that an attacker might remove the mobile device SIM, or any other persistent memory device, i.e., thesecond memory44, to ensure it does not have coverage.
• In the present embodiments, theprocessor35 takes steps to ensure data and access to theeSE43 is prevented when the mobile device wipe is triggered (effectively resembling a wipe of theeSE43 to the end user) and will result in the eSE being wiped at the next possible opportunity, i.e., whenever themobile device32 has coverage and is able to contact theTSM36.
• TheeSE43 may include applets or other code to perform the wipe process. More particularly, theeSE43 may include one or more emulation layers, for example, the MIFARE and iClass emulation layers. The emulation layers may not be directly linked to applets or other code on theeSE43, for example. The applet generally includes security keys for writing to its corresponding emulation layer, for example, for the MIFARE emulation class, this would be K_MIFARE, which is derived from K_A and K_B for a specific block of MIFARE memory. Each of the wipe applets may be installed and instantiated by theTSM36. The applets may be visible over the baseband interface, and it may respond to a specific APDU that may trigger it to wipe its corresponding emulation layer using the security keys, for example.
• The ISD lifecycle state can be moved to card lock, effectively disabling access to all applets on theeSE43 by an applet provided that it is granted the card lock privilege. Thus, a wipe applet can be installed and instantiated by theTSM36 to the ISD and given card lock privileges. The applet may be only visible over the baseband interface, and may respond to a specific APDU that triggers it to move the ISD lifecycle state to card lock. Additional code may be used so that certain portions, for example, internal code, can communicate with this applet.
• In a normal operating state, the user uses themobile device32 normally for voice and/or data communications. For example, if the user uses a wallet application and theTSM36 has installed anything to their mobile device'seSE43, the TSM installs and instantiates the “wipe applet” to the ISD, and asserts a persistent flag indicating theeSE43 is in use. If, at some point, theeSE43 is provisioned with an emulation layer credential, for example, the corresponding emulation layer wipe applet would be installed and instantiated at this time. For example, if theeSE43 is provisioned with a MIFARE credential, then the MIFARE wipe applet would be installed and instantiated at this time.
• In a first step, the wipe is triggered. As noted above, the mobile device wipe may be triggered in multiple ways, for example, receipt of too many incorrect password entries via theinput device45 in an attempt to gain access to themobile device32, receipt of a local wipe command, e.g., comprising a “wipe” option on the mobile device, or a remote wipe command may be sent. In the remote wipe case, an acknowledgement may be sent, for example. It is worthwhile noting that the wipe may not be delayed if this acknowledgement is not sent.
• In a second step, access to the processing interface for communicating with the eSE43 and thetransceiver42 is prevented or restricted. If a persistent flag indicating theeSE43 has been personalized, the mobile device wipe code may assert a persistent flag indicating theeSE43 has been locked. Each of the above-noted persistent flags may be set or cleared. The eSE primary interface APIs and the NFC transceiver APIs check the value of a persistent flag indicating that theeSE43 has been locked when they are called. If it is asserted, the eSE primary interface APIs typically should ignore any call not coming from an internal or trusted module, and the NFC transceiver APIs should disable all access to the card emulation mode.
• In a third step, each emulation layer is wiped. The wipe APDU is sent to the corresponding wipe applet over the baseband interface. The applet wipes personalization data in the emulation layer. More particularly, for example, the wipe APDU may wipe the personalization data in the iClass and MIFARE emulation layers.
• In a fourth step, theeSE43/ISD is moved to a card locked state. The wipe APDU is sent to the wipe applet over the baseband interface. The applet moves the ISD state to card locked, effectively denying access to applets and security domains on theeSE43. It should be noted that this step should take place after the third step, since otherwise communication may not be possible with the applets that wipe the emulation layers in those steps. After this step, although theeSE43 still includes personalized applets, these applets are no longer accessible to anyone but theTSM36. From the end user's perspective, theeSE43 is “wiped”.
• In a fifth step, themobile device32 is wiped. Themobile device32 is wiped by operating system (OS) code, for example.
• In a sixth step, themobile device32 restarts. Themobile device32 restarts after the wipe is successful.
• In a seventh step, an eSE proxy (not shown) signals theTSM36. The eSE proxy starts up and detects that the ISD is in a card locked state (by attempting to select the ISD over the baseband interface, or by checking the persistent flag indicating theeSE43 has been locked. It then waits for a data connection and signals theTSM36 that theeSE43 needs to be wiped.
• In an eighth step, theeSE43 is wiped. TheTSM36 deletes all applets from theeSE43. It should be noted that in some embodiments, selective access to theeSE43 may be provided over the baseband interface. For example, an application from a mobile device manufacturer may be allowed to access theeSE43 for the purposes of wiping the eSE, while access from third party applications may be restricted.
• In a ninth step, access to eSE primary interface APIs and theNFC transceiver42 are restored. Once theTSM36 is satisfied that all applets have been deleted from theeSE43, it signals the eSE proxy that a persistent flag indicating theeSE43 has been locked. At this stage, eSE primary interface APIs are unlocked to third parties, and theNFC transceiver42 is permitted to enter card emulation mode again. TheeSE43, at this point, has been reset to a factory state. It should be noted that in different embodiments steps other steps may be performed, or some steps may be performed in different orders.
• Referring now to theflowchart60 ofFIG. 4, related method aspects are now described. Beginning atBlock62, theprocessor35 determines whether a security condition has been initiated (Block64). For example, the securing condition may comprise a wipe, or entering a wrong password a given number of times (which may also trigger a wipe in some embodiments). If a security condition is determined, theprocessor35 disables the NFC transceiver42 (Block66). Theprocessor35 then disables access to the first plurality of applications on the first memory43 (Block68). AtBlock70, theprocessor35 erases the second application from thesecond memory44. A reset operation is performed by the processor35 (Block72). AtBlock74, thesecurity server36 sends a signal to theprocessor35 via thewireless transceiver34 once a connection is established therewith. AtBlock76 theprocessor35 erases the first plurality of applications from thefirst memory43 if the signal from thesecurity server36 is received. TheNFC transceiver42 atBlock78 is re-enabled after the first plurality of applications is erased. The method ends atBlock80.
• Turning now toFIG. 5, arelated communications system130 illustratively includes anNFC terminal131, a communications device132 (e.g., a mobile wireless communication device), and asecurity server136, which are similar to those described above. In particular, in the present example the communications device132 illustratively includes ahousing133 carrying awireless transceiver134, aNFC device140, an input device(s)145, adisplay146, one ormore memories147, and aprocessor135. Thewireless transceiver134,NFC device140,input device145,display146, andmemory147 are illustratively coupled with theprocessor135, and these components are similar to the counterpart components described above except as otherwise described below.
• TheNFC device140 has one ormore NFC APIs150 associated therewith. Moreover, thememory147 may be part of theNFC device140 in some embodiments, it may be a separate memory (e.g., SD card, SIM card, etc.), or both types of memories may be used, as noted above. In the present example, thememory147 illustratively includes secure element (SE)application data148 to be communicated via the NFC device140 (e.g., a secure applet, account information, etc.), and anSE API149 associated with the secure application data. As noted above, the API controls access to theSE application data148 stored in thememory147.
• As also noted above, SEs are where NFC applets such as payment (e.g., credit or debit card, etc.), transit, physical access control, and other secure applications are stored. In conjunction with theNFC device140, the SE will allow the mobile device132 to act as a payment or access card, for example. Typically, installation and removal or deletion of applications from an SE may only be performed by a third party entity that holds the master keys (i.e., issuer security domain keys) to authenticate with the SE. The third party entity (e.g., TSM) may open a cryptographically secure channel to the secure element (e.g., using a proxy application running on the mobile device132 to access the SE). For example, when a credit card applet is to be installed on the SE of the mobile device132, the TSM, after receiving the appropriate instructions from the given bank, will open a secure channel to a secure element and install the appropriate credit card applet. Subsequently, if the credit card applet is to be removed or deleted, the TSM will remove it.
• Such TSM operations require a communications link between the proxy and the TSM (typically an over-the-air connection in the case of a mobile wireless communications device, as described above). Again, this may create a problem in that if the user wants to wipe the mobile device132 before giving it away or disposing of it, etc., the user may not have coverage, either because of being out of wireless communications range, account cancellation, SIM card removal, etc. Without coverage, the TSM will not be able to issue the appropriate delete commands, so even after a security wiping of the mobile device132, thememory147 will still retain all of theSE application data148. Thus, for example, a credit card may still be used after the mobile device132 is wiped and handed off to another user.
• With further reference to the flow diagram160 ofFIG. 6, beginning atBlock162, theprocessor135 is configured to disable theSE API149 to prevent access to theSE application data148 based upon a security condition such as a device wipe, at Blocks164,166. In particular, the disabling may occur despite thewireless transceiver134 not being in communication with the security server136 (e.g., TSM) via a wireless communications network. Another security condition that may trigger disabling of theSE API149 may include a threshold number of unsuccessful access attempts to access the mobile device132 via the input device145 (e.g., incorrectly entered passwords, etc.), as noted above.
• Still another security condition that may trigger disabling of theSE API149 is a security command entered via theinput device145. For example, in some instances a user may desire to temporarily disable theSE application data148 so that the mobile device132 may be loaned to another user without allowing the other user to access the SE data, but not completely wipe the mobile device. In such cases, a security command (e.g., selection of a security option from an on-screen menu, etc.) may be used to temporarily cause theprocessor135 to disable theSE API149 so that theSE application data148 may not be accessed.
• In some embodiments, write access to thememory147 may optionally be selectively disabled while the SE API is disabled, atBlock168. That is, theprocessor135 may prevent any further SE data from being written to or installed on thememory147 by TSMs until the security condition has been resolved, as will be discussed further below. However, in the interim, theprocessor135 may optionally enable (or continue to allow) theNFC API150 to perform NFC communication while theSE API149 remains disabled for other NFC applications that do not require access to theSE data148, atBlock147.
• Theprocessor135 may enable theSE API149 to again allow access to theSE data148 based upon a security restore event, atBlocks172,174, which concludes the illustrated method (Block176). Accordingly, theprocessor135 may advantageously prevent access to theSE data148 without having to wait for a TSM to authorize deletion of the secure application data, for example. By way of example, the security restore event may include receiving a secure application data delete command via thewireless transceiver134, such as a delete command from the TSM that issued theSE data148. In the case of a user that temporarily disables theSE API149 as described above, the security restore event may comprise providing a secure password, biometric, etc., to restore NFC communication for the SE API.
• Accordingly, theprocessor135 is advantageously able to disable or suspend theSE API149 and the ability for theNFC device140 to route NFC traffic to the SE API if a security condition occurs. Thus, after the mobile device132 is wiped, etc., even thoughSE data148 remains in thememory147, theprocessor135 preventsNFC device140 traffic from being routed to or from theSE API149. As such, theSE data148 may not be accessed by the NFC terminal131 (e.g., an external point-of-sale terminal) for the purposes of performing a payment or other secure transaction.
• Moreover, theprocessor135 may, for example, only allowNFC device140 traffic to resume routing to theSE API149 after a delete command has been successfully received from the TSM and injected to delete theSE application data148, etc. This way, it may be assured that theSE data148 has been deleted before allowing a next user, for example, to activateNFC device140 communication routing to thememory147. In some example embodiments, theprocessor135 may also lock baseband access to the SE data148 (e.g. through JSR-177) unless the baseband access is being used to issue a delete command. Once the delete command has been issued, baseband access may be reinstated.
• This example approach provides several advantages. For example, the mobile device132 may be wiped at any time, regardless of whether it has coverage or whether there is a SIM inserted, without having to wait for a TSM to issue delete commands to the secure element to ensureSE data148 protection. Then, before theSE API149 orSE data148 may effectively be used again, theprocessor135 will enforce receipt of a cryptographically protected delete command from the TSM (in the case of a device wipe security condition) or appropriate security credentials before allowing theSE API149 to be used again, such as through theNFC device140 or thewireless transceiver134.
• A related non-transitory computer-readable medium example embodiment may have computer-executable instructions for causing the communications device132 to perform steps including disabling the SE.API149 to prevent access to theSE data148 based upon a security condition, and enabling the SE API to again allow access to the SE data based upon a security restore event, as described further above. The non-transitory computer-readable medium may perform additional steps described above as well.
• Example components of a mobilewireless communications device1000 that may be used in accordance with the above-described embodiments are further described below with reference toFIG. 7. Thedevice1000 illustratively includes ahousing1200, a keyboard orkeypad1400 and anoutput device1600. The output device shown is adisplay1600, which may comprise a full graphic LCD. Other types of output devices may alternatively be utilized. Aprocessing device1800 is contained within thehousing1200 and is coupled between thekeypad1400 and thedisplay1600. Theprocessing device1800 controls the operation of thedisplay1600, as well as the overall operation of themobile device1000, in response to actuation of keys on thekeypad1400.
• Thehousing1200 may be elongated vertically, or may take on other sizes and shapes (including clamshell housing structures). The keypad may include a mode selection key, or other hardware or software for switching between text entry and telephony entry.
• In addition to theprocessing device1800, other parts of themobile device1000 are shown schematically inFIG. 7. These include acommunications subsystem1001; a short-range communications subsystem1020; thekeypad1400 and thedisplay1600, along with other input/output devices1060,1080,1100 and1120; as well asmemory devices1160,1180 and variousother device subsystems1201. Themobile device1000 may comprise a two-way RF communications device having data and, optionally, voice communications capabilities. In addition, themobile device1000 may have the capability to communicate with other computer systems via the Internet.
• Operating system software executed by theprocessing device1800 is stored in a persistent store, such as theflash memory1160, but may be stored in other types of memory devices, such as a read only memory (ROM) or similar storage element. In addition, system software, specific device applications, or parts thereof, may be temporarily loaded into a volatile store, such as the random access memory (RAM)1180. Communications signals received by the mobile device may also be stored in theRAM1180.
• Theprocessing device1800, in addition to its operating system functions, enables execution ofsoftware applications1300A-1300N on thedevice1000. A predetermined set of applications that control basic device operations, such as data andvoice communications1300A and1300B, may be installed on thedevice1000 during manufacture. In addition, a personal information manager (PIM) application may be installed during manufacture. The PIM may be capable of organizing and managing data items, such as e-mail, calendar events, voice mails, appointments, and task items. The PIM application may also be capable of sending and receiving data items via awireless network1401. The PIM data items may be seamlessly integrated, synchronized and updated via thewireless network1401 with corresponding data items stored or associated with a host computer system.
• Communication functions, including data and voice communications, are performed through thecommunications subsystem1001, and possibly through the short-range communications subsystem. Thecommunications subsystem1001 includes areceiver1500, atransmitter1520, and one ormore antennas1540 and1560. In addition, thecommunications subsystem1001 also includes a processing module, such as a digital signal processor (DSP)1580, and local oscillators (LOs)1601. The specific design and implementation of thecommunications subsystem1001 is dependent upon the communications network in which themobile device1000 is intended to operate. For example, amobile device1000 may include acommunications subsystem1001 designed to operate with the Mobitex™, Data TAC™ or General Packet Radio Service (GPRS) mobile data communications networks, and also designed to operate with any of a variety of voice communications networks, such as AMPS, TDMA, CDMA, WCDMA, PCS, GSM, EDGE, etc. Other types of data and voice networks, both separate and integrated, may also be utilized with themobile device1000. Themobile device1000 may also be compliant with other communications standards such as 3GSM, 3GPP, UMTS, 4G, etc.
• Network access requirements vary depending upon the type of communication system. For example, in the Mobitex and DataTAC networks, mobile devices are registered on the network using a unique personal identification number or PIN associated with each device. In GPRS networks, however, network access is associated with a subscriber or user of a device. A GPRS device therefore typically involves use of a subscriber identity module, commonly referred to as a SIM card, in order to operate on a GPRS network.
• When required network registration or activation procedures have been completed, themobile device1000 may send and receive communications signals over thecommunication network1401. Signals received from thecommunications network1401 by theantenna1540 are routed to thereceiver1500, which provides for signal amplification, frequency down conversion, filtering, channel selection, etc., and may also provide analog to digital conversion. Analog-to-digital conversion of the received signal allows theDSP1580 to perform more complex communications functions, such as demodulation and decoding. In a similar manner, signals to be transmitted to thenetwork1401 are processed (e.g. modulated and encoded) by theDSP1580 and are then provided to thetransmitter1520 for digital to analog conversion, frequency up conversion, filtering, amplification and transmission to the communication network1401 (or networks) via theantenna1560.
• In addition to processing communications signals, theDSP1580 provides for control of thereceiver1500 and thetransmitter1520. For example, gains applied to communications signals in thereceiver1500 andtransmitter1520 may be adaptively controlled through automatic gain control algorithms implemented in theDSP1580.
• In a data communications mode, a received signal, such as a text message or web page download, is processed by thecommunications subsystem1001 and is input to theprocessing device1800. The received signal is then further processed by theprocessing device1800 for an output to thedisplay1600, or alternatively to some other auxiliary I/O device1060. A device may also be used to compose data items, such as e-mail messages, using thekeypad1400 and/or some other auxiliary I/O device1060, such as a touchpad, a rocker switch, a thumb-wheel, or some other type of input device. The composed data items may then be transmitted over thecommunications network1401 via thecommunications subsystem1001.
• In a voice communications mode, overall operation of the device is substantially similar to the data communications mode, except that received signals are output to aspeaker1100, and signals for transmission are generated by amicrophone1120. Alternative voice or audio I/O subsystems, such as a voice message recording subsystem, may also be implemented on thedevice1000. In addition, thedisplay1600 may also be utilized in voice communications mode, for example to display the identity of a calling party, the duration of a voice call, or other voice call related information.
• The short-range communications subsystem enables communication between themobile device1000 and other proximate systems or devices, which need not necessarily be similar devices. For example, the short-range communications subsystem may include an infrared device and associated circuits and components, a Bluetooth™ communications module to provide for communication with similarly-enabled systems and devices, or a near field communications (NFC) sensor for communicating with a NFC device or NFC tag via NFC communications.
• Many modifications and other embodiments will come to the mind of one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is understood that various modifications and embodiments are intended to be included within the scope of the appended claims.

Claims (24)

1. A communications device comprising:

a near field communication (NFC) device;

at least one memory configured to store secure application data to be communicated via said NFC device and a secure element (SE) application programming interface (API) associated with the secure application data; and

a processor coupled with said NFC device and with said at least one memory, the processor being configured to

disable the SE API to prevent access to the secure application data based upon a security condition, and

enable the SE API to allow access to the secure application data based upon a security restore event.

2. The communications device ofclaim 1 further comprising a wireless transceiver coupled with said processor; and wherein the security condition comprises initiation of a wipe while said wireless transceiver is not in communication with a wireless communications network.

3. The communications device ofclaim 1 further comprising an input device coupled with said processor; and

wherein the security condition comprises a threshold number of unsuccessful device authentication attempts via said input device.

4. The communications device ofclaim 1 further comprising an input device coupled to said processor; and wherein the security condition comprises a security command entered via said input device.

5. The communications device ofclaim 1 further comprising a wireless transceiver coupled with said processor; and wherein the security restore event comprises receiving a secure application data delete command via said wireless transceiver.

6. The communications device ofclaim 1 further comprising an input device coupled with said processor; and wherein the security restore event comprises receiving a security restore command via said input device.

7. The communications device ofclaim 1 wherein said NFC device has an NFC API associated therewith; and wherein said processor is further configured to enable said NFC API for NFC communication while the SE API is disabled.

8. The communications device ofclaim 1 wherein said processor is further configured to disable write access to said memory based upon the occurrence of the security condition.

9. A communications system comprising:

a near field communication (NFC) terminal; and

a communications device configured to communicate with said NFC terminal, the communications device comprising

a NFC device,

at least one memory configured to store secure application data to be communicated via said NFC device to said NFC terminal and a secure element (SE) application programming interface (API) associated with the secure application data, and

a processor coupled with said NFC device and with said at least one memory, the processor being configured to

disable the SE API to prevent access to the secure application data based upon a security condition, and

enable the SE API to allow access to the secure application data based upon a security restore event.

10. The communications system ofclaim 9 wherein said communications device further comprises a wireless transceiver coupled with said processor; and wherein the security condition comprises initiation of a wipe while said wireless transceiver is not in communication with a wireless communications network.

11. The communications system ofclaim 9 wherein said communications device further comprises an input device coupled with said processor; and wherein the security condition comprises a threshold number of unsuccessful device authentication attempts via said input device.

12. The communications system ofclaim 9 wherein said communications device further comprises an input device coupled to said processor; and wherein the security condition comprises a security command entered via said input device.

13. The communications system ofclaim 9 wherein said communications device further comprises a wireless transceiver coupled with said processor; and wherein the security restore event comprises receiving a secure application data delete command via said wireless transceiver.

14. The communications system ofclaim 9 wherein said communications device further comprises an input device coupled with said processor; and wherein the security restore event comprises receiving a security restore command via said input device.

15. A method for operating a communications device comprising a near field communication (NFC) device and at least one memory configured to store secure application data to be communicated via the NFC device and a secure element (SE) application programming interface (API) associated with the secure application data, the method comprising:

disabling the SE API to prevent access to the secure application data based upon a security condition; and

enabling the SE API to allow access to the secure application data based upon a security restore event.

16. The method ofclaim 15 wherein the communications device further comprises a wireless transceiver coupled with the processor; and wherein the security condition comprises initiation of a wipe while the wireless transceiver is not in communication with a wireless communications network.

17. The method ofclaim 15 wherein the communications device further comprises an input device; and wherein the security condition comprises a threshold number of unsuccessful device authentication attempts via the input device.

18. The method ofclaim 15 wherein the communications device further comprises an input device; and wherein the security condition comprises a security command entered via the input device.

19. The method ofclaim 15 wherein the communications device further comprises a wireless transceiver coupled with the processor; and wherein the security restore event comprises receiving a secure application data delete command via the wireless transceiver.

20. A non-transitory computer-readable medium for a communications device comprising a near field communication (NFC) device and at least one memory configured to store secure application data to be communicated via the NFC device and a secure element (SE) application programming interface (API) associated with the secure application data, the non-transitory computer-readable medium having computer-executable instructions for causing the communications device to perform steps comprising:

disabling the SE API to prevent access to the secure application data based upon a security condition; and

enabling the SE API to allow access to the secure application data based upon a security restore event.

21. The non-transitory computer-readable medium ofclaim 20 wherein the communications device further comprises a wireless transceiver; and wherein the security condition comprises initiation of a wipe while the wireless transceiver is not in communication with a wireless communications network.

22. The non-transitory computer-readable medium ofclaim 20 wherein the communications device further comprises an input device; and wherein the security condition comprises a threshold number of unsuccessful device authentication attempts via the input device.

23. The non-transitory computer-readable medium ofclaim 20 wherein the communications device further comprises an input device; and wherein the security condition comprises a security command entered via the input device.

24. The non-transitory computer-readable medium ofclaim 20 wherein the communications device further comprises a wireless transceiver; and wherein the security restore event comprises receiving a secure application data delete command via the wireless transceiver.

Images