WO2016189277A1

WO2016189277A1 - Securing host card emulation (hse) solutions

Info

Publication number: WO2016189277A1
Application number: PCT/GB2016/051458
Authority: WO
Inventors: Theresa Smith; Colin Tanner
Original assignee: Digiseq Limited
Priority date: 2015-05-22
Filing date: 2016-05-20
Publication date: 2016-12-01
Also published as: GB201508870D0

Abstract

A computer-implemented method of authenticating communication between a device and an entity, the device having an identity application residing on a secure element and a received application residing on an application processor, the method comprising the steps of providing at least one cryptographic key to the identity application, receiving encrypted data from a server, authenticating communication between the device and the server by unencrypting the encrypted data using the at least one cryptographic key, receiving, at the identity application, one or more security tokens from the server, providing, to the received application, at least one of the one or more security tokens, and communicating, via the received application, with an entity based on receiving at least one of the one or more security tokens at the received application.

Description

Securing Host Card Emulation (HCE) Solutions

This disclosure relates to improving the security of a secure host card emulation (HCE) application when deployed to a consumer device. It is particularly suitable for, but by no means limited to, enabling a secure element (or other secure environment such as a trusted execution environment (TEE)) within a mobile device (which may be N FC enabled) to be used to secure and authenticate communication between the device and an HCE token server. This may be undertaken during manufacture (or before the final owner of the device is known) for use by one or more host card emulation (HCE) applications that may subsequently be downloaded to the device.

Background

Consumer Electronics manufactures have in recent years included Near Field Communication (N FC) functionality in an increasing number of mobile phones and other consumer devices. Currently to meet the security requirements of some applications, such as those for conducting financial transactions (mobile payments), the whole application that utilizes the N FC functionality has been provisioned to a specialist secure element (SE) within the consumer device or within a separate removable security device. In the case of this being directly included within the device it is known as an embedded secure element (eSE), or in the case of a removable security device, it has been included within a U ICC or Micro SD device. However the payments industry has experienced problems when deploying applications to a Secure Element as typically there are many business owners and interested parties involved. This has led to both commercial and technical challenges that have prevented significant deployment of mobile applications requiring security (e.g. mobile payment) to consumer devices.

Recently Google has introduced into the android operating system (Android 4.4, known as Kit Kat) functionality that allows an application on the consumer device (e.g. mobile phone) to directly communicate over the NFC interface. This technology does not require the presence or use of a secure element. The wider industry believes that applications using this functionality may be easier to deploy than applications that must be provisioned into a secure element. However others see such applications as not being as secure as SE based applications which may limit the mass adoption and deployment of some applications using this technology. Applications that support payments, Transit, Identity or Access control need to maintain a level of security which may not be achievable using a conventional mobile phone application.

To provide greater security within an HCE application, the security of the application can be enhanced by utilizing security functionality on a remote server, the actual HCE application on the consumer device having minimal involvement in the overall security of the solution. However this approach introduces a number of security vulnerabilities not previously present in a Secure Element based application including:

1. The HCE application on the consumer device must communicate with a remote server in order to undertake a transaction or otherwise perform its function. An attacker may impersonate the consumer device in order to connect with the remote server such that they may undertake a transaction or otherwise benefit from its functionality without physical access to the consumer device, knowledge or authorization of its owner.

2. The HCE application on the consumer device may be compromised by another application on the device such that an attacker may extract information from the application. This information may then be communicated using the devices connectivity in order for the attacker to undertake a transaction or otherwise perform the application's function remotely from the original consumer's device without the knowledge or authorization of its owner. This type of attack can sometimes be undertaken on a vast scale with many devices

compromised without the knowledge of their owners. These devices are then ready to provide the attacker with the details they seek when required.

The secure element provides the security required by many applications, however is difficult to provision using "over-the-air" (OTA) or wireless communications. HCE applications are anticipated to be easier to deploy, however are recognized as less secure (insecure) than an SE based solution.

Summary

According to an aspect there is provided a computer-implemented method of authenticating communication between a device and an entity, the device having an identity application residing on a secure element and a received application residing on an application processor, the method comprising the steps of: providing at least one cryptographic key to the identity application;

receiving encrypted data from a server;

authenticating communication between the device and the server by unencrypting the encrypted data using the at least one cryptographic key; receiving, at the identity application, one or more security tokens from the server;

providing, to the received application, at least one of the one or more security tokens; and

communicating, via the received application, with an entity based on receiving at least one of the one or more security tokens at the received application.

Optionally, the method further comprises providing the received application to the application processor of the device. Optionally, the method further comprises the step of identifying, when the received application is received on the application processor of the device, that the identity application resides on the device.

Optionally, the method wherein the at least one of the one or more security tokens is only provided to the received application upon receiving confirmation from a user of the device.

Optionally, the method further comprises providing a notification to a user of the device when the at least one of the one or more security tokens is provided to the received application. Optionally, the method wherein the step of authenticating communication further comprises receiving a user authorisation input.

