KR102151579B1 - Method and system for generating an advanced storage key in a mobile device without secure elements - Google Patents

Abstract

A method of constructing an advanced storage key includes, in a memory of a mobile device, at least (i) device information associated with the mobile device, (ii) a program code associated with the first program, including an instance identifier, in a first program. Storing an associated program code, and (iii) a program code associated with the second program, the program code associated with the second program comprising a first key; Generating a device fingerprint associated with the mobile device based on the device information through execution of a code associated with the first program; Generating a random value through execution of a code related to the first program; Constructing a diversifier value based on the generated device fingerprint, the generated random value, and an instance identifier included in a code associated with the first program; And obtaining a storage key by decrypting the constructed pluralization value using a first key stored in the code associated with the second program through execution of the code associated with the second program.

Description

TECHNICAL FIELD [Method and system for generating an advanced storage key in a mobile device without secure elements]

Related applications

This application provides provisional applications previously filed pursuant to U.S. Patent Law 35 U.S.C.§119(e), Provisional Application No. 61/910,819 filed December 2, 2013; Provisional Application No. 61/951,842, filed March 12, 2014; Provisional Application No. 61/955,716, filed March 19, 2014; Provisional Application No. 61/979,132, filed April 14, 2014; Provisional application 61/980,784 filed April 17, 2014; Provisional Application No. 61/979,122, filed April 14, 2014; And Provisional Application No. 61/996,665 filed May 14, 2014; In particular, priority is claimed on the basis of the provisional application No. 61/979,113 filed on April 14, 2014, and the entire contents of each of these provisional applications are incorporated herein by reference.

Technical field

The present disclosure relates to the generation of an advanced storage key for use in a mobile device that does not have the necessary security elements, and more specifically, a security element for use in safely storing data in a mobile device is not provided. It relates to the use of multiple values for building advanced storage keys on mobile devices that are not.

As mobile and communication technologies advance, significant opportunities have arisen, one of which is to give users of mobile computing devices the ability to initiate payment transactions using their mobile device and to make payments for payment transactions. To provide. One such trick to enable such operations via a mobile device is near field communication (NFC) that allows secure transfer of payment details from the mobile device to a nearby point of sale (POS) terminal. ) Was the use of technology. To achieve this, mobile phones equipped with secure element hardware such as a secure element (SE) chip are used to securely store payment credentials. The secure element is a dedicated secure element that can be included in some NFC-enabled devices, which are tamper-resistant platforms that can securely host applications and their confidential data.

However, not all mobile devices are equipped with security elements. In addition, some financial institutions were unable to access security elements on mobile devices, even if the mobile device was equipped with a security element. As a result, many consumers with mobile devices equipped with the necessary hardware to perform contactless or other types of remote payment transactions may not be able to actually use this functionality. Because of such difficulties, there is a need for a technical problem solving technique that enables mobile computing devices to initiate and perform payment transactions without the use of secure elements.

Some methods and systems for performing payment transactions using mobile devices that do not use security elements in mobile devices that do not have security elements or are equipped with security elements have the name of the invention as "No security elements are provided. Systems and Methods for Processing Mobile Payments by Provisioning Credentials to Mobile Devices Without Secure Elements" and Mehdi Collinge, filed March 14, 2013. It can be found in US patent application Ser. No. 13/827,042 in the name of his associates, the entire contents of which are incorporated herein by reference. While such methods and systems may be suitable for performing payment transactions through a mobile device that does not use a secure element, many consumers, merchants, and financial institutions are participating in such transactions due to the need for greater security. Can be alert.

As a result, while providing greater security for the reception and storage of payment credentials on a mobile device that is not equipped with a security element, payment from the mobile device to the point of sale information management terminal during the execution of a financial transaction. There is a need for technical troubleshooting techniques that provide increased security for the transmission of payment credentials. Increased security in these processes can result in increased peace of mind for all involved entities, which can result in increased use of mobile devices for contactless or remote payment transactions. In other words, it can provide many benefits to consumers through traditional payment methods.

This disclosure provides a description of a system and method for building advanced storage keys.

The method of constructing an advanced storage key includes, in a memory of a mobile communication device, at least (i) device information associated with the mobile communication device, (ii) a program code associated with a first application program, at least one instance identifier. Storing the program code associated with the first application program, and (iii) the program code associated with the second application program, the program code associated with the second application program including the first key; Generating, by a processing device, a device fingerprint associated with the mobile communication device based on the stored device information through execution of a program code associated with the first application program; Generating, by the processing device, a random value through execution of a program code associated with the first application program; Constructing, by the processing device, a diversifier value based on at least the generated device fingerprint, the generated random value, and an instance identifier included in a program code associated with the first application program. ; And by the processing device, through execution of the program code related to the second application program, the constructed pluralization value is decrypted using the first key stored in the program code related to the second application program, and the storage key is stored. It includes; obtaining;

The system for building the advanced storage key includes the memory and processing device of a mobile communication device. The memory of the mobile communication device includes at least device information associated with the mobile communication device, a program code associated with a first application program, and including at least one instance identifier, a program code associated with a first application program, and a second application Program code associated with the program, configured to store program code associated with the second application program, including a first key. The processing device is configured to generate a device fingerprint associated with the mobile communication device based on the stored device information through execution of a program code associated with the first application program, and a program code associated with the first application program Is configured to generate a random value through execution of, at least the generated device fingerprint, the generated random value, and a diversity value based on an instance identifier included in a program code associated with the first application program. value), and decrypts and stores the constructed pluralization value using a first key stored in the program code associated with the second application program through execution of the program code associated with the second application program It is configured to obtain a key.

The scope of the present disclosure will be best understood from the following detailed description of exemplary embodiments considered in connection with the accompanying drawings. The accompanying drawings include the following drawings.

1 is a block diagram illustrating a high-level system architecture for processing payment transactions with advanced security in provisioning and storage of payment credentials according to exemplary embodiments.
FIG. 2 is a block diagram illustrating the mobile device of FIG. 1 for secure reception and storage of payment credentials and processing payment transactions without a secure element in accordance with exemplary embodiments.
3 is a block diagram illustrating a card database of the mobile device of FIG. 2 for storing payment credentials according to exemplary embodiments.
FIG. 4 is a block diagram illustrating a memory of the mobile device of FIG. 2 for storing data used for generation of application passwords and advanced storage keys according to exemplary embodiments.
5 is a block diagram illustrating a transaction management server of FIG. 1 for processing payment transactions with a mobile device not equipped with a security element according to exemplary embodiments.
6 is a block diagram illustrating an account database of the processing server of FIG. 5 for storage of account details and payment credentials according to exemplary embodiments.
7 is a flow chart illustrating a process for transmission and verification of a dual application cryptography for processing payment transactions involving a mobile device not equipped with a secure element according to exemplary embodiments.
8 is a flow diagram illustrating an alternative process for transmission and verification of dual application cryptography for processing payment transactions involving a mobile device not equipped with a secure element according to exemplary embodiments.
9 is a flow chart illustrating a process of generating, sending, and verifying a remote notification service or other data message provisioned to a mobile device not equipped with a secure element according to exemplary embodiments.
10A and 10B are flow charts illustrating a process for generating, transmitting, and confirming a message returned by a mobile device not equipped with a secure element according to an exemplary embodiment.
11 is a flow diagram illustrating a process for confirming a remote notification service message using the mobile device of FIG. 2 in accordance with exemplary embodiments.
12 is a diagram illustrating generation of an advanced storage key using the mobile device of FIG. 2 according to exemplary embodiments.
13 and 14 are flow charts illustrating typical methods for payment credentials generated in a payment transaction according to exemplary embodiments.
15 is a flow diagram illustrating an exemplary method for receiving and processing a remote notification service message according to exemplary embodiments.
16 is a flow diagram illustrating an exemplary method for building an advanced storage key according to exemplary embodiments.
17 is a block diagram illustrating a computer system architecture in accordance with exemplary embodiments.

Additional available fields of the present disclosure will become apparent from the detailed description provided below. It is to be understood that the detailed description of the exemplary embodiments is intended for illustrative purposes only, and thus is not intended to limit the scope of the present disclosure.

Glossary of terms

Payment Network-A system or network used for remittances through the use of cash-alternates. Payment networks may use several different protocols and procedures to handle remittances for different types of transactions. Transactions that may be performed over the payment network may include product or service purchases, credit purchases, debit transactions, money transfers, account withdrawals, and the like. Payment networks may be configured to perform transactions via cash-alternatives, which may include payment cards, letters of credit, checks, transactional accounts, and the like. Examples of network or system configured to perform as payment network include those run by ^{MasterCard ®, VISA ®, Discover ®} , American Express ®, PayPal ® and so on. As used herein, the term "payment network" may refer to both a payment network as an entity and a physical payment network such as equipment, hardware, and software including the payment network.

Transaction Account-A financial account that can be used to finance transactions such as checking accounts, savings accounts, credit accounts, virtual payment accounts, etc. A transactional account may be associated with a consumer, which may be any suitable type of entity associated with a payment account, which may include individuals, families, companies, businesses, government agencies, and the like. In some cases, the transaction account may be a synthetic transaction account, such as those accounts operated by PayPal ^® or the like.

Payment Card-A card or data associated with a transaction account that can be provided to a merchant to fund a financial transaction through the associated transaction account. Payment cards may include credit cards, debit cards, recharge cards, storage cards, prepaid cards, vehicle cards, virtual payment numbers, virtual card numbers, controlled payment numbers, etc. have. The payment card may be a physical card that may be provided to a merchant, or may be data representing an associated transactional account (eg, an associated transactional account as stored in a communication device such as a smartphone or computer). For example, in some cases, data including a payment account number can be regarded as a payment card for processing a transaction funded by the related transaction account. In some cases, the check may be considered a payment card if applicable.

