WO2015177574A1 - Provisioning of secure host card emulation - Google Patents

Provisioning of secure host card emulation Download PDF

Info

Publication number
WO2015177574A1
WO2015177574A1 PCT/GB2015/051523 GB2015051523W WO2015177574A1 WO 2015177574 A1 WO2015177574 A1 WO 2015177574A1 GB 2015051523 W GB2015051523 W GB 2015051523W WO 2015177574 A1 WO2015177574 A1 WO 2015177574A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
secure
security
security application
processor
Prior art date
Application number
PCT/GB2015/051523
Other languages
French (fr)
Inventor
Theresa L. Smith
Colin Tanner
Original Assignee
Smith Theresa L
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Smith Theresa L filed Critical Smith Theresa L
Publication of WO2015177574A1 publication Critical patent/WO2015177574A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3226Use of secure elements separate from M-devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326Payment applications installed on the mobile devices

Definitions

  • HCE secure host card emulation
  • TEE trusted execution environment
  • NFC Near Field Communication
  • SE specialist secure element
  • eSE embedded secure element
  • TEE Trusted Execution Environment
  • the secure element provides the security required by many applications, however is difficult to provision OTA. HCE applications are anticipated to be easier to deploy, however are recognized as less secure (insecure) than an SE based solution. Summary
  • a method as defined in Claim 1 of the appended claims comprising the steps of providing at least one cryptographic key to the security application, providing at least one secure process to the security application, executing the at least one secure process based on the at least one cryptographic key.
  • the method further comprises providing an application layer process in the security application to allow an additional cryptographic key to be downloaded to the security application.
  • the method further comprises providing an application layer process in the security application to allow an additional secure process to be downloaded to the security application.
  • the method further comprises providing an application layer process in the security application to allow downloading of data to a secure data store of the security application.
  • the method wherein the application layer process is controlled by the provider of the security application.
  • the method wherein the provider of the security application was not the provider of the secure application processor.
  • the method wherein the cryptographic keys are arranged in key sets.
  • each key set is assigned an identifier.
  • a secure process is arranged to use a cryptographic key based on the identifier.
  • each identifier comprises a generic identifier and a unique identifier.
  • a secure process is arranged to use a cryptographic key based on either the generic identifier or the unique identifier.
  • a secure process is arranged to define which cryptographic key is usable with the secure process.
  • a secure process defines at least one input parameter, a calculation to be performed, and an output format.
  • a secure process defines security checks to be performed by a calling application.
  • a non-secure application is arranged to undertake a secure transaction by authenticating with the secure process of the security application.
  • the method wherein the authenticating with the secure process of the security application comprises authenticating with a cryptographic key that has been downloaded to a secure key store of the security application under control of the provider of the non-secure application.
  • the method wherein the secure application processor resides in a trusted execution environment.
  • the method wherein the secure application processor resides in a secure element of a device.
  • the method wherein the non-secure application resides in a nonsecure application processor.
  • the method wherein the secure application processor resides on a mobile device.
  • an apparatus arranged as defined in claim 21.
  • the apparatus comprises a security application residing on a secure application processor.
  • the apparatus comprises a mobile device.
  • 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 an embodiment on a consumer device with a secure element
  • Figure 3a illustrates a process for loading and configuring an application
  • Figure 4 illustrates the architecture of an embodiment.
  • HCE secure host card emulation
  • 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.
  • SE secure element
  • 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).
  • TEE Trusted Execution Environment
  • NFC Near Field Communication
  • 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.
  • Transport 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
  • SE Secure Element
  • SE Secure Element
  • TEE Trusted Execution Environment
  • 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.
  • 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
  • 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.
  • Apps 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.
  • 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.
  • a secure application processor (103) such as a secure element or other secure environment such as the Trusted Execution Environment (TEE).
  • TEE Trusted Execution Environment
  • 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).
  • 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.
  • 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.
  • the mutually authenticated session is closed (133) to prevent any further commands being sent.
  • 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).
  • UICC network operators universal integrated circuit card
  • 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.
  • MNO Mobile Network Operator
  • Host Card Emulation 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.
  • NFC Near Field Communication
  • secure application processor 103 Secure element
  • 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.
  • 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.
  • Hosting an application on the application processor allows for the rapid and widespread post issuance deployment of an application with minimal effort or cost.
  • the application processor does not offer the same level of security or confidentially as a secure application processor such as a secure element.
  • 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).
  • 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.
  • 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).
  • application functionality is included within the portion hosted and executed on the application processor (102) within the consumer device.
  • all functionality not deemed security relevant, i.e. the majority of the application is included. This allows for the easy deployment of the application, and replacement or update as required.
  • this portion can only offer very limited security and confidentiality. Those components of the overall application requiring greater security or confidentiality such as cryptographic keys, confidential data or protected processes should be hosted within the secure application processor (103).
  • Figure 3 shows a consumer device (306) configured according to an embodiment.
  • One or more end user applications (305) provided by application providers will be hosted and executed on the application processor (102) within the device. These applications may be distributed using application stores 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 (305) may utilize secure processes implemented on a security application (300) with the secure application processor (103).
  • the security application (300) may further comprise a secure key store (301), secure Data store (302), one or more protected process definitions (303) and security application processing engine (304) that can interpret the protected process definitions (303) to provide the functionality required. It is typically much harder to deploy or update an application hosted or executed on the secure application processor (103) as previously stated.
  • the security application (300) should be deployed once, ideally during the manufacture of initial setup of the device. However it should be understood that at this stage the identity of the consumer may not be known, and which applications the consumer may wish to install and use may also not be known.
  • the security application (300) deployed to the secure application processor (103) is preferably sufficiently generic that it is not necessary at the point of deployment to know this information. This is possible because for many applications, industry bodies define the functionality through the publication of specifications. Although individual organizations interpret these specifications to produce their own versions, the underlying processes are often identical.
  • the security application (300) may be configured with a number of secure processes to fulfill the requirements of many applications.
  • Cryptographic Keys however are often diversified based on data within the application provider's application (305) so it is more difficult to preload these keys. However this can be resolved by pre-loading keys defined by the security application service provider and then offering a service to validate the cryptographic elements on behalf of the application provider.
  • a service may be offered where the applications providers own application (305) can contain new keys which are encrypted for security and confidentiality and can be loaded into the security application (300) on first use.
  • Figure 3a shows an example of the process for loading and configuring an application.
  • the consumer device is first manufactured (310) with a secure application processor, or a removable secure application processor such as a UICC or micro SD device is manufactured or otherwise initially enabled.
  • the security application will be loaded and configured (311) with a range of key sets and secure process definitions to meet expected market requirements. This is performed in an environment and location compatible with the industry processes used to manufacture and configure the consumer device.
  • the device is then distributed in accordance with that industry's normal distribution processes (e.g. retail distribution) such that an individual consumer will finally receive the device for their personal use (313).
  • the consumer can then select which applications and functionality they require on the device and download the required application (314) from a suitable application store.
  • the downloaded application then contacts the consumer application provider (316) to obtain the necessary unique configuration information for that consumer (315) which may involve processes (Identification and verification ID&V) to determine if that consumer is truly the legitimate consumer who the application provider wishes to enable with the services and functionality provided by the application.
  • the security application provider (312) may provide additional secure configuration data for the security application (300) and other functionality as a service to assist the Consumer application provider (316). It will be recognized by those skilled in the art that other methods exist and this example only represents one of many processes that may be undertaken.
  • the security application (300) on the secure application processor (103) will hold cryptographic keys and the ability to undertake processes using those keys.
  • one or more sets of keys will be included within the security application (300), each with a corresponding process defined for their use.
  • the key sets will be assigned a key identifier, which may also be used to identify for which industry or type of application (for example a payment, Identification (ID), Loyalty, Ticketing or Transit) they are intended for.
  • the secure processes defined are bound or otherwise linked to one or more keysets such that keys can only be used by the intended (authorized) protected processes.
  • the key set identifiers are preferably defined such that they comprise two parts, an industry or application type (generic) identifier, and a unique key set identifier.
  • an industry or application type (generic) identifier When defining a keyset it is possible to authorize any secure process defined for that industry or application type to utilize it or only one of a more specific secure process. It is also possible for a secure process to define which keysets it may be used with using the same process. The control of this is defined by the secure application provider using rules defined by the application providers using the functionality, as such application providers do not need to understand how such association or binding is configured, only that once configured in accordance with their requirements, secure processes cannot use key sets they are not authorized to and vice versa.
  • the secure process defines the input parameters, the calculation to be performed, and the format of the final output.
  • the protected process may define security checks that must be fulfilled by the calling application to ensure only authorized applications have access to use the protected processes. These are defined using a method such as an interpreted expression language such that definitions are not permanently encoded into security application processing engine (304). It shall be possible as application layer functionality provided by the security application (103) to load or amend new secure process definitions. Typically such processes are cryptographically protected (authentication and encryption of data) to ensure that only the owner of the application or a party authorized by them can undertake such an update.
  • an application layer process is included in the security application to allow new keys to be downloaded into the existing application.
  • processes are cryptographically protected (authentication and encryption of data) to ensure that only the owner of the application or a party authorized by them can undertake such an update.
  • secure data store (302) within the security application (300) being hosted and executed within the secure application processor (103).
  • processes are cryptographically protected (authentication and encryption of data) to ensure that only the owner of the application or a party authorized by them can undertake such an update.
  • the application provider application (305) preferably contains the functionality to undertake a payment application with a merchant terminal (or remote terminal) compliant with the PayPass specifications.
  • the security application (300) one or more secure processes are defined to undertake combined Data Authentication (CDA) using keys and secure data stored with the security application.
  • CDA Data Authentication
  • the keys used may be under the control of the security application provider, in which case a service may be offered to the end user application provider to validate the authorization cryptogram, or under the control of the end user application provider where the security application provider has allowed the end user application provider to download their own keyset into the secure key store (301) within the security application (300).
  • an example of a protected process in its simplest embodiment might be the use of a DES (triple DES or AES) key to encrypt a data element passed into the secure application processor.
  • Figure 4 shows an architecture of an overall solution according to an embodiment.
  • the consumer device (306) may be as configured as shown in figure 3 with an application provider's application (305) hosted and executed on the application processor (102), and a security application (300) hosted and executed on the secure application processor (103).
  • the security application (300) will have been configured by the consumer device manufacturer or distributor (401) as defined and provided by (407) the security application provider before being delivered (409) to the final end user or consumer of the device.
  • the consumer may then access an application store (402) to download (415) the application they require. This application will have previously been uploaded (416) by the application service provider (404) to the application store (402).
  • the application Once the application has been downloaded, it will communicate with the application provider to 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 application provider, the download of authentication data to allow access to the security application, download of updates for the security application to add new keys, secure processes or secure data. If may also involve setting up the service on the application provider's systems.
  • the application provider (404) preferably has an arrangement with the security application provider (403) to gain access to the security application (300) on the consumer device (306).
  • the security application provider (403) may also provide services to the application provider (404) to assist with the process of providing and configuring the application provider's application (305) on the consumer device (306). If under that agreement an update is required to the security application (keyset, secure process or secure data) then the security application provider (403) will provide that to the application service provider (404) to be transferred to the application provider's application (305) and ultimately to the security application (300).
  • the application service provider (404) and the security application provider (403) may exchange cryptographic keys and other data before or during the setup of an end users application.
  • 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 the terminal (or communicates with the merchants virtual terminal) and performs a payment transaction in accordance 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.
  • the Key Index is used to identify which set of security keys, secrets, and processing methods is to be used c.
  • different ranges of Key index values are assigned to different types of application such that applications from different industries cannot access functionality intended for a different types of application.
  • the security application owner allows other parties to maintain their own security keys, secrets, and processing methods within the security application.
  • a mobile phone application may update security keys, secrets, and processing methods within the security application in the secure element provided it has the permission of the security application owner,
  • a process protected process
  • a process can be configured into the application post issuance.
  • the security application owner offers a service to verify any cryptographic processes performed by the security application on behalf of an application provider.
  • the security application owner offers a service to securely configure the security application pre or post issuance with an application providers own security keys, secrets, and processing methods.
  • TEE Trusted Execution Environment
  • the implementation of communication methods and protocols with the secure application processor which are independent of the underlying physical implementation of the secure processor means that a common interface can be used across different physical implementations.
  • the physical protocols are typically compliant with international standards such as ISO/IEC 7816 and industry standards such as those published by Global Platform.
  • ISO/IEC 7816 international standards
  • industry standards such as those published by Global Platform.
  • abstracting the communication protocols and methods from the physical implementation is beneficial.
  • separating the security functions from the NFC controller within a mobile phone (or similar device) allows for different implementations to be created by those skilled in the art.
  • the security application no longer needs to directly process commands that may be received over the NFC interface, instead the HCE application directly processes those commands and only uses the secure application processor to undertake defined security relevant functions.
  • 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.
  • 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.
  • 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.
  • SE Secure Element
  • OTA Over The Air'
  • HCE Host Card Emulation

