Patent Description:
Many mobile platforms (e.g., ANDROIDTM, WINDOWS MOBILE OS, etc.) use a technology called host card emulation (HCE), which allows normal mobile applications to process data and communicate with a point of sale (POS) terminal through near field communications (NFC). Disadvantageously, part of the payment channel within the mobile device is exposed in the operating system (OS) framework layer, such that the payment channel may be compromised and data can be stolen by malicious applications software (i.e., an "app"). <CIT> relates to mobile device whereon a trusted application performed in a trusted execution environment (TEE) is capable of transmitting payment information to an NFC controller via an NFC driver which is also executed in the trusted execution environment. During the NFC payment a token cryptogram is generated by the payment module of the TEE. <CIT> discloses a computer system which stores sensitive data in a data storage component of a trusted execution component. A browser component running on the computer system may initiate a transmission of the sensitive data to a remote service by establishing a secure channel (encrypted connection). <CIT> relates to a mobile terminal for performing NFC payments which receives transaction data via an NFC communication from a merchant terminal. The transaction data is processed by a host card emulation module before being forwarded to a trusted application running in a trusted execution environment which provides authentication data for the transaction that are returned to the merchant device. <CIT> discloses a mobile device comprising a host-card-emulation (HCE) application module and a security module The mobile device has an NFC controller for receiving an NFC transaction signal from an NFC reader. The HCE application module processes the NFC transaction signal and decides whether to forward the signal to the security module based on a pre-defined application ID routing table. <CIT> discloses an electronic device which provides a rich operation system and a trusted execution environment (TEE). Applications residing in the Rich OS may communicate over a data channel with an NFC controller by using an NFC driver running in the Rich OS. The TEE provides a control channel from the TEE to the NFC controller to configure the NFC controller. As an alternative embodiment it is disclosed to use a router which deploys an NFC driver to respectively route data channels from the Rich OS and TEE and a control channel from the TEE to the NFC controller. <CIT> discloses to deploy a rich execution environment (REE) and a trusted execution environment (TEE) on a communication apparatus. The rich execution environment comprises a first NFC module and a virtual NFC module and the trusted execution environment comprises a second NFC module and an NFC controller. A secure application running in the TEE communicates via the second NFC module with the NFC controller. A regular application running in the REE communicates via the first NFC module with the virtual NFC module which forwards the communication to the NFC controller.

One particular example where payment data can be exposed by a vulnerable payment channel is a mobile wallet, such as ANDROID PAY™ or SAMSUNG PAY™, although the threat may extend to other scenarios in which sensitive data are being exchanged through a HCE to NFC port channel.

This disclosure provides a system and method for securing transactions, which are particularly suitable for mobile platforms, although not limited thereto.

For a more complete understanding of the principles present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:.

It may be advantageous to set forth definitions of certain words and phrases used throughout this patent document. The terms "transmit", "receive", and "communicate", as well as derivatives thereof, encompass both direct and indirect communication. The terms "include" and "comprise", as well as derivatives thereof, mean inclusion without limitation. The phrase "associated with", as well as derivatives thereof, means to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, have a relationship to or with, or the like.

As used herein, the terms "have", "may have", "include", "may include", "can have", or "can include" a feature (e.g., a number, function, operation, or a component such as a part) indicate the existence of the feature and do not exclude the existence of other features.

As used herein, the terms "A or B", "at least one of A and/or B", or "one or more of A and/or B" may include all possible combinations of A and B. For example, "A or B", "at least one of A and B", "at least one of A or B" may indicate all of (<NUM>) including at least one A, (<NUM>) including at least one B, or (<NUM>) including at least one A and at least one B.

As used herein, the terms "first" and "second" may modify various components regardless of importance and do not limit the components. These terms are only used to distinguish one component from another. For example, a first user device and a second user device may indicate different user devices from each other regardless of the order or importance of the devices. For example, a first component may be denoted a second component, and vice versa without departing from the scope of the present disclosure.