Payment Transaction-A transaction between two entities in which money or other financial benefits are exchanged from one entity to the other. The payment transaction, as will be apparent to those skilled in the art, may be a transfer of funds for the purchase of goods or services, for repayment of debts, or for any other exchange of financial benefits. In some cases, a payment transaction may refer to transactions financed through a payment card and/or a payment account, such as credit card transactions. Such payment transactions can be processed through issuers, payment networks, and recipients. The process for processing such payment transactions may include at least one of approval, batching, liquidation, settlement, and financing. Approval includes providing the merchant with payment details by the consumer, submitting transaction details (e.g., transaction details including payment details) from the merchant to the merchant's payee, and financing the transaction. It may include verifying payment details to the issuer of the consumer's payment account being used. Batching may refer to storing one approved transaction in a batch with other approved transactions for distribution to a recipient. Clearing may involve sending batched transactions from the recipient to the payment network for processing. Settlement may include the issuer's withdrawal by the payment settlement network for transactions involving the issuer's beneficiaries. In some cases, the issuer can make a deposit to the recipient through the payment network. In other cases, the issuer can deposit directly to the recipient. Funding may include deposits from payees to merchants for cleared and settled payment transactions. As will be apparent to those skilled in the relevant art, the sequence and/or classification of the steps reviewed above is performed as part of the payment transaction processing.

Point of Sale Information Management System-User to enter transaction data, payment data, and/or other suitable type of data for purchase of goods and/or services and/or payment for goods and/or services A computing device or computing system configured to receive an interaction with (eg, a consumer, a user, etc.). The point of sale information management system is a physical device (e.g., cash register, kiosk, desktop computer) in a physical location that a customer visits as part of the transaction, such as a "brick and mortar" store. , Smartphone, tablet computer, etc.), or it may be a virtual device in e-commerce environments such as online retailers that receive communications from customers over a network such as the Internet. When the point of sale information management system may be a virtual device, the point of sale information management system when a computing device operated by a user to initiate the transaction or a computing device receiving data as a result of the transaction is applicable Can be regarded as.

Using a mobile device without security elements Payment System to process transactions

1 illustrates a system 100 for processing payment transactions using a mobile device that does not require the use of secure elements, wherein the use of secure elements includes secure provisioning of payment credentials to the mobile device. And secure storage of mobile devices, and use in generating multiple application cryptograms for use in verifying and processing the payment transaction.

The system 100 may include a transaction management server 102. The transaction management server 102 will be reviewed in more detail below, but to provision payment credentials to the mobile device 104 using a securely transmitted remote notification message, and as part of a payment transaction. It may be one or more computing devices specifically programmed to perform the functions reviewed herein to verify payment credentials generated by 104. In the present specification, the transaction management server 102 will be illustrated and reviewed as performing various functions, but for those skilled in the related art, the transaction management server 102 is configured to perform the functions reviewed in the present specification. It will be apparent that it may consist of devices, servers, and/or computing networks. The mobile device 104, which will be discussed in more detail below, is suitable for performing the functions reviewed in the present specification, and includes a cellular phone, a smart phone, a smart watch, other wearable or embedded computing device, a tablet computer, a laptop computer, and the like. It can be any type of mobile computing device that can be included. In some embodiments, the mobile device 104 may not be equipped with a security element. In other embodiments, the mobile device 104 may include a secure element, but such a secure element may not be used with the methods and systems reviewed herein, such as to provide additional security. It may also be used with the methods and systems reviewed in.

The mobile device 104 may communicate with the transaction management server 102 using multiple communication channels, such as multiple communication channels using dual channel communication. Dual channel communication may include ensuring higher security in data transmission using, for example, two communication channels transmitting and receiving data for verification and authentication. The mobile device 104 may include a mobile payment application (MPA) configured to be executed by the mobile device 104 in order to perform the functions of the mobile device 104 discussed herein. have. The MPA may be installed on the mobile device 104, as will be discussed in more detail below, and the MPA may be used by the mobile device 104 and the transaction management server 102 to provide one or more communication channels using shared data. It can be activated using methods and systems that are self-evident to those skilled in the relevant art that enable secure transmission and reception of communications over the network.

The system 100 may also include an issuer 106. The issuer 106 may be a financial institution such as an issuing bank that issues payment cards or payment credentials to the consumer 108 associated with the transactional account. The issuer 106 may provide payment details associated with the transaction account and/or payment card to the transaction management server 102. The payment details may include, for example, a transaction account number, an account holder name, an expiration date, a security code, and the like. The transaction management server 102 may store the data in an account database, which will be discussed in more detail below. The transaction management server 102 may provision the payment credentials to the mobile device 104. As used herein, the term "payment credentials" includes, but is not limited to payment details, payment credentials, single use keys, session keys, application passwords, card master keys, etc. Any data used by the mobile device 104 and/or the transaction management server 102 may be referred to in the transmission and verification of payment information used in a payment transaction using the method and system reviewed in .

In some embodiments, the payment credentials may be provisioned to the mobile device 104 via remote notification service messages. As will be discussed in more detail below, the remote notification service (RNS) message is a security message that is confirmed by the mobile device 104 after being transmitted to the mobile device 104, and the data contained therein are different devices. And a secure message that makes it safe from users. The MPA of the mobile device 104 may verify the authenticity of the received RNS message and may obtain data contained therein by decrypting the received RNS message. Then, the mobile device 104 can perform any necessary functions based on the data (e.g., by executing instructions contained in the data) and, if applicable, manage the transaction A return message to be sent back to the server 102 can be generated. In some cases, the return message may be verified by the transaction management server 102.

In some cases, verification of RNS messages in the mobile device 104 or verification of return messages in the transaction management server 102 may use at least message counters and an authentication code. The use of counters and authentication codes may enable only the intended mobile device 104 to verify and decrypt the data contained in the RNS message. In addition, when the rules and/or algorithms used in the generation of the authentication codes are included in the MPA, only the mobile device 104 which also includes a specific instance of the application program is required to check the RNS message. As possible, it results in an additional increase in security. In case the RNS message may contain payment credentials, this means that the MPA used to access the payment credentials only on a suitable mobile device 104 and only on the appropriate mobile device 104 is suitable and approved. It can be guaranteed that it is available only in the case of an application that has been created.

Payment credentials provisioned to the mobile device 104 may be safely stored in a storage within the mobile device 104, such as a card database, as will be discussed in more detail below. In some embodiments, the mobile device 104 generates an advanced storage key for use in securely storing data such as payment credentials in a database or memory within the mobile device 104. Can be configured. The generation of the advanced storage key will be reviewed in more detail below, but a secure storage key that can be used to securely store data in the mobile device 104 by using unique device information, unique MPA information, and randomly generated information. Can be identified. As a result, the payment credentials or other sensitive data can be securely stored on the mobile device 104 without the use of a secure element, which allows the mobile device 104 to conduct payment transactions without the use of a secure element. It can result in initiation and execution, increasing availability to publishers 106 and consumers 108 while maintaining a high level of security.

Once the mobile device 104 is received, verified, and has payment credentials for a transactional account securely stored therein, the consumer 108 manages the point-of-sale information on the merchant side of the mobile device 104 It can be moved to the terminal 110 to perform a payment transaction. The consumer 108 may select products or services to purchase, initiate a payment transaction with a merchant for purchase of the products or services, and use the mobile device 104 to make the payment. You can pass payment credentials for use in financing payment transactions. Transferring payment credentials to the point of sale information management terminal 110 may include transfer of two or more application passwords. The use of two or more application ciphers uses the methods and systems discussed herein rather than those available in traditional contactless and remote transactions, including transactions performed using a mobile device 104 equipped with a secure element. This can lead to a high level of security for transactions being processed.

The application passwords may each be generated by the mobile device 104 using individual session keys and additional data, which are reviewed below. Application passwords that are guaranteed through the advanced storage key and generated using data stored in the mobile device 104 as in the storage associated with the MPA include the application passwords being a specific instance of the mobile device 104 and the MPA. Can be guaranteed to authenticate. In some cases, the ciphers and/or one of the session keys used to generate the ciphers may use information provided by the consumer 108, such as a personal identification number (PIN). . The use of the PIN or other consumer authentication information may allow a password to authenticate both the consumer 108 and the mobile device 104. In such a case, the passwords generated by the mobile device 104 are a first password that authenticates the mobile device 104 and a second password that authenticates both the mobile device 104 and the consumer 108. It may include.

The ciphers may be received by the point of sale information management terminal 110 as part of the execution of a payment transaction such as through near field communication. The application ciphers may be required in the context of any suitable type of payment transaction such as contactless transaction, remote transaction, secure remote payment transaction, magnetic stripe transaction, and M/Chip EMV transaction, and for those skilled in the related art. As will be apparent, any suitable method accordingly may be used to accompany additional payment information such as that which may be transmitted to the point of sale information management terminal 110. The ciphers may be transmitted to the recipient 112, which may be a financial institution, such as a recipient bank, associated with the merchant. The payee 112 may issue a transaction account to the merchant which is used to receive payment of funds from the consumer 108, for example for a payment transaction. The payee 112 may submit the ciphers and additional transaction details to the payment network 114 using methods and systems that are obvious to those skilled in the relevant art. For example, the transaction details and application cryptograms may be included in an authorization request submitted to the payment network 114 on payment rails.

In some embodiments, both application ciphers may be included in a single transaction message. For example, the mobile device 104 and/or point-of-sale information management system 110 may use existing payment systems and hardware to transmit both application ciphers within legacy data fields of a traditional transaction message. Both application ciphers can be included. In some cases, the transaction management server 102 may be configured to use track 2 data for validation of the application ciphers as in a magnetic stripe transaction. In such a case, if the transaction message contains track 1 data, the transaction management server 102 may be configured to convert track 1 data to track 2 data, which is also modified track 1 or track 2 data. It may involve converting the data to unmodified (eg, original, reconstructed, etc.) Track 1 or Track 2 data, respectively. By performing these functions, and by including the application ciphers in legacy data fields, the transaction management server 102 does not require the use of the secure element 104 on the mobile device 104, and It can be used to process and validate remote and contactless payment transactions using a mobile device 104 with a high level of security, without modification to payment systems.

The payment network 114 may process the payment transaction using methods and systems that become apparent to those skilled in the related art. As part of the process, the payment network 114 may send the application cryptograms to the issuer 106 for verification. In some embodiments, the verification may be performed by the payment network 114. The issuer 106 or payment network 114 may communicate with the transaction management server 102. In some embodiments, the application passwords may be transmitted to the transaction management server 102, and may be verified through the generation of application passwords for verification using the transaction management server 102, and the application password for verification They can be created using locally stored payment credentials. In other embodiments, the issuer 106 or payment network 114 may request application passwords from the transaction management server 102, and the transaction management server 102 generates application passwords and the mobile device ( The ciphers can be returned to the issuer 106 or payment network 114 for validation of the ciphers generated by 104).

