WO2012091351A2 - System and method for provisioning over the air of confidential information on mobile communicative devices with non-uicc secure elements - Google Patents

System and method for provisioning over the air of confidential information on mobile communicative devices with non-uicc secure elements Download PDF

Info

Publication number
WO2012091351A2
WO2012091351A2 PCT/KR2011/009868 KR2011009868W WO2012091351A2 WO 2012091351 A2 WO2012091351 A2 WO 2012091351A2 KR 2011009868 W KR2011009868 W KR 2011009868W WO 2012091351 A2 WO2012091351 A2 WO 2012091351A2
Authority
WO
WIPO (PCT)
Prior art keywords
mobile device
ota
provisioning
tsm
ota proxy
Prior art date
Application number
PCT/KR2011/009868
Other languages
French (fr)
Other versions
WO2012091351A3 (en
Inventor
Sung Woo Bae
Dong Hyun Kim
Jae Min Lim
Dae Man Kwon
Young Jin You
Ki Do CHEONG
Original Assignee
Sk C&C Co., Ltd.
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
Priority claimed from US13/310,344 external-priority patent/US9161218B2/en
Application filed by Sk C&C Co., Ltd. filed Critical Sk C&C Co., Ltd.
Priority to EP11853081.5A priority Critical patent/EP2659695A4/en
Priority to AU2011350197A priority patent/AU2011350197A1/en
Priority to KR1020137019435A priority patent/KR101514754B1/en
Priority to CN2011800616198A priority patent/CN103262590A/en
Priority to SG2013042999A priority patent/SG190988A1/en
Publication of WO2012091351A2 publication Critical patent/WO2012091351A2/en
Publication of WO2012091351A3 publication Critical patent/WO2012091351A3/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G06F21/35—User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/88—Detecting or preventing theft or loss
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/354—Card activation or deactivation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/067—Network architectures or network communication protocols for network security for supporting key management in a packet data network using one-time keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2153—Using hardware token as a secondary aspect

Definitions

  • the following description relates to over-the-air provisioning of virtual cards on a mobile device, such as a mobile communication terminal, with a non-Universal Integrated Circuit Card (UICC) type secure element.
  • a mobile device such as a mobile communication terminal
  • UICC Universal Integrated Circuit Card
  • the SE may be a smart card chip capable of storing multiple applications, including of account specific information that may not be easily accessed by external parties.
  • the model mobile wallet application may have the same composition as a conventional wallet, which may contain payment cards, member cards, transportation cards, and loyalty cards.
  • Mobile wallet functionality may be further enhanced by provisioning the user financial credential onto mobile devices equipped with Near Field Communication chipset (NFC enabled).
  • NFC enabled Near Field Communication chipset
  • the provisioned NFC enabled device may transfer information or make payments to another NFC compatible device by coming near within a few centimeters of one another without physically contacting each other.
  • This type of technology is conventionally referred to as “contactless” technology and a payment made with this technology is referred to as “contactless” payment.
  • contactless a payment made with this technology
  • One possible solution for provisioning mobile wallet cards is to perform the provisioning at a secure facility controlled by the mobile wallet card issuer.
  • this solution may require users to bring their mobile device to the physical mobile wallet card issuer for provisioning. This process has to be repeated for every mobile wallet card the user seeks to provision at different card issuer facility, making the concept of utilizing mobile wallet application impractical.
  • OTA provisioning has been provided for mobile device with the SE types of UICC, Services Identity Module (SIM), Universal Subscriber Identity Module (USIM) (herein referred collectively as UICC) cards via industry standard Short Message Service Point to Point (SMS-PP) and Bearer Independent Protocol (BIP) protocols.
  • SMS-PP protocol and Bearer Independent Protocol BIP allow OTA provisioning for UICC cards and their equivalents, it does not allow for OTA provisioning of MicroSD’s and Embedded SEs (i.e.
  • non-UICC SEs which may not support conventional Subscriber Identity Module Application Toolkit (SAT) / Universal Subscriber Identity Module Application Toolkit (USAT) / Card Application Toolkit (CAT) framework.
  • SAT Subscriber Identity Module Application Toolkit
  • USAT Universal Subscriber Identity Module Application Toolkit
  • CAT Card Application Toolkit
  • any mobile device with SE types MicroSD, Embedded SE, or other non-UICC SE type that does not support SMS-PP or BIP protocol may not be provisioned OTA with the conventional technology.
  • FIG. 1 illustrates a system diagram of a conventional OTA provisioning process through SMS PP protocol.
  • FIG. 2 is a corresponding flow diagram illustrating a conventional method for OTA provisioning to mobile device using SMS PP protocol. Specifically, the referenced figures will provide for OTA provisioning via SMS PP protocol.
  • a user makes a request to a financial institution 18 to provision a mobile wallet card, in step 202. Then, the financial institution 18 will process the request and send the request along with necessary identifiers, such as Mobile Subscriber Integrated Services Digital Network Number (MSISDN) along with provisioning data to MNO OTA server 16 in step 203. MNO OTA Server 16 will then transmit the provisioning command to the mobile device 11 directly via SMS-PP protocol in step 204.
  • MNO OTA Server 16 and MNO 19 may be owned by the same entity but illustrated as two different entities to show the different functions performed by the individual elements. More specifically, MNO 19 is shown only in step 201 to illustrate the pre-registration step that is performed by the MNO 19.
  • MNO OTA server primarily interacts with the mobile device 11 to provision the information provided by financial institution 18.
  • mobile device 11 receives the message and performs the provisioning process into its SE (e.g., USIM, SIM, UICC).
  • SE e.g., USIM, SIM, UICC
  • Exemplary embodiments of the present invention provide a mobile device to provision information into a non-Universal Integrated Circuit Card (UICC) type secure element (SE) through an over-the-air (OTA) proxy.
  • exemplary embodiments of the present invention also provide a method for OTA provisioning a non-UICC SE of the mobile device.
  • UICC Universal Integrated Circuit Card
  • OTA over-the-air
  • Exemplary embodiments of the present invention provide a method for OTA provisioning a non- UICC type SE of a mobile device including receiving a request to initialize an OTA proxy of a mobile device, initializing the OTA proxy, receiving provisioning data through the OTA proxy, and provisioning the received data into the SE, the SE being a non-UICC type SE.
  • Exemplary embodiments of the present invention provide a method for OTA provisioning a non- UICC type SE including receiving a request to initialize an OTA proxy of a mobile device from a Trusted Service Manager (TSM) system; initializing the OTA proxy; communicating, by the mobile device, with the TSM system through the OTA proxy; retrieving mobile device information and SE information, in which the SE information includes an SE status and an SE type; receiving a key from the TSM system for accessing the SE, in which the key includes at least one of an initial issuer master key and a final issuer master key; securing the SE by injecting the corresponding key to the SE based on its status; receiving provisioning data; and provisioning the received data into the SE, the SE being a non-UICC type SE.
  • TSM Trusted Service Manager
  • Exemplary embodiments of the present invention provide a mobile device to provision secure data OTA in a non-UICC type SE including an OTA proxy to connect to a TSM system, and to receive provisioning data from the TSM system; a near-field-communication (NFC) enabled chip to conduct a contactless transaction; and a SE to store information provisioned through OTA proxy, the SE being a non-UICC type SE.
  • a mobile device to provision secure data OTA in a non-UICC type SE including an OTA proxy to connect to a TSM system, and to receive provisioning data from the TSM system; a near-field-communication (NFC) enabled chip to conduct a contactless transaction; and a SE to store information provisioned through OTA proxy, the SE being a non-UICC type SE.
  • NFC near-field-communication
  • FIG. 1 is a system diagram of a prior art OTA provisioning process through SMS PP protocol.
  • FIG. 2 is a flow diagram illustrating a method for prior art OTA provisioning process through SMS PP protocol.
  • FIG. 3 is a system diagram of a TSM ecosystem supporting the OTA provisioning process through OTA proxy according to an exemplary embodiment of the present invention.
  • FIG. 4 is a block diagram of an example TSM system, its components, and its relationship with external parties according to an exemplary embodiment of the present invention.
  • FIG. 5 is a flow diagram illustrating steps a service provider must take in order to take advantage of the TSM architecture according to an exemplary embodiment of the present invention.
  • FIG. 6 is a flow diagram illustrating a method of obtaining a mobile wallet application with accompanying OTA proxy application according to an exemplary embodiment of the present invention.
  • FIG. 7 is a flow diagram illustrating a high level OTA provisioning process though OTA proxy according to an exemplary embodiment of the present invention.
  • FIG. 8 is a flow diagram illustrating in detail a method of verifying SE types and status as required to provision into various types of SEs according to an exemplary embodiment of the present invention.
  • FIG. 9 is a system diagram depicting mobile device that has installed a mobile wallet application, accompanying OTA Proxy application and wallet management applet, and payment applets according to an exemplary embodiment of the present invention.
  • FIG. 10 is a flow diagram illustrating operation of a retry mechanism to ensure reliable data transmission according to an exemplary embodiment of the present invention.
  • X, Y, and Z will be construed to mean X only, Y only, Z only, or any combination of two or more items X, Y, and Z (e.g. XYZ, XZ, YZ, X).
  • XYZ, XZ, YZ, X any combination of two or more items X, Y, and Z (e.g. XYZ, XZ, YZ, X).
  • FIG. 3 is a system diagram of a Trusted Service Manager (TSM) ecosystem supporting the over-the-air (OTA) provisioning process through OTA proxy according to an exemplary embodiment of the present invention.
  • TSM Trusted Service Manager
  • an example system employing TSM technology with OTA proxy provisioning includes a TSM system 30; mobile device 31; third party messaging platform 32; network 33; financial institution 34; Mobile Network Operator (MNO) 35; handset manufacturer 36; and card manufacturer 37.
  • service providers such as identified in 34 - 37 typically go through a pre-registration process such as that outlined in FIG. 5.
  • the handset manufacturers 36 may include embedded secure element (SE) producer, and card manufacturers 37 may include producers of micro secure digital (SD) SE.
  • SE embedded secure element
  • SD micro secure digital
  • UICC Universal Integrated Circuit Card
  • Exemplary embodiments of the invention provide for OTA proxy to be connected with TSM system only during usage as it will conserve technical resources. As such, OTA proxy will be in a sleep mode as a default until it is awaken for its utility.
  • a third party messaging platform 32 e.g. Cloud to Device Messaging (C2DM)
  • C2DM Cloud to Device Messaging
  • the third party messaging platform 32 may also be used to send a Short Message Service (SMS) message or a Multimedia Messaging Service (MMS).
  • SMS Short Message Service
  • MMS Multimedia Messaging Service
  • TSM system sends a message to the third party messaging platform 32 (i.e., a push message server), with the wake up command and identifying information
  • the third party messaging platform 32 in turn sends a message to the identified mobile device to wake up OTA proxy residing within the mobile device.
  • OTA proxy Once awake, OTA proxy will collect the mobile device and SE information and connect to the TSM system for provisioning or other utility.
  • an owner of the mobile device may make a purchase at the NFC enabled Point-of-Sale (POS) 40 merchant by waving the NFC enabled mobile device at the corresponding NFC enabled POS device.
  • POS Point-of-Sale
  • the acquirer network 39 and payment processor 38 work together to ensure the payment gets updated at the financial institution 34.
  • This end user application does not involve the described TSM ecosystem and is illustrated to provide a description of a complete ecosystem.
  • FIG. 4 is a system diagram illustrating a TSM system and its relationship to external parties according to an exemplary embodiment of the present invention.
  • a TSM system 30 may be comprised of a Card & Application Management System (CAMS) 41; Key Management System (KMS) 42; Post Issuance Processor (PIP) 43; Customer Care, Billing, Participant System (CBPS) 44; Wallet Management System (WMS) 45; Operation Maintenance & Administration (OM&A) 46; and External System Interface (ESI) 47.
  • CMS Card & Application Management System
  • PIP Post Issuance Processor
  • WMS Wallet Management System
  • O&A Operation Maintenance & Administration
  • EI External System Interface
  • Component CAMS 41 may be responsible for managing life cycle of SE, secure domains, and applets. Life cycle refers to the various status of the respective device or application.
  • life cycle of a SE may include Operating System (OS) native, initialized, and secured.
  • Life cycle of an applet may include lock and unlock.
  • OS Operating System
  • Some of the functionalities offered by the CAMS 41 will be management of SE type, SE profile, SE ID, application profile, and card profile.
  • Each SE is identified individually and controlled by CAMS 41 with its own SE ID (Card Reference Number (CRN), Card Image Number (CIN), Card Production Life Cycle (CPLC), Card Serial Number (CSN)).
  • Component KMS 42 may be responsible for all of key management for allowing secure transactions. This may include secure log in, access control, audit, key profile management, key management, key profile exchange and recovery, and delegated management.
  • Component PIP 43 is primarily responsible for provisioning information into the mobile device, which may include preparation of data to be provisioned and the actual execution of sending and receiving provisioning messages provided in Application Protocol Data Units (APDU).
  • APDU may refer to a communication unit between a reader and a card. The structure of the APDU described in more detail by the ISO 7816 standards.
  • Component CBPS 44 may be responsible for customer management. It may keep customer account status as well as link data once SP requests service subscription. The CBPS 44 may modify the status of the SPs related to the customer as specified events occur (e.g. stolen handset) or as requested by the SP.
  • Component WMS 45 may be responsible for management of wallet application and its associated mobile card widgets stored therein. This component may provide a mobile ID to associate the wallet application stored in the user’s mobile device as well as all of the individual widgets stored in the wallet application. In addition, this component will store any of the user preferences made by the wallet owner (e.g. language, font, default card, etc.). This component may hold the master configuration which may provide synchronization benefit for the wallet application.
  • Component OM&A 46 may be responsible for overall system monitoring and maintenance. Further, OM&A may also facilitate external managers to access TSM directly.
  • Component ESI 47 may provide for an interface for all external parties to send and receive data. As external parties may have specific protocol they utilize, ESI 47 has the capability to translate commands and requests arriving or leaving the TSM system as necessary.
  • the described TSM system is a third party entity positioned to consolidate all of the information from various service providers (SP) including, financial institutions, MNOs, Handset Manufacturers, and Card Manufacturers.
  • SP service providers
  • MNOs financial institutions
  • MNOs Handset Manufacturers
  • Card Manufacturers Card Manufacturers
  • the mobile device need only to interact with the TSM system rather than various discrete entities.
  • the described TSM system acts as an integration point for all of the external parties the mobile device may have to deal with, providing for a seamless and more efficient operation of mobile services.
  • FIG. 5 illustrates a pre-registration process that may take place before provisioning services into the mobile device according to an exemplary embodiment of the invention.
  • SPs may first register their information into the TSM system for use by the TSM system.
  • a SP may be any entity that seeks to provision its services onto the end mobile device.
  • SPs’ information has been registered into the TSM system.
  • This process may be achieved by various methods.
  • the SP may send an encrypted email with basic registration information along with PGP public key. Registration may be achieved in person, by phone, through an automated system or any other method available to exchange information.
  • TSM administrator may then enter SP’s basic information into the TSM system and provide a unique SP ID, transport key ID, and the participant type (MNO, service provider, SE manufacturer, application).
  • MNO service provider
  • SE manufacturer service provider
  • TSM administrator may be a person, an automated system, or a separate entity.
  • TSM system may creates a participant account and generate secure token for the correlating SP ID. Once that is accomplished, TSM encrypts the SP account information in an encrypted email to send to the requesting SP.
  • a transport key is exchanged between the TSM system and the SP.
  • Transport key serves to provide secure transmission of sensitive data between various parties. Such security may be provided through encryption, cryptographic transformation of data through Message Authentication Code (MAC), or other conventional security measures.
  • the SP requests transport key sets to the TSM system.
  • the TSM checks for duplicate keys assigned to the requesting SP, and if no such key has been assigned, then TSM generates transport key sets inside a Hardware Security Module (HSM).
  • HSM Hardware Security Module
  • transport key sets may include three numbered keys including an encryption key (ENC), data encryption key (DEK), and message authentication code (MAC).
  • ENC encryption key
  • DEK data encryption key
  • MAC message authentication code
  • TSM exports the generated keys in an encrypted form using the PGP key provided by the SP in step 501.
  • Loadfile profile 503 describes the application code file that could contain one or more applications or describes the load files that make up an application code.
  • Application profile 504 describes a smart card application as a meta data, which will be utilized later for creating an instance of the application.
  • Key profile & key 505 describes basic profile information and key information as a metadata, which will be utilized for creating an instance of the key.
  • ISD master keys are also registered in the system, including Initial Supplier Key (ISK), Initial Issuer Master Key (KMC), and Final Issuer Master Key (CMK).
  • SE profile 506 describes attributes of a smart card.
  • handset profile 507 describes attributes of a handset device, including NFC capability, supported SE types, and OTA channel support.
  • the TSM system will establish link between the provided profiles in step 508.
  • the provided profiles may be provided to the TSM system in various ways.
  • the profiles may be sent to the TSM system directly through the network, by physical embodiments of provided data, or any other conventional method that is available to transfer information.
  • a check is conducted to verify compatibility with the aggregated business rules and or technical limitations in step 509. For example, a business rule may dictate that a certain MNO may not work with a SP for business reasons. Based on this business limitation, the TSM system may sever linkage between profiles to reflect this limitation.
  • there may be some technical limitations in providing certain products to user mobile device such as incompatible mobile operating systems. By configuring the described limitations in step 509, the mobile device user may access only the applications that may be valid to their mobile device and specific account attributes.
  • FIG. 6 shows a method for downloading OTA Proxy as an attached application to a SK C&C wallet mobile application according to an exemplary embodiment of the present invention.
  • step 601 new mobile device is obtained by the user.
  • the user in receipt of the mobile device initiates the payment card issuance request to the card provider in step 602.
  • This request may be made in person, by phone, internet request, or via mobile web service. It is assumed that a physical credit card account already exists with the issuing payment card provider. Some of the information that may be required includes personal information and handset information (MNO, Mobile Subscriber Integrated Services Digital Network Number (MSISDN)).
  • MNO Mobile Subscriber Integrated Services Digital Network Number
  • MSISDN Mobile Subscriber Integrated Services Digital Network Number
  • TSM When TSM system receives the request, TSM will first authenticate the SP account for its validity. TSM may then perform a check to verify existence of a mobile wallet application and an OTA proxy associated with the requesting user account in step 604 in its system.
  • the mobile wallet application may include an accompanying OTA proxy application, which may also be indicated in the user account.
  • the mobile wallet application may not include the OTA proxy application, which may be obtained separately from the mobile wallet application.
  • the TSM system may conduct this check by using identifying information provided by the user, which may include a mobile phone number, account number, birth date, or other identifying information.
  • the TSM system may perform a check to verify the existence of the OTA proxy application associated with the user account separately from the mobile wallet application.
  • the TSM system may be unable to identify a mobile wallet application or an OTA proxy application associated with the user account.
  • the TSM system may create a mobile wallet application associated with the user account identifying information when the user mobile device with the newly activated mobile wallet application connects to the TSM system.
  • the mobile wallet application also includes a corresponding OTA proxy application, information regarding the OTA proxy application will also be noted on the user account.
  • the TSM system may update its account information to note the possession of the OTA proxy application independent of the mobile wallet application.
  • OTA proxy allows for provisioning account specific information OTA to non-UICC SEs
  • certain mobile wallet applications may opt to add OTA proxy as an accompanying application.
  • OTA proxy software application independent of the mobile wallet application.
  • the TSM system will check for existence of both a mobile wallet and an OTA proxy application.
  • existence of one may provide existence of the other.
  • the TSM system will provide the deficient application for the user. Accordingly, if OTA proxy application is not associated with the user account, OTA proxy may be provided to the requesting user as described in step 606 below.
  • OTA proxy may integrate itself with a third party wallet application to allow OTA provisioning into the third party wallet application. While OTA proxy may be used in the mobile wallet application, it should be noted that OTA proxy software application is not limited to its use with the mobile wallet application and may be integrated with other software applications for mobile devices.
  • step 602 If the requesting user in step 602 has a mobile wallet application with the accompanying OTA proxy as determined in step 605, OTA provisioning process will occur immediately in step 609.
  • SMS message may include URL, MSISDN, service ID, and service account number.
  • step 607 the requesting user will view the SMS and triggers the attached URL to form a WAP push message to the TSM system with the appropriate identifier.
  • TSM system will authenticate the customer and customer’s handset by the given token and HTTP headers.
  • TSM system will then send the mobile wallet and the accompanying OTA proxy application in step 608.
  • mobile wallet and the OTA proxy application may be obtained in various other ways as well and are not limited to the SMS message as described above.
  • the specified applications may be downloaded directly to the requesting mobile device, sent to the user in a physical medium storing the applications, or by any other suitable method of providing an application to a mobile device.
  • the customer will launch the mobile wallet application.
  • the mobile wallet application through OTA proxy, will gather SE information (Card Production Life Cycle (CPLC), Card Serial Number (CSN), Card Image Number (CIN), Integrated Circuit Card Identification (ICCID)) and handset information (International Mobile Equipment Identity (IMEI)/Mobile Equipment Identifier (MEID), MSISDN) and connect to the TSM system for activation.
  • SE Card Production Life Cycle
  • CSN Card Serial Number
  • CIN Card Image Number
  • ICCID Integrated Circuit Card Identification
  • IMEI International Mobile Equipment Identity
  • MEID Mobile Equipment Identifier
  • MSISDN Mobile Service Set
  • the originally requested mobile wallet card may be provisioned through OTA via OTA proxy in step 609.
  • FIG. 7 is a flow diagram illustrating the general OTA provisioning process via OTA proxy according to an exemplary embodiment of the present invention.
  • the issuing service provider Prior to any provisioning of mobile card application, the issuing service provider will be ideally pre-registered into the TSM system as shown in step 701 as described in detail in FIG. 5. Once registered, a customer may select a registered SP’s payment card for provisioning by the mobile device owner in step 702.
  • Request for service subscription may include identifying information such as MSISDN along with encrypted account related information that is to be provisioned.
  • TSM in response to the request will begin preparation of the provisioning data in step 704.
  • provisioning information Upon receipt of provisioning information, internal data link will be conducted to log the service request made by the financial institution.
  • One of the information that will be maintained is a portion of the payment card account data which will be utilized to identify card account to the requesting user within the TSM system. For security purposes, the entire account number need not be maintained.
  • TSM system transmits an OTA proxy wake-up request to a push server.
  • TSM will then push the wake up request command to a third party messaging platform or a mobile push server (e.g. C2DM) along with identifying information (i.e. MSISDN), which will in turn relay the command to wake up the OTA proxy residing in the requesting user’s mobile device in step 706.
  • C2DM mobile push server
  • MSISDN identifying information
  • OTA proxy will be expected to be asleep prior to being awaken. Once OTA proxy is woken, it connects to the TSM system automatically. Upon connection, OTA Proxy gathers the SE and handset specific information and sends the collected information to TSM for verification. However, OTA Proxy may gather the specified information prior to connection or provide the information to the TSM system in a separate process. In receipt of provided information, the TSM system conducts an internal check to see if the MSISDN, IMEI/MEID, CIN/ICCID of handset and SE match the user information stored in the TSM server. As this check is conducted every time OTA proxy is initialized, additional security is provided verifying account specific information storage SE with the mobile device which houses the SE.
  • TSM will analyze the provided data for any additional processing SE may require and the best mode of provisioning the information into the respective mobile device in step 707. This analysis is described in detail in FIG. 8.
  • TSM prepares the data as necessary and sends the provisioning data in APDU format to the OTA proxy in step 708.
  • OTA proxy in receipt of APDU commands by TSM relays the provisioning data to the SE in step 709.
  • OTA proxy is allowed access to the non-UICC SEs through the various keys that have been loaded onto the TSM device along with SE specific APIs which are exchanged offline. Through the incorporation of these attributes, OTA proxy protocol is provided access to the SE to be provisioned.
  • FIG. 8 illustrates a detailed description for checking of SE status and type performed by the TSM system prior to provisioning as outlined in step 707 in FIG. 7.
  • step 801 after OTA proxy receives a wake up command from the third party messaging platform or the mobile push server originating from the TSM system, OTA wakes up and connects to the TSM system to retrieve the requested command.
  • the OTA proxy retrieves SE and mobile device specific information such as MSISDN and CIN. Once the necessary information has been gathered, OTA proxy sends the information to TSM in step 803 for verification and analysis of requesting device. Communications between the TSM system and the OTA proxy may be provided through a standard mobile network, wireless network, or similar mechanisms.
  • step 804 once the TSM system receives mobile device and SE information, the TSM system checks the status of SE. As processing of stored SE is dependent on its status, analysis of SE status is important prior to its provisioning.
  • SE equipped in the mobile device may have any of the 3 statuses: OS native, initialized, and secured.
  • OS Native status may refer to a status of the SE that is not initialized according to manufacturer’s initialization method
  • initialized status may refer to an administrative card production state
  • secured status may refer to an intended operating life cycle in post-issuance.
  • step 805 If the status of SE is determined to be as already secured in step 805, then it proceeds to step 809 which checks for the type of SE.
  • step 805 If the status of SE is determined as initialized in step 805, then the TSM will provide a final issuer master key for provisioning prior to proceeding to step 809.
  • step 806 If the status of SE is determined to be OS native in step 805, then pre-personalization process may take place in step 806. Afterwards, an initial issuer master key may be injected into the SE for provisioning in step 807. Once the initial issuer master key is injected, a final issuer master key may be injected as shown in step 808, prior to proceeding to step 809.
  • an analysis of SE type is performed in step 809 in order to determine the type of protocol that should run within OTA proxy in order to provision into the identified SE.
  • SE is a UICC type or an embedded type
  • application is ready to provision in step 811 and moves to step 708 in FIG. 7.
  • step 810 additional process specific protocol should be executed for MicroSD in step 810, before it can be ready to be provisioned in step 811.
  • FIG. 9 illustrates exemplary provisioned mobile device according to an embodiment of the present invention.
  • the mobile device illustrated in FIG. 9 represents an exemplary mobile phone, however, the mobile device embodying the present invention may be any mobile device, such as a personal digital assistant (PDA), a mobile computer device, or other similar mobile communicative devices.
  • PDA personal digital assistant
  • FIG. 9 illustrates exemplary provisioned mobile device according to an embodiment of the present invention.
  • the mobile device illustrated in FIG. 9 represents an exemplary mobile phone, however, the mobile device embodying the present invention may be any mobile device, such as a personal digital assistant (PDA), a mobile computer device, or other similar mobile communicative devices.
  • PDA personal digital assistant
  • the mobile device 31 may be comprised of the apparatus itself; mobile wallet application 91 software; OTA Proxy application 92 software; Device Stack 93 software; and Secure Element 94 hardware.
  • Mobile wallet application 91 such as a SK C&C wallet, provides the user with a graphically displayed mobile wallet, which includes various components such as payment widgets that are tied to the installed NFC enabled payment applets 943, as well as other components (e.g. coupons, transport pass, phone bill, and etc.).
  • various components such as payment widgets that are tied to the installed NFC enabled payment applets 943, as well as other components (e.g. coupons, transport pass, phone bill, and etc.).
  • the OTA Proxy 92 is a mobile client which supports OTA post-issuance related services to the secure element in a mobile device. More specifically, OTA proxy provisions confidential information, such as financial applications and related account information into non-UICC type SE equipped on a mobile device. As SE types, Micro SD and Embedded SEs cannot support conventional SAT/SUSAT/CAT framework, OTA provisioning is unavailable using the conventional technology for the specified SE types. OTA Proxy over OTA overcomes this limitation and allows any external party to send data to mobile devices equipped with the specified non-UICC SE types. However, if desired, OTA proxy can also provide an alternative protocol, over the conventional protocol, to UICC SE devices which can support conventional SAT/SUSAT/CAT framework.
  • OTA Proxy is able to gain access to the non-UICC SE types by using the keys to the SE provided by the manufacturers.
  • the respective keys to the non-UICC types may be obtained by having the manufacturers register the information to the TSM system, through an offline exchange, or any other conventional methods. Further, the obtained keys may be integrated into the OTA Proxy application or may be used separate from the OTA Proxy application.
  • Device Stack 93 is a standard handset platform which facilitates the mobile device operations. No modification is done to this component and is illustrated only to provide an accurate visual representation.
  • SE 94 may be further comprised of a Wallet Management Applet (WMA) 941 software; Payment Procedure Secure Elements (PPSE) 942 software; and Payment Applet(s) 943 software.
  • WMA Wallet Management Applet
  • PPSE Payment Procedure Secure Elements
  • Payment Applet(s) 943 software When a payment applet 943 is provisioned into the SE 940 of the mobile device, it is located in a secure domain within the SE where external parties may not have access to the account sensitive information that is stored within the payment applet.
  • PPSE 942 manages relevant Application ID and Application label of the payment applet for selection.
  • WMA 941 is required for the management of mobile wallet cards stored within mobile wallet application.
  • WMA 941 will store duplicate payment applet account information so that mobile wallet application may access the account specific information stored within the SE. Like the contactless payment applets, WMA 941 is stored in a separate security domain within the SE.
  • FIG. 10 is a flow diagram illustrating a retry mechanism which operates to ensure successful provisioning process via OTA proxy.
  • OTA proxy is designed to authenticate its connection to the TSM server.
  • TSM makes a request to a third party messaging platform or a mobile push server to wake up OTA proxy.
  • OTA proxy Once OTA proxy is woken up, it connects to the TSM in step 1002.
  • OTA proxy After a preset period of time, OTA proxy checks to see if the connection to the TSM was made in step 1003.
  • TSM will reattempt to connect to the OTA Proxy by submitting another request to the mobile server as described in step 1001. However, if no connection is made after a preset N number of retries, TSM will log the attempt to wake up the OTA Proxy as a failure. Notification of this failure may be provided to the requesting SP.
  • TSM checks the SE type and status for provisioning in step 1004. Subsequently, TSM processes the information and produce APDU commands to send over to OTA Proxy in step 1005. If the connection to the OTA proxy is disconnected during the sending of APDU commands or TSM system receives unusable data, then OTA proxy will retry its connection to the TSM system as defined in 1002 and subsequent processes will be executed. However, if session continues to disconnect or unusable data is returned after the Nth try, a failure is logged at the TSM server and notification will be sent to the relevant parties.
  • the TSM will reattempt to connect to the OTA Proxy and resend the provisioning data to the OTA proxy by repeating steps 1002 to 1005.
  • TSM will log the attempt to provision the requested data as a failure. Notification of this failure may be provided to the requesting SP.
  • the OTA proxy relays the provisioning data to the SE in step 1007.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Finance (AREA)
  • Computing Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Telephone Function (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

A method for over-the-air (OTA) provisioning a non-Universal Integrated Circuit Card (UICC) type secure element (SE) of a mobile device, including receiving a request to initialize an OTA proxy of a mobile device; initializing the OTA proxy; receiving provisioning data through the OTA proxy; and provisioning the received data into the SE, in which the SE is a non-UICC type SE. A mobile device to provision secure data OTA in a non-UICC type SE including an OTA proxy to connect to a Trusted Service Manager (TSM) system, and to receive provisioning data from the TSM system; a near-field-communication (NFC) enabled chip to conduct a contactless transaction; and a SE to store information provisioned through OTA proxy, in which the SE is a non-UICC type SE.

Description

SYSTEM AND METHOD FOR PROVISIONING OVER THE AIR OF CONFIDENTIAL INFORMATION ON MOBILE COMMUNICATIVE DEVICES WITH NON-UICC SECURE ELEMENTS
The following description relates to over-the-air provisioning of virtual cards on a mobile device, such as a mobile communication terminal, with a non-Universal Integrated Circuit Card (UICC) type secure element.
With the advent of advancing mobile technology, more features have been integrated into the mobile devices. From GPS applications to mobile office products, mobile device, such as a mobile communication terminal, has become a necessity for everyday needs. In order to further utilize mobile technology to better cater to consumer’s daily requirements, attempts have been made to provide for a mobile financial management system to replace conventional physical wallets. Specifically, this mobile wallet functionality was sought to be realized through provisioning of card issuer’s account information directly into a secure element (SE) of the mobile device equipped with Near Field Communication (NFC) chipset. Provisioning may refer to a process of preparing and equipping an apparatus with information (e.g., financial information) to allow it to provide one or more services to its users. The SE may be a smart card chip capable of storing multiple applications, including of account specific information that may not be easily accessed by external parties. The model mobile wallet application may have the same composition as a conventional wallet, which may contain payment cards, member cards, transportation cards, and loyalty cards.
Mobile wallet functionality may be further enhanced by provisioning the user financial credential onto mobile devices equipped with Near Field Communication chipset (NFC enabled). Once the user financial credentials have been provisioned onto the NFC enabled mobile device, the provisioned NFC enabled device may transfer information or make payments to another NFC compatible device by coming near within a few centimeters of one another without physically contacting each other. This type of technology is conventionally referred to as “contactless” technology and a payment made with this technology is referred to as “contactless” payment. Despite the numerous benefits that are available utilizing the described technology, there has been no practical solution to provision sensitive user information to the NFC enabled mobile devices.
One possible solution for provisioning mobile wallet cards is to perform the provisioning at a secure facility controlled by the mobile wallet card issuer. However, this solution may require users to bring their mobile device to the physical mobile wallet card issuer for provisioning. This process has to be repeated for every mobile wallet card the user seeks to provision at different card issuer facility, making the concept of utilizing mobile wallet application impractical.
In light of this limitation, a new system and method has been developed providing for over-the-air (OTA) provisioning. Rather than relying on provisioning at physical locations, a method for provisioning financial account information via OTA has been sought. Through technological advancement, OTA provisioning has been provided for mobile device with the SE types of UICC, Services Identity Module (SIM), Universal Subscriber Identity Module (USIM) (herein referred collectively as UICC) cards via industry standard Short Message Service Point to Point (SMS-PP) and Bearer Independent Protocol (BIP) protocols. However, while SMS-PP protocol and Bearer Independent Protocol BIP allow OTA provisioning for UICC cards and their equivalents, it does not allow for OTA provisioning of MicroSD’s and Embedded SEs (i.e. non-UICC SEs), which may not support conventional Subscriber Identity Module Application Toolkit (SAT) / Universal Subscriber Identity Module Application Toolkit (USAT) / Card Application Toolkit (CAT) framework. As such, any mobile device with SE types MicroSD, Embedded SE, or other non-UICC SE type that does not support SMS-PP or BIP protocol may not be provisioned OTA with the conventional technology.
FIG. 1 illustrates a system diagram of a conventional OTA provisioning process through SMS PP protocol. FIG. 2 is a corresponding flow diagram illustrating a conventional method for OTA provisioning to mobile device using SMS PP protocol. Specifically, the referenced figures will provide for OTA provisioning via SMS PP protocol.
Typically, before the request is made to provision a mobile device, it is assumed that that the MNO has already registered all of its information including OTA key information in step 201 in an offline batch process. Once MNO registers all of the necessary information, mobile device may be ready for provisioning.
To begin the provisioning process, a user makes a request to a financial institution 18 to provision a mobile wallet card, in step 202. Then, the financial institution 18 will process the request and send the request along with necessary identifiers, such as Mobile Subscriber Integrated Services Digital Network Number (MSISDN) along with provisioning data to MNO OTA server 16 in step 203. MNO OTA Server 16 will then transmit the provisioning command to the mobile device 11 directly via SMS-PP protocol in step 204. MNO OTA Server 16 and MNO 19 may be owned by the same entity but illustrated as two different entities to show the different functions performed by the individual elements. More specifically, MNO 19 is shown only in step 201 to illustrate the pre-registration step that is performed by the MNO 19. Once registered, MNO OTA server primarily interacts with the mobile device 11 to provision the information provided by financial institution 18. Lastly, in step 205, mobile device 11 receives the message and performs the provisioning process into its SE (e.g., USIM, SIM, UICC).
Exemplary embodiments of the present invention provide a mobile device to provision information into a non-Universal Integrated Circuit Card (UICC) type secure element (SE) through an over-the-air (OTA) proxy. Exemplary embodiments of the present invention also provide a method for OTA provisioning a non-UICC SE of the mobile device.
Additional features of the invention will be set forth in the description which follows, and in part will be apparent from the description, or may be learned by practice of the invention.
Exemplary embodiments of the present invention provide a method for OTA provisioning a non- UICC type SE of a mobile device including receiving a request to initialize an OTA proxy of a mobile device, initializing the OTA proxy, receiving provisioning data through the OTA proxy, and provisioning the received data into the SE, the SE being a non-UICC type SE.
Exemplary embodiments of the present invention provide a method for OTA provisioning a non- UICC type SE including receiving a request to initialize an OTA proxy of a mobile device from a Trusted Service Manager (TSM) system; initializing the OTA proxy; communicating, by the mobile device, with the TSM system through the OTA proxy; retrieving mobile device information and SE information, in which the SE information includes an SE status and an SE type; receiving a key from the TSM system for accessing the SE, in which the key includes at least one of an initial issuer master key and a final issuer master key; securing the SE by injecting the corresponding key to the SE based on its status; receiving provisioning data; and provisioning the received data into the SE, the SE being a non-UICC type SE.
Exemplary embodiments of the present invention provide a mobile device to provision secure data OTA in a non-UICC type SE including an OTA proxy to connect to a TSM system, and to receive provisioning data from the TSM system; a near-field-communication (NFC) enabled chip to conduct a contactless transaction; and a SE to store information provisioned through OTA proxy, the SE being a non-UICC type SE.
It is to be understood that both foregoing general descriptions and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed. Other features and aspects will be apparent from the following detailed description, the drawings, and the claims.
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention, and together with the description serve to explain the principles of the invention.
FIG. 1 is a system diagram of a prior art OTA provisioning process through SMS PP protocol.
FIG. 2 is a flow diagram illustrating a method for prior art OTA provisioning process through SMS PP protocol.
FIG. 3 is a system diagram of a TSM ecosystem supporting the OTA provisioning process through OTA proxy according to an exemplary embodiment of the present invention.
FIG. 4 is a block diagram of an example TSM system, its components, and its relationship with external parties according to an exemplary embodiment of the present invention.
FIG. 5 is a flow diagram illustrating steps a service provider must take in order to take advantage of the TSM architecture according to an exemplary embodiment of the present invention.
FIG. 6 is a flow diagram illustrating a method of obtaining a mobile wallet application with accompanying OTA proxy application according to an exemplary embodiment of the present invention.
FIG. 7 is a flow diagram illustrating a high level OTA provisioning process though OTA proxy according to an exemplary embodiment of the present invention.
FIG. 8 is a flow diagram illustrating in detail a method of verifying SE types and status as required to provision into various types of SEs according to an exemplary embodiment of the present invention.
FIG. 9 is a system diagram depicting mobile device that has installed a mobile wallet application, accompanying OTA Proxy application and wallet management applet, and payment applets according to an exemplary embodiment of the present invention.
FIG. 10 is a flow diagram illustrating operation of a retry mechanism to ensure reliable data transmission according to an exemplary embodiment of the present invention.
The invention is described more fully hereinafter with references to the accompanying drawings, in which exemplary embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these exemplary embodiments are provided so that this disclosure is thorough, and will fully convey the scope of the invention to those skilled in the art. It will be understood that for the purposes of this disclosure, “at least one of each” will be interpreted to mean any combination the enumerated elements following the respective language, including combination of multiples of the enumerated elements. For example, “at least one of X, Y, and Z” will be construed to mean X only, Y only, Z only, or any combination of two or more items X, Y, and Z (e.g. XYZ, XZ, YZ, X). Throughout the drawings and the detailed description, unless otherwise described, the same drawing reference numerals are understood to refer to the same elements, features, and structures. The relative size and depiction of these elements may be exaggerated for clarity, illustration, and convenience.
FIG. 3 is a system diagram of a Trusted Service Manager (TSM) ecosystem supporting the over-the-air (OTA) provisioning process through OTA proxy according to an exemplary embodiment of the present invention.
As shown in FIG. 3, an example system employing TSM technology with OTA proxy provisioning includes a TSM system 30; mobile device 31; third party messaging platform 32; network 33; financial institution 34; Mobile Network Operator (MNO) 35; handset manufacturer 36; and card manufacturer 37. Before TSM system may be fully utilized by the user and its participants, service providers (SP) such as identified in 34 - 37 typically go through a pre-registration process such as that outlined in FIG. 5.
The handset manufacturers 36 may include embedded secure element (SE) producer, and card manufacturers 37 may include producers of micro secure digital (SD) SE. As different SE manufacturer may provide for a different OTA keys than Universal Integrated Circuit Card (UICC) SE devices, handset manufacturers 36 and card manufacturers 37 may provide their OTA keys to their respective devices in the pre-registration process mentioned above.
Exemplary embodiments of the invention provide for OTA proxy to be connected with TSM system only during usage as it will conserve technical resources. As such, OTA proxy will be in a sleep mode as a default until it is awaken for its utility. To provide for an awakening mechanism, a third party messaging platform 32(e.g. Cloud to Device Messaging (C2DM)) may be utilized to wake the OTA proxy, which in turn will connect with the TSM system for usage. In an example, the third party messaging platform 32 may also be used to send a Short Message Service (SMS) message or a Multimedia Messaging Service (MMS). When TSM system sends a message to the third party messaging platform 32 (i.e., a push message server), with the wake up command and identifying information, the third party messaging platform 32 in turn sends a message to the identified mobile device to wake up OTA proxy residing within the mobile device. Once awake, OTA proxy will collect the mobile device and SE information and connect to the TSM system for provisioning or other utility.
Finally, once the mobile device 31 has been provisioned with contactless card applets and is NFC enabled, an owner of the mobile device may make a purchase at the NFC enabled Point-of-Sale (POS) 40 merchant by waving the NFC enabled mobile device at the corresponding NFC enabled POS device. Subsequently, once a purchase is made with the NFC enabled mobile device, the acquirer network 39 and payment processor 38 work together to ensure the payment gets updated at the financial institution 34. This end user application, however, does not involve the described TSM ecosystem and is illustrated to provide a description of a complete ecosystem.
Further, a TSM system may include multiple components for more efficient processing. FIG. 4 is a system diagram illustrating a TSM system and its relationship to external parties according to an exemplary embodiment of the present invention.
A TSM system 30 may be comprised of a Card & Application Management System (CAMS) 41; Key Management System (KMS) 42; Post Issuance Processor (PIP) 43; Customer Care, Billing, Participant System (CBPS) 44; Wallet Management System (WMS) 45; Operation Maintenance & Administration (OM&A) 46; and External System Interface (ESI) 47.
Component CAMS 41 may be responsible for managing life cycle of SE, secure domains, and applets. Life cycle refers to the various status of the respective device or application. In an example, life cycle of a SE may include Operating System (OS) native, initialized, and secured. Life cycle of an applet may include lock and unlock. Some of the functionalities offered by the CAMS 41 will be management of SE type, SE profile, SE ID, application profile, and card profile. Each SE is identified individually and controlled by CAMS 41 with its own SE ID (Card Reference Number (CRN), Card Image Number (CIN), Card Production Life Cycle (CPLC), Card Serial Number (CSN)).
Component KMS 42 may be responsible for all of key management for allowing secure transactions. This may include secure log in, access control, audit, key profile management, key management, key profile exchange and recovery, and delegated management.
Component PIP 43 is primarily responsible for provisioning information into the mobile device, which may include preparation of data to be provisioned and the actual execution of sending and receiving provisioning messages provided in Application Protocol Data Units (APDU). APDU may refer to a communication unit between a reader and a card. The structure of the APDU described in more detail by the ISO 7816 standards.
Component CBPS 44 may be responsible for customer management. It may keep customer account status as well as link data once SP requests service subscription. The CBPS 44 may modify the status of the SPs related to the customer as specified events occur (e.g. stolen handset) or as requested by the SP.
Component WMS 45 may be responsible for management of wallet application and its associated mobile card widgets stored therein. This component may provide a mobile ID to associate the wallet application stored in the user’s mobile device as well as all of the individual widgets stored in the wallet application. In addition, this component will store any of the user preferences made by the wallet owner (e.g. language, font, default card, etc.). This component may hold the master configuration which may provide synchronization benefit for the wallet application.
Component OM&A 46 may be responsible for overall system monitoring and maintenance. Further, OM&A may also facilitate external managers to access TSM directly.
Component ESI 47 may provide for an interface for all external parties to send and receive data. As external parties may have specific protocol they utilize, ESI 47 has the capability to translate commands and requests arriving or leaving the TSM system as necessary.
All of the above described components may reside within the TSM system or separately as deemed necessary.
The described TSM system is a third party entity positioned to consolidate all of the information from various service providers (SP) including, financial institutions, MNOs, Handset Manufacturers, and Card Manufacturers. As TSM holds all of the information from various parties, the mobile device need only to interact with the TSM system rather than various discrete entities. In sum, the described TSM system acts as an integration point for all of the external parties the mobile device may have to deal with, providing for a seamless and more efficient operation of mobile services.
FIG. 5 illustrates a pre-registration process that may take place before provisioning services into the mobile device according to an exemplary embodiment of the invention. In an example, SPs may first register their information into the TSM system for use by the TSM system. A SP may be any entity that seeks to provision its services onto the end mobile device.
In step 501, SPs’ information has been registered into the TSM system. This process may be achieved by various methods. For example, the SP may send an encrypted email with basic registration information along with PGP public key. Registration may be achieved in person, by phone, through an automated system or any other method available to exchange information. TSM administrator may then enter SP’s basic information into the TSM system and provide a unique SP ID, transport key ID, and the participant type (MNO, service provider, SE manufacturer, application). TSM administrator may be a person, an automated system, or a separate entity. Afterwards, TSM system may creates a participant account and generate secure token for the correlating SP ID. Once that is accomplished, TSM encrypts the SP account information in an encrypted email to send to the requesting SP.
In step 502, a transport key is exchanged between the TSM system and the SP. Transport key serves to provide secure transmission of sensitive data between various parties. Such security may be provided through encryption, cryptographic transformation of data through Message Authentication Code (MAC), or other conventional security measures. The SP requests transport key sets to the TSM system. The TSM checks for duplicate keys assigned to the requesting SP, and if no such key has been assigned, then TSM generates transport key sets inside a Hardware Security Module (HSM). In an example, transport key sets may include three numbered keys including an encryption key (ENC), data encryption key (DEK), and message authentication code (MAC). TSM exports the generated keys in an encrypted form using the PGP key provided by the SP in step 501. Once the transport key set has been exchanged between the parties, the following SP related profiles may be provided to the TSM system: Loadfile Profile 503, application profile 504, key profile & key 505, SE profile 506, and handset profile 507.
Loadfile profile 503 describes the application code file that could contain one or more applications or describes the load files that make up an application code. Application profile 504 describes a smart card application as a meta data, which will be utilized later for creating an instance of the application. Key profile & key 505 describes basic profile information and key information as a metadata, which will be utilized for creating an instance of the key. ISD master keys are also registered in the system, including Initial Supplier Key (ISK), Initial Issuer Master Key (KMC), and Final Issuer Master Key (CMK). SE profile 506 describes attributes of a smart card. And lastly, handset profile 507 describes attributes of a handset device, including NFC capability, supported SE types, and OTA channel support.
Once all of the necessary profiles have been provided to the TSM system, the TSM system will establish link between the provided profiles in step 508. The provided profiles may be provided to the TSM system in various ways. The profiles may be sent to the TSM system directly through the network, by physical embodiments of provided data, or any other conventional method that is available to transfer information. Once the provided profiles have been linked with one another, a check is conducted to verify compatibility with the aggregated business rules and or technical limitations in step 509. For example, a business rule may dictate that a certain MNO may not work with a SP for business reasons. Based on this business limitation, the TSM system may sever linkage between profiles to reflect this limitation. In addition, there may be some technical limitations in providing certain products to user mobile device, such as incompatible mobile operating systems. By configuring the described limitations in step 509, the mobile device user may access only the applications that may be valid to their mobile device and specific account attributes.
FIG. 6 shows a method for downloading OTA Proxy as an attached application to a SK C&C wallet mobile application according to an exemplary embodiment of the present invention.
In step 601, new mobile device is obtained by the user. The user in receipt of the mobile device initiates the payment card issuance request to the card provider in step 602. This request may be made in person, by phone, internet request, or via mobile web service. It is assumed that a physical credit card account already exists with the issuing payment card provider. Some of the information that may be required includes personal information and handset information (MNO, Mobile Subscriber Integrated Services Digital Network Number (MSISDN)). Once the financial institution receives the request by the user and authenticates the user as one of its customer, the respective financial institution will forward the request onto the TSM system in step 603.
When TSM system receives the request, TSM will first authenticate the SP account for its validity. TSM may then perform a check to verify existence of a mobile wallet application and an OTA proxy associated with the requesting user account in step 604 in its system. In an example, the mobile wallet application may include an accompanying OTA proxy application, which may also be indicated in the user account. Alternatively, the mobile wallet application may not include the OTA proxy application, which may be obtained separately from the mobile wallet application.
Further, the TSM system may conduct this check by using identifying information provided by the user, which may include a mobile phone number, account number, birth date, or other identifying information. Alternatively, in an example, the TSM system may perform a check to verify the existence of the OTA proxy application associated with the user account separately from the mobile wallet application.
Accordingly, if a user is a new customer, the TSM system may be unable to identify a mobile wallet application or an OTA proxy application associated with the user account. However, if the new customer later obtains and activates a mobile wallet application, the TSM system may create a mobile wallet application associated with the user account identifying information when the user mobile device with the newly activated mobile wallet application connects to the TSM system. Further, if the mobile wallet application also includes a corresponding OTA proxy application, information regarding the OTA proxy application will also be noted on the user account. Similarly, if the new customer later obtains and OTA proxy separately from the mobile wallet application, the TSM system may update its account information to note the possession of the OTA proxy application independent of the mobile wallet application.
It should be noted as OTA proxy allows for provisioning account specific information OTA to non-UICC SEs, certain mobile wallet applications may opt to add OTA proxy as an accompanying application. However, it is possible to provide OTA proxy software application independent of the mobile wallet application. In an example, the TSM system will check for existence of both a mobile wallet and an OTA proxy application. As some of the mobile wallet applications may have accompanying OTA proxy application, existence of one may provide existence of the other. However, if only one application is tied to the requesting user account, the TSM system will provide the deficient application for the user. Accordingly, if OTA proxy application is not associated with the user account, OTA proxy may be provided to the requesting user as described in step 606 below. Once the OTA proxy application is downloaded onto a mobile device, OTA proxy may integrate itself with a third party wallet application to allow OTA provisioning into the third party wallet application. While OTA proxy may be used in the mobile wallet application, it should be noted that OTA proxy software application is not limited to its use with the mobile wallet application and may be integrated with other software applications for mobile devices.
If the requesting user in step 602 has a mobile wallet application with the accompanying OTA proxy as determined in step 605, OTA provisioning process will occur immediately in step 609.
However, if the requesting user in step 602 does not have a mobile wallet application or the accompanying OTA proxy as determined in step 605, TSM will send a push SMS message with a download URL to the requesting mobile device in step 606. SMS message may include URL, MSISDN, service ID, and service account number.
In step 607, the requesting user will view the SMS and triggers the attached URL to form a WAP push message to the TSM system with the appropriate identifier. As a response, TSM system will authenticate the customer and customer’s handset by the given token and HTTP headers. TSM system will then send the mobile wallet and the accompanying OTA proxy application in step 608. However, mobile wallet and the OTA proxy application may be obtained in various other ways as well and are not limited to the SMS message as described above. The specified applications may be downloaded directly to the requesting mobile device, sent to the user in a physical medium storing the applications, or by any other suitable method of providing an application to a mobile device.
Ideally, once the mobile wallet application has been installed onto the mobile device, the customer will launch the mobile wallet application. Once launched, the mobile wallet application, through OTA proxy, will gather SE information (Card Production Life Cycle (CPLC), Card Serial Number (CSN), Card Image Number (CIN), Integrated Circuit Card Identification (ICCID)) and handset information (International Mobile Equipment Identity (IMEI)/Mobile Equipment Identifier (MEID), MSISDN) and connect to the TSM system for activation. If the SE is a UICC type, it will read both the SE information and handset information from the UICC card. If however, SE is a Micro SD or Embedded SE, OTA Proxy will read the CIN from the SE and then obtain MSISDN and IMEI/MEID via mobile device application programming interface (API). Based on the information provided by OTA proxy, the TSM system will authenticate the received information and create a Mobile ID for the installed wallet application.
Once the mobile wallet application and accompanying OTA proxy has been installed, the originally requested mobile wallet card may be provisioned through OTA via OTA proxy in step 609.
FIG. 7 is a flow diagram illustrating the general OTA provisioning process via OTA proxy according to an exemplary embodiment of the present invention. Once the requesting mobile device has installed a mobile wallet and accompanying OTA proxy application, provisioning process follows the process outlined below.
Prior to any provisioning of mobile card application, the issuing service provider will be ideally pre-registered into the TSM system as shown in step 701 as described in detail in FIG. 5. Once registered, a customer may select a registered SP’s payment card for provisioning by the mobile device owner in step 702.
Once a request has been made to provision the selected mobile payment card, the financial institution service provider will request its issuance to the TSM system in step 703. Request for service subscription may include identifying information such as MSISDN along with encrypted account related information that is to be provisioned.
TSM in response to the request will begin preparation of the provisioning data in step 704. Upon receipt of provisioning information, internal data link will be conducted to log the service request made by the financial institution. One of the information that will be maintained is a portion of the payment card account data which will be utilized to identify card account to the requesting user within the TSM system. For security purposes, the entire account number need not be maintained.
In step 705, TSM system transmits an OTA proxy wake-up request to a push server.
Once the request has been logged in the TSM system, TSM will then push the wake up request command to a third party messaging platform or a mobile push server (e.g. C2DM) along with identifying information (i.e. MSISDN), which will in turn relay the command to wake up the OTA proxy residing in the requesting user’s mobile device in step 706.
In a preferred embodiment of this invention, OTA proxy will be expected to be asleep prior to being awaken. Once OTA proxy is woken, it connects to the TSM system automatically. Upon connection, OTA Proxy gathers the SE and handset specific information and sends the collected information to TSM for verification. However, OTA Proxy may gather the specified information prior to connection or provide the information to the TSM system in a separate process. In receipt of provided information, the TSM system conducts an internal check to see if the MSISDN, IMEI/MEID, CIN/ICCID of handset and SE match the user information stored in the TSM server. As this check is conducted every time OTA proxy is initialized, additional security is provided verifying account specific information storage SE with the mobile device which houses the SE.
Once OTA proxy connects to TSM with the collected information and security check has been conducted, TSM will analyze the provided data for any additional processing SE may require and the best mode of provisioning the information into the respective mobile device in step 707. This analysis is described in detail in FIG. 8.
After the best mode of provisioning has been determined, TSM prepares the data as necessary and sends the provisioning data in APDU format to the OTA proxy in step 708. OTA proxy in receipt of APDU commands by TSM relays the provisioning data to the SE in step 709.
OTA proxy is allowed access to the non-UICC SEs through the various keys that have been loaded onto the TSM device along with SE specific APIs which are exchanged offline. Through the incorporation of these attributes, OTA proxy protocol is provided access to the SE to be provisioned.
FIG. 8 illustrates a detailed description for checking of SE status and type performed by the TSM system prior to provisioning as outlined in step 707 in FIG. 7.
In step 801, after OTA proxy receives a wake up command from the third party messaging platform or the mobile push server originating from the TSM system, OTA wakes up and connects to the TSM system to retrieve the requested command.
In step 802, the OTA proxy retrieves SE and mobile device specific information such as MSISDN and CIN. Once the necessary information has been gathered, OTA proxy sends the information to TSM in step 803 for verification and analysis of requesting device. Communications between the TSM system and the OTA proxy may be provided through a standard mobile network, wireless network, or similar mechanisms.
In step 804, once the TSM system receives mobile device and SE information, the TSM system checks the status of SE. As processing of stored SE is dependent on its status, analysis of SE status is important prior to its provisioning. SE equipped in the mobile device may have any of the 3 statuses: OS native, initialized, and secured. In an example, OS Native status may refer to a status of the SE that is not initialized according to manufacturer’s initialization method, initialized status may refer to an administrative card production state, and secured status may refer to an intended operating life cycle in post-issuance.
If the status of SE is determined to be as already secured in step 805, then it proceeds to step 809 which checks for the type of SE.
If the status of SE is determined as initialized in step 805, then the TSM will provide a final issuer master key for provisioning prior to proceeding to step 809.
If the status of SE is determined to be OS native in step 805, then pre-personalization process may take place in step 806. Afterwards, an initial issuer master key may be injected into the SE for provisioning in step 807. Once the initial issuer master key is injected, a final issuer master key may be injected as shown in step 808, prior to proceeding to step 809.
After status of the SE has been determined, an analysis of SE type is performed in step 809 in order to determine the type of protocol that should run within OTA proxy in order to provision into the identified SE.
If the SE is a UICC type or an embedded type, application is ready to provision in step 811 and moves to step 708 in FIG. 7.
On the other hand, if the SE is a Micro SD type, additional process specific protocol should be executed for MicroSD in step 810, before it can be ready to be provisioned in step 811.
FIG. 9 illustrates exemplary provisioned mobile device according to an embodiment of the present invention. The mobile device illustrated in FIG. 9 represents an exemplary mobile phone, however, the mobile device embodying the present invention may be any mobile device, such as a personal digital assistant (PDA), a mobile computer device, or other similar mobile communicative devices.
Once the mobile device 31 has been provisioned according the present disclosure, the mobile device 31 may be comprised of the apparatus itself; mobile wallet application 91 software; OTA Proxy application 92 software; Device Stack 93 software; and Secure Element 94 hardware.
Mobile wallet application 91, such as a SK C&C wallet, provides the user with a graphically displayed mobile wallet, which includes various components such as payment widgets that are tied to the installed NFC enabled payment applets 943, as well as other components (e.g. coupons, transport pass, phone bill, and etc.).
The OTA Proxy 92 is a mobile client which supports OTA post-issuance related services to the secure element in a mobile device. More specifically, OTA proxy provisions confidential information, such as financial applications and related account information into non-UICC type SE equipped on a mobile device. As SE types, Micro SD and Embedded SEs cannot support conventional SAT/SUSAT/CAT framework, OTA provisioning is unavailable using the conventional technology for the specified SE types. OTA Proxy over OTA overcomes this limitation and allows any external party to send data to mobile devices equipped with the specified non-UICC SE types. However, if desired, OTA proxy can also provide an alternative protocol, over the conventional protocol, to UICC SE devices which can support conventional SAT/SUSAT/CAT framework.
In an example, OTA Proxy is able to gain access to the non-UICC SE types by using the keys to the SE provided by the manufacturers. The respective keys to the non-UICC types may be obtained by having the manufacturers register the information to the TSM system, through an offline exchange, or any other conventional methods. Further, the obtained keys may be integrated into the OTA Proxy application or may be used separate from the OTA Proxy application.
Device Stack 93 is a standard handset platform which facilitates the mobile device operations. No modification is done to this component and is illustrated only to provide an accurate visual representation.
SE 94 may be further comprised of a Wallet Management Applet (WMA) 941 software; Payment Procedure Secure Elements (PPSE) 942 software; and Payment Applet(s) 943 software. When a payment applet 943 is provisioned into the SE 940 of the mobile device, it is located in a secure domain within the SE where external parties may not have access to the account sensitive information that is stored within the payment applet.
In order for retailers and manufacturers to select a specific payment applet, PPSE 942 manages relevant Application ID and Application label of the payment applet for selection. However, as mobile devices cannot access the payment applets directly, a separate WMA 941 is required for the management of mobile wallet cards stored within mobile wallet application.
During the provisioning process, WMA 941 will store duplicate payment applet account information so that mobile wallet application may access the account specific information stored within the SE. Like the contactless payment applets, WMA 941 is stored in a separate security domain within the SE.
FIG. 10 is a flow diagram illustrating a retry mechanism which operates to ensure successful provisioning process via OTA proxy. As connections between mobile device and external entities may be subject to disconnection for various reasons, OTA proxy is designed to authenticate its connection to the TSM server.
In step 1001, TSM makes a request to a third party messaging platform or a mobile push server to wake up OTA proxy. Once OTA proxy is woken up, it connects to the TSM in step 1002. After a preset period of time, OTA proxy checks to see if the connection to the TSM was made in step 1003.
If no connection was made, or the connection was lost, TSM will reattempt to connect to the OTA Proxy by submitting another request to the mobile server as described in step 1001. However, if no connection is made after a preset N number of retries, TSM will log the attempt to wake up the OTA Proxy as a failure. Notification of this failure may be provided to the requesting SP.
Once connection to the TSM is made by the OTA Proxy, TSM checks the SE type and status for provisioning in step 1004. Subsequently, TSM processes the information and produce APDU commands to send over to OTA Proxy in step 1005. If the connection to the OTA proxy is disconnected during the sending of APDU commands or TSM system receives unusable data, then OTA proxy will retry its connection to the TSM system as defined in 1002 and subsequent processes will be executed. However, if session continues to disconnect or unusable data is returned after the Nth try, a failure is logged at the TSM server and notification will be sent to the relevant parties.
If the session disconnects or garbage provisioning data is determined to have transmitted from the TSM system to the OTA proxy in step 1006, the TSM will reattempt to connect to the OTA Proxy and resend the provisioning data to the OTA proxy by repeating steps 1002 to 1005. However, if the session continues to disconnect during the transmission of the provisioning data or garbage provisioning data continues to be sent after a preset N number of retries, TSM will log the attempt to provision the requested data as a failure. Notification of this failure may be provided to the requesting SP. Alternatively, if the provisioning data is successfully received by the OTA proxy, then the OTA proxy relays the provisioning data to the SE in step 1007.
It will be apparent to those skilled in the art that various modifications and variation can be made in the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

Claims (26)

  1. A method for over-the-air (OTA) provisioning a non-Universal Integrated Circuit Card (UICC) type secure element (SE) of a mobile device, comprising:
    receiving a request to initialize an OTA proxy of a mobile device;
    initializing the OTA proxy;
    receiving provisioning data through the OTA proxy; and
    provisioning the received data into the SE, wherein the SE is a non-UICC type SE.
  2. The method of claim 1, further comprising:
    requesting the OTA proxy from a Trusted Service Manager (TSM) system;
    receiving OTA proxy installation information; and
    installing the OTA proxy in the mobile device.
  3. The method of claim 1, wherein initializing the OTA proxy comprises:
    waking the OTA proxy from its dormant state;
    gathering mobile device information;
    communicating, by the mobile device, with a TSM system through the OTA proxy; and
    transmitting the mobile device information to the TSM system.
  4. The method of claim 1, wherein receiving provisioning data through the OTA proxy comprises:
    receiving the provisioning data as Application Protocol Data Unit (APDU) commands through the OTA proxy, wherein the TSM system converts the provisioning data into APDU commands.
  5. The method of claim 4, wherein provisioning the received data into the non-UICC type SE comprises provisioning the APDU commands, wherein the non-UICC type SE comprises a Micro SD, an Embedded SE, or a SE that does not support either a Short Message Service Point to Point (SMS-PP) protocol or a Bearer Independent Protocol (BIP).
  6. The method of claim 1, wherein the request to initialize the OTA proxy is received through a push server.
  7. The method of claim 1, further comprising preparing the SE for provisioning, wherein preparing the SE for provisioning comprises:
    retrieving mobile device information and SE information, wherein the SE information comprises an SE status and an SE type;
    receiving a key from the TSM system for accessing the SE; and
    securing the SE based on the SE status.
  8. The method of claim 7, wherein the mobile device information comprises at least one of International Mobile Equipment Identity (IMEI), Mobile Equipment Identifier (MEID), and Mobile Subscriber Integrated Services Digital Network Number (MSISDN).
  9. The method of claim 7, wherein the key comprises at least one of an initial issuer master key and a final issuer master key.
  10. The method of claim 9, wherein securing the SE comprises providing the initial issuer master key and the final issuer master key to the SE in response to a determination that the SE status is Operating System (OS) native.
  11. The method of claim 9, wherein securing the SE comprises providing the final issuer master key to the SE in response to a determination that SE status is initialized.
  12. The method of claim 7, wherein preparing the SE for provisioning further comprises processing a protocol to enable the SE to be provisioned, the SE type being a Micro SD type.
  13. The method of claim 3, wherein communicating, by the mobile device, with the TSM system through the OTA proxy comprises reattempting to communicate with the TSM system in response to a failure to communicate with the TSM system by the mobile device.
  14. The method of claim 1, wherein receiving provisioning data comprises reconnecting to the TSM system and requesting to receive the provisioning data in response to receipt of unusable data or in response to a session disconnection during an attempted receiving of the provisioning data.
  15. A method for over-the-air (OTA) provisioning a non-Universal Integrated Circuit Card (UICC) type secure element (SE), comprising:
    receiving a request to initialize an OTA proxy of a mobile device from a Trusted Service Manager (TSM) system;
    initializing the OTA proxy;
    communicating, by the mobile device, with the TSM system through the OTA proxy;
    retrieving mobile device information and SE information, wherein the SE information comprises an SE status and an SE type;
    receiving a key from the TSM system for accessing the SE, wherein the key comprises at least one of an initial issuer master key and a final issuer master key;
    securing the SE by providing the corresponding key to the SE based on its status;
    receiving provisioning data; and
    provisioning the received data into the SE, wherein the SE is a non-UICC type SE.
  16. The method of claim 15, further comprising processing a protocol for enabling the SE to receive provisioning data.
  17. The method of claim 15, wherein the request to initialize the OTA proxy is received at the mobile device through a push server.
  18. The method of claim 15, wherein the non-UICC type SE comprises a Micro SD, an Embedded SE, or a SE that does not support either a Short Message Service Point to Point (SMS-PP) protocol or a Bearer Independent Protocol (BIP).
  19. A mobile device to provision secure data over-the-air (OTA) in a non-Universal Integrated Circuit Card (UICC) type secure element (SE), comprising:
    an OTA proxy to connect to a Trusted Service Manager (TSM) system, and to receive provisioning data from the TSM system;
    a near-field-communication (NFC) enabled device to conduct a contactless transaction; and
    a SE to store information provisioned through OTA proxy, wherein the SE is a non-UICC type SE.
  20. The mobile device of claim 19, wherein the OTA proxy is configured to transmit mobile device information and SE information to the TSM system, wherein the SE information comprises an SE status and an SE type.
  21. The mobile device of claim 20, wherein the mobile device information comprises at least one of International Mobile Equipment Identity (IMEI), Mobile Equipment Identifier (MEID), and Mobile Subscriber Integrated Services Digital Network Number (MSISDN).
  22. The mobile device of claim 20, wherein the OTA proxy is configured to receive a key from the TSM system to access the SE based on the SE information sent to the TSM system, wherein the key comprises at least one of an initial issuer master key and a final issuer master key.
  23. The mobile device of claim 20, wherein the OTA proxy is further configured to receive a protocol to prepare the SE to be provisioned, the SE type being a Micro SD type.
  24. The mobile device of claim 19, wherein the mobile device further comprises a mobile wallet application comprising a widget corresponding to the information stored in the SE.
  25. The mobile device of claim 19, wherein the OTA proxy is to be installed OTA.
  26. The mobile device of claim 24, wherein the information stored in the SE comprises:
    a Payment Procedure Secure Elements (PPSE) to store a contactless card applet; and
    a wallet management applet (WMA) corresponding to the contactless card applet.
PCT/KR2011/009868 2010-12-30 2011-12-20 System and method for provisioning over the air of confidential information on mobile communicative devices with non-uicc secure elements WO2012091351A2 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP11853081.5A EP2659695A4 (en) 2010-12-30 2011-12-20 System and method for provisioning over the air of confidential information on mobile communicative devices with non-uicc secure elements
AU2011350197A AU2011350197A1 (en) 2010-12-30 2011-12-20 System and method for provisioning over the air of confidential information on mobile communicative devices with non-UICC secure elements
KR1020137019435A KR101514754B1 (en) 2010-12-30 2011-12-20 System and method for provisioning over the air of confidential information on mobile communicative devices with non-uicc secure elements
CN2011800616198A CN103262590A (en) 2010-12-30 2011-12-20 System and method for provisioning over the air of confidential information on mobile communicative devices with non-UICC secure elements
SG2013042999A SG190988A1 (en) 2010-12-30 2011-12-20 System and method for provisioning over the air of confidential information on mobile communicative devices with non-uicc secure elements

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201061428851P 2010-12-30 2010-12-30
US61/428,851 2010-12-30
US13/310,344 US9161218B2 (en) 2010-12-30 2011-12-02 System and method for provisioning over the air of confidential information on mobile communicative devices with non-UICC secure elements
US13/310,344 2011-12-02

Publications (2)

Publication Number Publication Date
WO2012091351A2 true WO2012091351A2 (en) 2012-07-05
WO2012091351A3 WO2012091351A3 (en) 2012-08-23

Family

ID=46383645

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2011/009868 WO2012091351A2 (en) 2010-12-30 2011-12-20 System and method for provisioning over the air of confidential information on mobile communicative devices with non-uicc secure elements

Country Status (6)

Country Link
EP (1) EP2659695A4 (en)
KR (1) KR101514754B1 (en)
CN (1) CN103262590A (en)
AU (1) AU2011350197A1 (en)
SG (1) SG190988A1 (en)
WO (1) WO2012091351A2 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3104635A1 (en) * 2015-06-09 2016-12-14 Deutsche Telekom AG Method for an improved installation of a secure-element-related service application in a secure element being located in a communication device, system and telecommunications network for an improved installation of a secure-element-related service application in a secure element being located in a communication device, program comprising a computer readable program code, and computer program product
CN113760326A (en) * 2021-07-21 2021-12-07 江铃汽车股份有限公司 Upgrading method and device, readable storage medium and vehicle
US11418494B2 (en) 2017-09-20 2022-08-16 Samsung Electronics Co., Ltd. Electronic device for supporting backup and reinstallation of mobile card
US20230196337A1 (en) * 2020-12-23 2023-06-22 China Unionpay Co., Ltd. Method, terminal device, server, system and storage medium for activating payment functions

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150339659A1 (en) * 2014-05-23 2015-11-26 Miguel Ballesteros System And Method For Payment Credential-Based Mobile Commerce
KR20160002321A (en) 2014-06-30 2016-01-07 삼성전자주식회사 Method and apparatus for receiving/transmitting a profile for communication service in a mobile communication system
WO2016003178A1 (en) * 2014-06-30 2016-01-07 삼성전자 주식회사 Method and device for transmitting and receiving profile for providing communication service in wireless communication system
CN105635268B (en) * 2015-12-28 2018-12-25 红豆电信有限公司 Trusted service manages cloud platform
CN108781358B (en) * 2016-03-30 2021-02-23 华为技术有限公司 Method for managing subscription information set in eUICC and related equipment
CN106101984B (en) * 2016-05-31 2019-08-02 东莞宇龙通信科技有限公司 A kind of the security module management method and terminal of NFC Mobile payment terminal
KR101944770B1 (en) * 2017-07-03 2019-04-17 주식회사 이비카드 System for providing traffic card service based on open api
CN110223060A (en) * 2019-05-21 2019-09-10 四川精创国芯科技有限公司 A kind of multi-chip intelligent card management platform
US11683325B2 (en) * 2020-08-11 2023-06-20 Capital One Services, Llc Systems and methods for verified messaging via short-range transceiver
CN114501416A (en) * 2020-10-26 2022-05-13 中移互联网有限公司 BIP gateway-based SIM card application processing method, device and equipment
CN113950036B (en) * 2021-10-15 2023-06-09 中国联合网络通信集团有限公司 NFC capability synchronization method, UICC, terminal, equipment and medium

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009141805A2 (en) 2008-05-22 2009-11-26 Nxp B.V. Methods, systems and arrangements for wireless communication with near-field communication terminals
US20100291904A1 (en) 2009-05-13 2010-11-18 First Data Corporation Systems and methods for providing trusted service management services

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1455499B1 (en) * 2003-03-03 2009-09-09 Nokia Corporation Security element commanding method and mobile terminal
US7370189B2 (en) * 2004-09-30 2008-05-06 Intel Corporation Method and apparatus for establishing safe processor operating points in connection with a secure boot
US7840687B2 (en) * 2007-07-11 2010-11-23 Intel Corporation Generic bootstrapping protocol (GBP)
HU230695B1 (en) * 2007-10-20 2017-09-28 Andrá Vilmos Method of preparing storing and method of storing single user access information into safe storage unit of a communication device
ES2525469T3 (en) * 2008-03-31 2014-12-23 Orange Procedure for accessing and transferring data related to an application installed in a security module associated with a mobile terminal, security module, management server and associated system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009141805A2 (en) 2008-05-22 2009-11-26 Nxp B.V. Methods, systems and arrangements for wireless communication with near-field communication terminals
US20100291904A1 (en) 2009-05-13 2010-11-18 First Data Corporation Systems and methods for providing trusted service management services

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2659695A4

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3104635A1 (en) * 2015-06-09 2016-12-14 Deutsche Telekom AG Method for an improved installation of a secure-element-related service application in a secure element being located in a communication device, system and telecommunications network for an improved installation of a secure-element-related service application in a secure element being located in a communication device, program comprising a computer readable program code, and computer program product
US10097553B2 (en) 2015-06-09 2018-10-09 Deutsche Telekom Ag Installation of a secure-element-related service application in a secure element in a communication device, system and telecommunications
US11418494B2 (en) 2017-09-20 2022-08-16 Samsung Electronics Co., Ltd. Electronic device for supporting backup and reinstallation of mobile card
US20230196337A1 (en) * 2020-12-23 2023-06-22 China Unionpay Co., Ltd. Method, terminal device, server, system and storage medium for activating payment functions
CN113760326A (en) * 2021-07-21 2021-12-07 江铃汽车股份有限公司 Upgrading method and device, readable storage medium and vehicle

Also Published As

Publication number Publication date
AU2011350197A1 (en) 2013-06-20
WO2012091351A3 (en) 2012-08-23
KR20130108443A (en) 2013-10-02
CN103262590A (en) 2013-08-21
AU2011350197A8 (en) 2013-06-27
EP2659695A4 (en) 2017-08-02
KR101514754B1 (en) 2015-04-24
SG190988A1 (en) 2013-07-31
EP2659695A2 (en) 2013-11-06

Similar Documents

Publication Publication Date Title
US9161218B2 (en) System and method for provisioning over the air of confidential information on mobile communicative devices with non-UICC secure elements
WO2012091351A2 (en) System and method for provisioning over the air of confidential information on mobile communicative devices with non-uicc secure elements
WO2012091349A2 (en) System and method for managing mobile wallet and its related credentials
RU2630419C2 (en) Integrated mobile trusted services manager
AU2010249101B2 (en) Systems and methods for providing trusted service management services
US9332009B2 (en) Use, provision, customization and billing of services for mobile users through distinct electronic apparatuses
US20120303310A1 (en) Systems and Methods for Providing Test Keys to Mobile Devices
KR101514753B1 (en) System and method for secure containment of sensitive financial information stored in a mobile communication terminal
CA2958267A1 (en) System and method for management of payee information
US20090015374A1 (en) User authentication system and method
KR101419138B1 (en) Master trusted service manager
JP4979723B2 (en) COMMUNICATION METHOD, COMMUNICATION SYSTEM, SERVICE PROVIDING BASE ACCESS METHOD
KR101561534B1 (en) System and method for managing ota provisioning applications through use of profiles and data preparation
KR20130075752A (en) Method for near field transaction by using providing dynamic created code
JP2022166919A (en) Information processing system, portable reading terminal, and software product
AU2014200310A1 (en) Systems and methods for providing trusted service management services
AU2016203394A1 (en) Systems and methods for providing trusted service management services
KR20100103441A (en) Payment device
KR20120029454A (en) Method mapping payment means

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: 11853081

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2011853081

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2011350197

Country of ref document: AU

Date of ref document: 20111220

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20137019435

Country of ref document: KR

Kind code of ref document: A