Detailed Description
The present description has been made with reference to example embodiments. 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.
Generally, provided herein is a mobile communication device, which may include: a Near Field Communication (NFC) device, an input device configured to generate a memory scrub command, a memory, and a memory controller coupled to the NFC device, the input device, and the memory. The memory controller is capable of receiving secure data from a provisioning server to the memory, receiving erase instruction data from the provisioning server to the memory for erasing the secure data from the memory, and erasing the secure data from the memory based on the memory erase command and the received erase instruction data.
In this way, the memory controller may advantageously be able to erase the secure data from the memory without an over-the-air (OTA) connection to the provisioning server. As an example, the memory may include a secure element, and the memory controller may include a secure element controller. Further, the provisioning server may include, for example, a Trusted Service Manager (TSM) server. Example mobile communication devices (also referred to herein as "mobile devices") may include portable or personal media players (e.g., music or MP3 players, video players, etc.), portable gaming devices, portable or mobile phones, smart phones, portable computers (e.g., tablet computers), digital cameras, and so forth. Also by way of example, the memory may include: SIM cards, euiccs, or removable memory, SD cards, embedded memory, and the like.
A related communication method may be for a mobile wireless communication device, such as the one briefly described above. The method may include: the method includes receiving secure data from a provisioning server to a memory, receiving erasure instruction data from the provisioning server to the memory for erasing the secure data from the memory, and erasing the secure data from the memory based on the memory erasure command and the received erasure instruction data.
A related non-transitory computer readable medium may be for a mobile communication device, such as the one briefly described above. The medium may have computer-executable instructions that cause the mobile communication device to perform steps comprising: the method includes receiving secure data from a provisioning server to a memory, receiving erasure instruction data from the provisioning server to the memory for erasing the secure data from the memory, and erasing the secure data from the memory based on the memory erasure command and the received erasure instruction data.
By way of background, NFC is a short-range wireless communication technology in which an NFC-enabled device is "waved," "bumped," or otherwise moved in proximity for communication. In one non-limiting example implementation, NFC may operate at 13.56MHz with an effective range of a few centimeters (typically up to about 4cm or up to about 10cm depending on a given implementation), although other suitable versions of near field communication, e.g., with different operating frequencies, effective ranges, etc., may also be used.
Referring initially to fig. 1 and 3, communication system 29 and related method aspects are first described. NFC enabled devices may be preconfigured to initiate NFC transactions, such as payment or secure transactions. This is sometimes referred to as a mobile or electronic wallet (e-wallet) configuration, allowing the mobile communication device 30 (also referred to herein as a "mobile device") to be used similar to a credit card or security card typically carried in a wallet. This may be accomplished, for example, by provisioning the Secure Element (SE)32 on the memory 33 of the mobile device 30 via a provisioning server 34 (which may be provided by a Trusted Service Manager (TSM)) using secure data including one or more secure applets 41 (steps 50-51). The memory 33 may include, for example: a Subscriber Identity Module (SIM) card, a removable memory (e.g., a Secure Digital (SD) card), a designated or embedded memory associated with NFC circuitry (e.g., within an NFC chipset), an embedded uicc (euicc), and so forth.
An example mobile device 30 may include: portable or personal media players (e.g., music or MP3 players, video players, etc.), portable gaming devices, portable or mobile phones, smart phones, portable computers (e.g., tablet computers), digital cameras, and so forth. The mobile device 30 also illustratively includes a memory controller 35, such as an NFC security unit controller, coupled to the memory 33. Further, an NFC device 36 (e.g., an NFC transceiver) and a processor 37 are also coupled to the memory controller 35. More specifically, the processor 37, and the memory controller 35 may communicate via a designated communication channel, such as a JSR-177 channel, although other suitable communication channels may be used in various embodiments.
The mobile device 30 also illustratively includes a wireless device 38, such as a cellular or Wireless Local Area Network (WLAN) transceiver, coupled to the processor 37 for establishing an over-the-air (OTA) connection with the provisioning server 34 via a wireless network 39, such as a cellular or WLAN network. One or more input devices 43 (e.g., a keypad, touch screen, trackball, trackpad, buttons, etc.) are also coupled to processor 37, which can be used to provide a memory erase command that causes secure element 32 to be erased as will be discussed further below. The processor 37 or memory controller 35 may be implemented using, for example, a combination of hardware (e.g., microprocessors, memory, etc.) and software (e.g., a non-transitory computer-readable medium having computer-executable instructions) to perform various operations or functions described herein.
Generally, the specific content of the secure element 32 can only be modified by the provisioning server 34 (i.e., the TSM) because the TSM holds the secure element's issuer key. Both the secure element 32 and the TSM know these issuer keys. Commands issued by the TSM to the secure element 32 are signed using its knowledge of these keys and verified by the secure element before accepting them. The security domain established by these keys is also referred to as an Issuer Security Domain (ISD). These commands may relate to the installation or deletion of content and applications or applets on the secure element 32 (e.g., payment account applets, secure or physical access applets, traffic access applets (e.g., subway cards, etc.)). Any given set of commands issued during a single session is conducted in a "secure channel" that is a mutually authenticated communication session.
However, this can be problematic if the mobile device 30 needs to be erased (and the contents of the security element 32 similarly erased or cleared) when the mobile device does not have an over-the-air (OTA) connection to the provisioning server 34. This may occur in various situations, such as: in facilities where mobile devices are repaired and refurbished for future purchase; a customer that removes the SIM card before attempting to erase the mobile device, and so on.
According to an example embodiment, the provisioning server 34 may send to the mobile device 30 at step 52 erasure instruction data or erasure scripts, which may include a pre-computed command set or Application Protocol Data Unit (APDU), that may be used to erase the security unit 32 without an OTA connection. Example embodiments will now be described with reference to a global platform (GlobalPlatform) secure channel implementation, and APDUs transmitted between devices and TSMs conform to ISO7816-4, although other suitable protocols and implementations may be used in different embodiments. According to this example, the mobile device 30 and provisioning server 34 have means for communicating, such as a proxy application running on the mobile device 30 that sends and receives command OTA to and from the provisioning server and relays the command OTA to the security element 32 via the memory controller 35.
When a secure channel is established and communicated over, the Issuer Security Domain (ISD) key and sequence counter are used as inputs to the session _ mac, session _ enc, and session _ kek (signature, encryption, and further encryption) keys that generate the particular secure channel. For example,
session key as a function (issuer Security Domain Key, sequence counter)
The session key is then used to sign and encrypt the APDUs of the secure channel. The sequence counter is provided by the security element 32 and is incremented each time the security element is accessed. A challenge/response mechanism may occur at the beginning of secure channel setup to prove that both parties are able to compute the correct session key given the sequence counter. At the end of each secure channel session, the sequence counter is incremented by the security unit 32 so that the session keys and APDUs from the previous secure channel are not reused. Further information relating to the implementation of the global platform secure channel is provided in the global platform card specification v2.1.1 and the global platform card specification v 2.2. Section e.1.2.1 of the global platform card specification v2.1.1 is summarized below:
e.1.2.1 explicit secure channel initiation
The secure channel may be explicitly initiated by the card-leaving entity using initialization UPDATE (initialization UPDATE) and EXTERNAL authentication (EXTERNAL authentication) commands. The application may use an appropriate API to pass APDUs to the security domain, such as the process security () method of the global platform Java card. The explicit secure channel initiation allows the off-card entity to indicate to the card (see appendix e.5.2-external authentication command) what security level (integrity and/or confidentiality) is required for the current secure channel and apply this security level to all subsequent messages exchanged between the card and the off-card entity until the end of the session. It also provides the off-card entity with the possibility to choose the key version number to be used (see appendix e.5.1-initial update command).
Note that: explicit secure channel session initiation also allows the card to inform the off-card entity what secure channel protocol is supported using the returned secure channel protocol identifier. The secure channel is always initiated by the off-card entity by passing the "host" challenge (random data unique to the session) to the card (see appendix e.5.1-initial update command). When the challenge is received, the card generates its own "card" challenge (random data that is also unique to the session). The card creates a new secret session key using its internal sequence counter and static keys, and generates a first encrypted value (card cryptogram) using one of its newly created session keys (see appendix e.4.1-DES session key). The card ciphertext is sent back to the card-leaving entity along with the sequence counter, card challenge, secure channel protocol identifier, and other data. Since the off-card entity should now have all the same information as the card used to generate the cryptogram, it should be able to generate the same session key and the same cryptogram and by performing the comparison, be able to authenticate the card. A similar process is now used by the off-card entity to create a second encrypted value (host cryptogram) to be passed back to the card (see appendix e.5.2-external authentication command). Since the card has all the same information that the host uses to generate the host cryptogram, it should be able to generate the same cryptogram and by performing the comparison, be able to authenticate the off-card entity. The off-card entity also creates a MAC to be passed back to and verified by the card. The authenticated MAC is used by the card to create an initial chain vector to authenticate subsequent C-MACs and/or RMACs. Upon successful authentication of the off-card entity, the card increments its internal secure channel sequence counter.
Thus, assume that the sequence counter value is X. Before provisioning server 34 begins any secure channel with mobile device 30, it may send an erase script (which may be integrity checked in some embodiments) to the mobile device. The erase script may be configured to expect the sequence counter to have a value of X +1 and it may include all the necessary APDUs for erasing or deleting some or all of the contents of the secure element 32. That is, the erase script may include an initialization update command, an external authentication command, and a delete command for each application (or a subset of applications) installed on the secure element 32.
In some example embodiments, the device agent may save the script in persistent memory 40 accessible by the processor 37. Once saved, the proxy may then send an APDU to the security unit 32 requested by the provisioning server 34. The device agent may also scan the APDUs being sent to the security unit 32 and as soon as the agent finds a successful response to the external authentication (meaning that a secure channel has been established between the provisioning server 34 and the mobile device 30 and the sequence counter will have a value of X +1 for the next secure channel attempt), the device agent may discard the previous erase script and set the erase script it just received to the latest one.
Accordingly, the above-described scheme may advantageously allow some or all of the contents of the secure element 32 to be deleted by having the provisioning server 34 pre-calculate or pre-determine the appropriate erase scripts for the secure element and store them on the memory 37. Upon receiving the memory scrub command via the input device 43, the processor 37 may thus prompt the memory controller 35 at steps 53-54 to scrub some or all of the contents of the security element 32 without establishing an OTA connection with the provisioning server 34, which ends the method shown in fig. 3 (step 55). As an example, it may be desirable to erase all applets 41 and related data (e.g., identification numbers, account numbers, encrypted data, etc.) from the secure element 32 during an erase operation, while leaving basic secure element operation applets, such as an applet that controls the secure element erase operation, or a routing applet that controls communications with the secure element. However, in some embodiments, the secure applet 41 may be selectively erased, or the entire secure element 32 may be erased, if desired.
By having the TSM send a new erase script before initiating the secure channel, mobile device 30 may have a valid erase script to execute or process (play) for the next sequence counter value. In some embodiments, the mobile device 30 may discard an older erase script after it finds a successful external authentication command (meaning that the older erase script may no longer be processed and only the new erase script may be processed). When it is determined that it is time to erase the secure element, only the erase script needs to be processed. The process of erasing the script may be initiated via the input device 43, for example, through an on-screen menu option.
In the example of fig. 4 and 5, the mobile device 30 illustratively includes a touch screen display 45 that also serves as an input device, although other display and input device configurations may be used in different embodiments. Upon selection of a menu option for erasing data from the mobile wallet application running on the mobile device 32, which serves as a graphical user interface for accessing the secure applet stored in the secure element 32, a confirmation prompt is provided on the display 45 (fig. 4). The confirmation prompt asks for confirmation of the erase operation (by pressing "OK") at which point the processor may proceed to the step of executing the process erase script described above and clearing or erasing secure element 32. Once the erase operation is complete, a confirmation prompt may be provided on display 45 to confirm that the secure data has been cleared or erased from secure element 32 as requested. However, it should be noted that: in some embodiments, secure element 32 and memory 40 may be erased together as part of the same overall device erase operation.
Referring also to fig. 2, according to another example embodiment, it may be advantageous in some cases to instead store one or more erase scripts 42 ' in the secure element 32 ' relative to the memory 40 '. This may help to ensure that: as long as there is content in the secure element 32 ', the erase script 42 ' remains intact regardless of what happens to the memory 40 '. For example, if the mobile device 30 'is transferred to another user, the memory 40' may be erased, for example, or the memory 40 'may be replaced when the mobile device 30' is repaired. In this case, the erase script 42 'will no longer be available to erase the secure element 32', meaning that the secure element cannot be erased without an OTA connection to the provisioning server (at which point it may not be available).
As described above, erasure of the secure element 32 'may be included as part of an overall device erasure operation (e.g., when a user purchases or transfers the mobile device 30' to another user). That is, selection of a device erase operation by the user (e.g., via an on-screen menu selection) may advantageously make the erasure of secure or personal data of the secure element 32 'and memory 40' part of the same operation, although these erase operations may be performed separately.
Another potential advantage of storing erase script 42 'in secure element 32' is that: this may help to ensure that only the authorized owner of the security element (i.e., the appropriate TSM) is able to provide the mobile device 30' with a new erase script. For example, if a malicious attacker is able to provide a fake erase script to the memory 40 ', the attack may cause the secure element 32 ' erase operation to fail and thereby cause the secure data to be "left" on the secure element 32 ' even if the memory 40 has been erased.
Another consideration is: in some cases, it may be desirable to store or maintain more than one erase script at a time. More specifically, it may be desirable to store (on secure element 32 'or memory 40') multiple erase scripts at a given time, since it is not always possible to predict what the ISD sequence counter value will be when the secure element needs to be erased. As described above, when a given transaction is completed using the security element 32', the ISD sequence counter value is incremented (e.g., from X to X + 1). However, error conditions may occur, such as when the OTA secure channel to the provisioning server 34' is lost due to poor signal strength, interference, network error, power down, and the like. In this case, a new erase script (corresponding to count value X +1) may be downloaded to the secure element 32, but the session or transaction is not completed and thus the sequence count is not successfully increased to X + 1. In this case, if only the most recent erase script (i.e., the X +1 erase script) is stored, when the secure element 42 is requested to erase, the current ISD count will be X, which will not correspond to the value associated with the X +1 erase script, and thus the erase operation may fail.
Thus, to account for such error conditions, when the provisioning server 34 ' is to open a secure channel with the mobile device 30 ' based on the sequence counter value X, it may first ensure that the mobile device 30 ' has an erase script that is valid for the respective different sequence count values, as in this example for sequence counter values X and X + 1. This may advantageously provide the following consistent and reliable solution: ensure that valid erase scripts are always stored, and determine which erase script is the appropriate erase script at a given time. That is, the memory controller 35' may be configured to: a given erase script 41' of the plurality of stored erase scripts is executed based on the current sequence count values and corresponding sequence count values associated with the plurality of erase scripts.
In some embodiments, the erase script 42 'may be stored as part of a special applet on the secure element 42'. The applet may advantageously be placed in its own security domain or partition and may be configured such that it accepts applets only over a secure channel, helping to ensure that only the TSM owning the secure element 32' is able to configure the erase script for that TSM. When the mobile device 30 'needs to erase the secure element 32' (e.g., receive an erase command via the input device 43 '), the processor 37' may communicate with a special applet (outside the secure channel and without an OTA connection) to retrieve the appropriate erase script so that the APDU located in the erase script may be run.
Furthermore, a special applet on the secure element 32' may advantageously be configured to store multiple erase scripts simultaneously. Thus, when the provisioning server stores the erase script 42 'in the secure element 32', the erase script is associated with the sequence counter for which it is valid. When the mobile device 30 'needs to erase the secure element 32', the processor 37 'may send an initialization update command to the memory controller 35' prior to communicating with a particular applet, in response to which the memory controller 35 'provides the current sequence counter value from the secure element 32'. Then, when the processor 37' requests an erase script from a particular applet, it includes the current sequence counter provided in response to the initialize update command as a parameter into the erase script request. In this way, the special applet may return or provide an erase script corresponding to the current sequence counter value identified by the initialize update command.
Incorporating the erase script 42' in a special applet on the secure element may provide certain advantages. For example, management of erase scripts may be more easily delegated to the corresponding TSM owning or controlling the secure element 32'. That is, existing authentication mechanisms already used at the security element level may be used to perform these functions, rather than having to include additional authentication mechanisms, for example, in the operating system of the mobile device 30'. This may also advantageously help facilitate the above-described operations being implemented on different mobile device platforms (e.g., different types of mobile devices or mobile devices from different manufacturers). As described above, this may also make it easier to ensure that the erase script 42 ' remains intact in the event that the rest of the mobile device (i.e., the memory 40 ') is erased prior to erasing the secure element 32 '.
It should be noted that: in some embodiments, the mobile device 30 ' may include more than one security unit 32 ' and may communicate with more than one provisioning server 34 '. In the case of multiple secure elements 32 ', each secure element may store or receive its own respective erase script 42' and associated erase script applet. In this way, the contents of different security elements may be erased separately or together (e.g., as part of an overall device erase). Also as described above, the respective contents of each secure element 32' may be erased, in whole or in part, depending on a given implementation.
It should also be noted that: although the above examples for erasing secure memory relate to a secure element on an NFC enabled device, the above techniques may also be applicable to data management for other secure memory applications. That is, the use of, for example, an erase script may be applied to other secure storage applications to allow data modification or deletion without a data connection to a security provider that would otherwise be required to perform a data modification or deletion operation.
Example components of a mobile communication device 1000 that may be used in accordance with the above-described embodiments are further described below with reference to fig. 6. The apparatus 1000 illustratively includes: a housing 1200, a keyboard or keypad 1400, and an output device 1600. The output device shown is a display 1600, which may include a full graphic LCD. Other types of output devices may alternatively be employed. A processing device 1800 is contained within the housing 1200 and the processing device 1800 is coupled between the keypad 1400 and the display 1600. In response to actuation of the keys on the keypad 1400, the processing device 1800 controls the operation of the display 1600, as well as the overall operation of the mobile device 1000.
The housing 1200 may be elongated vertically, or may take on other sizes and shapes (including clamshell housing structures). The keypad may include mode selection keys, or other hardware or software for switching between text entry and telephony entry.
In addition to the processing device 1800, other portions of the mobile device 1000 are schematically illustrated in FIG. 6. These parts include: a communications subsystem 1001, a short-range communications subsystem 1020, a keypad 1400 and a display 1600, as well as other input/output devices 1060, 1080, 1100 and 1120, and memory devices 1160, 1180 and various other device subsystems 1201. The mobile device 1000 may include a two-way RF communications device having data and, optionally, voice communications capabilities. In addition, the mobile device 1000 may have the capability to communicate with other computer systems via the Internet.
Operating system software executed by the processing device 1800 is stored in a persistent store, such as the flash memory 1160, 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. Communication signals received by the mobile device may also be stored in the RAM 1180.
The processing device 1800, in addition to its operating system functions, enables execution of software applications 1300A-1300N on the device 1000. A predetermined set of applications that control basic device operations, such as data and voice communications 1300A and 1300B, may be installed on the device 1000 during manufacture. In addition, a Personal Information Manager (PIM) application may be installed during manufacture. The PIM is capable of organizing and managing data items, such as e-mail, calendar events, voice mails, appointments, and task items. The PIM application is also capable of sending and receiving data items via the wireless network 1401. The PIM data items may be seamlessly integrated, synchronized and updated via the wireless network 1401 with the corresponding data items stored or associated with a host computer system.
Communication functions, including data and voice communications, are performed through the communications subsystem 1001, and possibly through the short-range communications subsystem. The communications subsystem 1001 includes: a receiver 1500, a transmitter 1520, and one or more antennas 1540 and 1560. In addition, the communications subsystem 1001 includes a processing module, such as a Digital Signal Processor (DSP)1580 and a Local Oscillator (LO) 1601. The specific design and implementation of the communications subsystem 1001 is dependent upon the communications network in which the mobile device 1000 is intended to operate. For example, the mobile device 1000 may include a communications subsystem 1001, the communications subsystem 1001 being designed to operate with a MobiteXTM, Data tac, or General Packet Radio Service (GPRS) mobile Data communications network, and also being designed to operate with various voice communications networks, such as AMPS, TDMA, CDMA, WCDMA, PCS, GSM, EDGE, and the like. Other types of data and voice networks, both separate and integrated, may also be utilized with the mobile device 1000. The mobile device 1000 may also conform to other communication standards such as 3GSM, 3GPP, UMTS, 4G, and the like.
Network access requirements vary depending on 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. Thus, in order to operate on a GPRS network, GPRS devices typically involve the use of a subscriber identity module (commonly referred to as a SIM card).
When required network registration or activation procedures have been completed, the mobile device 1000 may send and receive communication signals over the communication network 1401. Signals received from the communications network 1401 by the antenna 1540 are routed to the receiver 1500, the receiver 1500 provides signal amplification, frequency down conversion, filtering, channel selection, and so forth, and the receiver 1500 may also provide analog-to-digital conversion. Analog-to-digital conversion of the received signal allows the DSP 1580 to perform more complex communications functions, such as demodulation and decoding. In a similar manner, signals to be transmitted to the network 1401 are processed (e.g. modulated and encoded) by the DSP 1580 and are then provided to the transmitter 1520 for digital to analog conversion, frequency up conversion, filtering, amplification and transmission to the communication network 1401 (or networks) via the antenna 1560.
In addition to processing communications signals, the DSP 1580 provides for control of the receiver 1500 and the transmitter 1520. For example, gains applied to communications signals in the receiver 1500 and transmitter 1520 may be adaptively controlled through automatic gain control algorithms implemented in the DSP 1580.
In a data communication mode, a received signal, such as a text message or web page download, is processed by the communications subsystem 1001 and is input to the processing device 1800. The received signal is then further processed by the processing device 1800 for an output to the display 1600, or alternatively to some other auxiliary I/O device 1060. The device may also be used to compose data items, such as e-mail messages, using the keypad 1400 and/or some other auxiliary I/O device 1060, such as a touchpad, a rocker switch, a thumbwheel, or some other type of input device. The composed data items may then be transmitted over the communications network 1401 via the communications subsystem 1001.
In a voice communication mode, overall operation of the device is substantially similar to the data communication mode, except that received signals are output to a speaker 1100, and signals for transmission are generated by a microphone 1120. Alternative voice or audio I/O subsystems, such as a voice message recording subsystem, may also be implemented on the device 1000. The display 1600 may also be used in voice communication mode, for example, to display the identity of a calling party, the length of a voice call, or other voice call related information.
The short-range communications subsystem enables communication between the mobile device 1000 and other neighboring systems or devices, which are not necessarily similar devices. For example, the short-range communications subsystem may include an infrared device and associated circuits and components, Bluetooth for providing communications with systems and devices supporting similar componentsTMA communication module, or a Near Field Communication (NFC) device (which may include an associated security element) for communicating with another NFC device or NFC tag via NFC communication.
Many modifications and other embodiments will come to mind to one skilled in the art to which this invention pertains having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that various modifications and embodiments are intended to be included within the scope of the appended claims.