Since the transaction management server 102 processes payment credentials and other data used by the mobile device 104 to generate the application cryptograms, the mobile device ( The validation of payment credentials generated by 104) may be performed through comparison of application passwords generated by the mobile device 104 and passwords generated by the transaction management server 102. In some embodiments, the transaction management server 102 may be part of the issuer 106 or payment network 114. In examples where the transaction management server 102 may be part of the payment network 114, a payment transaction (e.g., for authorization of financing using a transaction account of the consumer 108 with the issuer 106). The validation may be performed prior to contacting the issuer 106 as part of the traditional process of.

By using multiple application ciphers, the security of the payment transactions can be increased. In addition, as in the examples where one password authenticates the mobile device 104 and the other password authenticates both the mobile device 104 and the consumer 108 (e.g., through the consumer's PIN), each In examples in which the cryptogram of a may authenticate separate data, it may also provide the issuer 106 with additional data and considerations for use in deciding whether to approve or reject a transaction. For example, if both passwords are incorrect (e.g., the passwords generated by the mobile device 104 do not match the passwords generated by the transaction management server 102), the The transaction may be rejected. In case one cipher is correct and the other cipher is incorrect, the transaction may be rejected for security reasons or may be approved as based on the decision of the issuer 106. For example, the issuer 106 may approve a transaction in which consumer authentication has failed but mobile authentication has passed, because other available data is authorized by the user using the mobile device 104 for the transaction. However, this is because it may indicate that the consumer 108 cannot use the mobile device 104 for a transaction.

Consequently, the use of both cryptography can provide valuable data that can be used by the issuers 106 and payment networks 114 in the processing of payment transactions. In addition, the use of two or more passwords can provide higher security than traditional contactless or remote payment methods, which reduces fraud to consumers 108, issuers 106, and merchants and It may result in increased acceptance for the fields 108, publishers 106, and merchants. Payments where the use of two or more application passwords is securely provisioned using the RNS messaging methods and systems reviewed herein, and securely stored via Advanced Stored Keys generated using the methods and systems reviewed herein. In examples that are generated from credentials, the overall security of the system 100 can be greatly increased compared to traditional systems for contactless payments and transaction processing. As a result, the system 100 can provide increased security in several data transmission, storage, and processing embodiments than those provided in traditional contactless payment systems, and can use the methods and systems discussed herein. It can provide common remote payment transactions and payment transactions.

Mobile device

2 illustrates one embodiment of the mobile device 104 of the system. As will be apparent to those skilled in the related art, the embodiment of the mobile device 104 illustrated in FIG. 2 is provided by way of example only, and all possible configurations of the mobile device 104 suitable for performing the functions as discussed herein May not be complete about the field. For example, the computer system 1700 illustrated in FIG. 17 and discussed in more detail below may be a suitable configuration of the mobile device 104.

The mobile device 104 may include a receiving unit 202. The receiving unit 202 may be configured to receive data via one or more network protocols via one or more networks. The receiving unit 202 is installed on the mobile device 104 and executed by the mobile device 104, for example a mobile payment application (MPA), which is discussed in more detail below. Program data for one or more application programs to be executed may be received. The receiving unit 202 may also receive remote notification service (RNS) messages, such as messages sent by the transaction management server 102 including RNS messages including payment credentials. . The receiving unit 202 may also receive additional data suitable for performing traditional functions of the mobile device 104 such as telephony communications, cellular communications, and the like. In some examples, the mobile device 104 may include a plurality of receiving units 202, such as separate receiving units 202, each configured to communicate with one or more separate networks via suitable protocols. For example, the mobile device 104 may include a first receiving unit 202 for receiving data for NFC transactions, and a second receiving unit 202 for receiving communications over a mobile communication network.

The mobile device 104 may also include an input unit 214. The input unit 214 is internally or externally to the mobile device 104 for receiving input from the consumer 108 such as a keyboard, mouse, click wheel, scroll wheel, touch screen, microphone, camera, receiver, etc. It may be configured to communicate with one or more input devices connected to each other. The input unit 214 may receive input from the consumer 108, which may be processed by the processing unit 204.

The processing unit 204 may be configured to perform the functions of the mobile device 104 discussed herein. The processing unit 204 can execute the program code stored in the mobile device, such as for the MPA, and perform a plurality of functions associated with each application program, as well as other functions of the mobile device 104 Can be configured to The processing unit 204 receives the input from the consumer 108 through the input unit 214 and will be apparent to those skilled in the related art, but executes application programs, performs the functions of the programs, and performs data Functions such as by receiving, transmitting data, displaying data, and so on, can be performed accordingly. For example, the processing unit 204 may be configured to validate RNS messages, generate advanced storage keys, and generate application ciphers, as will be discussed in more detail below.

The mobile device 104 may also include a display unit 210. The display unit 210 is connected internally or externally to the mobile device 104 to display data, e.g., data transmitted to the display unit 210 for display by the processing unit 204. It may be configured to communicate with one or more display devices. Display devices may include liquid crystal displays, light emitting diode displays, thin film transistor displays, touch screen displays, and the like.

The mobile device 104 may also include a transmission unit 206. The transmission unit 206 may be configured to transmit data via one or more network protocols over one or more networks. The transmission unit 206 may transmit RNS response messages to the transaction management server 102. The transmission unit 206 may also be configured to transmit application cryptograms and/or payment credentials to, for example, point of sale information management system 110 for use in a payment transaction. The transmission unit 206 may be further configured to perform additional functions of the mobile device 104, such as the traditional functions of the mobile communication device for transmitting cellular communications, etc., as will be apparent to those skilled in the related art. have. In some examples, one transmitting unit 206 configured to transmit payment credentials and payment passwords via NFC and the other transmitting unit 206 configured to transmit data over a mobile communication network. ), may include a plurality of transmission units 206 that may be separately configured to communicate with one or more separate networks.

The mobile device 104 may also include a card database 208. The card database 208, which is reviewed in more detail below, may be a data store on the mobile device 104 configured to store data associated with one or more transactional accounts and/or payment cards. The card database 208 will be reviewed in more detail below, but the payment credentials associated with the transactional account as provisioned to the mobile device 104 by the transaction management server 102 within a secure RNS message, and the application Additional data can be stored that can be used in the generation of ciphers. In some examples, the card database 208 may be stored as part of a mobile payment application.

The mobile device 104 may further include a memory 212. Memory 212, which is discussed in more detail below, may be configured to store data for mobile device 104 suitable for performing the functions of mobile device 104 discussed herein. For example, the memory 212 stores data suitable for generation of advanced storage keys for encryption of additional data in a mobile device 104, such as the card database 208, which will be reviewed in more detail below. I can. The memory 212 also receives program code for application programs executed by the processing unit 204 such as an operating system, data through the input unit 214 and data through the display unit 210 May be configured to store program code for displaying, rules and/or algorithms for performing functions reviewed herein, and the like. The memory 212 may also store data suitable for performing traditional functions of the mobile device 104, such as rules and/or algorithms for transmitting and receiving cellular communications over the mobile network. Additional data stored in the memory 212 will become apparent to those skilled in the related art.

Mobile device card database

3 shows a card database of the mobile device 104 for storing payment credentials and other data associated with transaction accounts for use in financing payment transactions performed with the mobile device 104 ( 208) is illustrated.

The card database 208 may include one or more payment profiles 302 illustrated in FIG. 3 as payment profiles 302a, 302b, 302c. Each payment profile 302 can be associated with a transactional account that can be used to fund a payment transaction, at least one payment credential 304, one or more single use keys 306, a first session. A key 308, a second session key 310, and an application transaction counter 312 may be included.

The payment credentials 304 are data associated with an associated transaction account used for identification and validity by the issuer 106 and/or payment network 114 in the processing of payment transactions using the associated transaction account. It may include. The payment credentials 304 include, for example, a transaction account number, a security code, an expiration date, a cardholder name, an authorized user name, tracking data, card layout description data, digit counts, and bitmaps. And so on.

Single-use keys 306 generate one or more of the application ciphers used in the payment transaction, which can be used by the processing unit 204 of the mobile device 104 for a single payment transaction. It could be tokens. In some embodiments, single use key 306 may include one or more of the other data elements included in payment profile 302. For example, each single use key 306 may include a separate application transaction counter 312, which may not be separately included in the payment profile 302. Different configurations of data stored in the payment profile 302 for use in performing the functions discussed herein will become apparent to those skilled in the relevant art. In some examples, the single use key 306 may comprise a key used to generate the one or more application ciphers or may consist of a key used to generate the one or more application ciphers. In some embodiments, the first session key 308 and the second session key 310 may be included in a single use key 306 provisioned on the mobile device 104 and/or the single use key 306 ) Can be created using the data contained in.

The first session key 308 and the second session key 310 are used in the generation of application passwords transmitted to the point of sale information management system 110 as part of performing a payment transaction using the mobile device 104. There may be additional keys used by the processing unit 204. In some embodiments, the first session key 308 is a first application encryption by the processing unit 204 using, for example, program code, rules, or algorithms stored in the memory 212 of the mobile device 104. Can be used in the creation of. The second session key 310 may be used to generate a second application password.

In some embodiments, the second session key 310 may be generated by the processing unit 204. In such an embodiment, the second session key 310 is generated using a single use key 306 and user authentication data such as a PIN provided by the consumer 108 (e.g., via the input unit 214). Can be. In such an embodiment, the second session key 310 may not be stored in the payment profile 302, but instead may be created, used, and discarded as part of a payment transaction process. Therefore, when the second application password is generated from the single use key 306 and the second session key 310 generated using the consumer PIN, both the mobile device 104 and the consumer 108 It can be helpful in authenticating.

A personal identification number (PIN) can be used to authenticate the consumer 108 (e.g., the registration of the MPA on the mobile device 104 or the issuer 106 and/or the transaction management server ( 102) may be a number supplied by the consumer 108). When performing a payment transaction, the consumer 108 or another user of the mobile device 104 may supply a PIN through the input unit 214. In some embodiments, if the supplied PIN is incorrect (e.g., does not match the PIN supplied by the consumer 108 upon registration), the processing unit 204 continues to retrieve the second session key 310. And then, a second application password can be generated. If the supplied PIN is incorrect, then the second application password becomes incorrect, which is the second application by the transaction management server 102, issuer 106, and/or payment network 114. The failure of validating the password will result, and the failure of validating the second application password by the transaction management server 102, the issuer 106, and/or the payment network 114 will cause the transaction to be executed accordingly. The issuer 106 may be given the opportunity to decline or may still approve the transaction.

