Establishing connections for secure element communications

A server is configured to establish connections for secure element communication sessions. The server receives a request from a device to establish a first secure connection, and establishes the first secure connection with the device in response to the received request. The server sends a request to a Trusted Service Manager (TSM). The sent request instructs the TSM to establish a second secure connection between the TSM and a secure memory. The server receives an authentication request from the TSM to establish the second secure connection, and forwards the authentication request to the device over the first secure connection.

BACKGROUND

The use of devices to make secure and convenient transactions is expected to grow and present new opportunities to users and providers of services and applications. Providing trusted channels for transactions relies upon the collaboration between a variety of parties, including Mobile Network Operators (MNOs), financial institutions, service providers, and end users. Because the number of parties in the mobile transaction ecosystem can be large, a secure network entity called a Trusted Service Manager (TSM) can facilitate interactions between the various parties, and specifically act as a trusted element for provisioning and personalization of information on a secure memory. For example, a TSM can remotely initialize a secure memory, for example, a so called Secure Element (SE), which is one type of a protected integrated storage and execution platform installed within the device, so the user may, for example, safely transact with the appropriate parties for goods and services. This initialization can include provisioning the SE with secure applications and/or cryptographic data. Conventional provisioning approaches may use the Simple Message Service (SMS) as a primary push mechanism to establish communication sessions between the TSM and the SE. However, SMS messaging may be inconsistent and unreliable, and can introduce significant latencies in message delivery.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Embodiments described herein facilitate the establishment of secure communications for performing mobile transactions. These mobile transactions, which may be conveniently initiated through a device, can include trusted exchanges between one or more service providers and a user of the device. The trusted exchanges can include transactions for any type of good and/or service, which may involve retail stores, banks, credit card companies, loyalty/rewards programs, entertainment providers, restaurants, and/or public and private travel services. The trusted exchanges may also be used in environments employing physical security measures, therefore allowing users with the properly provisioned devices access to secure areas in office buildings, homes, laboratories, vehicles, etc. In order to promote ease of use, the device may employ Near Field Communications (NFC) functionality to wirelessly communicate with an NFC reader. Alternatively, other embodiments may use other types of Personal Area Networks, such as, for example, Bluetooth® Low Energy, to easily exchange data for transactions.

In order to initialize a device for performing trusted exchanges with service providers, the device may be provided with security information by a Trusted Service Manager (TSM). Because the security information is sensitive, it should be provided over a secure connection from the TSM to a secure memory, such as, for example, a Secure Element (SE). The SE, as will be discussed below, is a trusted component typically housed within the device. To maintain security, the secure connection between the SE and TSM is established by the SE upon receiving an “authentication request” (also referred to herein a “wakeup trigger”). The mechanisms for providing the authentication requests may be based upon client initiated actions (referred to herein as “client triggered”) or predicated upon actions initiated by a server (referred to herein as “server triggered”). For embodiments described below, the authentication request may be provided by a different secure connection previously established between the device and another network entity. Thus, the previously established secure connection, which can use protocols having low latency and high reliability, is used as a primary connection for authentication requests instead of the conventional approach of sending the authentication request via SMS messaging. However, is some embodiments, conventional SMS messaging may be used as a secondary approach (e.g., as a backup) for sending authentication requests if the previously established secure connection is unavailable.

FIG. 1is a block diagram showing an exemplary environment100for establishing secure connections between entities engaging in a mobile transactions. The environment may include a device110, an Application Server (AS)140, and a Trusted Service Manager (TSM)150(which may further include one or more Mobile Network Operator (MNO) TSM150_1, and one or more Service Provider (SP) TSM150_2). Device110, AS140and TSM150may be interconnected by a plurality of networks130to provide communications over a variety of different connections, which include secure connections for facilitating trusted exchanges. For ease of explanation, only one device110, AS140, and TSM150, MNO TSM150_1, and SP TSM150_2are illustrated as being connected to networks130. However, it should be understood that a plurality of devices110, ASs140, and/or TSMs150, or other known network entities, may be communicatively coupled to networks130.