Optionally, the method wherein the server is a remote server or a cloud-based server.

Optionally, the method wherein the encrypted data received from the server is an encrypted public key certificate, and the step of unencrypting the encrypted data comprises unencrypting the encrypted public key certificate.

Optionally, the method further comprises identifying, by the identity application, a public key associated with the encrypted public key certificate corresponding to a cryptographic key provided to the identity application, and determining that the encrypted public key certificate is valid.

Optionally, the method further comprises identifying a level of confidence associated with the device based on external information.

Optionally, the method wherein the secure element comprises a secure application processor.

Optionally, the method wherein the secure element resides in a trusted execution environment. Optionally, the method wherein the secure element resides in a subscriber identity module (SIM) or a universal integrated circuit card (UICC). Optionally, the method wherein the received application is a host card emulation application.

According to a second aspect there is provided a computer readable medium comprising instructions that, when executed on a processor, cause the processor to carry out any of the above methods.

According to a third aspect there is provided a device for authenticating communication with an entity, the device comprising a secure element having an identity application residing thereon, wherein the identity application is arranged to:

receive at least one cryptographic key;

receive encrypted data from a server;

authenticate communication between the device and the server by

unencrypting the encrypted data using the at least one cryptographic key; receive one or more security tokens from the server; and

provide at least one of the one or more security tokens to a received application residing on an application processor of the device, thereby permitting secure communication between the received application and the entity.

Optionally, the device is arranged to receive the received application and, when the received application is received, identify whether the identity application resides on the device.

Optionally, wherein the device is arranged to receive the at least one of the one or more security tokens upon receiving confirmation from a user of the device. Optionally, wherein the device is arranged to provide a notification to a user of the device when the at least one of the one or more security tokens is provided to the received application.

Optionally, wherein the identity application is further arranged to, at the step of authenticating communication, receive a user authorisation input.

Optionally, wherein the server is a cloud-based server.

Optionally, wherein the encrypted data received from the server is an encrypted public key certificate, and the step of unencrypting the encrypted data comprises unencrypting the encrypted public key certificate. Optionally, wherein the identity application is further arranged to identify a public key associated with the encrypted public key certificate corresponding to a cryptographic key received by the identity application, and determine that the encrypted public key certificate is valid. Optionally, wherein the identity application is further arranged to identify a level of confidence associated with the device based on external information.

Optionally, wherein the secure element comprises a secure application processor.

Optionally, wherein the secure element resides in a trusted execution environment. Optionally, wherein the secure element resides in a subscriber identity module (SIM) or a universal integrated circuit card (UICC).

Optionally, wherein the received application is a host card emulation application.

Brief Description of the Drawings

Embodiments will now be described, by way of example only, and with reference to the drawings in which:

Figure 1 illustrates consumer devices with and without a secure application processor;

Figure la illustrates the functionality and components that represent the application processor shown in figure 1;

Figure lb illustrates the functionality and components that represent the secure application processor shown in figure 1;

Figure lc illustrates the steps required to configure or load an application to a secure element;

Figure 2 illustrates the architecture of a cloud based secure element solution to support mobile payments;

Figure 3 illustrates the architecture of an embodiment.

Figure 4 illustrates the process of using an identity application to support authentication between an HCE application and a cloud based Secure element server.

In the figures, like elements are indicated by like reference numerals throughout. Overview Methods, apparatus and systems for improving the security of a host card emulation (HCE) application onto a consumer device are provided. An embodiment allows the secure configuration of a secure element (or other secure environment such as TEE) within a mobile device (which may be NFC enabled) during manufacture (or before the final owner of the device is known) to subsequently secure communication between a HCE mobile payment application downloaded to the device and a remote security server or cloud based secure element. This allows the technically challenging and difficult Secure Element provisioning to be separated from the easier and less technically complex mobile application deployment.

A combination of a secure element providing security and a non-secure host card emulation application is therefore proposed by separating the provisioning of the secure element and deployment of the actual application implementing the functionality. This simplifies and enables the mass deployment of applications to consumer devices such as NFC enabled mobile phones while maintaining the security required by many application providers. Instead of a secure element (SE), other secure environments may alternatively be utilized to support the provisioning of the secure element and deployment of the actual application implementing the required functionality, for example a Trusted Execution Environment (TEE) or other security environment within the device (SIM or U ICC). The principles and issues outlined above for enabling NFC payments on a mobile phone are also experienced when deploying other applications such as payment acceptance, identity, loyalty, transit and access control. Such principles and issues are also experienced when deploying to other consumer devices, such as PDA's, tablet computers, laptop computers, desktop computers, and smart watches and other wearable devices, whether to support NFC based applications or applications using other communication methods (e.g. remote payments via the internet) where security is required. Those skilled in the art will therefore realize that the systems and methods described herein may be utilized on those platforms too beyond the exemplary embodiments described herein.