Mobile device memory

FIG. 4 shows the memory of the mobile device 104 for storing application programs and other data to be used for secure storage of data on the mobile device 104 and execution of payment transactions using the mobile device 104. One embodiment of (212) is illustrated. In one exemplary embodiment, the memory 212 may not be a security element.

Device information 402 may be included in the memory 212. The device information 402 may include one or more pieces of data associated with the mobile device 104 that may be unique to the mobile device 104 in some examples. For example, the device information 402 may include a media access control address, a reference number, a serial number, an identification number, and the like. Additional information that may be considered as the device information 402 of the mobile device 104 will become apparent to those skilled in the related art.

The memory 212 may also contain a mobile payment application (MPA) 404. The MPA 404 performs functions of the mobile device 104 discussed herein, such as receiving and storing payment credentials, validating RNS messages, and generating application cryptograms for use in performing payment transactions. It may be an application program configured to be. Additional features of the MPA 404 may include traditional features of a digital wallet or other similar application program, as will be apparent to those skilled in the art.

Program code 406 may be included in the MPA 404. The program code 406 is a code executed by the processing unit 204 of the mobile device 104, and allows the processing unit 204 and other components of the mobile device 104 to be reviewed in the present specification. It may be code to perform the functions of MPA 404 as described above. For example, the program code 406 may include code suitable for generating application ciphers, validating RNS messages, and so on. The program code 406 may also include program code suitable for generating a random value, which may be used in the generation of an advanced storage key. The random value may be a random number or a pseudo-random number, which may be generated using methods and systems that will become apparent to those skilled in the related art.

An instance identifier 408 may also be included in the MPA 404. The instance identifier 408 may be a value unique to a specific MPA 404, which may be used to generate an advanced storage key used to secure data in a mobile device 104 such as the card database 208. . By making the instance identifier 408 unique to the MPA 404, a plurality of MPAs 404 can provide the mobile device without any MPA 404 accessing data securely stored by any other MPA 404. It may be installed on 104, thereby making payment profiles 302 for certain transactional accounts inaccessible by other programs. The instance identifier 408 may be a number, an alphanumeric value, a hexadecimal value, or any suitable value that may be unique to the MPA 404.

As will be discussed in more detail below, the processing unit 204 of the mobile device 104 may be configured to generate a diversifier value using the device information 402, and the random value is the MPA It is generated using the program code 406 of 404, and the instance identifier 408 is stored in the MPA 404. The pluralization value may be used by an encryption application 410 that is also stored in the memory 212. The encryption application 410 may be an application program configured to perform white box encryption and/or any other suitable encryption function that will become apparent to those skilled in the related art.

Program code 412 may be included in the encryption application 410. The program code 412 allows the processing unit 204 and other components of the mobile device 104 to perform the encryption functions of the encryption application 410 reviewed herein. ) Can be executed by the processing unit 204. The functions may include generation of an advanced storage key. The advanced storage key may be generated using an encryption key 414 included in the encryption application 410 and a multiplex value generated by the mobile payment application 404. In some embodiments, the pluralization value may be decrypted to obtain the advanced storage key using the encryption key 414.

The encryption application 410 may also be configured to encrypt storage within the mobile device 104 using the advanced storage key. In some embodiments, the encryption may be performed using one or more box encryption techniques. The encrypted storage may be a card database 208 and/or any other suitable storage, such as data stored in the MPA 404. In some embodiments, the encryption application 410 may be included as part of the MPA 404. The advanced storage key may be included in the encryption application 410 or MPA 404, and may be regenerated by the MPA 404 and encryption application 410 when necessary.

The memory 212 may also contain any additional data stored in the mobile device 104 suitable for performing the functions discussed herein, as well as any additional functions of mobile devices. For example, the memory 212 may contain an operating system, code, rules, or program code for algorithms for receiving and transmitting mobile communications such as telephone calls and the like.

In some embodiments, the mobile device 104 may also be stored in an encrypted local storage native to the mobile device 104, such as in the memory 212, the card database 208, or other suitable storage. It can be configured to receive data that has already been encrypted using an additional storage key that can be used. In such an embodiment, the mobile device 104 may generate the advanced storage key using the same methods and systems using the generated random value and encrypt the data provisioned to the mobile device 104 May be configured to transmit the generated random value to the transaction management server 102 or other trusted entity. Accordingly, the mobile device 104 may receive data that has already been encrypted using the advanced storage key for local storage in the mobile device 104.

Transaction Management Server

5 illustrates an embodiment of the transaction management server 102 of the system 100. As will be apparent to those skilled in the related art, the embodiment of the transaction management server 102 illustrated in FIG. 5 is provided by way of example only, and a transaction management server 102 suitable for performing functions as discussed herein. May not be complete for all possible configurations of For example, the computer system 1700 illustrated in FIG. 17 and discussed in more detail below may be a suitable configuration of the transaction management server 102.

The transaction management server 102 may include a receiving unit 502. The receiving unit 502 may be configured to receive data via one or more network protocols via one or more networks. The receiving unit 502 may provide data from the mobile device 104, such as receive or return messages, confirmation messages, transaction notifications, etc., from the payment network 114, the issuer 106, or other suitable entity. It can be configured to receive data. The receiving unit 502 may receive transaction notifications or cryptographic requests to initiate the generation of application cryptograms for use in the validation of payment credentials, for example in a payment transaction. The receiving unit 502 may also receive transaction account data, for example from the issuer 106 for use in generating payment credentials for provisioning to the mobile device 104.

The transaction management server 102 may also include a processing unit 504. Although the processing unit 504 will be apparent to those skilled in the related art, it may be configured to perform the functions of the transaction management server 102 discussed in the present specification. Therefore, the processing unit 504 generates and encrypts RNS messages and data included in the present specification, as will be discussed in more detail below, validates return messages from the mobile device 104, and provides payment credentials. Can be configured to generate files, generate application passwords, validate application passwords, and so on.

The transaction management server 102 may additionally include a transmission unit 506. The transmission unit 506 may be configured to transmit data via one or more network protocols over one or more networks. The transmission unit 506 may transmit RNS messages, payment credentials, application ciphers, validation notifications, and other data that will become apparent to those skilled in the related art. The transmission unit 506 may be configured to transmit data to the mobile device 104, for example via a mobile communication network or the Internet, a payment network 114, an issuer 106, and any other suitable entity.

The transaction management server 102 may also include an account database 508. The account database 508, which will be reviewed in more detail below, may be configured to store account information for a plurality of transaction accounts. The account information may include data and keys used for generation of application passwords used for validating payment credentials received during payment transactions performed using the mobile device 104. The account database 508 also includes transaction data for payment transactions carried out involving the mobile device 104, such as data associated with the consumer 108 or other authorized users of the relevant transaction account, and other It can be configured to store data.

The transaction management server 102 may also include a memory 510. The memory 510 may be configured to store additional data for use by the transaction management server 102 to perform the functions disclosed herein. For example, the memory 510 includes rules or algorithms for validating application ciphers, rules or algorithms for generating validation notifications, algorithms for generating session keys and application ciphers, data and RNS messages. Encryption keys for encryption and decryption of the files can be stored. Additional data that may be stored in the memory 510 will become apparent to those skilled in the related art.

Transaction Management Server Accounting Database

6 shows the transaction management server ( 102) of the account database 508 is illustrated.

The account database 508 may include a plurality of account profiles 602 illustrated in FIG. 6 as account profiles 602a, 602b, 602c. Each account profile 602 contains one or more single use keys 604, a first session key 606, a second session key 608, an application transaction counter 610, and a first card master key 612. Can be included. In some embodiments, the account profile 602 may additionally include a second card master key 612.

Each account profile 602 may correspond to a payment profile 302 provisioned to the mobile device 104. To this end, the single use keys 604 stored in the account profile 602 may correspond to the single use keys 306 stored in the corresponding payment profile 302 associated with the same transactional account. The data is that when the application password is generated by the transaction management server 102 or the mobile device 104, the application passwords must match if the data is correct and not tampered with, which means that the mobile device 104 It is possible to enable the validation of payment credentials presented by.

In some embodiments, the account profile 602 may include a personal identification number (PIN) that corresponds to the PIN 314 stored in the corresponding payment profile 302. In such an embodiment, the PIN 314 is provided to the receiving unit 202 of the transaction management server 102 through a secure message such as a received message provided by the mobile device 104 which is reviewed in more detail below. Can be. In other embodiments, the card master key may be used instead of the PIN, such as the first card master key 612. In such an embodiment, the processing unit 504 of the transaction management server 102 uses the single use key 306 and the PIN 314 to generate a second session key ( It may be configured to generate a second session key 608 corresponding to 310) based on the second card master key 614. In some examples, the second session key 608 may also be based on the corresponding single use key 604. In such embodiments, algorithms for the generation of session keys and/or application ciphers are made so that ciphers generated by the mobile device 104 and the transaction management server 102 are made based on the data used herein. can do.

The first session key 606 may be used by the processing unit 504 of the transaction management server 102 to generate a first application password, and the second session key 608 generates a second application password. Can be used to In some embodiments, the application transaction counter 610 may be used to generate one or more of the session keys and/or application ciphers. The application transaction counter 610 may be a value corresponding to a payment transaction to be performed that is incremented during each transaction or modified otherwise. The application transaction counter 610 may correspond to the application transaction counter 312 stored in the corresponding payment profile 302 in the mobile device 104, whereby the MPA 404 whose use is only valid is valid. It makes it possible to own the correct application transaction counter 312 to generate session keys and/or application ciphers. Additional techniques may be used to further enhance the security of the session key and/or application cryptographic generation, such as unpredictable numbers and other techniques that will become apparent to those skilled in the relevant art.

Processing payment transactions using mobile devices

7 illustrates a process for processing payment transactions performed using a mobile device 104 that does not have a secure element and using the generation and validation of two or more application ciphers.

In step 702, the transaction management server 102 transfers payment credentials 304 and other account data to the mobile device 104, for example, through an RNS message that is reviewed in more detail below (e.g., the transmission unit ( 506)). In step 704, the receiving unit 202 of the mobile device 104 may receive the payment credentials 304 and other account data. In step 706, the processing unit 204 of the mobile device 104 may store the data in the payment profile 302 of the card database 208. The account data may include the payment credentials 304, one or more single use keys 308, and any other suitable data such as one or more of the session keys 308, 310.