Networks130may include a plurality of networks of any type, and may be broadly grouped into one or more access network(s)130_1and one or more back end network(s)130_2. Access network(s)130_1provides connectivity between device110and other network elements within access network(s)130_1and/or back end network(s)130_2. Access network(s)130_1may include, for example, a telecommunications network (e.g., a Public Switched Telephone Network (PSTN)), wired (e.g., Ethernet) and/or wireless local area network(s) (LAN) (e.g., WiFi), wireless wide area networks (WAN) (e.g., WiMax), and/or one or more wireless public land mobile networks (PLMNs). The PLMN(s) may include a Code Division Multiple Access (CDMA) 2000 PLMN, a Global System for Mobile Communications (GSM) PLMN, a Long Term Evolution (LTE) PLMN and/or other types of PLMNs not specifically described herein. Back end network(s)130_2may exchange data with access network(s)130_1to provide device110connectivity to various servers, gateways, and other network entities, which may include one or more Application Server(s)140and one or more trusted service manager(s)150. Back end network(s)130_2may include a wide area network (WAN), a metropolitan area network (MAN), an intranet, the Internet, a wireless satellite network, a cable network (e.g., an optical cable network).

Device110may include any type of electronic device having communication capabilities, and thus communicate over networks130using a variety of different channels, including both wired and wireless connections. Device110may include, for example, a cellular radiotelephone, a smart phone, a tablet, a set-top box (STB), a mobile phone, a Voice over Internet Protocol (VoIP) device, a laptop computer, a palmtop computer, a gaming device, a media player device, or a digital camera that includes communication capabilities (e.g., wireless communication mechanisms).

Device110may further include one or more client applications115, an application framework117, and a secure memory118. Secure memory118can provides a trusted and compartmentalized storage and execution environment, and securely stores cryptographic data as well as programs from various service providers. In some implementations, secure memory118may include a secure element (SE)119, a Trusted Execution Environment (TEE), or other devices capable of providing secure storage and/or program execution. In embodiments presented below, a SE119is shown, however any type of secure memory may also be used.

Client application115may execute on the device110, and provide a user interface for interacting with a particular service provider. For example, client application115may be a “wallet client” associated with credit cards and/or debit card applications. Client application115may use application framework117to access various resources provided by device110. For example, through application framework117, client application115may communicate with other entities, both within device110, and with external network entities over one or more network in networks130. For example, through application framework117, client application110may communicate with application server140over a secure device-AS connection160supported by access network(s)130_1. Application framework117may also be used as an interface between client application115and SE119, which in this embodiment is an internal component residing in device110.

SE119is a tamper resistant platform which may be embodied in a single chip secure microcontroller. SE119is capable of securely storing applications (hereinafter referred to as “secure applications”) and cryptographic data (such as, for example, secure keys). The secure information stored in SE119may be managed in accordance with rules and security requirements provided by established trusted authorities. SE119may communicate with TSM150using access networks130_1over a secure SE-TSM connection170which supports Bearer Independent Protocol (BIP) sessions. BIP sessions permit the SE and TSM to communicate independently of the physical transportation layers which support secure SE-TSM connections170. BIP is a mechanism by which device110provides the SE119access to the data bearers supported by the device, which include bearers associated with local area networks (e.g., Bluetooth®, IrDA, etc.) and/or wide area networks (e.g., GPRS, 3G, HS×PA, HSPA+, LTE, etc.). Specifically, BIP is designed to make use of any IP based connection that device110is capable of establishing. Once a BIP session is established, Global Platform (GP) commands/payloads may be securely exchanged between SE119and TSM150. It is noted that access network(s)130_1can be one type of network, or a plurality of networks using different protocols, air channels, etc. which may be used independently and can be different for secure device-AS connection160and secure SE-TSM connection170. For example, secure device-AS connection160may be established over a WiFi connection, where secure SE-TSM connection170may be established over a cellular (e.g., LTE) connection.