Abstract

A method of providing by a secure application service provider a secure process of a security application residing on a secure application processor, the method comprising the steps of providing at least one cryptographic key to the security application, providing at least one secure process to the security application, executing the at least one secure process based on the at least one cryptographic key.

Description

Provisioning of Secure Host Card Emulation
This disclosure relates to the provisioning of a secure host card emulation (HCE) to a consumer device. It is particularly suitable for, but by no means limited to, secure configuration of a secure element (or other secure environment such as a trusted execution environment (TEE)) within a mobile device (which may be NFC enabled) during manufacture (or before the final owner of the device is known) to secure an application that is subsequently downloaded to the device.
Background
Consumer Electronics manufactures have in recent years included Near Field Communication (NFC) 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 NFC 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 UICC or Micro SD device.
However the payments industry has experience 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.
Some skilled in the art have proposed that the security of consumer devices (e.g. mobile phone) can be enhanced with technologies such as Trusted Execution Environment (TEE) to resolve this issue. Others have designed solutions where the consumer device utilizes security functionality on a remote server, and the actual application on the consumer device has minimal involvement in the overall security of the solution. Both these solutions, however, have their own limitations and issues, and although solutions will be deployed using them, neither may achieve the mass deployment many application providers are seeking.
The secure element provides the security required by many applications, however is difficult to provision OTA. HCE applications are anticipated to be easier to deploy, however are recognized as less secure (insecure) than an SE based solution. Summary
According to a first aspect there is provided a method as defined in Claim 1 of the appended claims. Thus there is provided a method of providing by a secure application service provider a secure process of a security application residing on a secure application processor, the method comprising the steps of providing at least one cryptographic key to the security application, providing at least one secure process to the security application, executing the at least one secure process based on the at least one cryptographic key. Optionally, the method further comprises providing an application layer process in the security application to allow an additional cryptographic key to be downloaded to the security application.
Optionally, the method further comprises providing an application layer process in the security application to allow an additional secure process to be downloaded to the security application.
Optionally, the method further comprises providing an application layer process in the security application to allow downloading of data to a secure data store of the security application.
Optionally, the method wherein the application layer process is controlled by the provider of the security application. Optionally, the method wherein the provider of the security application was not the provider of the secure application processor. Optionally, the method wherein the cryptographic keys are arranged in key sets.
Optionally, the method wherein each key set is assigned an identifier.
Optionally, the method wherein a secure process is arranged to use a cryptographic key based on the identifier.
Optionally, the method wherein each identifier comprises a generic identifier and a unique identifier.
Optionally, the method wherein a secure process is arranged to use a cryptographic key based on either the generic identifier or the unique identifier.
Optionally, the method wherein a secure process is arranged to define which cryptographic key is usable with the secure process.
Optionally, the method wherein a secure process defines at least one input parameter, a calculation to be performed, and an output format.
Optionally, the method wherein a secure process defines security checks to be performed by a calling application. Optionally, the method wherein a non-secure application is arranged to undertake a secure transaction by authenticating with the secure process of the security application. Optionally, the method wherein the authenticating with the secure process of the security application comprises authenticating with a cryptographic key that has been downloaded to a secure key store of the security application under control of the provider of the non-secure application.
Optionally, the method wherein the secure application processor resides in a trusted execution environment.
Optionally, the method wherein the secure application processor resides in a secure element of a device.
Optionally, the method wherein the non-secure application resides in a nonsecure application processor. Optionally, the method wherein the secure application processor resides on a mobile device.
According to a second aspect there is provided an apparatus arranged as defined in claim 21. The apparatus comprises a security application residing on a secure application processor.
Optionally, the apparatus comprises a mobile device.
According to a third aspect there is provided a computer readable medium as defined in claim 23.
With all the aspects, preferable and optional features are defined in the dependent claims. 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 an embodiment on a consumer device with a secure element;
Figure 3a illustrates a process for loading and configuring an application; and Figure 4 illustrates the architecture of an embodiment.
In the figures, like elements are indicated by like reference numerals throughout. Overview
Methods, apparatus and systems for the simplified provisioning of a secure 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 a HCE mobile payment application downloaded to the device. 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). 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, smart watches or 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 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. 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 a secure application processor, or have limitations and potentially lower security when utilizing a cloud based secure element. There is provided an alternative solution that is easier to deploy than an application wholly executed with a secure application processor, but offers greater security and functionality than a cloud based secure element solution. This solution is achieved by decoupling the download of the actual application providing the non-secure functionality (for example a Payment, Identification (ID), Loyalty, Ticketing or Transit application) to the application processor (102), and the downloading and configuration of a security application within a secure application processor (103) such as the secure element. This allows application providers to freely distribute their HCE based applications using application stores 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. Instead of these applications then using a cloud based secure element solution for security, a generic security application running on or within a secure application processor (103) may be used.
To maximize the usability of this solution, application functionality is included within the portion hosted and executed on the application processor (102) within the consumer device. Preferably all functionality not deemed security relevant, i.e. the majority of the application is included. This allows for the easy deployment of the application, and replacement or update as required. However it is recognized that this portion can only offer very limited security and confidentiality. Those components of the overall application requiring greater security or confidentiality such as cryptographic keys, confidential data or protected processes should be hosted within the secure application processor (103).
Figure 3 shows a consumer device (306) configured according to an embodiment. One or more end user applications (305) provided by application providers will be hosted and executed on the application processor (102) within the device. These applications may be distributed using application stores 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 (305) may utilize secure processes implemented on a security application (300) with the secure application processor (103). The security application (300) may further comprise a secure key store (301), secure Data store (302), one or more protected process definitions (303) and security application processing engine (304) that can interpret the protected process definitions (303) to provide the functionality required. It is typically much harder to deploy or update an application hosted or executed on the secure application processor (103) as previously stated. Therefore the security application (300) should be deployed once, ideally during the manufacture of initial setup of the device. However it should be understood that at this stage the identity of the consumer may not be known, and which applications the consumer may wish to install and use may also not be known. The security application (300) deployed to the secure application processor (103) is preferably sufficiently generic that it is not necessary at the point of deployment to know this information. This is possible because for many applications, industry bodies define the functionality through the publication of specifications. Although individual organizations interpret these specifications to produce their own versions, the underlying processes are often identical. 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 Organisation ltd, ITSO) for example, the security application (300) may be configured with a number of secure processes to fulfill the requirements of many applications. Cryptographic Keys however are often diversified based on data within the application provider's application (305) so it is more difficult to preload these keys. However this can be resolved by pre-loading keys defined by the security application service provider and then offering a service to validate the cryptographic elements on behalf of the application provider. Alternatively a service may be offered where the applications providers own application (305) can contain new keys which are encrypted for security and confidentiality and can be loaded into the security application (300) on first use.
Figure 3a shows an example of the process for loading and configuring an application. The consumer device is first manufactured (310) with a secure application processor, or a removable secure application processor such as a UICC or micro SD device is manufactured or otherwise initially enabled. Before distribution the security application will be loaded and configured (311) with a range of key sets and secure process definitions to meet expected market requirements. This is performed in an environment and location compatible with the industry processes used to manufacture and configure the consumer device. The device is then distributed in accordance with that industry's normal distribution processes (e.g. retail distribution) such that an individual consumer will finally receive the device for their personal use (313). The consumer can then select which applications and functionality they require on the device and download the required application (314) from a suitable application store. The downloaded application then contacts the consumer application provider (316) to obtain the necessary unique configuration information for that consumer (315) which may involve processes (Identification and verification ID&V) to determine if that consumer is truly the legitimate consumer who the application provider wishes to enable with the services and functionality provided by the application. To support the Consumer application provider (316) the security application provider (312) may provide additional secure configuration data for the security application (300) and other functionality as a service to assist the Consumer application provider (316). It will be recognized by those skilled in the art that other methods exist and this example only represents one of many processes that may be undertaken.
The security application (300) on the secure application processor (103) will hold cryptographic keys and the ability to undertake processes using those keys. When deploying (311) the security application (300), one or more sets of keys will be included within the security application (300), each with a corresponding process defined for their use. The key sets will be assigned a key identifier, which may also be used to identify for which industry or type of application (for example a payment, Identification (ID), Loyalty, Ticketing or Transit) they are intended for. The secure processes defined are bound or otherwise linked to one or more keysets such that keys can only be used by the intended (authorized) protected processes.
The key set identifiers are preferably defined such that they comprise two parts, an industry or application type (generic) identifier, and a unique key set identifier. When defining a keyset it is possible to authorize any secure process defined for that industry or application type to utilize it or only one of a more specific secure process. It is also possible for a secure process to define which keysets it may be used with using the same process. The control of this is defined by the secure application provider using rules defined by the application providers using the functionality, as such application providers do not need to understand how such association or binding is configured, only that once configured in accordance with their requirements, secure processes cannot use key sets they are not authorized to and vice versa. The secure process defines the input parameters, the calculation to be performed, and the format of the final output. Other features may be incorporated that for example record and use data that is maintained by the secure application processor such as counters or confidential configuration data. Further to this, the protected process may define security checks that must be fulfilled by the calling application to ensure only authorized applications have access to use the protected processes. These are defined using a method such as an interpreted expression language such that definitions are not permanently encoded into security application processing engine (304). It shall be possible as application layer functionality provided by the security application (103) to load or amend new secure process definitions. Typically such processes are cryptographically protected (authentication and encryption of data) to ensure that only the owner of the application or a party authorized by them can undertake such an update.
When the application is first deployed to the secure application processor (103), preferably as many cryptographic keysets and secure processes will be included as possible. However over the life of the consumer device, things change and there may be need to add an additional keyset or implement a new secure process. Instead of deleting the existing application and replacing it which would suffer from the many difficulties highlighted earlier in this description, an application layer process is included in the security application to allow new keys to be downloaded into the existing application. Typically such processes are cryptographically protected (authentication and encryption of data) to ensure that only the owner of the application or a party authorized by them can undertake such an update. It is also possible to add and amend data within the secure data store (302) within the security application (300) being hosted and executed within the secure application processor (103). Typically such processes are cryptographically protected (authentication and encryption of data) to ensure that only the owner of the application or a party authorized by them can undertake such an update.
In the case of the exemplary embodiment of a payment application such as PayPass for an NFC enabled mobile phone, the following will be required:
1. Issuer DES keys
2. RSA keys to support offline authentication with the payment terminal
3. The ability to protect the processes used by the application to decide if a transaction is to be approved, declined or flagged for an online authorization to be conducted.
The application provider application (305) preferably contains the functionality to undertake a payment application with a merchant terminal (or remote terminal) compliant with the PayPass specifications. Within the security application (300) one or more secure processes are defined to undertake combined Data Authentication (CDA) using keys and secure data stored with the security application. Depending on the agreement between the security application provider and the end user application provider, the keys used may be under the control of the security application provider, in which case a service may be offered to the end user application provider to validate the authorization cryptogram, or under the control of the end user application provider where the security application provider has allowed the end user application provider to download their own keyset into the secure key store (301) within the security application (300). To support applications providers in other industries, an example of a protected process in its simplest embodiment might be the use of a DES (triple DES or AES) key to encrypt a data element passed into the secure application processor.
Figure 4 shows an architecture of an overall solution according to an embodiment. The consumer device (306) may be as configured as shown in figure 3 with an application provider's application (305) hosted and executed on the application processor (102), and a security application (300) hosted and executed on the secure application processor (103). The security application (300) will have been configured by the consumer device manufacturer or distributor (401) as defined and provided by (407) the security application provider before being delivered (409) to the final end user or consumer of the device. The consumer may then access an application store (402) to download (415) the application they require. This application will have previously been uploaded (416) by the application service provider (404) to the application store (402). Once the application has been downloaded, it will communicate with the application provider to 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 application provider, the download of authentication data to allow access to the security application, download of updates for the security application to add new keys, secure processes or secure data. If may also involve setting up the service on the application provider's systems.
The application provider (404) preferably has an arrangement with the security application provider (403) to gain access to the security application (300) on the consumer device (306). The security application provider (403) may also provide services to the application provider (404) to assist with the process of providing and configuring the application provider's application (305) on the consumer device (306). If under that agreement an update is required to the security application (keyset, secure process or secure data) then the security application provider (403) will provide that to the application service provider (404) to be transferred to the application provider's application (305) and ultimately to the security application (300). In order to then undertake transactions or otherwise use the functionality provided by the security application (300), the application service provider (404) and the security application provider (403) may exchange cryptographic keys and other data before or during the setup of an end users application. 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 the terminal (or communicates with the merchants virtual terminal) and performs a payment transaction in accordance 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: An application that contains security keys, secrets, and processing methods that can be deployed in advance (e.g. at time of manufacture) of the consumer or final functionality being known
a. Optionally, where said application may hold many different security keys, secrets, and processing methods
b. Optionally, where the Key Index is used to identify which set of security keys, secrets, and processing methods is to be used c. Optionally, where different ranges of Key index values are assigned to different types of application such that applications from different industries cannot access functionality intended for a different types of application.
d. Optionally, where the security application owner maintains the security keys, secrets, and processing methods for providing services to other parties
e. Optionally, where the security application owner allows other parties to maintain their own security keys, secrets, and processing methods within the security application.
The ability to manage the security keys, secrets, and processing methods post issuance using application layer functionality such that it is not necessary to utilise or have use of the security methods maintained by the secure element for management of security domains or applications.
a. Optionally, where this is controlled using security and cryptographic methods defined by the provider of the security application, which may not be the Secure Element Issuer.
b. Optionally, where a mobile phone application may update security keys, secrets, and processing methods within the security application in the secure element provided it has the permission of the security application owner,
c. Optionally, where a process (protected process) can be configured into the application post issuance.
Optionally, the security application owner offers a service to verify any cryptographic processes performed by the security application on behalf of an application provider.
Optionally, the security application owner offers a service to securely configure the security application pre or post issuance with an application providers own security keys, secrets, and processing methods.
Optionally, the same principles described herein may utilise a Trusted Execution Environment (TEE) instead of a secure element. The implementation of communication methods and protocols with the secure application processor which are independent of the underlying physical implementation of the secure processor means that a common interface can be used across different physical implementations. In the case of a secure element within a mobile phone, the physical protocols are typically compliant with international standards such as ISO/IEC 7816 and industry standards such as those published by Global Platform. When implementing a secure application processor on other devices such as personal computers, abstracting the communication protocols and methods from the physical implementation is beneficial. Optionally, separating the security functions from the NFC controller within a mobile phone (or similar device) allows for different implementations to be created by those skilled in the art. The security application no longer needs to directly process commands that may be received over the NFC interface, instead the HCE application directly processes those commands and only uses the secure application processor to undertake defined security relevant functions.
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 UICC) 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

