CN105046479B

CN105046479B - Trusted service manager architecture and method

Info

Publication number: CN105046479B
Application number: CN201510312392.XA
Authority: CN
Inventors: 阿鹏卓·马蒂卡
Original assignee: PayPal Inc
Current assignee: eBay Inc
Priority date: 2008-06-06
Filing date: 2009-06-04
Publication date: 2020-01-24
Anticipated expiration: 2029-06-04
Also published as: US20150056957A1; EP2308014A1; US20090307140A1; US8554689B2; US8150772B2; US20120173434A1; US20090307139A1; WO2010002541A1; US20120089520A1; CN102057386B; US8108318B2; US20180218358A1; US9858566B2; US11521194B2; US9852418B2; US8417643B2; EP2308014A4; CN105046479A; US20090307778A1; US20180225654A1

Abstract

The present disclosure relates to a Trusted Service Manager (TSM) architecture and method. A client device includes a first secure element and a second secure element. The first secure element includes a first computer-readable medium having a payment application that includes instructions for causing a client device to initiate a financial transaction. The second secure element includes a second computer-readable medium having a secure key, a payment instrument, stored authentication data, and instructions for generating a secure payment information message in response to the payment application. The secure payment information message includes a payment instrument and is encrypted according to a secure key.

Description

Trusted service manager architecture and method

Description of divisional applications

The application is a divisional application of a chinese invention patent application 200980121058.9(PCT international application PCT/US2009/046322) entitled "Trusted Service Manager (TSM) architecture and method" with the application date of 2009, 6/4.

RELATED APPLICATIONS

This application claims priority to U.S. provisional application serial No. 61/095, 395, filed on 6/2008 and U.S. provisional application serial No. 61/059, 907, filed on 9/2008, and is hereby incorporated by reference in its entirety.

Technical Field

Embodiments of the present disclosure relate generally to financial transactions and, more particularly, to secure financial transactions initiated from electronic devices.

Background

"contactless technology" refers to near field communication between two devices that are not physically connected. Today, there is a wide variety of "contactless technologies". Near Field Communication (NFC) is a specific type of "contactless technology" which is very important for Mobile Network Operators (MNOs) and for Service Providers (SPs), such as banks. NFC is a close-range high-frequency wireless communication technology that enables data exchange between devices at distances of typically about 10 centimeters (or about 4 inches), thus providing a quick, simple, and secure way for users to experience a range of contactless services using mobile devices.

Wireless mobile devices, including NFC devices and smart cards, which may use RFID for identification purposes, allow individuals to conduct financial transactions, such as purchasing retail products. Typically, the customer waves or taps the wireless mobile NFC device on a reader to effect the money transfer and subtracts the price of the product from the total amount available stored on the smart card of the wireless mobile device. Alternatively, the quantity of the product may be forwarded to a server, which may identify the identification code of the particular device and then charge the individual for the purchase of the retail product. Such NFC-based point of sale (POS) transactions provide advantages such as eliminating the need to carry cash and supporting faster financial transactions.

In addition to NFC-based POS payments, there are a number of popular payment modes in the mobile industry, including Short Message Service (SMS), a communications protocol that allows short text messages to be exchanged between mobile devices, and mobile internet-based payments by which customers search for and purchase products and services by electronically communicating with online providers via an electronic network such as the internet. In this regard, individual customers may often engage in transactions with a variety of suppliers, for example, through various supplier websites. Credit cards may be used to make payments via the internet. A disadvantage of using credit cards is that online providers may be subjected to high fraud costs and liability for "chargeback fees" because there is no credit card signature with online sales.

The use of mobile devices such as personal electronic devices to conduct financial transactions involving the transfer of funds from an SP to a seller via an MNO network using SMS, NFC at a POS, and mobile internet based transactions raises security issues or issues. For example, these methods involve credit card/financial instrument information, user names and passwords flowing through a network. In addition, the user may use different payment applications for different service providers at different times. To the extent that each payment application has its own, separate secure registration and authentication process, the user experience can be cumbersome, as the user must separately load and run different specialized applications, each of which must be separately registered and authenticated for conducting secure financial transactions. Moreover, viruses, trojans, key loggers (key loggers), and the like may compromise the security of each of these applications, as these applications and their security information may reside on the same data storage element. Moreover, unique biometric identification information, such as a fingerprint of a thumb or finger read from a biometric reader on the device, may be obtained by any of a variety of applications loaded on the device. Additional security measures may be desirable to support more secure service provider/vendor financial transactions via one or more networks.

Mobile payment services using SMS communication may be insecure or use cumbersome security measures. For example, one approach involves using an Interactive Voice Response (IVR) call to make a callback to a PIN. This approach, for example for PayPal move 1.x, may result in a less than optimal user experience for users who may not want the burden of entering a PIN. Other methods involve key management in software and/or downloading client applications (e.g., interfaces available from kryptext co. uk and fortress sms).

Disclosure of Invention

According to one embodiment, a client device includes a first secure element and a second secure element. The first secure element includes a first computer-readable medium having a payment application that includes instructions for causing a client device to initiate a financial transaction. The second secure element includes a second computer-readable medium having a secure key, a payment instrument, stored authentication data, and instructions for generating a secure payment information message in response to the payment application. The secure payment information message includes a payment instrument and is encrypted according to a secure key.

These and other features and advantages of the present invention will become more apparent from the detailed description of the embodiments set forth below when taken in conjunction with the drawings.

Drawings

FIG. 1 illustrates a block diagram of an ecosystem or environment for conducting financial transactions over a network.

Fig. 2 illustrates a payment system according to an example embodiment of the present disclosure.