Detailed Description

A number of terms and references are used in the following description and are defined below to assist understanding:

"PayPass", "payWave" and "ExpressPay" are used to refer to a contactless payment method promoted by MasterCard, Visa and American Express respectively. Those skilled in the art will appreciate that other contactless payment schemes also exist which may utilize the systems and methods described herein.

NFC (Near Field Communication) is a communication method defined by international standards ISO/IEC 21481 and ISO/IEC 18092 that also references and consumes Proximity contactless standard ISO/IEC 14443 and contact smart card standard ISO/IEC 7816. "Access Control Application" is used to reference an application that has the primary purpose of enabling physical access to the legitimate holder of the device. This may be a campus, building, or area within a campus or building. "Transit Application" is used to reference an application that has the primary purpose to allow the legitimate holder of the device to travel from one location to another, typically via a public transport network such as train, subway, bus, tram, ferry or in some cases taxi. "Identity Application" is used to reference an application that has the primary purpose to confirm the identity of the legitimate holder of the device. This may be used to support another application, enforce logical security (e.g. computer login) or to provide an electronic signature that is legally binding. "Payment Acceptance Application" is used to reference an application running on a mobile phone or other suitable device that is designed to accept payments from a payment card or other payment device.

"Secure Element" (SE) is used to define security functionality of a device compliant to Global Platform Card Specifications. However for the purpose of this specification, it may also refer to a secure environment or functionality within or directly accessible to the consumer device. This may include technologies such as Trusted Execution Environment (TEE). Figure 1 shows a consumer device 101 (a device used by a consumer, which may or may not be owned by that consumer) which is required to support an application requiring a level of security or confidentiality above what can be achieved by running that application solely on the device's own application processor (102). The application processor (102) typically comprises one or more of the functionality and components as shown in figure la including circuits to execute a program (110) such as one or more processors or other processing device(s), persistent memory (111) for the storage of that application and any persistent data, non-persistent memory (112) for the temporary storage of data while the application is executing, typically it may also have connection to a display (114), user input device (115) such as a function buttons, a keyboard or touch sensitive device, communication functionality (113) for connection to other devices or the internet and other functionality (116) that may include but is not limited to a speaker, finger print reader, external memory card interface, camera etc. This application processor is typically designed to be general purpose, and may be used to run the device's operating system, applications provided to enable core functionality of the device (for example, a mobile phone is required to make phone calls, send messages, and access the internet) and any applications selected by the consumer to provide functionality such as additional communication functionality, business applications, games, utilities etc. These consumer selected applications are typically loaded onto the device by one of the following methods: direct download for internet, CD, memory stick or transfer via a local connection such as USB, Bluetooth or Wi-Fi from another device.

Applications executed on the device's own application processor (102) typically are not considered secure as many methods are known by those skilled in the art to compromise or otherwise access data stored or used by these applications. As such they cannot reliably be used to maintain a secret such as a cryptographic key, confidential information or business process. However these applications are typically very easy to load onto the device and only limited skill is required by the consumer to add further applications or delete existing applications. In the case of a mobile phone or tablet device, an application can be downloaded for an application store such as Google's play store, Apple's iTunes store, or from other services that exist in the market to offer applications for download to compatible devices.

Applications that require security or confidentially due to the need to store cryptographic keys, other confidential information, or are required to protect business processes used to conduct their function typically cannot be loaded, stored or executed exclusively on this general purpose application processor (102). Due to these requirements they also cannot typically be distributed via such application stores.

In a consumer device (101) designed to support secure application processing, typically there will be a secure application processor (103) such as a secure element or other secure environment such as the Trusted Execution Environment (TEE). In the case of a secure element, the secure application processor (103) which may comprise one or more of functionality and components as shown in figure lb which may include circuits to securely execute a program (120), secure persistent memory (121) for the storage of that application and any persistent data, secure non-persistent memory (122) for the temporary storage of data while the application is executing, and optionally a cryptographic processor (123) and NFC interface (124). In the case of a trusted execution environment (TEE) connectivity to user input (115) and display (114) as shown in figure la may also be implemented.

An application requiring security or confidentially will be securely loaded from a trusted source into the secure application processor (103), a typical process is shown in figure lc, for the case of a secure element the process is fully defined in the Global Platform card specification and associated amendments. After establishing communication between the secure element and application provider (130) which may involve the owner of the secure application processor (the secure element issuer trusted service manager - SEI TSM), a mutually authenticated session (131) between the application provider and the secure application processor will be established before any program or data transfer, or any modification to the configuration of the secure application processor is allowed (132). Any program / data transfer, or configuration commands sent to the secure application processor will typically be signed and encrypted to prevent any modification during this stage of the process. Once the program is loaded, updated or otherwise configured, the mutually authenticated session is closed (133) to prevent any further commands being sent.