CLAIMS:
A method of providing by a secure application service provider a secure process of a security application residing on a secure application processor, the method comprising the steps of:
providing at least one cryptographic key to the security application;
providing at least one secure process to the security application; executing the at least one secure process based on the at least one cryptographic key.
The method claim 1 further comprising providing an application layer process in the security application to allow an additional cryptographic key to be downloaded to the security application.
The method of claim 1 or 2 further comprising providing an application layer process in the security application to allow an additional secure process to be downloaded to the security application.
The method of claim 3 wherein the additional secure process supports new security functions required by a payment, payment acceptance, transit, identity, access control or loyalty application.
5. The method of any preceding claim further comprising providing an application layer process in the security application to allow
downloading of data to a secure data store of the security application.
6. The method of any preceding claim further comprising providing an application layer process in the security application to allow secure export of data from a secure data store of the security application.
7. The method of any of claims 2 to 6 wherein the application layer
process is controlled by the provider of the security application.
8. The method of any preceding claim wherein the provider of the
security application was not the provider of the secure application processor.
9. The method of any preceding claim wherein the cryptographic keys are arranged in key sets.
10. The method of claim 9 wherein each key set is assigned an identifier.
11. The method of claim 10 wherein a secure process is arranged to use a cryptographic key based on the identifier.
12. The method of claim 10 or 11 wherein each identifier comprises a generic identifier and a unique identifier.
13. The method of claim 12 wherein a secure process is arranged to use a cryptographic key based on either the generic identifier or the unique identifier.
14. The method of any preceding claim wherein a secure process is arranged to define which cryptographic key is usable with the secure process. 15. The method of any preceding claim wherein a secure process defines at least one input parameter, a calculation to be performed, and an output format.
16. The method of any preceding claim wherein a secure process defines security checks to be performed by a calling application.
17. The method of any preceding claim wherein a non-secure application is arranged to undertake a secure transaction by authenticating with the secure process of the security application.
18. The method of claim 17 wherein the authenticating with the secure process of the security application comprises authenticating with a cryptographic key that has been downloaded to a secure key store of the security application under control of the provider of the non-secure application.
19. The method of any preceding claim wherein the secure application processor resides in a trusted execution environment. 20. The method of any preceding claim wherein the secure application processor resides in a secure element of a device.
21. The method of any preceding claim wherein the non-secure
application resides in a non-secure application processor.
22. The method of any preceding claim wherein the secure application processor resides on a mobile device.
23. An apparatus arranged to provide the method of any of claims 1 to 22, the apparatus comprising a security application residing on a secure application processor.
24. The apparatus of claim 23 wherein the apparatus comprises a mobile device.
25. 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 22.
26. A method substantially as herein described with reference to and as illustrated in any combination of the accompanying drawings.
27. An apparatus substantially as herein described with reference to and as illustrated in any combination of the accompanying drawings.
PCT/GB2015/051523 2014-05-23 2015-05-22 Provisioning of secure host card emulation WO2015177574A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1409277.9A GB2526540A (en) 2014-05-23 2014-05-23 Provisioning of secure host card emulation
GB1409277.9 2014-05-23