It will be understood that when an element (e.g., a first element) is referred to as being (operatively or communicatively) "coupled with/to", or "connected with/to" another element (e.g., a second element), it can be coupled or connected with/to the other element directly or via a third element. In contrast, it will be understood that when an element (e.g., a first element) is referred to as being "directly coupled with/to" or "directly connected with/to" another element (e.g., a second element), no other element (e.g., a third element) intervenes between the element and the other element.

As used herein, the terms "configured (or set) to" may be interchangeably used with the terms "suitable for", "having the capacity to", "designed to", "adapted to", "made to", or "capable of' depending on circumstances. The term "configured (or set) to" does not essentially mean "specifically designed in hardware to". Rather, the term "configured to" may mean that a device can perform an operation together with another device or parts.

For example, the term "processor configured (or set) to perform A, B, and C" may mean a generic-purpose processor (e.g., a CPU or application processor) that may perform the operations by executing one or more software programs stored in a memory device or a dedicated processor (e.g., an embedded processor) for performing the operations.

The terms as used herein are provided merely to describe some embodiments thereof, but not to limit the scope of other embodiments of the present disclosure. It is to be understood that the singular forms "a", "'an", and "the" include plural references unless the context clearly dictates otherwise. All terms including technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the embodiments of the present disclosure belong. In some cases, the terms defined herein may be interpreted to exclude embodiments of the present disclosure.

For example, examples of the electronic device according to embodiments of the present disclosure may include at least one of a smartphone, a tablet personal computer (PC), a mobile phone, a video phone, an e-book reader, a desktop PC, a laptop computer, a netbook computer, a workstation, a PDA (personal digital assistant), a portable multimedia player (PMP), an MP3 player, a mobile medical device, a camera, or a wearable device (e.g., smart glasses, a head-mounted device (HMD), electronic clothes, an electronic bracelet, an electronic necklace, an electronic accessory, an electronic tattoo, a smart mirror, or a smart watch).

According to embodiments of the present disclosure, the electronic device can be a smart home appliance. Examples of the smart home appliance can include at least one of a television, a digital video disk (DVD) player, an audio player, a refrigerator, an air conditioner, a cleaner, an oven, a microwave oven, a washer, a drier, an air cleaner, a set-top box, a home automation control panel, a security control panel, a TV box (e.g., Samsung HomeSync™, APPLE TV™, or GOOGLE TV™) , a gaming console (XBOX™, PLAYSTATION™), an electronic dictionary, an electronic key, a camcorder, or an electronic picture frame.

According to certain embodiments of the present disclosure, examples of the electronic device can include at least one of various medical devices (e.g., diverse portable medical measuring devices (a blood sugar measuring device, a heartbeat measuring device, or a body temperature measuring device), a magnetic resource angiography (MRA) device, a magnetic resource imaging (MRI) device, a computed tomography (CT) device, an imaging device, or an ultrasonic device), a navigation device, a global positioning system (GPS) receiver, an event data recorder (EDR), a flight data recorder (FDR), an automotive infotainment device, an sailing electronic device (e.g., a sailing navigation device or a gyro compass), avionics, security devices, vehicular head units, industrial or home robots, automatic teller's machines (ATMs), point of sales (POS) devices, or Internet of Things devices (e.g., a bulb, various sensors, an electric or gas meter, a sprinkler, a fire alarm, a thermostat, a street light, a toaster, fitness equipment, a hot water tank, a heater, or a boiler).

According to certain embodiments of the disclosure, the electronic device can be at least one of a part of a piece of furniture or building/structure, an electronic board, an electronic signature receiving device, a projector, or various measurement devices (e.g., devices for measuring water, electricity, gas, or electromagnetic waves).

According to embodiments of the present disclosure, the electronic device is one or a combination of the above-listed devices. According to embodiments of the present disclosure, the electronic device is a flexible electronic device. The electronic device disclosed herein is not limited to the above-listed devices, and can include new electronic devices depending on the development of technology.

As used herein, the term "user" may denote a human or another device (e.g., an artificial intelligent electronic device) using the electronic device.