TSM150may be a server having functions which include accessing and managing SE119for provisioning operations, which can include operations of maintenance, personalization, instantiation, etc. Security is maintained since SE119only accepts secure applications/data from authorized TSMs150. Accordingly, TSM150may be thought of as a trusted intermediary designed to assist service providers and securely distribute and manage secure applications and cryptographic data for their customers using the Mobile Network Operators (MNO) networks. TSM150does not necessarily participate in the actual transactions between device110and a service provider, as these transactions are processed by systems previously established by the service provider and its merchant partners. Instead, TSM150may act as a neutral entity that enables service providers to distribute and manage their secure applications remotely by allowing access to the secure storage and processing resources within SE119. In summary, the functions of TSM150may include: issuing and managing a trusted execution environment in the SE; assigning trusted areas within a trusted execution environment to a specific service; managing keys for a trusted execution environment; safely downloading secure applications into the SE; personalizing applications; and locking, unlocking, and deleting secure applications according to the request of a user or a service provider. While only one TSM150is shown inFIG. 1, environment100may have a number of different TSMs operated by different organizations. For example, the MNO may have its own TSM within its network (hereinafter referred to as an “MNO TSM”), which may manage SE lifecycles and security domains for service providers. Additionally, service providers may also have their own TSMs (hereinafter referred to “SP TSMs”) which may manage the provisioning and lifecycles of the service provider's secure application and cryptographic key data.

AS140may be a server that manages applications which may reside on the device110. AS140may communicate with device110over access network(s)130_1using secure device-AS connection160. Additionally, AS140may communicate with TSM150over back end network130_2using a secure AS-TSM connection180. While only one Application Server (AS140) is shown inFIG. 1, in various embodiments, multiple application servers may be associated with different entities and used within environment100. For example, an application server may be associated with the MNO (hereinafter referred to as an “MNO AS”). An MNO AS may provide client applications115to device110, which reside within the memory and execute on the processor of device110. For example, an MNO AS may provide a “wallet application” which may be used as an electronic wallet to provide a user interface to manage various services associated with digital equivalent of credit cards, debit cards, loyalty cards, etc. Additionally, service providers may also be associated with their own application servers, which may be referred to herein as an “SP AS.” An SP AS may serve as a repository for secure applications which may run on SE119. The secure applications may be provided by an SP AS to an SP TSM, over secure AS-TSM connection180, for subsequent provisioning onto SE119by SP TSM over secure SE-TSM connection170. Note that the SP AS cannot provision the secure application to SE119, as only an authorized TSM may perform this function.

Further referring toFIG. 1, the following embodiment provides a mechanism to establish a secure SE-TSM connection170over access network(s)130_1, which may be triggered by the user through client application115, or triggered by a remote server such as a TSM150. This embodiment maintains the desired security of the contents of SE119, and is motivated by the permitted interactions between SE119, AS140, and TSM150. The permissible interactions are as follows:

1) The SE only performs operations provided by an authorized TSM.

2) Client application115provides the user with a service typically by requesting SE119to perform a secure service involving sensitive information (e.g., make a payment). Client application115can use SE119to perform some limited operations related to content change which involve non-sensitive data. However, client application115may not perform any functional change or personalization of sensitive data (e.g., account numbers). Changing a secure application and/or sensitive data may only be performed by TSM150via secure SE-TSM connection170interactions.

Given the context of the permissible interactions provided above, the following approach may be used to establish a secure SE-TSM connection170. Client application115may establish a secure Device-AS connection160with AS140through application framework117. This may be done by requesting a service utilizing secure information (e.g., add a credit card). AS140may then request TSM150to generate an authentication request for establishing a secure connection with SE119. TSM may forward the authentication request back to AS140over secure AS-TSM connection180. AS140may forward the authentication request, over the established secure Device-AS connection160, to application framework117. Note that it is this previously established secure connection, rather than a conventional SMS messaging connection, which may be used as the primary connection to provide an authentication request to device110. In alternative embodiments, SMS messaging may be used as backup connection if other connections for forwarding the authentication request are unavailable. Application framework117then forwards the authentication request to SE119. The SE119may then establish secure SE-TSM connection170with TSM150.

Accordingly, the authentication request may be sent over a secure connection (secure Device-AS connection160) which has already been established, thus leveraging an existing connection which does not have the latency or reliability issues associated with the conventional approach of using an SMS wakeup trigger as described above.

FIG. 2is a block diagram depicting exemplary components of Application Server (AS)140. AS140may include a bus210, a processor220, a memory230, mass storage240, an input device250, an output device260, and a communication interface270.

Bus210includes a path that permits communication among the components of server140. Processor220may include any type of single-core processor, multi-core processor, microprocessor, latch-based processor, and/or processing logic (or families of processors, microprocessors, and/or processing logics) that interprets and executes instructions. In other embodiments, processor220may include an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and/or another type of integrated circuit or processing logic. For example, the processor220may be an x86 based CPU, and may use any operating system, which may include varieties of the Windows, UNIX, and/or Linux. The processor220may also use high-level analysis software packages and/or custom software written in any programming and/or scripting languages for interacting with other network entities and providing applications to a plurality of devices110which are communicatively coupled to networks130.