Publications (1)

Publication Number Publication Date
WO2015177574A1 true WO2015177574A1 (en) 2015-11-26

Family

ID=51177413

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2015/051523 WO2015177574A1 (en) 2014-05-23 2015-05-22 Provisioning of secure host card emulation

Country Status (2)

Country Link
GB (1) GB2526540A (en)
WO (1) WO2015177574A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11195167B2 (en) 2016-06-20 2021-12-07 Advanced New Technologies Co., Ltd. Offline payment method and device

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016207339A1 (en) 2016-04-29 2017-11-02 Volkswagen Aktiengesellschaft A method for securely interacting a user with a mobile device and another entity

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8171525B1 (en) * 2011-09-15 2012-05-01 Google Inc. Enabling users to select between secure service providers using a central trusted service manager
US20120265988A1 (en) * 2011-04-14 2012-10-18 Yubico Ab Dual interface device for access control and a method therefor
US20130139230A1 (en) * 2006-09-24 2013-05-30 Rfcyber Corporation Trusted Service Management Process
US20140031024A1 (en) * 2012-02-05 2014-01-30 Rfcyber Corporation Method and system for providing controllable trusted service manager

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090307140A1 (en) * 2008-06-06 2009-12-10 Upendra Mardikar Mobile device over-the-air (ota) registration and point-of-sale (pos) payment
US8429409B1 (en) * 2012-04-06 2013-04-23 Google Inc. Secure reset of personal and service provider information on mobile devices
EP2770470A1 (en) * 2013-02-26 2014-08-27 Nxp B.V. Method for personalizing a secure element, method for enabling a service, secure element and computer program product

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130139230A1 (en) * 2006-09-24 2013-05-30 Rfcyber Corporation Trusted Service Management Process
US20120265988A1 (en) * 2011-04-14 2012-10-18 Yubico Ab Dual interface device for access control and a method therefor
US8171525B1 (en) * 2011-09-15 2012-05-01 Google Inc. Enabling users to select between secure service providers using a central trusted service manager
US20140031024A1 (en) * 2012-02-05 2014-01-30 Rfcyber Corporation Method and system for providing controllable trusted service manager

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11195167B2 (en) 2016-06-20 2021-12-07 Advanced New Technologies Co., Ltd. Offline payment method and device
US11250412B2 (en) 2016-06-20 2022-02-15 Advanced New Technologies Co., Ltd. Offline payment method and device