In step 708, the processing unit 204 may generate two application ciphers for use in performing a payment transaction. In some embodiments, how step 708 represents via the input unit 214, a method of placing the mobile device 104 near the point-of-sale information management system 110 to initiate a transaction via near-field communication, or another. It can be initiated by the consumer 108 as by any suitable method. The generation of the application passwords may include generating a first application password using the first session key 308 stored in the payment profile 302. The second application password may be generated using a second session key 310, and the second session key 310 may be generated using a single use key 306 and a PIN 314. In some examples, the consumer 108 may enter a PIN into the mobile device 104 (eg, via the input unit 214) during the initiation of step 708 or step 708. In some embodiments, one or both of the application ciphers may also be generated using the application transaction counter 312.

Once the application ciphers are generated, the application ciphers, along with the payment credentials 304, are sent to the issuer via the point of sale information management system 110, the receiver 112, and the payment network 114. It can be sent to 106. The payment credentials 304 and application passwords may be received by the issuer 106 at step 710. In step 712, the transmission unit 206 of the mobile device 104 may transmit a transaction notification to the transaction management server 102. In step 714, the receiving unit 502 of the transaction management server 102 may receive the transaction notification. The transaction notification may inform the transaction management server 102 that the mobile device 104 has initiated a payment transaction using the payment profile 302. In some examples, identification information may be included in the transaction notification.

In step 716, the processing unit 504 of the transaction management server 102 can identify the account profile 602 corresponding to the payment profile 302, and use the data contained therein to obtain two application passwords. Can be created. The first application password may be generated using the first session key 606, and the first session key 606 may be generated using the first card master key 612. The second application password may be generated using the second session key 608. In some embodiments, one or both of the application ciphers and/or session keys may additionally be made based on the single use keys 604, application transaction counter 610, or any other suitable data. .

In step 718, the transmission unit 506 of the transaction management server 102 may transmit the generated application ciphers to the issuer 106, and the issuer 106 may receive the ciphers in step 718. have. In step 720, the issuer 106 may validate the application passwords provided by the mobile device 104 with the payment credentials 304. Validation of the application passwords may include comparing application passwords generated and supplied by the transaction management server 102 with passwords supplied by the mobile device 104. Once validation is performed, in step 722, the issuer 106 may process the transaction accordingly. Transaction processing may include, for example, acknowledging the payment transaction if one or both of the ciphers are valid, or of the payment transaction, e.g. if one or both of the ciphers are determined to be invalid. It can also include rejection.

In step 724, a transaction notification may be sent by the issuer 106, or another entity (eg, the payment network 114, the receiver 112, etc.) as part of the payment transaction processing. The transaction notification may be transmitted to the transaction management server 102 in step 726 and received by the receiving unit 502. The transaction notification may also be received by the receiving unit 202 of the mobile device 104 at step 728. The transaction notification may be an indication of approval or rejection of the payment transaction. The processing units 204 and 504 of each of the mobile device 104 and the transaction management server 102 may each perform one or more functions as a result of the received transaction notification. For example, when the transaction is approved and successfully processed, the application transaction counters 310 and 610 may be updated accordingly in corresponding profiles.

8 illustrates a variant process for processing a payment transaction using the mobile device 104.

In step 802, the payment credentials 304 and other account data may be transmitted to the mobile device 104 by the transmission unit 506 of the transaction management server 102. In step 804, the receiving unit 202 of the mobile device 104 may receive payment credentials 304 and other account data, which may be stored in the payment profile 302 in step 806. In step 808, the processing unit 204 of the mobile device 104 may generate the two application ciphers as reviewed above, the ciphers, payment credentials 304, and other suitable data. May be transmitted to the publisher 106 (eg, through the point of sale information management system 110).

In step 810, the issuer 106 may receive application ciphers and any other suitable data that can be used by the issuer 106 to validate the transaction data and/or process approval or rejection of the transaction. have. In step 812, the issuer 106 may submit a request for validation ciphers to the transaction management server 102. In some embodiments, the request includes payment credentials 304 or other data suitable for use by the transaction management server 102 in identifying the account profile 602 to be used to generate the validation ciphers. I can. In one embodiment, the request may additionally include two application passwords generated by the mobile device 104 for validation.

In step 814, the receiving unit 502 of the transaction management server 102 may receive the encryption request. In step 816, the processing unit 504 of the transaction management server 102 may generate two application ciphers to be used for validation as discussed above. In embodiments in which the password request also includes two application passwords generated by the mobile device 104, step 816 also includes two passwords by the processing unit 504 using two newly generated application passwords. May include validation of Validation ciphers, or validation results in applicable embodiments may be transmitted to the issuer 106 by the transmission unit 506. In step 818, the issuer 106 may receive the validation ciphers and/or the validation result.

In step 820, the issuer 106 may validate application ciphers provided by the mobile device 104 using the application ciphers generated by the transaction management server 102. In embodiments in which the transaction management server 102 provides a validation result to the issuer 106, step 820 may include identifying the validation result of each of the two application ciphers. In step 822, the issuer 106 may process the payment transaction accordingly based on the result of the validation. In step 824, transaction notifications may be sent to the transaction management server 102 in steps 826 and 828, respectively, and may be received by corresponding receiving units 502, 202.

Remote notification service and data messaging

9 illustrates a process for transmission and validation of remote notification service (RNS) messages and other data messages transmitted from the transaction management server 102 to the mobile device 104. RNS messages may be transmitted through a remote notification service such as using a mobile communication network associated with the mobile device 104. RNS messages, such as account data used in the processing of payment transactions as reviewed above, and other information that may be used in establishing a secure connection between the mobile device 104 and the transaction management server 102, It can be used to provision credentials 304 and other account data.

In step 902, the processing unit 504 of the transaction management server 102 may generate a message. In examples where mutual authentication is established with the mobile device 104, the message may include information suitable for establishing the mutual authentication, such as a session identifier. In other examples, such as when mutual authentication is established between the transaction management server 102 and the mobile device 104 using the process illustrated in FIG. 9 and reviewed herein, payment credentials are included in the generated message. 304 and account data may be included, and removal of one or more commands (e.g., single use keys 306 or payment credentials 304) to be executed by the MPA 404 of the mobile device 104 ) May be included, there may be notifications (eg, account balances, payment notifications, etc.) to be presented to the consumer 108, and other suitable data may be included.

In step 904, the processing unit 504 may encrypt the generated message. The message may be encrypted using a private key of a private/public key pair, in which case the mobile device 104 may possess a corresponding public key. In some examples, the message may be encrypted using an encryption key associated with the MPA or mobile device 104, such as the encryption key 414. In step 906, the processing unit 504 may generate a message authentication code. The message authentication code may be generated using the encrypted message and may be a key generated using one or more specially configured rules and/or algorithms. For example, the message authentication code may be generated using one or more encryption and obfuscation methods such as padding. In some embodiments, the message authentication code may be generated using the encryption key.

In step 908, the transmission unit 506 of the transaction management server 102 may transmit the combined data message to the mobile device 104. In embodiments in which the mutual authentication can be performed, the combined data message may be a remote notification service message transmitted to the mobile device 104 through the remote notification service. The combined data message may be received by the receiving unit 202 of the mobile device 104 in step 910, and the combined data message may include the message authentication code and the encrypted message. In some examples, the combined data message may also include an additional identifier, such as generated using methods known for the MPA 404 for verification of the combined data message. In some cases, such as when mutual authentication has already been performed, a message counter may also be included in the combined data message.

In step 912, the processing unit 204 may generate a reference authentication code. The reference authentication code may be generated using the received encrypted message and may be generated using rules and algorithms such as the transaction management server 102 used to generate the message authentication code, whereby the When the message authentication code is generated by a trusted source (eg, the transaction management server 102), the generated reference authentication code corresponds to the message authentication code. In embodiments in which the message authentication code may be generated using the encryption key, the processing unit 204 uses the encryption key 414 or other suitable encryption key stored in the memory 212 to provide the reference authentication code. Can be created.

In step 914, the processing unit 204 validates the message authentication code included in the received combined data message by comparing the message authentication code included in the received combined data message against the generated reference authentication code. can do. If both the message counter and message authentication code are valid, the combined data message may be determined to be reliable (eg, true) as originating from the transaction management server 102. In examples where a message identifier may be included in the combined data message, the processing unit 204 may also determine the message identifier using a process known by the MPA 404 for generation and comparison of the combined data message. By generating, the message identifier can be validated. In embodiments where a message counter may be included in the combined data message, the processing unit 204 may be configured with a reference counter stored in the mobile device 104, for example in the MPA 404 or in the payment profile 502. Together, the message counter included in the received combined data message can be validated.

In step 916, the processing unit 204 may decrypt the encrypted message included in the received combined data message. The encrypted message is stored in the memory 212 (e.g., in the encryption application 410 or MPA 404) or in an encrypted (e.g., encrypted using an advanced storage key) key stored in a local database, Alternatively, it may be decoded using another suitable decoding method. In step 918, in the processing unit 204, the processing unit 204 may perform one or more suitable actions based on data decrypted from the encrypted message. In the example illustrated in FIG. 9, the mobile device 104 is mutually authenticated with the transaction management server 102 using, for example, a session identifier contained in the encrypted message and decrypted by the processing unit 204. Can be done. In step 920, the transaction management server 102 may receive the session identifier and perform any additional actions required for mutual authentication with the mobile device 104. In cases where mutual authentication has already been performed, as disclosed herein, such as payment credentials 404, single use keys 406, program instructions for the MPA 404, etc. in the message. Other information suitable to perform the functions may be included.

In some embodiments, the mobile device 104 may be configured to generate a return message and submit it to the transaction management server 102 (eg, via the MPA 404 ). In some examples, the return message may include data generated in response to actions performed as a command is received through the decrypted message as reviewed above. For example, the return message may indicate valid receipt and storage of single use keys 306 or payment credentials 304. In other examples, the return message may be a notification of reception and validation of the combined data message. In examples in which the authentication is performed first, a session identifier used to perform the mutual authentication may be included in the return message.

10A and 10B illustrate a process for generating and transmitting a return message by the mobile device 104 and validating the return message by the transaction management server 102.