Memory230may include any type of dynamic storage device that may store information and/or instructions, for execution by processor220, and/or any type of non-volatile storage device that may store information for use by processor220. For example, memory230may include a RAM or another type of dynamic storage device, a ROM device or another type of static storage device, and/or a removable form of memory, such as a flash memory. Mass storage device240may include any type of on-board device suitable for storing large amounts of data, and may include one or more hard drives, solid state drives, and/or various types of RAID arrays. Mass storage device240would be suitable for storing files associated client applications for distribution to a plurality of devices110.

Input device250, which may be optional, can allow an operator to input information into administration sever110, if required. Input device250may include, for example, a keyboard, a mouse, a pen, a microphone, a remote control, an audio capture device, an image and/or video capture device, a touch-screen display, and/or another type of input device. In some embodiments, AS140may be managed remotely and may not include input device250. Output device260may output information to an operator of AS140. Output device260may include a display (such as an LCD), a printer, a speaker, and/or another type of output device. In some embodiments, server140may be managed remotely and may not include output device260.

Communication interface270may include a transceiver that enables AS140to communicate over networks130with other devices and/or systems. The communications interface270may be a wireless communications (e.g., RF, infrared, and/or visual optics, etc.), wired communications (e.g., conductive wire, twisted pair cable, coaxial cable, transmission line, fiber optic cable, and/or waveguide, etc.), or a combination of wireless and wired communications. Communication interface270may include a transmitter that converts baseband signals to RF signals and/or a receiver that converts RF signals to baseband signals. Communication interface270may be coupled to one or more antennas for transmitting and receiving RF signals. Communication interface270may include a logical component that includes input and/or output ports, input and/or output systems, and/or other input and output components that facilitate the transmission/reception of data to/from other devices. For example, communication interface270may include a network interface card (e.g., Ethernet card) for wired communications and/or a wireless network interface (e.g., a WiFi) card for wireless communications. Communication interface270may also include a USB port for communications over a cable, a Bluetooth® wireless interface, an RFID interface, an NFC wireless interface, and/or any other type of interface that converts data from one form to another form.

As described below, AS140may perform certain operations relating to establishing a secure SE-TSM connection170over access network(s)130_1. AS140may perform these operations in response to processor220executing software instructions contained in a computer-readable medium, such as memory230and/or mass storage240. The software instructions may be read into memory230from another computer-readable medium or from another device. The software instructions contained in memory230may cause processor220to perform processes described herein. Alternatively, hardwired circuitry may be used in place of, or in combination with, software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

AlthoughFIG. 2shows exemplary components of AS140, in other implementations, AS140may include fewer components, different components, additional components, or differently arranged components than depicted inFIG. 2.

FIG. 3Ais a block diagram showing exemplary components of a device110according to an embodiment. Device110may include a bus310, a processor315, memory320, a read only memory (ROM)325, a storage device330, an input device(s)335, an output device(s)340, a communication interface345, a Near Field Communications (NFC) transceiver350, and Secure Element (SE)119. Bus310may include a path that permits communication among the elements of device110. SE119may be inserted into a secure element interface (I/F) (e.g., a smart card or Subscriber Identifier Module (SIM) card interface) of device110.

Processor315may include a processor, microprocessor, or processing logic that may interpret and execute instructions. Memory320may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processor315. ROM325may include a ROM device or another type of static storage device that may store static information and instructions for use by processor315. Storage device330may include a magnetic and/or optical recording medium and its corresponding drive.

Input device(s)335may include one or more mechanisms that permit an operator to input information to device110, such as, for example, a keypad or a keyboard, a microphone, voice recognition and/or biometric mechanisms, etc. Output device(s)340may include one or more mechanisms that output information to the operator, including a display, a speaker, etc. Communication interface345may include any transceiver mechanism that enables device110to communicate with other devices and/or systems. For example, communication interface345may include mechanisms for communicating with another device or system via a network, such as networks130. A Near Field Communications (NFC) transceiver350may interface with bus310to permit device110to exchange data with NFC readers, thus allowing convenient transactions with appropriately equipped Point of Sale terminals, kiosks, building security gateways, etc. Secure Element119may be insertable into device110via a smart module I/F, which may store secure applications and data to permit device110to perform trusted exchanges with other network entities. SE119may include, for example, a Universal Integrated Circuit Card (UICC), a removable user identity card (R-UIM), a subscriber identity module (SIM), a universal subscriber identity module (USIM), or an Internet Protocol (IP) multimedia services identity module (ISIM).