The process to load or manage an application within a secure application processor has proven sufficiently difficult to undertake that currently there have not been significant deployments of secure applications using this functionality. This is because the application typically cannot be deployed to the consumer device until the consumer has (1) received the device, (2) has requested the application, and (3) has completed application provider security checks. There are also commercial issues with the ownership, and technical issues with compatibility and interoperability of the various components and processes required.

Once a device has been delivered to the consumer, its exact state is no longer typically under the control of the original manufacturer, or in the case of a mobile phone for example, the Mobile Network Operator. It is recognized by those skilled in the art that to achieve greater deployment of secure applications then either the process must be simplified, or undertaken at a point in the lifecycle of the device where the application provider has more control and better access to the device.

The following describes how the above is currently used to support the deployment of a payment application compatible with the merchant payment infrastructure as defined for "PayPass", "payWave" or "ExpressPay" to an NFC enabled mobile phone utilizing a secure element.

Mobile payment applications such as "PayPass", "payWave" or "ExpressPay" require the storage of secret keys (issuer keys), other confidential information, and the protection of business processes used to conduct a payment transaction. Due to these requirements they cannot typically be distributed via such application stores as described earlier, or stored / executed on application processor (102).

The mobile phone is manufactured with either an embedded secure element or for the secure element to be included within the network operators universal integrated circuit card (UICC). The mobile phone is then sold or otherwise distributed to a consumer via the mobile industries sales and distribution network. This may involve the consumer obtaining their mobile phone directly from a physical mobile phone merchant (bricks and mortar store) or having the mobile phone delivered to them when purchased from an internet based mobile phone merchant. The mobile phone merchant may be an independent retailer, a retailer tied to or owned by the mobile phone manufacturer or Mobile Network Operator (MNO). Regardless of how the consumer obtains the phone, typically at no point in the supply chain does the party manufacturing or distributing the mobile phone know which consumer will finally use the device until the point of dispatch. Typically however even at this point, very little information will be known about the final intended user of the mobile phone. For security and logistical reasons, it is therefore typically impossible to load or configure any of the consumer's financial accounts (mobile payment applications) onto the secure element within the phone before it is dispatched to the end user. The consumer should they wish to configure or load a mobile payment application onto their phone after they receive the device will typically need to contact their financial account provider (Card Issuer) to arrange for the secure element to be set up, a user interface to be downloaded and any configuration of the mobile phone undertaken. The Card Issuer will typically engage a Trusted Service Manager (TSM) to undertake this task. This will involve identifying the current mobile phone's configuration, the type of secure element and who undertakes the role of Trusted Service Manager for the Secure Element Issuer (SEI-TSM). Once this has been established, if the necessary technical and commercial relationships are in place, the mobile phone and secure element are compatible, and communication to the phone can be established, the Card Issuer may attempt to provision their mobile payment application to the consumer's mobile phone.

Due to this complexity, there has not been widespread deployment of secure applications such as mobile payments in the market. Non-secure applications (such as business applications, games and utilities), i.e. applications not requiring execution within the secure element, however are currently being deployed in massive numbers as they are not constrained by this complexity. Secure application owners therefore seek to simplify the deployment of their applications and look at the processes currently used for non-secure applications as a potential option. However as this does not offer the security secure application owners require, the security and confidentiality required must be achieved using other methods.

Host Card Emulation (HCE) was introduced by Google into the Android operating system in Version 4.4 (Kit Kat) and has been, or will be introduced into other operating systems from Microsoft, Black Berry and Nokia and other device or operating system suppliers. This functionality allows an application being executed on the application processor within the device to access the Near Field Communication (NFC) interface (124, figure lb) as part of the communication circuitry (113, figure la) for the purpose of interacting with an NFC (or ISO/IEC 14443 RFID or contactless) reader. This allows functionality that was previously only accessible to applications being executed on the secure element (secure application processor 103) to be run on the general purpose application processor (102).

Those skilled in the art will know that there are many ways to offer and deliver applications and functionality to a consumer device. In the case of a mobile phone or tablet device, an application can be downloaded from an application store such as Google's play store, Apple's iTunes store, or from other services that exist in the market to offer applications for download to compatible devices. Hosting an application on the application processor allows for the rapid and widespread post issuance deployment of an application with minimal effort or cost. However as previously stated, the application processor does not offer the same level of security or confidentially as a secure application processor such as a secure element. In the example of a mobile payment application running on an NFC enabled mobile handset; the financial industry is developing a new mobile application for use on the non-secure application processor. A different application to that used on a secure application processor (103) such as a secure element is required to address the fact that the security and confidentially of issuer keys and transaction processes cannot be maintained within the less secure environment. Those skilled in the art will know that a number of companies including MasterCard, Visa, Bell ID, Inside Secure and SimplyTapp have developed or are developing solutions termed Remote Secure Element or NFC secure element in the cloud. These solutions splits mobile payment application as previously designed for use on a secure application processor (103) into two components, part of the application is run on a secure server; part of the application is run within the mobile device on the application processor (102).