In step 1002, the processing unit 204 of the mobile device 104 may generate a received message. The received message may be generated based on the program code 406 stored in the MPA 404, and actions performed as shown in the decrypted combined data message received from the transaction management server 102 It can be made additionally on the basis of. For example, the received message may include notification of successful receipt and storage of payment credentials 304. In step 1004, the processing unit 204 may increment the reception counter. The reception counter may be a counter indicating the number of received messages transmitted to the transaction management server 102. The reception counter may be stored in the memory 212, for example in the MPA 404 or in a database encrypted using the advanced storage key. As will be apparent to those skilled in the relevant art, step 1004 may be an optional step, and may only be used in examples where a counter is used for validating data messages.

In step 1006, the processing unit 204 may encrypt the received message. The received message may be encrypted using the encryption key 414 stored in the encryption application 410, or otherwise stored in the MPA 404 or a locally encrypted database. The encryption key used to encrypt the received message may be a private key as part of a key pair, and the transaction management server 102 owns a corresponding public key. In step 1008, the processing unit 204 may generate a reception authentication code based on the encrypted received message. In some embodiments, the receipt authentication code may be generated using rules, algorithms, and/or processes as used to generate the reference authentication code illustrated in step 912 of FIG. 9, reviewed above.

In step 1010, the transmission unit 206 of the mobile device 104 may transmit a reception notification message to the transmission management server 102. The reception notification message may be received by the reception unit 502 of the transaction management server 102, and the reception notification message may include at least the reception authentication code, the encrypted reception message, and the reception counter. In some embodiments, the receipt notification message may be transmitted to the transaction management server 102 using a mobile communication network, such as a cellular network, associated with the mobile device 104.

In step 1014, the processing unit 504 of the transaction management server 102 may increment the confirmation counter. The confirmation counter may indicate the number of messages received from the mobile device 104 used to validate messages received from the mobile device 104. The confirmation counter may be stored in the memory 510 of the transaction management server 102 or other suitable data store. For example, in some embodiments, the verification counter may be stored in an account profile 602 associated with the mobile device 104. In one example, in each account profile 602, a confirmation counter (e.g., and/or message) to be used for messages sent to/from the transaction management server 102 and mobile device 104 associated with the corresponding transaction account. Counter) may be included. As will be apparent to those skilled in the relevant art, step 1014 may be an optional step and may not be used in examples where the counter will not be used for validation of return messages.

In step 1016, the processing unit 504 may generate a verification authentication code. The verification authentication code may be generated based on an encrypted received message included in the receipt notification message, and generated using the same rules, algorithms, and/or processes used to generate the message authentication code. Can be. In step 1018, the processing unit 504 can validate a reception counter included in the reception notification message by comparing the reception counter included in the reception notification message with the confirmation counter. In step 1020, the processing unit 504 validates the reception authentication code by comparing the reception authentication code with the message authentication code, thereby ensuring that the message originates from the approved mobile device 104.

Once the counter (eg, if applicable) and the authentication code are valid, in step 1022, the processing unit 504 may decrypt the encrypted message contained within the received reception notification message. The encrypted message can be decrypted using a stored encryption key or other suitable decryption method. The encrypted message may be decrypted to obtain a received message generated by the mobile device 104. In step 1024, the processing unit 504 may perform any suitable actions as needed based on the data included in the received message. If, for example, an indication of successful reception and storage of single use keys 306 is included in the received message, the processing unit 204 may display the corresponding single use keys 604 in the corresponding account profile 602. Can be activated.

Validation of data messages

11 illustrates a process 1100 for validating data messages received by the mobile device 104 from the transaction management server 102.

In step 1102, the processing unit 204 of the mobile device 104 is in a local storage, for example the memory 212 or the locally encrypted storage encrypted using the advanced storage key, encryption keys, authentication generation keys, And rules and/or algorithms for their use and application. In step 1104, the receiving unit 202 of the mobile device 104 may receive a data message from the transaction management server 102. In some embodiments, the data message may be received from the transaction management server 102 following establishment of mutual authentication between two devices using the process illustrated, for example in FIG. 9 and reviewed above. The data message may include at least a message counter, a message authentication code, and an encrypted message.

In step 1106, the processing unit 204 may increment the reference counter. The reference counter may be stored in the memory 212 or other local storage, and may be used to indicate the number of messages received from the transaction management server 102. In some examples, the reference counter may be incremented using an algorithm, so that the reference counter uses a serial number, but targets the mobile device 104 (e.g., via the MPA 404). In addition, it may not be incremented through an algorithm known for the transaction management server 102.

In step 1108, the processing unit 204 may validate a message counter included in the received data message. Validation of the message counter may include a comparison of the message counter to a value of a reference counter after incrementing. Failed validation may indicate that the source of the data message is not the transaction management server 102 or otherwise unreliable. If the validation fails, in step 1110, the processing unit 204 may perform one or more suitable actions related to receiving and/or validating the failed data message. For example, the processing unit 204 may discard the data message, notify the transaction management server 102, lock the associated payment profile 302, and be skilled in the related art. You can also perform other actions that become self-evident to them.

When the validation of the message is passed, the process 1100 may proceed to step 1112, and the encrypted message may be padded in step 1112. The padding of the encrypted message may include addition of values for the encrypted message or data associated therewith. Padding can be used to increase the security of the message validation process, because the padding must be duplicated by an unauthorized entity to successfully transmit or receive data messages without authorization, the mobile devices known to each other. This is because it may be another function that must be performed by 104 and the transaction management server 102. As will be apparent to those skilled in the relevant art, step 1112 may be an optional step. In some embodiments, step 1112 may be applied to some examples of process 1110. For example, the encrypted message may be padded with predetermined increments of the reference counter.

In step 1114, the processing unit 204 may generate a reference authentication code. The reference authentication code may be generated based on the encrypted message (eg, as padding, if applicable) using one or more rules or algorithms stored in step 1102, for example. In some embodiments, the reference authentication code may be a key or a value generated by application of a key to the encrypted message. In step 1116, the processing unit 204 may validate the message authentication code received in the RNS message. In the validation of the message authentication code, when the received data message is derived from an authorized source (eg, the transaction management server 102), a comparison of the code with the generated reference authentication code as another identification method is performed. Can be included.

If validation of the message authentication code fails, the process 1100 may proceed to step 1110, and in step 1110, a failure process is performed. When the validation of the message authentication code passes, in step 1118, the encrypted message included in the received data message may be decrypted by the processing unit 204. The message may be decrypted, for example in step 1102 using one or more encryption/decryption keys, rules, and/or algorithms stored in the mobile device 104. For example, the encryption key 414 stored in the encryption application 410 of the memory 212 may be used to decrypt the encrypted message. In step 1120, the processing unit 204 may perform one or more actions, if appropriate, based on the content of the decrypted message. For example, if the decrypted message contains single use keys 306, the single use keys 306 may be stored in a suitable payment profile 302 of the card database 208, This can thereby be encrypted using the advanced storage key.

Advanced Save Key

12 shows the above for secure storage of data on the mobile device 104, such as payment profiles 302 and other data that can be securely stored and accessed on the mobile device 104 without the use of a secure element. The generation and use of advanced storage keys by mobile device 104 is illustrated.

The device information 402 stored in the memory 212 of the mobile device 104 includes three or more portions of the device information 1202 illustrated in FIG. 12 as the device information 1202a, 1202b, and 1202c. I can. Each portion of device information 1202 may be associated with the mobile device 104. In some examples, each portion of device information 1202 may be unique to the mobile device 104. In other examples, one or more of the portions of device information 1202 may be non-unique to the mobile device 104 (e.g., model number), but if three portions of device information 1202 are taken together It may be unique to the mobile device 104 (eg, a unique combination). Portions of the device information 1202 may be data that does not change during the life of the mobile device 104.

The processing unit 204 of the mobile device 104 may generate a mobile device fingerprint 1204 based on the three parts 1202a, 1202b, and 1202c of the device information. The mobile device fingerprint 1204 may be a value unique to the mobile device 104 and stored in the memory 212, for example, one or more rules or algorithms included in the program code 406 of the MPA 404 Can be created using The mobile device fingerprint 1204 may be, for example, a numeric value, a hexadecimal value, a character string, or the like.

The processing unit 204 may also be configured to generate a diversifier value 1208 using the mobile device fingerprint 1204. The pluralization value may be generated by combining the instance identifier 408 of the MPA 404 and the mobile device fingerprint 1204 along with a random value 1206. The random value 1206 may be a random number or a pseudo-random number generated by the processing unit 204. In some examples, the random value 1206 may be generated according to one or more rules or algorithms stored in the memory 212. The combination of the mobile device fingerprint 1204, instance identifier 408, and random value 1206 may also be performed using, for example, one or more rules or algorithms stored in the program code 406 of the MPA 404. I can. The use of the instance identifier 408 to generate the multiplicity value allows the MPA 404 to prevent access to data stored by other instances of the MPA 404 with multiple installations of the MPA 404. This can result in the ability to safely store data associated with an instance of.

The processing unit 204 may then generate an advanced storage key 1210 through application of the encryption value 414 stored in the encryption application 410 to the multiplexing value 1208. In some examples, the advanced storage key 1210 may be generated by decrypting the pluralization value 1208 using the encryption key 414. In other examples, the advanced storage key 1210 may be a value resulting from encryption of the pluralization value 1208 using the encryption key 414. In some embodiments, the advanced storage key 1210 may be generated as a result of performing white box encryption using the pluralization value 1208 and the encryption key 414.

Once the advanced storage key 1210 is generated, the processing unit 204 may encrypt the local database 1210 using the advanced storage key 1210. The local database 1210 may consist of, for example, the card database 208, one or more payment profiles 302, a portion of the memory 212, or other suitable data source. In some examples, the local database 1210 may be part of another database within the mobile device 104, such as the card database 208. For example, the card database 208 may have a separate local database 1212 for each instance of the MPA 404 to store payment profiles 302 associated with each instance of the MPA 404. ) May include a plurality of local databases 1212. The resulting encrypted local database 1214 is thereby provided by any other application program inside or outside the mobile device 104 except for a specific instance of the MPA 404 that contains the instance identifier 408. Data that is not accessible can be safely stored. Thus, the encrypted local database 1214 may be ideal for storing payment credentials 304, single use keys 306, and other account data, and secure storage of sensitive account information without the use of security elements. Function can be provided.