Device110may perform certain operations or processes, as may be described in detail below. Device110may perform these operations in response to processor315executing software instructions contained in a computer-readable medium, such as memory320. A computer-readable medium may be defined as a physical or logical memory device. A logical memory device may include memory space within a single physical memory device or spread across multiple physical memory devices. Memory may further include a memory space322which stores client applications115and application framework117. Client applications115may be provided by an MNO Application Server as described above. Application framework117permits client applications115to utilize resources of device110, and further to interface with SE119.

The software instructions may be read into memory320from another computer-readable medium, such as storage device330, or from another device via communication interface345. The software instructions contained in memory320may cause processor315to perform operations or processes that will be described in detail with respect toFIG. 8. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes consistent with the principles of the embodiments. Thus, exemplary implementations are not limited to any specific combination of hardware circuitry and software.

The configuration of components of device110illustrated inFIG. 3Ais for illustrative purposes only. It should be understood that other configurations may be implemented. Therefore, device110may include additional, fewer and/or different components than those depicted inFIG. 3A.

FIG. 3Bis a block diagram showing exemplary components with Secure Element (SE)119and an associated secure memory layout according to an embodiment. SE119is the component in device110providing the security and confidentiality required to support trusted exchanges among various network entitles over networks130. In general, SE119is a tamper-resistant platform (e.g., a single-chip secure microcontroller) capable of securely hosting applications and their associated confidential and/or cryptographic data (e.g., key management) in accordance with the rules and security requirements set forth by a set of well-identified trusted authorities. The common form factors of SE119may include Universal Integrated Circuit Card (UICC), embedded SE, and microSD, where the UICC and microSD may be removable. SE119may include a secure processor355, a secure memory360, and an interface350.

Interface350may include circuitry for inputting data to SE119from device110, and output circuitry for outputting data from SE119to device110. Secure processor355may include a processor, microprocessor, or processing logic that may interpret and execute instructions stored in secure memory360. For example, secure processor355may interpret and execute instructions an application received from a service provider TSM. Memory360may include RAM, ROM, and/or Electrically Erasable Programmable Read-Only Memory (EEPROM). Secure memory360may further be organized according to various security domains to ensure sensitive information remains compartmentalized, and cannot be shared between different service providers or the MNO. Specifically, according to Global Platform guidelines, a number of different security domains can be established such that each organization is associated with its own security domain. The MNO may be associated with an Issuer Security Domain (ISD)362. The ISD362may store a framework companion364which includes instructions for interfacing with application framework117which executes on processor315in mobile device110. Additionally, ISD362may include a set of default keys set by the SE manufacturer.

Secure memory360may further include compartmentalized memory areas called service provider security domains which may be associated with each service provider for which device110transacts. Thus, each service provider is associated with a different security domain, SP SD1366-1through SP SD366-n(generically and individually referred to herein as “SP SD366”). Each security domain SP SD366has its own separate memory store for secure data369-1through369-n(generically and individually referred to herein as “369”) which may store sensitive information such as account numbers and/or cryptographic keys which are only known to the respective service provider. Additionally, each security domain SP SD366may have its own separate memory store368-1through368-n(generically and individually referred to herein as “368”) for secure application(s) associated with each service provider.

The secure applications may run on secure processor355, which maintains separation from processor315of mobile device110for security. Accordingly, each service provider may cipher/authenticate a payload with the cryptographic keys personalized for its security domain. Only applications on the security domain associated with the service provider are able to decipher its respective payload. Secure applications368may include, for example, credit card applications, debit card applications, loyalty program applications, ticketing applications, building access applications, and travel applications.

When SE119undergoes a provisioning/personalization process for a specific service provider, the SE119is loaded with the appropriate secure application and sensitive data, such as account numbers and/or cryptographic keys, into the appropriate SP SD366. This provisioning may provided over the air using the established secure SE-TSM connection170during a BIP session.