Also Published As

Publication number Publication date
GB2526540A (en) 2015-12-02
GB201409277D0 (en) 2014-07-09

Similar Documents

Publication Publication Date Title
KR102305943B1 (en) Managing credentials of multiple users on an electronic device
CN104380652B (en) Many publisher's safety element subregion frameworks for NFC enabled devices
US10699277B2 (en) Security for mobile payment applications
EP2641162B1 (en) System and method for providing secure data communication permissions to trusted applications on a portable communication device
EP2617219B1 (en) Secure near field communication of a non-secure memory element payload
FI125071B (en) Payment system
US8196131B1 (en) Payment application lifecycle management in a contactless smart card
US20220012716A1 (en) Application selection on a digital transaction processing unit (dtpu)
JP7186163B2 (en) Systems and methods for generating, storing, managing and using digital secrets in connection with portable electronic devices
EP3430829B1 (en) Managing program credentials on electronic devices
Dmitrienko et al. Secure free-floating car sharing for offline cars
KR20190083360A (en) Cryptographic system management
Alliance Host card emulation (hce) 101
WO2015177574A1 (en) Provisioning of secure host card emulation
Akram et al. Rethinking the smart card technology
WO2016189277A1 (en) Securing host card emulation (hse) solutions
EP3446274A1 (en) Method and device for authorizing mobile transactions
Mattsson Security and Infrastructure for Mobile Phone Payments using Near Field Communication
Kumar Security analysis of mobile payment systems
WO2024002511A1 (en) Methods and systems for personalizing secure smart objects

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15728583

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15728583

Country of ref document: EP

Kind code of ref document: A1