<FIG>, discussed below, and the various embodiments used to describe the principles of this disclosure in this patent document are by way of illustration only. Those skilled in the art will understand that the principles of this disclosure can be implemented in any suitably arranged wireless communication system.

Referring to <FIG>, according to an embodiment of the present disclosure, an electronic device <NUM> is included in a network environment <NUM>. The electronic device <NUM> may include at least one of a bus <NUM>, a processor <NUM>, a memory <NUM>, an input/ output interface <NUM>, a display <NUM>, a communication interface <NUM>, or an event processing module <NUM>. In some embodiments, the electronic device <NUM> may exclude at least one of the components or may add another component.

For example, examples of the electronic device <NUM> according to embodiments of the present disclosure may include at least one of a smartphone, a tablet personal computer (PC), a mobile phone, a video phone, an e-book reader, a desktop PC, a laptop computer, a netbook computer, a workstation, a PDA (personal digital assistant), a portable multimedia player (PMP), an MP3 player, a mobile medical device, a camera, or a wearable device (e.g., smart glasses, a head-mounted device (HMD), electronic clothes, an electronic bracelet, an electronic necklace, an electronic appcessory, an electronic tattoo, a smart mirror, or a smart watch).

According to an embodiment of the present disclosure, the electronic device <NUM> may be a smart home appliance. Examples of the smart home appliance may include at least one of a television, a digital video disk (DVD) player, an audio player, a refrigerator, an air conditioner, a cleaner, an oven, a microwave oven, a washer, a drier, an air cleaner, a set-top box, a home automation control panel, a security control panel, a TV box (e.g., Samsung HomeSync™, Apple TV™, or Google TV™) , a gaming console (Xbox™, PlayStation™), an electronic dictionary, an electronic key, a camcorder, or an electronic picture frame.

According to an embodiment of the present disclosure, examples of the electronic device <NUM> may include at least one of various medical devices (e.g., diverse portable medical measuring devices (a blood sugar measuring device, a heartbeat measuring device, or a body temperature measuring device), a magnetic resource angiography (MRA) device, a magnetic resource imaging (MRI) device, a computed tomography (CT) device, an imaging device, or an ultrasonic device), a navigation device, a global positioning system (GPS) receiver, an event data recorder (EDR), a flight data recorder (FDR), an automotive infotainment device, an sailing electronic device (e.g., a sailing navigation device or a gyro compass), avionics, security devices, vehicular head units, industrial or home robots, automatic teller's machines (ATMs), point of sales (POS) devices, or Internet of Things devices (e.g., a bulb, various sensors, an electric or gas meter, a sprinkler, a fire alarm, a thermostat, a street light, a toaster, fitness equipment, a hot water tank, a heater, or a boiler).

According to various embodiments of the disclosure, examples of the electronic device <NUM> may at least one of part of a piece of furniture or building/structure, an electronic board, an electronic signature receiving device, a projector, or various measurement devices (e.g., devices for measuring water, electricity, gas, or electromagnetic waves).

According to an embodiment of the present disclosure, the electronic device <NUM> may be one or a combination of the above-listed devices. According to an embodiment of the present disclosure, the electronic device may be a flexible electronic device. The electronic device disclosed herein is not limited to the above-listed devices, and may include new electronic devices depending on the development of technology.

As used herein, the term "user" may denote a human or another device (e.g., an artificial intelligent electronic device) using the electronic device <NUM>.

Returning to <FIG>, the bus <NUM> may include a circuit for connecting the components <NUM> to <NUM> with one another and transferring communications (e.g., control messages and/or data) between the components.

The processing module <NUM> may include one or more of a central processing unit (CPU), an application processor (AP), or a communication processor (CP). The processor <NUM> may perform control on at least one of the other components of the electronic device <NUM>, and/or perform an operation or data processing relating to communication.