SE119may perform certain operations or processes, as may be described in detail below in relation toFIG. 8. SE119may perform these operations in response to secure processor355executing software instructions contained in a computer-readable medium, such as secure memory360. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes consistent with the principles of the embodiment. Thus, exemplary implementations are not limited to any specific combination of hardware circuitry and software.

The configuration of components of SE119illustrated inFIG. 3Bis for illustrative purposes only. It should be understood that other configurations may be implemented. Therefore, SE119may include additional, fewer and/or different components than those depicted inFIG. 3B.

FIG. 4is an exemplary call flow diagram400illustrating communications between network entities for establishing a secure connection between Secure Element (SE)119and service provider Trusted Service Manager (SP TSM)406, which may be triggered by client application115on device110. As shown, within Device110, client application115may send a Register request to Application Framework117(405). The Register request may be the result of locally triggered event initiated by the user who wishes to perform a service operation (e.g., determine a balance of an account). In response, Application Framework117may send a request to MNO AS403to establish a secure connection160to Device110(410). The MNO AS403may then establish secure Device-AS connection160(block412). In an embodiment, secure Device-AS connection160may be a mutually authenticated Secure Sockets Layer/Transport Layer Security (SSL/TLS) connection over TCP. MNO AS403may then send a request to SP TSM406to generate a secure SE-SP TSM connection170(415A). In another embodiment, MNO AS403may instead send the request to MNO TSM406to generate a secure SE-SP TSM connection170(415C)

In one embodiment, SP TSM406may respond by generating an authentication request for a secure SE-SP TSM connection, and send the authentication request to MNO TSM404in mobile network402(420A). In this embodiment, upon receiving the authentication request from MNO TSM404, MNO AS403may immediately forward the authentication request for secure SE-SP TSM connection170to Application Framework117in Device110(425A). In an alternative embodiment, the authentication request may be sent directly by the SP TSM406to MNO AS403, thus completely bypassing MNO TSM404(420B, represented with a dotted line).

In the alternative embodiment as described above, where the request is sent to MNO TSM406(415C), MNO TSM404may send the authentication request to AS403(420C).

For either embodiment described above, an exemplary format600for the authentication request message is described below with respect toFIG. 5. The authentication request may include a “wakeup payload” providing parameters to facilitate the SE119in establishing a secure connection170with the SP TSM406.

The authentication request may be sent by MNO AS403to Application Framework117, over the previously established secure Device-AS connection160(430). The Application Framework117forwards the authentication request to the SE119(435). Upon receiving the authentication request, SE119establishes a secure SE-SP TSM connection170with SP TSM406(block416). Once established, the secure SE-SP TSM connection170may support BIP sessions in which the SE119and SP TSM406may exchange GP commands (440), as described briefly above.

Given the service provider is associated with SP TSM150, it can create a ciphered/authentication request having a payload with cryptographic keys personalized on a particular service provider security domain. This can provide greater flexibility as any service provider associated with a TSM may provide a request to the SE119to establish a secure connection.

Since SMS messaging is not being used as the primary means for forwarding authentication requests, the modem in device110and the UICC interface is less likely to become congested, thus avoiding communication “bottlenecks.” Also, by avoiding the use of SMS messaging as the primary forwarding approach, embodiments described herein decouple the messaging associated with trusted exchanges from the telecommunications infrastructure, which can further increase reliability.

Additionally, augmenting SMS messaging with secure Device-AS connection160increases security by preventing the possibility of SMS Denial of Service (DoS) attacks. This is because secure Device-AS connection160, which may be secured using SSL/TSL sessions, implicitly filters messages since only authorized application servers may send messages over the secure connection.

FIG. 5is a diagram depicting an exemplary format for an authentication request message500(i.e., a “wakeup” message). The message include a TCP Header field505, an SSL/TLS Header field510, a security domain Application ID (AID)515, a TSM IP address520, extra parameters525, sequence random number530, Media Access Control (MAC) address535, and SSL/TLS MAC address540. The wakeup payload for authentication request message500includes security domain AID515, which may be read by the application framework, and TSM IP address520, extra parameters525, and sequence random number530, which is encrypted so only the appropriate security domain may decipher this information with the SP channel keys. As will be describe below in reference toFIG. 6, the security domain AID should be sent so that it may read by Application Framework117, so the authentication request message may be routed to the appropriate security domain in the SE1119.