FIG. 3 shows a block diagram of an overview of an example embodiment of a system for conducting a purchase transaction between a customer/user and a provider/service provider that is paid for by conducting a financial transaction using a financial service provider.

Fig. 4 is a block diagram of an example embodiment of a client device.

Fig. 5a and 5b illustrate an example system for registering a client device.

Fig. 6a to 6c show an example embodiment of a method 600 of conducting a Near Field Communication (NFC) transaction at a point of sale (POS).

The example embodiments and their advantages are best understood by referring to the detailed description that follows. It should be understood that the same reference numerals are used to identify similar elements in one or more of the figures, the illustrations of which are for the purpose of illustrating example embodiments and not for the purpose of limiting the same.

Detailed Description

Embodiments of the present disclosure relate to systems and methods for conducting secure financial transactions over a network. A user may use a client device, such as a personal electronic device, to make a payment from a service provider to a vendor/seller or other payee. The device may comprise at least two separate Secure Elements (SE), one dedicated to running applications (App SE) of various service providers and the other dedicated to providing security (Crypto SE) for applications and financial transactions. The device may include a biometric sensor for providing biometric information to the Crypto SE to provide transaction security for transactions conducted from the device. The device may provide other means of authentication for non-repudiation of the transaction, including a secure payment mode in which secure information or a Personal Identification Number (PIN) may be securely tunneled directly to the Crypto SE without being otherwise stored or obtained on the device or elsewhere. A Trusted Service Manager (TSM) may support secure SMS communications between a user device, an MNO, and a service provider. The device may be capable of Near Field Communication (NFC) and may be capable of conducting secure financial transactions at a point of sale (POS) for NFC.

FIG. 1 illustrates an example embodiment of an "ecosystem" or environment in which various embodiments of the present disclosure can be used. The ecosystem can include or involve any number of parties. One such ecosystem has been proposed by the global system for mobile communications association (GSMA), which is a global trade association that represents over 700 GSM mobile phone operators throughout the world. See "Mobile NFC Services", GSMA, version 1.0, month 2 of 2007. The mobile ecosystem can include parties, including:

client-client subscriptions are to Mobile Network Operators (MNOs) and service providers and are clients of suppliers/vendors. The customer may be an individual or a company.

Mobile Network Operators (MNOs) -MNOs offer a full range of mobile services to customers. Also, the MNO may provide UICC and NFC terminals plus over-the-air (OTA) transport mechanisms. Examples of MNOs include Sprint, Verizon, and ATT.

Service Provider (SP) -SP provides contactless services to customers. Examples of SPs include banks, credit card issuers, and public transportation companies, loyalty program owners, and so forth.

Retailer/vendor-a retailer/vendor may operate a point-of-sale terminal with NFC-enabled and an NFC reader.

Trusted Service Manager (TSM) -the TSM securely distributes and manages NFC applications and may have a direct relationship with SPs or a relationship via a clearing house, for example.

Handset, NFC chipset and UICC manufacturer-manufacturer produces mobile NFC/communication devices and associated UICC hardware.

Reader manufacturer-reader manufacturer manufactures NFC reader devices.

Application developer-application developer designs and develops mobile NFC applications.

Standardization bodies and industry forums-forming a global standard for NFC, supporting interoperability, backward compatibility and future development of NFC applications and services.

NFC-based financial transactions may require cooperation between various participants of the ecosystem. Each participant may have their own desires, e.g., a customer desires convenient, friendly and secure services in a trusted environment; SPs want their applications to be hosted and used in as many mobile devices as possible; and the MNO wants to provide new mobile contactless services that are secure, of high quality and consistent with the existing services experienced by the customer. However, although each participant may have his own culture and expectations, they all have the same basic requirements-the need for security and confidentiality.

A Trusted Service Manager (TSM) may be particularly helpful to bring trust and convenience to a complex multi-participant NFC ecosystem. The roles of TSMs include providing a single point of contact for SPs (e.g., banks) to access their customer base through MNOs, and providing secure download and lifecycle management for mobile NFC applications on behalf of SPs. The TSM may not interfere with the business model of the SP because the TSM may not participate in the trading phase of the service.

Fig. 2 illustrates a payment system 200 according to an embodiment of the present disclosure. Financial transactions, for example using an NFC-based point of sale (POS) payment system, may be conducted through a retailer or vendor server 210 using a client device 400 (see fig. 4), the client device 400 being, for example, an NFC-enabled mobile device. It should be understood that although an NFC application is shown in this embodiment, the system is not limited to NFC applications, but may also be applied to other types of applications, such as SMS, mobile internet or other forms of communication.

Client device 400 may be implemented using any suitable combination of hardware and/or software configured for wired and/or wireless communication via a network. For example, in one embodiment, client device 400 may be implemented as a personal computer of a user 220 (also referred to as a "customer" or "consumer") in communication with the Internet or another network. In other embodiments, client device 400 may be implemented as a wireless telephone, a Personal Digital Assistant (PDA), a notebook computer, and/or other types of electronic computing and/or communication devices. Further, client device 400 may support NFC, bluetooth, online, infrared communications, and/or other types of communications.

Client device 400 may include various applications as desired in particular embodiments to provide desired features to client device 400. For example, in various embodiments, the applications may include security applications for implementing client-side security features, programmatic client applications for interacting with appropriate Application Programming Interfaces (APIs) via a network, or other types of applications.