Figure 2 shows an example of how such a cloud based solution may operate without the need for a secure element within a consumer device (104) of figure 1. The party enabling the cloud based service (200) uploads (204) the consumer device portion of the application to an appropriate application store (201) or hosts the download of the application on their own application store. The consumer signs up to the service and downloads (206) the application from the application store onto their mobile device (may also download (206) application and then sign up for the service). To make a payment transaction, the application on the consumer's device (104) authenticates (205) to the cloud based secure element provider (200) and receives one or more transaction tokens (205). The consumer device can then undertake a transaction depending on the capabilities of the payment application with merchant payment infrastructure, for example compliant with "PayPass", "payWave" or "ExpressPay" specifications. Depending on the configuration of solution, this transaction is then either routed (209) to the financial account issuer (203) for processing, or via (208) the cloud based secure element processor (200) for pre-processing (validation of cryptographic elements) before being forwarded (210) to the financial account issuer (203) for processing.

The key design elements of this solution are (1) the application on the handset does not hold issuer keys, (2) the application on the handset is only provided with one (or limited number) of single use tokens based on an authentication between the handset and cloud based secure element provider (200). For online transactions where the handset has access to the cloud based secure element provider (200) to obtain transaction security tokens, this solution potentially can work well. However the weakness of the solution is in the authentication with the cloud based secure element provider to obtain the one time transaction tokens (205), if an attacker can access the information stored in the payment application stored on the handset and authenticate to the cloud based secure element provider (205) they can undertake transactions without the knowledge or permission of the genuine financial account holder. Furthermore, because it could be possible to copy security tokens received, only online authenticated transactions can be undertaken. Offline transactions are not possible because from a single one time token, multiple transactions could be undertaken without initial detection. For the above reasons many of those skilled in the art consider an application running within an application processor (102) supported by a cloud based secure element to be significantly less secure than transactions performed from a secure application processor (103) such as a secure element. Therefore existing solutions requiring security are either difficult to deploy as they require OTA deployment of the application to a secure application processor, or have limitations and potentially lower security when utilizing a Host Card Emulation (HCE) application and remote security server or cloud based secure element. Hence a method of addressing two of the security weaknesses identified by those skilled in the art with the Host Card Emulation (HCE) application approach while maintaining its deployment advantages is provided.

This is achieved by decoupling the download of the HCE based application (for example a Payment, Identification (ID), Loyalty, Ticketing or Transit

application) to the application processor (102) that provides the non-secure functionality, and the method used to authenticate and secure

communication between that application and the remote security server or cloud based secure element. On the consumer device within the secure element, UICC or TEE environment, an identity application, independent and separate from the HCE application, is provisioned. This identity application holds or otherwise maintains one or more cryptographic keys in order to authenticate to a remote third party. The primary function of the identity application is to provide a unique and secure identity which can be

cryptographically confirmed during authentication. This functionality is not initially associated with the physical identity of the owner of the consumer device, or HCE applications on the device that may wish to utilize its functionality. In many embodiments the identity application contains no functionality associated with those applications. Given the separation of functionality between the identity application and any HCE based application that may utilize the identity application, and given that the identity application is not initially associated with the physical identity of the owner of the consumer device, the identity application may be loaded during the manufacture of the consumer device, or at a point when it is most convenient to do so. This allows the identity application to be pre-loaded, and one or many HCE based applications to subsequently share its functionality.

Many types of identity application already exist in the market based on symmetric and asymmetric cryptography as those skilled in the art will recognize. The exact method used may therefore vary between

implementations, however a certificate based solution using asymmetric cryptography provides many advantages.

A consumer device manufacture such as Apple, Blackberry, Microsoft, Nokia or Samsung, or Secure Element or UICC provider such as Broadcom, Gemalto, Infineon, NXP or Oberthur, may standardize the inclusion of an identity application on all devices they produce. HCE application providers may then use the identity application (potentially under a commercial agreement) to authenticate and secure communication between the consumer device and any remote security server or cloud based secure element.

In some embodiments, the party providing the identity application or a third party provider may provide additional services to the remote security server, cloud based secure element provider, or the HCE application owner. These may include but shall not be limited to: Providing a certificate signing service such that the remote security server or cloud based secure element provider can have their own public key certificate signed using a private key that the identity application knows the corresponding public key for and can therefore verify. This then allows mutual authentication to be undertaken between the remote security server or cloud based secure element and the identity application on the consumer device during initial setup and subsequent communication.

A service may also offer to assist in the IDentification and Verification (ID&V) process. The service provider collects information about the user of the consumer device and compares the collected information against details of the consumer provided when signing up for a new service. This allows the service provider to provide a confidence score that can be provided to the remote security server or cloud based secure provider to be used as one of the factors in determining the risk of allowing that consumer device to access the service requested. When such a service is provided in partnership with the entity providing the physical device to the consumer, or in the case of a mobile phone the mobile network operator, this can help address fraudulent applications even on a newly issued device. It can also help simplify the signup process for the consumer as, through careful risk based validation methods, what may be seen by some consumers as onerous proof that they are who they claim to be may not be required in many cases.