In some embodiments, the storage key may also be used by the transaction management server 102 to provide encrypted data to the mobile device 104 for storage in the encrypted local database 1214. For example, the transmission unit 206 of the mobile device 104 may transmit the generated random value 1206 to the transaction management server 102. In some examples, the instance identifier 408 may also be transmitted to the transaction management server 102 and the instance identifier 408 may be preloaded by the transaction management server 102, such as during registration of the MPA 404. May be owned by The transaction management server 102 may then generate the advanced storage key 1210 itself, and data to be provisioned on the mobile device 104 using the advanced storage key 1210, such as payment Credentials 304, single use keys 306, etc. may be encrypted, and then the encrypted data may be transmitted to the mobile device 104. The mobile device 104 may then store the previously encrypted data in the encrypted local database 1214.

Payment In the transaction Payment Credentials The first representative method to generate

13 illustrates a method 1300 for generation of payment credentials in a payment transaction, including the use of two application cryptograms for securely using payment credentials on a mobile device 104 without a secure element. Has been.

In step 1302, at least a single use key (eg, single use key 306) may be stored in a memory (eg, payment profile 302) associated with the transactional account. In some embodiments, the memory 302 may be a non-secure element memory of a mobile communication device (eg, the mobile device 104). In step 1304, a personal identification number (PIN) may be received by a receiving device (eg, the receiving unit 202 and/or the input unit 214).

In step 1306, a first session key (eg, first session key 308) may be identified by a processing device (eg, the processing unit 204). In step 1308, a second session key (e.g., second session key 310) may be generated by the processing device 204 based at least on the stored single use key 306 and the received PIN. .

In step 1310, a first application password may be generated by the processing device 204 based on at least the first session key 308. In step 1312, a second application password may be generated by the processing device 204 based on at least the second session key 310.

In step 1314, at least the first application password and the second application password may be transmitted by a transmitting device (eg, the transmitting unit 206) for use in a payment transaction. In some embodiments, the first application password and the second application password may be transmitted to a point of sale information management device (eg, the point of sale information management system 110 ). In one embodiment, the method 1300 may additionally include storing a card master key associated with the transactional account in the memory 302, in which case the identification of the first session key 308 Includes generating the first session key 308 based at least on the stored card master key by the processing device 204.

In some embodiments, the method 1300 may also include storing an application transaction counter (e.g., the application transaction counter 312) in the memory, in which case the first session key 308 Identification includes generating the first session key 308 based at least on the stored application transaction counter 312 by the processing device 204. In one embodiment, the method 1300 may additionally include validating the received PIN prior to the generation of the second session key 310 by the processing device 204. In an additional embodiment, the processing device 204 may be configured to generate an invalid second session key 310 when the received PIN fails.

Payment In the transaction Payment Credentials Second representative way to generate

14 shows a method 1400 for generation of payment credentials in a payment transaction, including the use of two application cryptographic validation of payment credentials generated by mobile device 104 without the use of a secure element. This is illustrated.

In step 1402, at least a card master key (eg, first card master key 612) may be stored in a memory (eg, account profile 602) associated with the transactional account. , The first session key 606 may be generated by the processing device (eg, the processing device 504) based at least on the stored card master key 612. In step 1406, the second session key ( For example, the second session key 608 may be generated by the processing device 504.

In step 1408, a first application password may be generated by the processing device 504 based on at least the first session key 606. In step 1410, a second application password may be generated by the processing device 504 based on at least the second session key 608. In step 1412, at least the first application password and the second application password may be transmitted by a transmitting device (eg, the transmitting unit 506) for use in a payment transaction.

In one embodiment, the method 1400 may additionally include storing a transaction account sequence number associated with the transaction account in the memory 602, in which case the first session key is the stored It is additionally done based on the transaction account sequence number. In some embodiments, the method 1400 may also include storing a second card master key (e.g., the second card master key 614) associated with the transactional account in the memory 602. In this case, the second session key 608 is at least based on the stored second card master key 614.

In one embodiment, the method 1400 receiving a first corresponding application password and a second corresponding application password by a receiving device (eg, the receiving unit 502); By the processing unit, (i) the received first corresponding application password made based on the generated first application password, and (ii) the reception made based on the generated second application password Validating the generated second corresponding application cipher; And transmitting, by the transmitting device 506, the result of the validation for use in the payment transaction. In an additional embodiment, the first corresponding application password and the second corresponding application password may be received from a point-of-sale information management device (eg, the point-of-sale information management system 110). In another additional embodiment, the result of the validation may be transmitted to a financial institution (eg, the issuer 106) associated with the transaction account.

Typical way to process data messages

FIG. 15 shows a remote notification message received through a remote notification service, including reception and validation of a data message, such as a remote notification message received through a remote notification service, by a mobile device 104 that does not use a secure element. A method 1500 of processing the same data message is illustrated.

In step 1502, at least the encryption key may be stored in a memory (eg, the memory 212). In some embodiments, the memory 212 may be a non-secure element memory within a mobile communication device (eg, the mobile device 104). In step 1504, a data message may be received by a receiving device (e.g., the receiving unit 202), in which case the data message may contain at least an encrypted message and a message authentication code, and the message authentication code Is generated using at least a portion of the encrypted message. In some embodiments, the data message may be a remote notification service message received through a remote notification service.

In step 1506, a reference authentication code may be generated by a processing device (eg, the processing unit 204) using at least a portion of the encrypted message included in the received data message. In one embodiment, the memory 212 may additionally include one or more authentication code generation rules, and the reference authentication code is the stored one or more of the portion of the encrypted message included in the received data message. It can be generated based on the application of authentication code generation rules. In step 1508, the received data message may be validated by the processing device 204 based on a check of a message authentication code included in the received data message against the generated reference authentication code. In some embodiments, a reference counter may be additionally included in the memory, and a message counter may be additionally included in the received data message, and the received data message is the received data for the stored reference counter. It may be additionally validated by the processing device 204 based on a check of a message counter included in the message.

In step 1510, the encrypted message included in the data message may be decrypted by the processing device 204 using the stored encryption key to obtain a decrypted message. In one embodiment, the decrypted message includes at least one of a digitized card profile (e.g., payment credentials 304) and a single use key (e.g., the single use key 306) for use in a payment transaction. One can be included. In some embodiments, the method 1500 may also include checking the data format of the decrypted message based on one or more data formatting rules by the processing device 204.

In one embodiment, the method 1500 may additionally include transmitting a reception notification in response to the received data message by a transmitting device (eg, the transmitting unit 206 ). In an additional embodiment, the method (1500) performing one or more actions based on the decrypted message by the processing device (204); Generating a return message as a result of the one or more actions performed by the processing device (204) or based on the one or more actions performed; Encrypting the generated return message by using the stored encryption key by the processing device (204) to obtain an encrypted return message; And generating a return authentication code using at least a portion of the encrypted return message, and in this case, the encrypted return message and the return authentication code are included in the transmitted reception notification. Included. In a further exemplary embodiment, a recovery counter may be additionally included in the memory 212, and the recovery counter may be additionally included in the transmitted reception notification.

In some embodiments, the method 1500 also includes padding an encrypted message contained within the received data message using a padding key by the processing device 204, in which case the reference Part of the encrypted message used to generate the authentication code is the padded encrypted message. In an additional embodiment, the padding key may be the encryption key. In another additional embodiment, the memory 212 may additionally include an authentication code padding algorithm, and padding the encrypted message using the padding key is the padding key for the authentication code padding algorithm. It may include padding the encrypted message based on the application of.

Representative method for building advanced storage keys

16 illustrates a method 600 of constructing an advanced storage key for secure encryption and storage of local data in a mobile device that does not use a secure element.

In step 1602, at least device information (eg, device information 402) associated with a mobile communication device (eg, the mobile device 104), a first application program (eg, the mobile payment application 404). A program code (e.g., program code 406), and a program code (e.g., program code 412) associated with a second application program (e.g., the encryption application 410) are stored in the memory of the mobile communication device 104 (For example, it may be stored in the memory 212, in this case, the program code 406 associated with the first application program 404 includes at least an instance identifier (eg, an instance identifier 408), and the The program code 412 associated with the second application program 410 includes at least a first key (eg, the encryption key 414).

In some embodiments, the device information 402 may include one or more unique identifiers associated with the mobile communication device 104. In one embodiment, the instance identifier 408 may be unique to an instance of the first application program 404. In some embodiments, the second application program 410 may be configured to perform white box encryption using the first key. In one embodiment, the first key may be a dynamic key. In some embodiments, the program code 412 associated with the second application program 410 may be included in the program code 406 associated with the first application program 404. In additional embodiments, the second application program 410 may be an executable function of the first application program 404.

In step 1604, a device fingerprint (eg, mobile device fingerprint 1204) associated with the mobile communication device 104 is stored in the stored device through execution of the program code 406 associated with the first application program 404. It may be generated by a processing device (eg, the processing unit 204) based on the information 402. In step 1606, a random value (eg, a random value 1206) may be generated by the processing device 204 through execution of the program code 406 associated with the first application program 404. In some embodiments, the random value 1206 may be a random number or a pseudo-random number.

In step 1608, at least the generated device fingerprint 1204, the generated random value 1206, and a program code 406 associated with the first application 404 are at least a plurality of values (e.g., a plurality of values 1208). ) May be constructed by the processing device 204 based on the instance identifier 408 included in the). In step 1610, the second application program 412 is executed through execution of the program code 412 associated with the second application program 410 so that the constructed diversification value 1208 obtains a storage key (eg, advanced storage key 1210). 2 It can be decrypted by the processing device 204 using the first key stored in the program code 412 associated with the application program 410.

In some embodiments, the method 1600 includes storing protected data in a local database (eg, the local database 1212) of the mobile communication device 104; And encrypting the protected data stored in the local database 1212 using the storage key 1210 by the processing device 204. In one embodiment, the method further includes storing program data associated with the first application program 404 in the memory 212; And storing the generated random data 1206 in program data associated with the first application program 404.

In one embodiment, the method 1600 further includes transmitting at least the random value 1206 by a transmitting device (eg, the transmitting unit 206); Receiving one or more encrypted parameters by a receiving device (eg, the receiving device 202), wherein the one or more encrypted parameters are each encrypted using the storage key 1210; And storing the received one or more encrypted parameters in the local database 1212 of the mobile communication device 104. In an additional embodiment, the storage key 1210 may be transmitted to a third party (eg, the transaction management server 102) and the one or more encrypted parameters may be received from the third party 102. I can. In some additional embodiments, the instance identifier 408 may also be transmitted by the transmitting device 206.

Computer system architecture