Client device 400 may also include one or more user identifiers, which may be implemented, for example, as operating system registry entries, cookies associated with a browser application, identifiers associated with hardware of client device 400, or other suitable identifiers. The identifier associated with the hardware of the client device 400 may be, for example, an international mobile equipment identification number (IMEI #) or a secure element ID number. In one embodiment, the user identifier may be used by the payment service provider or TSM240 to associate the client device 400 or user 220 with a particular account maintained by the payment service provider 240, as further described herein.

The vendor server 210 may be maintained, for example, by a retailer or an online vendor that offers various products and/or services in exchange for payments received via a network such as the internet. The vendor server 210 may be configured to accept payment information from the user 220, e.g., via the client device 400, and/or from the TSM240 via a network. It should be understood that although a user-provider transaction is shown in this embodiment, the system may also be applied to user-user, provider-provider, and/or provider-user transactions.

The vendor server 210 may use a security gateway 212 to connect to an acquirer (acquirer) 215. Alternatively, the vendor server 210 may be directly connected to the acquirer 215 or the processor 220. Once authenticated, the acquirer 215 associated with or subscribing to the payment service provider 240 processes the transaction through the processor 220 or TSM 240. A brand (brand)225, e.g., a payment card issuer, also affiliated with or subscribed to the TSM240 is then involved in the payment transaction, which will enable the user 120 to complete the purchase.

The TSM240 may have

data connections

255, 256, 257, and 258 with the subscriber client device 400, the subscriber acquirer 215, the subscriber processor 220, and/or the subscriber brand 225, respectively, for communicating and exchanging data. These

data connections

255, 256, 257, and 258 may occur, for example, over a network via SMS or Wireless Application Protocol (WAP). Additionally, in accordance with one or more embodiments, the payment service provider 240 may have a data connection (not shown) with a subscriber internet company, internet mortgage company, internet broker, or other internet company (not shown).

Fig. 3 shows a block diagram illustrating an overview of an example embodiment of a system 300 for conducting a purchase transaction between a customer/user 305 and a provider/service provider 310, the provider/service provider 310 being paid for by conducting a financial transaction using a financial service provider 315. The overview shows the relationships and roles of the participants in the transaction. The customer 305 may use a device 400 (fig. 4) that communicates over a network via a Mobile Network Operator (MNO)320, such as Sprint, Verizon, or other mobile network service provider 320. Customer 305 may desire to purchase or pay for goods or services provided by provider/service provider 310. The customer 305 may desire to make payment using the financial services provided by the SP 315.

In an example embodiment, Trusted Service Manager (TSM)325 may provide a single point of contact for service providers 315 or vendors to access their customers 305 through any of the various MNOs 320. The TSM325 may manage secure downloads and lifecycle management of mobile payment applications 450 (fig. 4) (e.g., NFC applications) on behalf of the service provider 315. Although NFC is shown and generally discussed herein with respect to various embodiments, the roles of TSMs or other entities discussed herein are not limited to NFC and may be applied to other types of electronic communications including technologies such as bluetooth, infrared, SMS (short message service), and/or other wireless or contactless technologies.

A central issue with mobile NFC or other wireless technologies is the need for cooperation between many parties to meet customer demand via a secure over-the-air (OTA) link. The payment provider system may act as a TSM325 to provide a single point of contact for service providers to access their customer base through the MNO 320. More particularly, electronic communication environments are constantly changing, including the advent of NFC, and service providers 315 may not be ready or willing to change their method of work or the functionality they provide, but they may still want to participate in new modes of service operation by enhancing the services they provide while maintaining the existing core processes. This conflict is resolved by the TSM325, which TSM325 may help service providers to use the MNO320 to securely distribute and manage contactless services for their customers. In this regard, the TSM may manage secure downloading and lifecycle management of mobile NFC applications on behalf of a service provider.

In an example embodiment, the responsibilities and roles of one or more parties may be combined and completed by a single entity. For example, service provider 315, a bank, or other financial institution, are those entities that typically issue credits and provide authorization to conduct financial transactions between customers and suppliers. The TSM325 may act as a payment provider system (PP), such as PayPal, and may provide payment processing for online transactions on behalf of a customer so that the customer does not directly expose payment information to the provider. Instead, the customer may pre-register his account with the payment provider system, map the account to an email address, and then use the payment provider system to make a purchase when redirected from the vendor site to the payment provider system. After the financial transaction is authorized, the TSM325 or the payment provider system completes the transaction.

In online and/or contactless financial transactions, the role of TSM325 or payment provider system may be extended to include or share responsibilities normally associated with service provider 315, such that a customer may use the payment provider system as a credit issuer and for services such as electronic banking transfers from one account to another, and/or to provide access to other related financial activities through electronic communications via an electronic network operated by MNO320, such as the internet. The payment provider system may provide infrastructure, software, and services that enable customers and providers to make and receive payments.

Client device

Fig. 4 shows an example embodiment of a block diagram of a client device 400, e.g., a communication device such as a mobile phone, a cellular phone, a Personal Digital Assistant (PDA), or other contactless electronic communication device. The client device 400 may include a communication chip 405, an antenna 407,

secure elements

410, 420, a keypad 430, and a biometric sensor 440.

In an example embodiment, the communication chip 405 may support one or more modes of communication including, for example, Near Field Communication (NFC), bluetooth, infrared, GSM, UMTS, and CDMA cellular telephone protocols, SMS and internet access via a mobile or local network, such as WAP and/or other wireless or contactless technologies. Near field communication is a short-range, high-frequency wireless communication technology that supports data exchange between devices over a very short distance, such as a four inch range. NFC may be an extension of the ISO 14443 proximity card standard, such as contactless card or RFID, and may combine the interfaces of a smart card and a reader into a single device. NFC devices can communicate with both existing ISO 14443 smartcards and readers, as well as with other NFC devices, and can be compatible with existing contactless architectures already used for public transportation and payment. For example, device 400 may be compatible with a near field communication point of sale device (NFC POS) located at a point of sale at a vendor's place of business.

In an example embodiment, keypad 430 may include any form of manual keys or touch sensors, or other means of inputting information to the device, such as a telephone touchpad physically located on or displayed on a touch screen device, a full or partial keyboard of qwerty or qwertz, or any other arrangement of input buttons, which may be sequentially pressed or selected for entry of characters, numbers, or letters representing a PIN. The keypad may include a "payment mode" button 439 for placing the device 400 in a payment mode, such as a secure payment mode, for conducting NFC POS transactions. The "pay mode" button may be located on keypad 430 or any other location on the device, or may be located on a remote control device coupled to the device for making inputs to the device. In an example embodiment, the secure payment mode may be used even if the phone communication mode is off, such as at an airport or other location that requires or requests the mobile phone to be muted or turned off. In an example embodiment, the tunneling circuitry 435 may be provided for direct input to Crypto or payment SE420 (discussed below) when in a secure payment mode, without requiring additional storage or retrieval at the device or elsewhere, in order to provide secure entry of a password or PIN during a financial transaction.

Biometric sensor

In an example embodiment, biometric sensor 440 may be any sensor that provides data representing unique biometric user attributes that may be used to identify a user, such as a finger/thumb fingerprint sensor, a retinal scan, or a voice identifier. In this description, the term biometric "sensor" 440 is used to refer not only to a physical sensor that receives raw biometric data, but also to aspects of the sensor, logic, algorithms, etc., that collectively sense, measure, evaluate, and generate a data signal representative of a biometric characteristic of a user. The biometric characteristic data from the biometric sensor 440 may be tunneled directly through the biometric tunneling circuit 441 to the Crypto SE420 (discussed below) without being acquired by any application on the separate APP SE 410 (discussed below). The biometric characteristic may be stored as authentication data 446 on Crypto SE 420.

Security element

In an example embodiment, the apparatus 400 may include at least two Secure Elements (SEs) 410, 420. The SE may be, for example, a smart card such as a Universal Integrated Circuit Card (UICC) or a smart card like a chip embedded within the device 400 (e.g., inside a cellular phone). Smart cards are small, relatively tamper-resistant calculators. The smart card itself contains a CPU and some non-volatile memory. In most cards, some portion of the memory may be tamper-resistant, while the remainder may be accessible to any application capable of communicating with the card. This capability allows the card to be kept secret from certain content, such as the private key associated with any certificate it holds. The card itself may perform its own encryption operations.

The

SE

410, 420 may include a data store and may pre-load applications and/or may download various applications, such as applications for facilitating financial transactions via a network, a key pair, a payment instrument, and/or a Certification Authority (CA) certificate.

In an example embodiment, each

SE

410, 420 may have logical end-to-end security. For example, there may be an authenticated and encrypted channel for communicating with the SE. In an example embodiment, the SE may have physical security. For example, the SE may comply with certain security standards such as FIPS 140-2Level 3 (tamper-proof and copy protection) and Common criterion ISO 15408EAL 4+, or other standards as needed or desired.

In an example embodiment, the

SE

410, 420 may be comprehensive. In other words, the SE may be compatible with various communication protocols or systems. For example, the device may be compatible with GSM, UMTS, and/or CDMA cellular telephone protocols.

In an example embodiment,

SE

410, 420 may be portable in that it may be easily transferred from one device 400 to another. This may be accomplished, for example, by carrying (port)

SE

410, 420 or by having a Trusted Service Manager (TSM)325 (fig. 3) carry applications. Portability may enable a user who has registered his/her device 400 to register any other device of the user. For example, a user may have one phone for business and one for home, where transactions from each phone are dedicated to business or personal use.

In an example embodiment, the

SE

410, 420 may be compatible with over-the-air (OTA) loading or dynamic remoting management. For example, an application residing in the APP SE may be compatible with OTA management for lifecycle management of the application. For example, the resident application may be managed, updated, changed, and/or fixed to avoid newly discovered vulnerabilities in the application or to update the application to add or change features.

In an example embodiment, the

SE

410, 420 may be normalized. For example, they may be compatible with standards set forth by known standards or protocols, such as those established by globalplatform.

In an example embodiment, the SE may still operate even when the device is turned off. For example, the NFC communication mode may allow the device to conduct NFC POS transactions or purchases even when other cellular and/or wireless communication modes of the phone are turned off or disabled. This is particularly desirable and/or convenient in the event that the equipment is shut down, or when the equipment must be shut down, such as at an airport or other location where electronic equipment is required to be shut down. In an example embodiment, the secure payment mode button 439 may be used to activate or prepare the NFC payment component for NFC payment without powering up other communication modes. Lower power, short range NFC communication may be allowed even when it is not desirable to use higher power/wider range communication modes.

Separate security element

In an example embodiment, a device may have more than one SE, e.g., two

SEs

410, 420. One SE may be referred to as an application SE (app SE)410, while a separate SE may be referred to as a payment, credential, wallet, or encryption SE420 (Crypto SE) (the term "Crypto SE" is used throughout this description to refer to any of a payment, certificate, wallet, or encryption SE unless otherwise specified). Separating App SE 410 from Crypto SE420 may enable a particular device 400 to be certified for use only once by Crypto SE, while allowing changes to App SE that may not require additional certification or re-certification because security and certification information is securely maintained on the separate Crypto SE 420.

App SE

In an example embodiment, the App SE 410 may be assigned and arranged to store various resident financial transaction or payment applications 450, each of which may facilitate financial transactions of different financial service providers. The applications 450 may include, for example, PayPal applications, or other payment applications provided by alternative service providers and that facilitate financial transactions over a network.

App SE 410 may be, for example, a SIM card. The SIM card may securely store a subscriber key (IMSI) for identifying the subscriber. The SIM card allows a user to change phones by simply removing the SIM card from one mobile phone and inserting it into another mobile phone or broadband phone device. The App SE may not include any payment ticket, certificate, key, certificate, or credential, all of which may be stored in a separate Crypto SE 420. App SE 410 may be a dynamic SE on which applications may be dynamically managed and changed, e.g., through OTA management. All applications 450 may be signed with a common Trusted Service Manager (TSM) public key. App SE applications may have a virtual environment (like MFC smartcards).

In an example embodiment, the application 450 may include instructions to periodically check whether updates to the application are available. If updates are available and the client is registered, the application is downloaded and the signature is verified. Once the signatures match, the new application is activated.

OTA management

In an example embodiment, an application 450, such as a mobile financial services application, may be managed via over-the-air (OTA). OTA management may be securely provided by the TSM for multiple service providers. The App SE may be shared by more than one such application 450 for various SPs. SPs may expect the services they provide via their applications 450 to be secure, isolated, under their control, have their specified life cycles for their respective applications, and certified. In an example embodiment, OTA updates, upgrades or other changes to the App 450 may require signing with the TSM public key.

Crypto SE

In an example embodiment, Crypto SE420 may be assigned and arranged to load and store authentication data 446 (e.g., a PIN or biometric signature), payment ticket 447, certificate 424, secret key 421, and other security-related information, including, for example, unique biometric authentication information related to a particular user. Crypto SE may be primarily static, although some credentials or other sensitive data may be dynamic. Crypto SE420 may provide verification and authentication for multiple applications stored in App SE 410.

Separating the App SE from the Crypto SE may enable a single trusted service manager to verify and authenticate the identity of the user for each of many different service providers. Separating the Crypto SE420 from the App SE 410 improves the user experience by reducing the necessity to register and authenticate various applications 450 individually for each service provider and/or to re-certify after any change to any of the applications 450. Separating the Crypto SE from the App SE 410 may also reduce the likelihood that the security information on the Crypto SE420 is compromised by viruses, trojans, key loggers, etc. that may find a way to enter the App SE 410.

An authentication application 442, such as a biometric authentication application, may reside on Crypto SE420 and may evaluate biometric data and compare the data to data from registered users, or may enroll the data, with the data being collected as part of an enrollment or attestation process.

Crypto SE420 may also have a communication application 443, a counter 444, and a clock 445. The communication application 443 may support or control communication through the SE. A counter 444 or clock 445 may be used to identify and/or time stamp a particular communication to prevent replay (replay).

In an example embodiment, Crypto SE420 may be certified, for example, by a credit processing company, such as MasterCard or VISA. For example, CryptoSE may be certified using the biometric sensor 440 and the biometric authentication application 442. Once the CryptoSE section is certified, the device 400 is certified for use. Additional financial applications 450 may be added or updated on the App SE without any additional certification or re-certification needs. As a result, the user experience may be enhanced by minimizing the number of times the user must register or certify his device 400 and/or new or updated applications 450 on his device 400. This is because App SE is separated or separated from Crypto SE.

In an example embodiment, Crypto SE420 may include one or several key pairs, such as X509 key pair 421a, EMV (Europay, MasterCard, VISA) key pair 421b, or ECC key pair 421 c. The key pair may be preloaded on Crypto SE 420. Trusted service manager credentials 424 or certificates, such as a root Certificate Authority (CA), may also be preloaded onto Crypto SE 420.

Public key infrastructure

In cryptographic systems, Public Key Infrastructure (PKI) is a scheme that binds public keys to individual user identities by means of a Certifying Authority (CA). The user identity must be unique for each CA. The binding is established through a registration and issuance process, which may be implemented by software at the CA, depending on the level of assurance the binding has. A Registration Authority (RA) guarantees the binding. For each user, the user identity, public key, their bindings, validity conditions and other attributes are made uneventable in the public key certificate issued by the CA. In an example embodiment, a Trusted Service Manager (TSM) may be used as Ca, and may work with the device and/or chip manufacturer to have a root certificate authority (Ca)424 preloaded on the client device 400, e.g., the Crypto SE420 of the device.

Registration

Fig. 5a and 5b illustrate an example system 500 for registering a client device 400. In an example embodiment, device users may be required to register their devices with trusted service manager 505 only once. This registration may open a payment instrument or CA certificate 424 (fig. 4) that was previously loaded on the device 400. Enrollment may include enrolling a biometric attribute, such as a thumb fingerprint or finger fingerprint, to initiate payment. All applications on the device may be registered and deployed via the trusted service manager. Registering all applications with one trusted service manager may provide improved security for payment applications loaded and running on the device.

In an example embodiment, the user may unlock the pre-loaded payment credentials 424 on the device 400 (FIG. 4). In an example embodiment, the payment credential may be opened by registering a unique biometric profile (profile) of the user using the biometric sensor 440 (fig. 4). The credential 424 is turned on, for example, by registering the thumbprint twice using a thumbprint/fingerprint biometric sensor. In an example embodiment, all payment applications 450 (fig. 4) may be registered and used using a common TSM signature.

In an example, when a customer invokes the pre-loaded application 450 (fig. 4), SECP/CRMF (simple certificate enrollment protocol/certificate request message format) is invoked. The user's TSM credentials or certificates 424 are entered and associated with the service provider's user account. A random counter may be generated by the counter 444 (fig. 4) on the Crypto SE and stored in the Crypto SE for counter-based replay protection. In an alternative embodiment, clock 426445 (fig. 4) may generate timestamps for timestamp-based playback protection. In an example embodiment, this information, e.g., tuples, may be sent along with SCEP, and certificates may be issued to the devices.

Payment account number deployment

In an example embodiment, the payment account number may be a deployed OTA. For example, the payment account number may be randomly generated along with the CVV (card verification value) by the service provider. In an example embodiment, the payment account number, CVV, and counter/timestamp (to prevent replay attacks) may be encrypted using the public key of the mobile phone and signed using the private key of the TSM.

In an example embodiment, the counter may be checked and the payment account number and CVV may be stored in the Crypto SE. The number may be obtained separately from a service provider (e.g., a representative), such as by telephone, email, or other querying method.

The customer manually enters:

in an example embodiment, the customer may manually enter a known account number using a keypad on the device. This may be done only after the biometric credential is initiated and the device is registered. The application may then load a Crypto SE with the payment ticket 447 identified with its account number.

Customer NFC transactions

Fig. 6a, 6b, and 6c illustrate a method 600 of conducting a Near Field Communication (NFC) transaction at a point of sale (POS). The customer may prepare 602 the device 400 for use. Preparing the device for use may include opening the device 400, placing the device in hand, selecting "payment mode," entering a payment application, or using other suitable methods if the device does not need to be "opened" for use. For example, the user 220 may select the payment mode or the secure payment mode by: a payment mode button provided on device 400 is pressed, or payment is otherwise suitably selected, such as by saying "pay" or other words associated with the function for a device having voice recognition technology, or any other suitable selection method appropriate for the particular device.

In an example embodiment, preparing the device for payment may prompt a payment application resident on App SE 410 of device 400 to check 604 a biometric sensor for biometric input. The user may then enter 606 their biometric Identification Data (ID) or signature by placing or swiping a thumb or finger over the biometric sensor 440. The input biometric ID may be sent directly to or tunneled through a tunneling circuit 441 provided 608 to crypt SE 420. In an example embodiment, the tunneling circuit 441 may be FIPS 140-2level 3 compliant and may be arranged such that the biometric ID is directly input to CryptoSE for authentication/enabling.

In an example embodiment, an application resident on the App SE 410 may send a message 610 for approval/disapproval of payment and payment information if approved to the Crypto SE 420. The Crypto SE may contain an access control system that can authenticate applications in the App SE for the type of request that the application on the App SE 410 has authority to execute. Once the user's biometric identity is properly authenticated, the Crypto SE420 may send 612 an approval/disapproval message and payment information or other information to the App SE. The App SE 410 may then send payment information 614 to the communication chip 405 for further transmission or transfer to a reader or other communication receiving device located at the POS, such as a POS NFC reader located at the vendor/seller's place of business.

In other example embodiments, Crypto SE420 may establish a direct secure transfer between Crypto SE 410 and the POS. The secure transmission may be established, for example, using techniques like Secure Sockets Layer (SSL), internet protocol security (IPSec), or conventional symmetric/asymmetric encryption, if supported by the POS. In these embodiments, the payment ticket may never be explicitly shown in the App SE. If SSL or IPSec is used, a known root CA may be stored in CryptoSE. POS certificates may be issued using the root CA. During the SSL or IPSec handshake, the certificate chain containing the POS's certificate and the root CA is sent directly by the POS to crypto SE. The Crypto SE may then operate as an SSL/IPSec/Crypto client. Crypto SE may verify the certificate of the POS against the root CA it already has. If the certificates match, it gives payment information using SSL/IPSec/secure tunnel.

Device 400 may transmit information, for example, via NFC technology, when a customer waves or taps the device at or near POS reader 650. The payment information may include payment information such as quantity and account number, and may include the CVV. In other embodiments, the payment information may be sent by alternative communication methods as desired or necessary in a particular embodiment or environment, such as by SMS (discussed below).

When payment is made at vendor POS 650 using Visa/MC/AmEx, the last four digits of the payment instrument may be sent to the TSM (e.g., using an application provided by the TSM on the App SE). By ensuring that private information is not revealed, this information can be associated with signature information, collated and provided to the financial institutions serving like banks, Visa/MC, and charles schwab, eTrade, Amazon. The only information collected by the TSM may be the last four digits of the financial instrument and the signature information. The TSM may collect and analyze this data and provide the information formed by this analysis as a fraud engine. The signature information is used to identify the client device and its user.

Authentication for password-authorized applications rather than authentication at the POS

In an example embodiment, the customer 220 may need to enter a PIN to complete payment, such as when a debit card (debit card) is used. The use of a PIN may provide an additional level of security. In other embodiments, a PIN or other alphanumeric code may be required and securely entered, either alone or in conjunction with biometric authentication. Rather than entering the PIN on the POS keypad or signing on the POS electronic signature screen, the POSPIN may be entered directly onto keypad 430 on device 400.

In an example embodiment, a user may first verify 608 their phone 602 for secure keypad PIN entry by using a biometric sensor and a biometric authentication application on their device, as described above. Biometric authentication of the phone may open or create a secure tunneling circuit from the keyboard directly to Crypto Se for secure keyboard entry on the device 400. The payment application on the App SE may prompt the user to enter PIN 616, the user may enter PIN 618, and the PIN may be tunneled 620 directly to Crypto SE420 via tunneling circuit 441. Crypto SE420 can be used for chip and PIN authentication and/or as ARQC-ARPC. When a PIN is required to be entered, the secure entry mode may be initiated by pressing the payment or secure payment key 439 on the device 400, by biometric verification of the device and/or by a payment application.

In some POS payment systems, the customer's PIN may be otherwise entered on a keypad connected to a card scanner or NFC reader, or the signature may be signed on a pressure-sensitive surface at the POS that electronically records the signature as a record of transaction authentication, such as a credit card, electronic check, or debit card transaction. Because banking regulations do not allow PIN entry on an unencrypted PIN pad, a client device with a secure payment mode as well as secure pad tunneling circuitry and a separate dedicated Crypto SE may provide an acceptable, convenient, and desirable way for conducting debit cards, electronic checks, or other transactions where secure PIN entry is required or desired.

In an example embodiment, the user may first biometrically authenticate the device and then be prompted to enter a PIN. When fully authenticated with a PIN and/or biometric features, Crypto SE420 may send 612 payment information to App SE 410 for forwarding via NFC or other communication mode. A full payment may be made when the device is "off," in other words, when the cellular phone, WAP, or other communication mode is disabled and only the NFC mode may be running. In this manner, the user can make payments without having to fully turn on the device, which is convenient at airports or other locations where a wireless telephone device or other communication device is required to be turned off or desired to be turned off.

The payment information may be sent to the reader 650 at the POS, further forwarded to and processed by the vendor server 210, and further forwarded to the acquirer/

processor

215, 220, the brand 225, and a Service Provider (SP)315, such as a card issuer or bank, to complete a payment transaction from the user account to the vendor/seller in accordance with the payment information sent from the client device 400.

Secure SMS for transactions

In an example embodiment, payment and financial transactions may be conducted using secure SMS communications. The TSM may generate random keys (AES-256 and SHA-512) and send the random keys to the client device's CryptoSE. The key may be encrypted using a public certificate of the client device and may be signed by the TSM. The key may be sent via an SMS channel, for example over multiple SMS. The client device may then verify the signature, decrypt the key, and store the key in Crypto SE. CryptoSE in turn can generate, encrypt and send encrypted SIMs to the TSM. The TSM may use a Diffie-Hellman (D-H) key exchange to generate or establish keys.

In an example embodiment, the user may desire to make a payment using an SMS interface, where NFC is not available and where WAP is undesirable or inconvenient. Having separate App SE and Crypto SE can support secure SMS communication without those drawbacks. The TSM may pre-load the public key inside a Crypto SE, such as a SIM/SE. A client application on the app of the client device, with the help of Crypto SE, may generate a symmetric key and a MAC key. The application may then encrypt the payload with the symmetric key and the MAC key. The key will be encrypted using the TSM public key which can then be used to create a digital envelope. The size of the SMS is a total of 160 characters. If 1024 bits are used, the binary value of the data is 128 bytes. If 128 bytes were Base 64 encoded, the output would be 171 bytes and there would be no room to send the message itself. Thus, Elliptic Curve Cryptography (ECC) may be used. The ECC output is 24 bytes and Base 64 encoded, the output is 32 bytes. The payload may then be less than 160-32-128 bytes. In an example embodiment, the client devices are also capable of sending secure SMS messages to each other.

Secure SMS may be implemented by TSM, along with various handset manufacturers, such as Nokia, using SIM cards and/or SE and ECC on mobile phones. The keys are dynamic and managed by hardware. In an example embodiment, when sending an SMS, the data is encrypted using AES-256 and the counter is used for replay protection and the SHA-512HMAC is appended. The SHA-512HMAC is 64 bytes in binary. Truncation is used to make the data 32 bytes BASE-64 encoded. The TSM may receive the SMS and determine to whom the message is to be sent or forwarded-and forward the message to the appropriate recipient, such as a service provider, to complete the payment transaction. The TSM may also have a key registered with the recipient's device. The TSM may decrypt and re-encrypt the message using the key of the recipient's phone. The time stamp may be used to prevent replay. The keys may be periodically rotated using an SMS key establishment scheme.

In implementations of various embodiments, the mobile device may comprise a personal computing device, such as a personal computer, laptop, PDA, cellular telephone, or other personal computing or communication device. The payment provider system may include a network computing device, such as a server or servers, computers, or processors, which are combined to define a computer system or network for providing payment services provided by the payment provider system.

In this regard, the computer system may include a bus or other communication mechanism for communicating information that interconnects the subsystems and components, such as a processing component (e.g., processor, microcontroller, Digital Signal Processor (DSP), etc.), a system memory component (e.g., RAM), a static storage component (e.g., ROM), a disk drive component (e.g., magnetic or optical), a network interface component (e.g., a modem or Ethernet card), a display component (e.g., CRT or LCD), an input component (e.g., keyboard or keypad), and/or a cursor control component (e.g., a mouse or trackball). In one embodiment, the disk drive components may include a database having one or more disk drive components.

The computer system may perform particular operations by a processor and execute one or more sequences of one or more instructions contained in a system memory component. Such instructions may be read into a system memory component from another computer-readable medium, such as a static storage component or a disk drive component. In other embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention.

Logic may be encoded in a computer-readable medium, which may refer to any medium that participates in providing instructions to a processor for execution. Such a medium may take many forms, including but not limited to, non-volatile media, and transmission media. In various implementations, non-volatile media includes optical or magnetic disks, such as the disk drive components, volatile media includes dynamic memory, such as the system memory components, and transmission media includes coaxial cables, twisted pair wires, and fiber optics, including the wires that comprise a bus. In one example, transmission media may take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

Some common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, any optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave, or any other medium to which a computer is adapted.

In various embodiments, execution of the sequences of instructions to practice the invention may be performed by a computer system. In various other embodiments, multiple computer systems connected by a communications link (e.g., a LAN, WLAN, PTSN, or various other wired or wireless networks) may execute sequences of instructions to practice the invention in cooperation with one another.

Computer systems can send and receive messages, data, information, and instructions, including one or more programs (i.e., application code), through the communication links and communication interfaces. When received and/or stored for execution in a disk drive component or some other non-volatile storage component, the received program code may be executed by a processor.

The various embodiments provided by the present disclosure may be implemented using hardware, software, or a combination of hardware and software, as appropriate. Moreover, where applicable, the various hardware components and/or software components set forth herein can be combined into hybrid components comprising software, hardware, and/or both without departing from the spirit of the present disclosure. Where applicable, the various hardware components and/or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the present disclosure. Additionally, where applicable, it is contemplated that software components can be implemented as hardware components and vice versa.

Software, such as program code and/or data, according to the present disclosure can be stored on one or more computer-readable media. It is also contemplated that the software identified herein can be implemented using one or more general purpose or special purpose computers and/or computer systems, networks, and/or the like. Where applicable, the order of various steps described herein can be varied, combined into hybrid steps, and/or separated into sub-steps to provide features described herein.

The foregoing disclosure is not intended to limit the invention to the precise form or particular field of use disclosed. It is contemplated that various alternative embodiments and/or modifications of the invention are possible in light of the present disclosure, whether explicitly described or implied herein. Having thus described various example embodiments of the disclosure, it will be apparent to those of ordinary skill in the art that changes in form and detail may be made therein without departing from the scope of the invention. Accordingly, the invention is limited only by the claims.

Claims

1. A client device, comprising:

a first secure element to execute a payment application to cause the client device to initiate a financial transaction; wherein:

the payment application has been securely downloaded from a trusted service manager to the first secure element; and is

The first secure element downloading the payment application in response to determining that the payment application is signed by the trusted service manager; and

a second secure element physically separate from the first secure element, the second secure element for generating a secure payment information message in response to the payment application and having a secure key, a payment ticket, stored authentication data; wherein:

the secure key is excluded from the first secure element;

the payment instrument is excluded from the first secure element;

the client device registering with the trusted service manager for authentication only through the second secure element and not through the first secure element, comprising: registering and storing the stored authentication data, wherein the stored authentication data is excluded from the first secure element;

and wherein the second secure element:

a user authentication input comprising a signal responsive to the payment application to the stored authentication data; and is

Generating a secure payment information message in response to an authentication comprising a match of the user authentication input with the stored authentication data, and

wherein the generated secure payment information message includes the payment instrument and is encrypted according to the secure key.

2. The client device of claim 1, further comprising:

a user authentication input device for inputting user authentication data;

secure tunneling circuitry to securely input the user authentication data directly to the second secure element;

wherein the second secure element generates the secure payment information message if the user authentication data matches the stored authentication data.

3. The client device of claim 2, wherein the user authentication input device comprises a biometric sensor and the authentication data comprises a biometric signature corresponding to a biometric feature of the user.

4. The client device of claim 3, wherein the biometric sensor comprises one of a finger/thumb fingerprint sensor, a voice recognition sensor, or a retinal scanner.

5. The client device of claim 2, wherein the user authentication input device comprises a keypad and the user authentication data comprises a personal identification number.

6. The client device of claim 3, further comprising a keypad for entering a personal identification number, the keypad being connected to the second secure element through a second secure tunneling circuit.

7. The client device of claim 6, wherein the user authentication data comprises biometric data and a stored personal identification number.

8. The client device of claim 7, further comprising means for switching the client device to a secure payment mode, wherein the second secure tunneling circuit is enabled when the client device is in the secure payment mode.

9. The client device of claim 1, further comprising a communication chip to communicate the secure payment information message in response to the payment application, wherein the secure payment information message is sent in one of near field communication, infrared, bluetooth, or short message service.

10. The client device of claim 1, wherein the secure payment information message is a secure short message service message destined for a trusted service manager and includes an address of a financial service provider to which the trusted service manager is to forward the secure payment information message.

11. The client device of claim 10, wherein the payment information is encrypted using AES-256 and appended with SHA-512 HMAC.

12. A trusted service manager server comprising a hardware processor for facilitating a financial transaction over a network via a short message service by performing a process comprising:

generating a random key for the client device;

encrypting the random key using a public certificate of the client device;

sending the random key to the client device for storage in a cryptographic secure element, wherein:

the client device excluding an application secure element physically separated from the cryptographic secure element and registering with the trusted service manager server only through the cryptographic secure element,

the random key and payment instrument are excluded from the application secure element such that registering the client device with the trusted service manager server for authentication includes registering and storing authentication data, and

the stored authentication data is excluded from the application secure element;

securely download a payment application from the trusted service manager server to the application secure element of the client device, wherein the application secure element downloads the payment application in response to determining that the payment application is signed by the trusted service manager server;

receiving an encrypted short message service message comprising a payment certificate and an address of a service provider, wherein the short message service message from the client device is encrypted according to the random key;

decrypting the short message service message using the random key and determining an address of the service provider;

re-encrypting the short message service message using a second stored key corresponding to the service provider; and

forwarding the re-encrypted short message service message to the service provider for completion of a financial transaction.

13. The trusted service manager server of claim 12, said random keys comprising AES-256 and SHA-512.

14. The trusted service manager server of claim 12, wherein the random key is established using a Diffie-Hellman key exchange.

15. The trusted service manager server of claim 12, wherein the encrypted short message service message is a secure short message service message destined for the trusted service manager server and includes an address of a financial service provider to which the trusted service manager server is to forward the encrypted short message service message.

16. The trusted service manager server of claim 12, wherein said encrypted short message service message is sent through a secure short message service, wherein when the short message service is sent, said message is encrypted using AES-256 and SHA-512HMAC is appended.

17. The trusted service manager server of claim 12, wherein said encrypted short message service message is sent through a secure short message service, wherein when the short message service is sent, said message is encrypted using AES-256 and SHA-512HMAC is appended; and is

The SHA-512HMAC is 64 bytes in binary and uses truncation to make the data 32 bytes BASE-64 encoded.

18. The trusted service manager server of claim 12, wherein said encrypted short message service message is sent through a secure short message service, wherein when the short message service is sent, said message is encrypted using AES-256 and SHA-512HMAC is appended; and is

The counter marks the secure payment information message for replay protection.