The identity application may additionally provide functionality to act as a proxy to the remote security server or cloud based secure element. Security tokens received from the remote security server or cloud based secure element may be stored by the identity application until the host card emulation (HCE) application actually needs them to carry out a transaction or otherwise undertake their intended function. User confirmation may be required before release of a token (or access to the identity application is allowed), which helps prevent tokens held on the consumer device being collected by an attacker without knowledge of the consumer.

Figure 3 shows a consumer device (307) configured according to an embodiment. One or more end user applications utilizing Host Card Emulation provided by application providers is hosted and executed on the application processor within the device. These applications may be distributed using application stores (201) such as Google's play store, Apple's iTunes store, or from other services that exist in the market to offer applications for download to compatible devices. These applications may utilize an identity application (302) implemented within a secure application processor on the consumer device. (307). This identity application (302) is created by the Identity application provider (305) who provides it to the consumer device manufacturer or distributor (304) to load the identity application (302) into the secure application processor on the consumer device (307) before delivery of the consumer device (307) to the consumer (301).

When an HCE application is first downloaded to the consumer device, it will check for the presence of the identity application (302) on the consumer device (307). If the identity application (302) is present, when registering with the cloud based secure element provider (308) and if the cloud based secure element provider (308) has an agreement with the identity application provider (305), the identity application provider (305) may offer a service to sign a public key certificate (306) of the cloud based secure element provider (308), using a private cryptographic key, such that the identity application (302) can verify the public key certificate (306). The identity application (305) contains information regarding which public key corresponds to which private cryptographic key contained in the identity application (305), and is therefore able to verify the public key certificate (306) by determining whether the public key corresponds to a private cryptographic key. The use of public key cryptography will allow reasonable authentication that the identity application (302) within the consumer device (307) is legitimate, and that an attacker is not spoofing the identity application (302). This process however will not confirm the actual identity of the consumer device directly; it will only provide an identity that in subsequent communications can be cryptographically checked by the remote security server or cloud based secure element (308) to confirm it is communicating with the same identity application (302) as presented during the initial setup. The asymmetric or public key cryptography may be based on RSA or ECC keys depending on the implementation and the cryptographic methods supported by the identity application (302). If the cloud based secure element provider (308) does not have a signed public key certificate that the identity application (302) can verify, then the identity application (302) cannot confirm that the cloud based secure element provider (308) is operating with approval of the identity application provider (305). In some implementations this may be considered acceptable, however it will mean than any remote entity could use the functionality of the identity application (302) without approval of the identity application provider (305). If the identity application provider (305) is offering a commercial service, this could limit the identity application provider's (305) ability to generate revenue from that service. Once the cloud based secure element provider (308) and the identity application (302) have exchanged certificates, the identity application (302) can unwrap one or more public keys and determine whether the certificate is valid. This is typically confirmed by checking the format of the unwrapped portion of the certificate that was encrypted using the secret private key that was unencrypted using the published public key. As this information is static, i.e. the content of the public key certificates does not change between each exchange, the recovered public key is now used by the cloud based secure element provider (308) to encrypt a challenge, which is typically data containing as a minimum a random number, which is then sent to the identity application (302). The identity application (302) then unencrypts that challenge using its secret private key and re-encrypts it using the public key it received in the public key certificate exchange. The re-encrypted challenge is then sent back to the cloud based secure element provider (308) who uses their own secret private key to confirm that the information received contains the original challenge. If confirmed then it proves that the identity application (302) contains the secret private key for the certificate provided by the cloud based secure element provider (308). There are many ways to undertake mutual authentication, the method described here is just one method. Those skilled in the art may substitute of methods which may provide both authentication and generation of one or more session keys to allow further communication to be encrypted. During the initial registration of the HCE application with the cloud based secure element provider (308), the cloud based secure element provider (308) will store the details provided by the identity application (302). In subsequent communication between the HCE application and the cloud based secure element provider (308), the details originally provided by the identity application (302) will be checked to confirm the same identity application (302) is present. The HCE application and the cloud based secure element provider (308) will then conduct a mutual authentication, as described above for example, to confirm that the identity application (302) is truly present and contains the appropriate secret private key. Once this authentication stage is completed, normal communication between the HCE application and the cloud based secure element provider (308) may proceed, and the HCE application may fetch a onetime security token (300). This token is then used by the HCE application to undertake a transaction (or other functionality) with a Payment or service acquirer.