17 illustrates a computer system 1700 that allows embodiments of the present disclosure, or portions thereof, to be implemented as computer-readable code. For example, the transaction management server 102 and the mobile device 104 of FIG. 1 may use hardware, software, firmware, a non-transitory computer-readable medium in which instructions are stored, or a combination thereof. 1700), and may be implemented in one or more computer systems or other processing systems. Hardware, software, or any combination thereof may include modules and components used to implement the methods of FIGS. 7, 8, 9A, 9B, 10A, 10B, 11, and 13-16. Can be specified.

Where programmable logic is used, such logic can be executed on a commercially available processing platform or on a dedicated device. For those of ordinary skill in the art, embodiments of the disclosed subject matter are multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, and virtually any device. It will be appreciated that it can be implemented with several computer system configurations, including low-end or small computers that can be embedded within. For example, at least one processor device and memory may be used to implement the above-mentioned embodiments.

The processor device as discussed herein may be a single processor, a plurality of processors, or combinations thereof. Processor devices may have one or more processor “cores”. Terms as reviewed herein, ie “computer program medium”, “non-transitory computer readable medium”, and “computer usable medium” generally refer to removable storage unit 1718, removable storage unit ( 1722), and a hard disk installed in the hard disk drive 1712.

Several embodiments of the present disclosure have been described for such an exemplary computer system 1700. Upon reading this description, it will become apparent to those skilled in the art how to implement the present disclosure using other computer systems and/or computer architectures. Although the operations may be described as a sequential process, some of the operations may be stored locally or remotely, in virtually parallel, concurrently, and/or in a distributed environment, and for access by a single or multi-processor machine. It can be executed with the program code. In addition, in some embodiments, the order of actions may be rearranged without departing from the spirit of the disclosed subject matter.

The processor device 1704 may be a dedicated or general purpose processor device. The processor device 1704 may be connected to a communication infrastructure 1706 such as a bus, a message queue, a network, a multi-core message delivery scheme, and the like. The network may be any network suitable for performing functions as disclosed herein, and may be a local area network (LAN), a wide area network (WAN), a wireless communication network (e.g. , WiFi), a mobile communication network, a satellite communication network, the Internet, an optical fiber, a coaxial cable, an infrared ray, a radio frequency (RF), or any combination thereof. Other suitable network types and configurations will become apparent to those skilled in the relevant art. The computer system 1700 may also include a main memory 1708 (eg, random access memory, read only memory, etc.) and may also include an auxiliary memory 1710. The auxiliary memory 1710 may include a removable storage drive 1714 and a hard disk drive 1712 such as a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, and the like.

The removable storage drive 1714 can be read from and/or written to the removable storage unit 1718 in a known manner. The removable storage unit 1718 may include a removable storage medium that can be read and written by the removable storage drive 1714. For example, when the removable storage drive 1714 is a floppy disk drive or a universal serial bus port, the removable storage unit 1718 may be a floppy disk or a portable flash drive, respectively. In one embodiment, the removable storage unit 1718 may be a non-transitory computer-readable recording medium.

In some embodiments, the auxiliary memory 1710 is modified means for allowing computer programs or other instructions to be loaded into the computer system 1700, for example the removable storage unit 1722 and the interface 1720. It may include. Examples of such means will be apparent to those skilled in the art, but include program cartridges and cartridge interfaces (eg, as found in video game systems), removable memory chips (eg EEPROM, PROM, etc.) and associated There may be sockets, and other removable storage units 1722 and interfaces 1720.

Data stored in the computer system 1700 (e.g., the main memory 1708 and/or the secondary memory 1710) may be stored in optical storage (e.g., compact disc, digital versatile disc, Blu-ray disc, etc.) or magnetic It can be stored on any type of suitable computer readable medium, such as tape storage (eg, hard disk drive). The data may be composed of any type of suitable database configuration, such as a relational database, a structured query language (SQL) database, a distributed database, an object database, and the like. Suitable configurations and storage types will become apparent to those skilled in the relevant art.

The computer system 1700 may also include a communication interface 1724. The communication interface 1724 may be configured to allow software and data to be transferred between the computer system 1700 and external devices. Representative communication interfaces 1724 may include a modem, a network interface (eg, an Ethernet card), a communication port, a PCMCIA slot and card, and the like. The software and data transmitted through the communication interface 1724 may be made in the form of signals, which may be electronic, electromagnetic, optical, or other signals, as will be apparent to those skilled in the related art. The signals may be configured to carry the signals and traveled through a communication path 1726, which may be implemented using wires, cables, optical fibers, telephone lines, cellular phone links, radio frequency links, and the like.

The computer system 1700 may additionally include a display interface 1702. The display interface 1702 may be configured to allow data to be transferred between the computer system 1700 and an external display 1730. Representative display interfaces 1702 may include a high-definition multimedia interface (HDMI), a digital visual interface (DVI), a video graphics array (VGA), and the like. The display 1730 includes a cathode ray tube (CRT) display, a liquid crystal display (LCD), a light-emitting diode (LED) display, a capacitive touch display, and a thin-film transistor. It may be any suitable type of display for displaying data transmitted through the display interface 1702 of the computer system 1700, including a transistor (TFT) display, and the like.

Computer program media and computer usable media may refer to memories such as main memory 1708 and auxiliary memory 1710, which may be memory semiconductors (eg, DRAMs, etc.). These computer program products may be means for providing software to the computer system 1700. Computer programs (eg, computer control logic) may be stored in the main memory 1708 and/or the auxiliary memory 1710. Computer programs may also be received via the communication interface 1724. Such computer programs, when executed, enable computer system 1700 to implement the methods of the present invention as discussed herein. In particular, the computer programs, when executed, cause the processor device 1704 to refer to FIGS. 7, 8, 9A, 9B, 10A, 10B, 11, and 13-16 as reviewed in the present specification. It makes it possible to implement the illustrated methods. Thus, such computer programs may represent the controllers of the computer system 1700. In case the present disclosure is implemented using software, the software may be stored in a computer program product and the removable storage drive 1714, interface 1720, and hard disk drive 1712, or communication interface ( 1724) can be used to load into the computer system 1700.

Techniques consistent with this disclosure include, among other features, secure storage of data using an advanced storage key and transmission and validation of remote notification service messages, of payment transactions using a mobile device that does not use a secure element. Processing systems and methods are provided. While several exemplary embodiments of the disclosed systems and methods have been described above, those skilled in the relevant art will understand that several exemplary embodiments of the disclosed systems and methods are presented for illustrative purposes only, not limitation. The various exemplary embodiments of the disclosed systems and methods are not exhaustive and are not intended to limit the disclosure to the precise form disclosed. Modifications and variations may be possible in light of the above teachings and may be obtained from practice of the present disclosure without departing from the breadth or scope.

Claims (18)

In the method of building the advanced storage key,
The above method,
Generating, by a processing device of the mobile communication device, a device fingerprint associated with the mobile communication device based on device information stored through execution of a first set of processor-readable instructions associated with the mobile communication device;
Generating a random value by the processing device;
Constructing, by the processing device, a diversifier value based on at least the generated device fingerprint, the generated random value, and an instance identifier included in the first set of processor-readable instructions. step;
By the processing device, through the execution of the second set of processor-readable instructions, the constructed pluralization value is decrypted using the first key included in the second set of processor-readable instructions to obtain a storage key. Step to do;
Storing, by the processing device, protected data in a local database of the mobile communication device; And
Encrypting, by the processing device, protected data stored in the local database using the storage key;
Including a, advanced storage key construction method. The method of claim 1,
The device information includes one or more unique identifiers associated with the mobile communication device. The method of claim 1,
The random value is a random number or a pseudo-random number, a method of constructing an advanced storage key. The method of claim 1,
Wherein the second set of processor readable instructions are configured to perform white box encryption using the first key. The method of claim 1,
The first key is a dynamic key, a method of constructing an advanced storage key. The method of claim 1,
The second set of processor readable instructions are included in the first set of processor readable instructions. The method of claim 6,
Wherein the second set of processor readable instructions are executable functions of the first set of processor readable instructions. The method of claim 1,
The method of constructing the advanced storage key,
Transmitting at least the generated random value by a transmitting device;
Receiving, by a receiving device, one or more encrypted parameters, each of the one or more encrypted parameters being encrypted using the storage key;
Storing the received one or more encrypted parameters in a local database of the mobile communication device;
The method of building an advanced storage key further comprising. The method of claim 8,
Transmitting at least the generated random value further comprises transmitting the instance identifier. A non-transitory computer-readable recording medium configured to store a program for causing a processing device of a mobile communication device to execute a method for constructing an advanced storage key, comprising:
The above method,
Generating, by a processing device of the mobile communication device, a device fingerprint associated with the mobile communication device based on device information stored through execution of a first set of processor-readable instructions associated with the mobile communication device;
Generating a random value by the processing device;
Constructing, by the processing device, a diversifier value based on at least the generated device fingerprint, the generated random value, and an instance identifier included in the first set of processor-readable instructions. step;
By the processing device, through the execution of the second set of processor-readable instructions, the constructed pluralization value is decrypted using the first key included in the second set of processor-readable instructions to obtain a storage key. Step to do;
Storing, by the processing device, protected data in a local database of the mobile communication device; And
Encrypting, by the processing device, the protected data stored in the local database using the storage key;
Containing, a non-transitory computer-readable recording medium. The method of claim 10,
The device information contains one or more unique identifiers associated with the mobile communication device. The method of claim 10,
The random value is a random number or a pseudo-random number, a non-transitory computer-readable recording medium. The method of claim 10,
The second set of processor-readable instructions configured to perform white box encryption using the first key. The method of claim 10,
The first key is a dynamic key, a non-transitory computer-readable recording medium. The method of claim 10,
The second set of processor-readable instructions are contained in the first set of processor-readable instructions. The method of claim 15,
The second set of processor-readable instructions are executable functions of the first set of processor-readable instructions. The method of claim 10,
The method of constructing the advanced storage key,
Transmitting the generated random value by a transmitting device;
Receiving, by a receiving device, one or more encrypted parameters, each of the one or more encrypted parameters being encrypted using the storage key;
Storing the received one or more encrypted parameters in a local database of the mobile communication device;
Further comprising, a non-transitory computer-readable recording medium. The method of claim 17,
The step of transmitting the generated random value further comprises transmitting the instance identifier, a non-transitory computer-readable recording medium.

Images