The memory <NUM> may include a volatile and/or non-volatile memory. For example, the memory <NUM> may store commands or data related to at least one other component of the electronic device <NUM>. According to an embodiment of the present disclosure, the memory <NUM> may store software and/or a program <NUM>. The program <NUM> may include, e.g., a kernel <NUM>, middleware <NUM>, an application programming interface (API) <NUM>, and/or an application program (or "application") <NUM>. At least a portion of the kernel <NUM>, middleware <NUM>, or API <NUM> may be denoted an operating system (OS).

For example, the kernel <NUM> may control or manage system resources (e.g., the bus <NUM>, processor <NUM>, or a memory <NUM>) used to perform operations or functions implemented in other programs (e.g., the middleware <NUM>, API <NUM>, or application program <NUM>). The kernel <NUM> may provide an interface that allows the middleware <NUM>, the API <NUM>, or the application <NUM> to access the individual components of the electronic device <NUM> to control or manage the system resources.

The middleware <NUM> may function as a relay to allow the API <NUM> or the application <NUM> to communicate data with the kernel <NUM>, for example. A plurality of applications <NUM> may be provided. The middleware <NUM> may control work requests received from the applications <NUM>, e.g., by allocation the priority of using the system resources of the electronic device <NUM> (e.g., the bus <NUM>, the processor <NUM>, or the memory <NUM>) to at least one of the plurality of applications <NUM>.

The API <NUM> is an interface allowing the application <NUM> to control functions provided from the kernel <NUM> or the middleware <NUM>. For example, the API <NUM> may include at least one interface or function (e.g., a command) for filing control, window control, image processing or text control.

The input/output interface <NUM> may serve as an interface that may, e.g., transfer commands or data input from a user or other external devices to other component(s) of the electronic device <NUM>. Further, the input/output interface <NUM> may output commands or data received from other component(s) of the electronic device <NUM> to the user or the other external device.