In order to further enhance the security of the HCE application, the identity application (302) may be enhanced to provide a secure encrypted channel between itself and the cloud based secure element provider (308). During mutual authentication, session keys will be derived which can be used to prevent any attacker gaining access to the data being communicated between the HCE application and the cloud based secure element provider (308). In some embodiments, when the identity application is implemented with the direct intention of supporting one or more applications conforming to a known specification, functionality may be included to enhance the security and operation of those applications. Such applications may be using specifications from Payment industries (The specification body set up by EuroPay MasterCard and Visa, EMVCo), ID (International Civil Aviation Organization, ICAO), Ticketing (Integrated Transport Smartcard Organization ltd, ITSO) for example. The identity application may be specifically designed to support one or more of these applications, or be configurable post issuance as described from page 18 line 20 to page 25 line 10, and figures 3, 3a and 4, of patent application number GB1409277.9 with reference to a "security application". In the case of the exemplary embodiment such as supporting a payment application, the identity application (302) may store all onetime security tokens (300) received from the cloud based secure element provider (308) and only release them to the HCE application immediately before use. The identity application (302) when releasing a token may seek formal consumer approval (simple acknowledgement or entry of a PIN to confirm) or just ensure that the consumer is aware that a token has been released via a notification or other means. The compromise of the HCE payment application by an attacker will not circumvent such a process, thereby preventing an attacker gaining access to large numbers of tokens with the consumer's knowledge. Figure 4 shows the process of the utilizing the solution according to an embodiment. The consumer device (307) may be configured as shown in figure 3 with one or many HCE applications hosted and executed on the application processor (102) as shown in figure 1, and an identity application (302) as shown in figure 3, hosted and executed on the secure application processor (103) as shown in figure 1. The identity application (302) as shown in figure 3 will have been loaded and configured (401) by the consumer device manufacturer or distributor (400) as defined and provided by the identity application provider (407) before the end user (consumer) obtains the device (402). The consumer may then access an application store (403) to download the HCE application they require. This application will have previously been uploaded by the HCE application service provider (408) to the application store (403). Once the application has been downloaded, it will communicate (404) with the cloud based Secure Element Server to register with the service and complete any identification and verification processes required before being configured with the consumer's unique details to allow it to operate. This may involve the download of data from the cloud based Secure Element Server, and registration of the devices identity as provided by the identity application (405).

The cloud based Secure Element Server preferably has an arrangement with the identity application provider to gain access to the identity application and perform mutual authentication with that application on the consumer device. In order to then undertake transactions or otherwise use the functionality provided by the HCE application, the application will need to communicate with the cloud based Secure Element Server to obtain a single or limited use token. The authentication between the HCE application and the cloud based Secure Element Server will be undertaken (406) by the identity application using the identity originally exchanged during the initial registration (404).