FIG. 6is a diagram illustrating the routing of authentication request messages into appropriate service provider secure domains366within the secure memory360of SE119. As described above in reference toFIG. 4, the MNO AS402may provide an authentication request for secure SE-SP TSM connection (430) over the previously established secure Device-AS connection160. The authentication request is received by Application Framework117in device110. Because security domain AID515is not encrypted with SP channel keys, Application Framework117may read these values, and provide them directly to the appropriate SP SD366, without having to go through Framework Companion364in ISD362.

FIG. 7is a flow chart showing an exemplary process700for establishing a secure connection between SE110and TSM150which may execute on MNO Application Server (AS)403. Process700may initially receive a request from Device110to establish a first secure connection (block710). Upon receiving the request, MNO AS403may establish the first secure connection with Device110in response to the received request (block720). The first secure connection may be a secure connection between Device110and MNO AS403, which may be an SSL/TSL TCP session. AS140may then send a request to SP TSM406(block820). The sent request may instruct the SP TSM406to establish a second secure connection between SP TSM406and Secure Element (SE)119(block730). The MNO AS403may receive an authentication request from the SP-TSM406to establish the second secure connection (block740). The second secure connection may be secure SE-SP TSM connection170. The MNO AS403may then forward the authentication request to Device110over the first secure connection (block750).

FIG. 8is a flow chart showing an exemplary process800for establishing a secure connection between SE119and SP TSM406, which may execute, in parts, on Device110and SE119. Device110may send a request to MNO AS403to establish a first secure connection (block810). As noted above the first secure connection may be secure connection between device110and MNO AS403, which may be an SSL/TSL TCP session. Device110may then receive an authentication request forwarded by the MNO AS403over the first secure connection. The authentication request may be generated by a SP TSM406to establish a second secure connection between SE119and SP TSM406(block820). Blocks810and820may be executed on processor315.

The SE119may establish the second secure connection170with the SP TSM406(block830). The second secure connection may be secure SE-SP TSM connection170which supports BIP session. The SE119may then receive provisioning information to conduct transactions with a service provider (block840). Here, the provisioning information may include secure applications and/or sensitive information (i.e., cryptographic keys), and may be exchange using Global Platform commands. Blocks830and840may be executed on secure processor355.

In an alternative embodiment, remote server triggered events based on “piggyback polling” may be used to take advantage of the secure Device-AS connection160established by the user using Device110. Client triggered events described above may be time-sensitive (i.e. customer initiates an action and quickly expects a response), and thus may utilize a fast response. On the other hand, server triggered events are typically not time-sensitive (i.e. applet upgrade to an improved version). Conventional approaches have the MNO AS403trigger update sessions using SMS messaging, which are handled in a batch mode. The SP TSMs may update applications in a serial manner, and thus for each application, will go one-by-one and try to connect and perform upgrades for each outdated application. This approach may not be very efficient, and can be subject to the high latency and unreliability associated with SMS messaging.

A more efficient approach is to use “piggyback polling” which takes advantage of the client initiated secure SE-SP TSM connection170. Each time a user-initiated operation is performed, the SP TSM406takes advantage of the active secure SE-SP TSM connection170to append any server-pending-operation(s) after provisioning of SE119. Accordingly, the triggering for this approach is still originally initiated by the client as described in the embodiments presented above, but afterwards the TSM may take advantage of the established connection to the SE for providing its secure memory with application updates and/or new cryptographic keys.

The rationale to add server pending operations after user-initiated operation is to ensure that the user's experience is not adversely affected. However, in some cases, upon a first time activation, the secure application may be downloaded from SP-TSM406prior to provisioning SE119.

The foregoing description of implementations provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, while series of messages and/or blocks have been described with regard toFIGS. 5,8and9, the order of the messages and/or blocks may be modified in other embodiments. Further, non-dependent messaging and/or processing blocks may be performed in parallel.

The terms “comprises” and/or “comprising,” as used herein specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components, or groups thereof. Further, the term “exemplary” (e.g., “exemplary embodiment,” “exemplary configuration,” etc.) means “as an example” and does not mean “preferred,” “best,” or likewise.