The display <NUM> may include, e.g., a liquid crystal display (LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, or a microelec-tromechanical systems (MEMS) display, or an electronic paper display. The display <NUM> may display, e.g., various contents (e.g., text, images, videos, icons, or symbols) to the user. The display <NUM> may include a touchscreen and may receive, e.g., a touch, gesture, proximity or hovering input using an electronic pen or a body portion of the user.

For example, the communication interface <NUM> may set up communication between the electronic device <NUM> and an external electronic device (e.g., a first electronic device <NUM>, a second electronic device <NUM>, or a server <NUM>). For example, the communication interface <NUM> may be connected with the network <NUM> or <NUM> through wireless or wired communication to communicate with the external electronic device.

The first external electronic device <NUM> or the second external electronic device <NUM> may be a wearable device or an electronic device <NUM>-mountable wearable device (e.g., a head mounted display (HMD)). When the electronic device <NUM> is mounted in a HMD (e.g., the electronic device <NUM>), the electronic device <NUM> may detect the mounting in the HMD and operate in a virtual reality mode. When the electronic device <NUM> is mounted in the electronic device <NUM> (e.g., the HMD), the electronic device <NUM> may communicate with the electronic device <NUM> through the communication interface <NUM>. The electronic device <NUM> may be directly connected with the electronic device <NUM> to communicate with the electronic device <NUM> without involving with a separate network.

The wireless communication may use at least one of, e.g., long term evolution (LTE), long term evolution- advanced (LTE-A), code division multiple access (CDMA), wideband code division multiple access (WCDMA), universal mobile telecommunication system (UMTS), wireless broadband (WiBro), or global system for mobile communication (GSM), as a cellular communication protocol. The wired connection may include at least one of universal serial bus (USB), high definition multimedia interface (HDMI), recommended standard <NUM> (RS-<NUM>), or plain old telephone service (POTS).

The network <NUM> may include at least one of communication networks, e.g., a computer network (e.g., local area network (LAN) or wide area network (WAN)), Internet, or a telephone network.

The first and second external electronic devices <NUM> and <NUM> each may be a device of the same or a different type from the electronic device <NUM>. According to an embodiment of the present disclosure, the server <NUM> may include a group of one or more servers. According to an embodiment of the present disclosure, all or some of operations executed on the electronic device <NUM> may be executed on another or multiple other electronic devices (e.g., the electronic devices <NUM> and <NUM> or server <NUM>). According to an embodiment of the present disclosure, when the electronic device <NUM> should perform some function or service automatically or at a request, the electronic device <NUM>, instead of executing the function or service on its own or additionally, may request another device (e.g., electronic devices <NUM> and <NUM> or server <NUM>) to perform at least some functions associated therewith. The other electronic device (e.g., electronic devices <NUM> and <NUM> or server <NUM>) may execute the requested functions or additional functions and transfer a result of the execution to the electronic device <NUM>. The electronic device <NUM> may provide a requested function or service by processing the received result as it is or additionally. To that end, a cloud computing, distributed computing, or client-server computing technique may be used, for example.

Although <FIG> shows that the electronic device <NUM> includes the communication interface <NUM> to communicate with the external electronic device <NUM> or <NUM> via the network <NUM>, the electronic device <NUM> may be independently operated without a separate communication function, according to an embodiment of the present disclosure.

The server <NUM> may support to drive the electronic device <NUM> by performing at least one of operations (or functions) implemented on the electronic device <NUM>. For example, the server <NUM> may include an event processing server module (not shown) that may support the event processing module <NUM> implemented in the electronic device <NUM>.

For example, the event processing server module may include at least one of the components of the event processing module <NUM> and perform (or instead perform) at least one of the operations (or functions) conducted by the event processing module <NUM>.

The event processing module <NUM> may process at least part of information obtained from other elements (e.g., the processor <NUM>, the memory <NUM>, the input/output interface <NUM>, or the communication interface <NUM>) and may provide the same to the user in various manners.

For example, according to an embodiment of the present disclosure, the event processing module <NUM> may process information related to an event, which is generated while the electronic device <NUM> is mounted in a wearable device (e.g., the electronic device <NUM>) to function as a display apparatus and to operate in the virtual reality mode, to fit the virtual reality mode and display the processed information. When the event generated while operating in the virtual reality mode is an event related to running an application, the event processing module <NUM> may block the running of the application or process the application to operate as a background application or process.

Although in <FIG> the event processing module <NUM> is shown to be a module separate from the processor <NUM>, at least a portion of the event processing module <NUM> may be included or implemented in the processor <NUM> or at least one other module, or the overall function of the event processing module <NUM> may be included or implemented in the processor <NUM> shown or another processor. The event processing module <NUM> may perform operations according to embodiments of the present disclosure in interoperation with at least one program <NUM> stored in the memory <NUM>.

Exemplary embodiments described herein are not meant to be limiting and merely illustrative of various aspects of the disclosure. While exemplary embodiments may be indicated as applicable to a particular device category (e.g., TVs, etc.) the processes and examples provided are not intended to be solely limited to the device category and can be broadly applicable to various device categories (e.g., appliances, computers, automobiles, etc.).

In one embodiment, as part of a setup process, a user may be presented with applications or services on a connected device (e.g., mobile device, smartphone, tablet, laptop, desktop, or similar device) which may be installed on the device being setup. The applications may be supported by effortless login (also referred to herein as silent login). When the application is selected on the connected device, the process may deep link to the mobile application installed on the connected device or launch a secure web browser to authenticate the user. Upon successful authentication, a token may be delivered to the connected device allowing the connected device to login without having to enter authentication information.

For implementing sensitive transactions through an NFC port, such as payment transactions between a mobile device and a point-of-sale (POS) terminal, different hardware / software implementations are possible. One option is to use a secure element (SE), which allows data to be exchanged directly between the SE and the NFC controller without access by the host OS. However, SE-based systems are difficult to develop and typically cannot be accessed by third-party developers. Another option is to use pluggable hardware (e.g., an NFC front-end and/or security modules), which allows an app to exchange NFC data under tight control. This option, however, not only requires additional hardware, but also requires set-up certificates and a protocol for both the app and the hardware to enable security and other operating features.

Another option for implementing secure NFC transactions is to use an HCE-service, although an HCE-service does not provide the same level of security as an SE. Generally, payment data (e.g., primary credit or debit number, expiration date, and cryptogram) are generated in a trusted execution environment (TEE) in response to a request through an HCE service running in the OS user space. Those data are then sent back through the HCE service and then to the NFC controller. Under this set of conditions, the data are not secure, since the OS can access those data during the exchange with the NFC controller. This problem is illustrated in <FIG>.

<FIG> illustrates the operation of a typical conventional HCE-based system <NUM> during a payment transaction. The payment credentials are generated by a payment trusted app <NUM> running within a TEE <NUM>. The credentials are sent to a wallet app (HCE service) <NUM> running within the OS user space <NUM>. The data are then transmitted from wallet app <NUM> to the NFC service <NUM>, also running within OS user space <NUM>. The NFC driver <NUM> in the kernel space <NUM> allows the NFC service <NUM> to interact with the NFC hardware chip <NUM>.

Consequently, the channel between the wallet app <NUM> and the NFC kernel driver <NUM> is completely exposed in the user space <NUM> and any software/firmware program or app that has privilege may be able to interfere with or monitor any transaction being implemented through the channel. In other words, a program or app having access to the channel may copy, modify, or tamper with the data being exchanged between wallet app <NUM> and NFC kernel driver <NUM>.

It has been discovered that building a trusted security foundation outside of a normal operating system may mitigate potential threats to HCE-based transactions when the payment channel is compromised by exposure in the OS framework layer, as illustrated by <FIG>.

<FIG> illustrates an exemplary system <NUM> with a TEE-based NFC control, according to an embodiment of the disclosure. For illustrative purposes, a payment transaction is being implemented by system <NUM>, although the principles of the present disclosure are not limited to payment systems. For example, system <NUM> could also be used to transfer personal identification data (e.g., passport or driver's license number), electronic key data, or any other form of sensitive information being exchanged between an NFC port and an app running within a TEE.

In exemplary system <NUM>, sensitive data generated by payment trusted app <NUM> are exchanged with NFC hardware chip <NUM> through an NFC driver <NUM> executing within TEE <NUM> to provide a secure channel (data path) <NUM>. In addition, NFC TEE driver <NUM> selectively enables and disables NFC kernel driver <NUM> within kernel space <NUM>. (The NFC TEE driver <NUM> always has higher privilege over the OS kernel <NUM> such that NFC TEE driver <NUM> controls the non-secure data path through NFC kernel driver <NUM>, notwithstanding any actions taken by other apps or programs executing within OS kernel <NUM>.

In some embodiments, the payment trusted app <NUM> directly calls the NFC TEE driver <NUM> and then exchanges data with the NFC driver <NUM> using the secured channel <NUM>. In other embodiments, the wallet app <NUM> may enable the NFC TEE driver <NUM>, for example through an API, and then command payment trusted app <NUM> exchange the sensitive data with NFC Tee driver 301via the secure channel <NUM>. In further embodiments, the payment trusted app <NUM> may enable the NFC TEE driver <NUM> when sensitive data are being exchanged and then sends the sensitive data to the NFC TEE driver <NUM> via the secure channel <NUM>.

The embodiment of system <NUM> of <FIG> allows for the transmission of sensitive data, which are preferably, but not necessarily, encrypted, entirely through the TEE <NUM>. In the example of a payment system, the sensitive data may be an application protocol data unit (APDU) (e.g., a unit of data containing, for example, payment credentials, including digital primary number, application cryptogram, card expiration, and so on). Consequently, the host OS, including applications and other programs executing in the kernel space <NUM> and the user space <NUM>, cannot access the sensitive data being exchanged between payment trusted app <NUM> and NFC hardware chip <NUM>.

Although non-sensitive or non-encrypted data may be exchanged through NFC TEE driver <NUM> in system <NUM>, non-sensitive data may also be exchanged between wallet app <NUM> and NFC chip <NUM> through a lower security data path including NFC service <NUM> and NFC kernel driver <NUM>. The use of this lower security data path allows for improved system performance (e.g., lower processing overhead) when higher data security is unnecessary.

<FIG> illustrates an exemplary system <NUM> with cloud credentials from a payment (wallet) cloud <NUM> accessed by the wallet <NUM> through a secure channel <NUM>. To meet a higher security requirement, system <NUM> can allow a third party to encrypt credentials at the device level or end-to-end between a payment server or payment cloud and the TEE NFC driver <NUM>. In this example of a payment system, the encrypted payment data pass through wallet app <NUM>, which cannot decrypt or otherwise modify those data, to payment trusted app <NUM>. As such, the sensitive data being exchanged are completely protected against access by apps and other programs executed within OS user space <NUM> and OS kernel <NUM>.

It should be recognized that the data path between payment cloud <NUM> and payment trusted app <NUM> does not necessarily have to pass through wallet app <NUM>. In alternate embodiments of the principles of the present disclosure, another suitable software program or app could provide the interface between payment cloud <NUM> and payment trusted app <NUM>, given that the secure data is not accessible by any program or app operating between payment cloud <NUM> and payment trusted app <NUM>.

In one embodiment of the inventive principles, to switch to the secure operating mode, and SMC call is made to NFC TEE driver <NUM>, which opens and locks the i2c bus. The NFC data is then serialized by NFC TEE driver <NUM> and then written to the i2c bus in accordance with the specification of NFC hardware chip <NUM>.

Furthermore, system <NUM> also allows the wallet cloud <NUM> to verify the public certificate of the TEE <NUM> with root certificate authority (CA), so that wallet cloud <NUM> can exchange the key with NFC TEE driver <NUM>, and sign and encrypt the credential with public key infrastructure (PKI). Mobile wallet <NUM> can send template APDU with encrypted credentials received from the wallet cloud <NUM> to the NFC TEE driver <NUM>. The NFC TEE driver <NUM> receives the template APDU and encrypted credential, reconstructs the APDU, and sends it to NFC hardware chip <NUM>.

Advantageously, embodiments of the principles of the disclosure provide a higher level of security under a number of different operating scenarios. For example, these principles can support various mobile payment apps, including both token and non-token based mobile payment apps, using NFC TEE driver <NUM> and the secure channel <NUM> as the payment channel. Additionally, to optimize performance, mobile wallet <NUM> can select the secure channel <NUM> to transmit sensitive data. Mobile wallet <NUM> can also transmit any APDU data including credentials and non-sensitive data through secure channel <NUM>. Finally, NFC TEE driver <NUM> may be configured to have the higher control over the host OS kernel, wherein NFC TEE driver <NUM> first disables access by the host OS to NFC hardware chip <NUM> by disabling NFC kernel driver <NUM> before sending data.

<FIG> is a sequence diagram illustrating an exemplary exchange of APDU data using either system <NUM> or system <NUM> discussed above. For discussion purposes, a commercial transaction between a mobile device and a POS terminal <NUM> is shown, although the principles of the disclosure are not limited thereto and can be equally applied to a wide range of scenarios where sensitive data must be exchanged between an NFC port and an onboard app or program without monitoring or interference from other apps or programs operating within the kernel or user spaces.

In <FIG>, the POS terminal <NUM> may send a command (CommandApdu) to the NFC service kernel driver <NUM>, which is then passed to the wallet app <NUM>. The NFC service kernel driver <NUM> may optionally provide a response (ResponseApdu) to the POS terminal <NUM>. In addition, the wallet app <NUM> may also optionally provide a response to the NFC service kernel driver <NUM>. This initial sequence of commands and responses may loop and may be used, for example, to exchange non-sensitive data for such purposes as link management and the exchange of non-sensitive end-user information.

Encrypted credentials may be generated by payment trusted app <NUM> running within TEE <NUM> (<FIG>), as discussed further below, or received from an external source (e.g., cloud wallet <NUM> of <FIG>). When the POS terminal <NUM> provides a command to request the credential, the wallet app <NUM> may provide the encrypted credential to the NFC TEE driver <NUM> through secure channel <NUM>. The NFC TEE driver <NUM> may selectively disable the unsecure channel through the NFC service kernel driver <NUM>, then decrypt the credential and provide a response to the POS terminal <NUM> through the secure channel and the NFC hardware chip <NUM>.

Subsequently, the POS terminal <NUM> may provide a command to the NFC service kernel driver <NUM>, which is then passed to the wallet app <NUM>, and the wallet app <NUM> may provide a response to the NFC service kernel driver <NUM>, which then may provide a response to the POS terminal <NUM>. This sequence of commands and responses may also be performed in a loop to implement non-sensitive operations such as link management and the exchange of non-sensitive end-user information.

<FIG> is a diagram of a representative payment transaction in which the payment credentials are generated on the mobile device itself according to an embodiment of the principles of the present disclosure. In this example, the transaction begins when an NFC POS terminal <NUM> transmits a Select Payment Proximity System environment (PPSE) command to the mobile terminal through NFC hardware chip <NUM>. The Select PPSE command is passed, as non-sensitive data, through NPC kernel driver <NUM> and NFC service <NUM> to wallet app <NUM>. Wallet app <NUM> and NPC kernel driver <NUM> then return an Application Identifier (AID) list to the POS terminal <NUM> identifying the supported payment applications (e.g., Visa, MasterCard). NFC POS terminal <NUM> and wallet app <NUM> may exchange additional CommandAPDUs and ResponseAPDUs through NFC kernel driver <NUM> and NFC hardware chip <NUM> to exchange additional non-sensitive data.

Next, the NFC POS terminal <NUM> POS sends a Generate Application Cryptogram command through NFC kernel driver <NUM> to wallet app <NUM>, which initiates the secure transaction.

In particular, wallet app <NUM> enables NFC TEE driver <NUM>, which in turns disables NFC kernel driver <NUM>. The payment trusted app <NUM> then generates the cryptogram using an encrypted key stored in wallet app <NUM>, which is transmitted to NFC POS terminal <NUM> through NFC TEE driver <NUM> and NFC hardware chip <NUM>. After generation of the cryptogram, wallet app <NUM> disables NFC TEE driver <NUM> and NFC kernel driver <NUM> is re-enabled.

NFC POS terminal <NUM> and wallet app <NUM> may exchange additional non-sensitive CommandAPDUs and ResponseAPDUs through NFC kernel driver <NUM> and NFC hardware chip <NUM> to complete the transaction.

It should be noted that the illustrated regions of the figures are merely examples. Also, it should be noted that although the above illustrations are shown in two dimensions, the zones are often three dimensional. It also should be noted that for clarity and ease of illustration, the figures are not necessarily made to scale.

While the above detailed diagrams have shown, described, and pointed out novel features of the disclosure as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the device or process illustrated may be made by those skilled in the art without departing from the disclosure. This description is in no way meant to be limiting, but rather should be taken as illustrative of the general principles of the disclosure.

Though embodiments have been described with reference to certain versions thereof; however, other versions are possible.

Claim 1:
A mobile communications device (<NUM>) comprising:
a near field communications, NFC, port; and
a processor (<NUM>) operable to:
execute a trusted application (<NUM>) within a trusted execution environment, TEE, (<NUM>) for processing sensitive data;
execute a first NFC driver (<NUM>) within the TEE (<NUM>) for providing a secure channel between the trusted application and the NFC port such that sensitive data being exchanged across the secure channel are inaccessible to other processes being executed by the processor (<NUM>);
execute the first NFC driver (<NUM>) for controlling a non-secure channel to the NFC port, wherein the non-secure channel is provided through a second NFC driver (<NUM>) within a kernel space (<NUM>) which is separated from the TEE (<NUM>); and
control the first NFC driver (<NUM>) to disable the second NFC driver (<NUM>) for disabling the non-secure channel during the exchange of sensitive data between the trusted application (<NUM>) and the NFC port through the secure channel.