In the exemplary embodiment of a mobile payment application running on an NFC enabled mobile handset; typically operation will involve the application being used to undertake a payment at a merchant store or via an internet connection to a merchant online store. The phone is presented to a terminal (or communicates with a merchant's virtual terminal) and performs a payment transaction in accordance with application specifications such as "PayPass", "payWave" or "ExpressPay". This transaction is then routed, depending on the commercial agreements in place, to either the application service provider for authorization, or via the security application provider for cryptographic validation before being forwarded to the application service provider for confirmation that the funds are available. Also disclosed herein:

1. The use of an identity application to authenticate and secure communication between an HCE application on a consumer device and a remote security server or cloud based secure provider.

a. optionally said application may hold one or many security keys for the purpose of authentication and confidentially b. optionally said identity application may be provisioned into a secure environment such as a secure element on the consumer device in advance of that device being delivered to the consumer.

c. optionally said identity application may be shared by many HCE applications on the consumer device.

2. Using the functionality of point 1, the identity application may optionally be integrated into the base functionality of the consumer device to prompt the consumer whenever its functionality is utilised.

3. Using the functionality of point 1, the identity application may optionally securely store any security tokens received from a remote security server or cloud based secure provider in advance of them being used by a HCE application to undertake a transaction of otherwise perform its intended functionality.

4. In addition to the identity application, a service is optionally offered to remote security server or cloud based secure providers to create public key certificates that may be cryptographically authenticated by the identity application to allow mutual authentication to be undertaken. 5. In addition to the identity application, a service is optionally offered to remote security server or cloud based secure provider to identify the level of confidence the identity of the owner of the consumer device in which the identity application resides based on past usage and information collected from other parties involved with the supply of the consumer device and services it supports.

6. The same principles described above may optionally utilise a Trusted

Execution Environment (TEE) instead of a secure element.

7. The same principles described above may optionally utilise the security afforded by a subscriber identity module (SIM) or UICC.

8. The same principles described above may be utilised by using the identity functionality within the secure processor to secure other applications not employing Host Card functionality. This can provide a mobile application with a reliable identity.

The various methods described above may be implemented by a computer program. The computer program may include computer code arranged to instruct one or more processors to perform the functions of one or more of the various methods described above. The computer program and/or the code for performing such methods may be provided to an apparatus, such as a processor, FPGA or other processing device on a computer readable medium or computer program product. The computer readable medium could be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, or a propagation medium for data transmission, for example for downloading the code over the Internet. Alternatively, the computer readable medium could take the form of a physical computer readable medium such as semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disc, and an optical disk, such as a CD-ROM, CD-R/W or DVD. Described is a method that allows the technically challenging and difficult Secure Element (SE) provisioning to be conducted in advance of a devices (mobile handset or UlCC) delivery to the consumer. This allows this process to be undertaken in a secure or otherwise more optimal environment than conducting this operation Over The Air' (OTA). Once the device is then in the possession of the consumer, applications for execution on the device itself using Host Card Emulation (HCE), for which those skilled in the art will be aware that many methods exist, may be freely downloaded as required to deliver the functionality or services. These applications can then utilize the previously deployed functionality within the secure element to secure their operation.

Claims

A computer-implemented method of authenticating communication between a device and an entity, the device having an identity application residing on a secure element and a received application residing on an application processor, the method comprising the steps of:

providing at least one cryptographic key to the identity application;

receiving encrypted data from a server;

authenticating communication between the device and the server by unencrypting the encrypted data using the at least one cryptographic key;

receiving, at the identity application, one or more security tokens from the server;

The method of either of claims 1 or 2 further comprising providing the received application to the application processor of the device.

The method of claim 2 further comprising the step of identifying, when the received application is received on the application processor of the device, that the identity application resides on the device. The method of any preceding claim wherein the at least one of the one or more security tokens is only provided to the received application upon receiving confirmation from a user of the device.

The method of any preceding claim further comprising providing a notification to a user of the device when the at least one of the one or more security tokens is provided to the received application.

The method of any preceding claim wherein the step of authenticating communication further comprises receiving a user authorisation input.

The method of any preceding claim wherein the server is a remote server or a cloud-based server.

The method of any preceding claim wherein the encrypted data received from the server is an encrypted public key certificate, and the step of unencrypting the encrypted data comprises unencrypting the encrypted public key certificate.

The method of claim 8 further comprising identifying, by the identity application, a public key associated with the encrypted public key certificate corresponding to a cryptographic key provided to the identity application, and determining that the encrypted public key certificate is valid.

10. The method of any preceding claim further comprising identifying a level of confidence associated with the device based on external information.

11. The method of any preceding claim wherein the secure element comprises a secure application processor.

12. The method of any preceding claim wherein the secure element resides in a trusted execution environment.

13. The method of any preceding claim wherein the secure element resides in a subscriber identity module (SIM) or a universal integrated circuit card (UICC). 14. The method of any preceding claim wherein the received application is a host card emulation application.

15. A computer readable medium comprising instructions that, when executed on a processor, cause the processor to carry out the method of any of claims 1 to 14.

16. A device for authenticating communication with an entity, the device comprising a secure element having an identity application residing thereon, wherein the identity application is arranged to:

receive at least one cryptographic key;

receive encrypted data from a server; authenticate communication between the device and the server by unencrypting the encrypted data using the at least one cryptographic key;

receive one or more security tokens from the server; and provide at least one of the one or more security tokens to a received application residing on an application processor of the device, thereby permitting secure communication between the received application and the entity.

17. The device of claim 16 wherein the device is arranged to receive the received application and, when the received application is received, identify whether the identity application resides on the device.

18. The device of claim 16 or claim 17 wherein the device is arranged to receive the at least one of the one or more security tokens upon receiving confirmation from a user of the device.

19. The device of any of claims 16-18 wherein the device is arranged to provide a notification to a user of the device when the at least one of the one or more security tokens is provided to the received application.

20. The device of any of claims 16-19 wherein the identity application is further arranged to, at the step of authenticating communication, receive a user authorisation input.

21. The device of any of claims 16-20 wherein the server is a cloud-based server.

22. The device of any of claims 16-21 wherein the encrypted data received from the server is an encrypted public key certificate, and the step of unencrypting the encrypted data comprises unencrypting the encrypted public key certificate.

23. The device of claim 22 wherein the identity application is further

arranged to identify a public key associated with the encrypted public key certificate corresponding to a cryptographic key received by the identity application, and determine that the encrypted public key certificate is valid.

24. The device of any of claims 16-23 wherein the identity application is further arranged to identify a level of confidence associated with the device based on external information.

25. The device of any of claims 16-24 wherein the secure element

comprises a secure application processor.

26. The device of any of claims 16-25 wherein the secure element resides in a trusted execution environment.

27. The device of any of claims 16-26 wherein the secure element resides in a subscriber identity module (SIM) or a universal integrated circuit card (UICC).

28. The device of any of claims 16-27 wherein the received application is a host card emulation application.

29. A method substantially as herein described with reference to and illustrated in any combination of the accompanying drawings.

30. An apparatus substantially as herein described with reference to and illustrated in any combination of the accompanying drawings.