Patent Application
20160005035
The subject matter described herein relates to mobile payments.
Mobile payments made via cellphones and smartphones are becoming ubiquitous in many parts of the world. Specifically, a user of a cell phone may make purchases, replenish an account, pay bills, and perform other transactions via the cell phone.
Methods and apparatus, including computer program products, are provided for secure financial transactions.
In one aspect there is provided a method. The method may include initiating, by an application at a user equipment, generation of a short message service message to carry at least financial transaction information; generating, in response to the initiating, a plaintext descriptor portion and an encrypted portion, wherein the plaintext descriptor portion provides a plaintext representation of the financial transaction information carried by the short message service message, and wherein the encrypted portion includes the financial transaction information in an encrypted form; and sending, via the short message service message, the plaintext descriptor portion and the encrypted portion. Related apparatus, systems, methods, and articles are also described.
In some variations, one or more of the featured disclosed herein including one or more of the following features can optionally be included in any feasible combination. The application may include a mobile payment application. The initiating may be performed in response to a data connection being unavailable or not allowed at the user equipment. The encrypted financial transaction information includes at least one of account information, a card number, a personal identification number (PIN), or cardholder information. The plaintext descriptor may include at least one of a destination phone number, an amount, a currency, an indication of secrecy, and/or a descriptor of a transaction type being carried by the short message service message. The encrypted portion may be performed using symmetric encryption. A user interface may present the short message service message including the plaintext descriptor portion and the encrypted portion.
The above-noted aspects and features may be implemented in systems, apparatus, methods, and/or articles depending on the desired configuration. The details of one or more variations of the subject matter described herein are set forth in the accompanying drawings and the description below. Features and advantages of the subject matter described herein will be apparent from the description and drawings, and from the claims.
In the drawings,
Like labels are used to refer to same or similar items in the drawings.
Mobile payments systems may use secure short message service (SMS) to pass financial information. Moreover, the SMS may be used, when a data connection, such as an Internet Protocol (IP) connection, is not available or allowed (for example, in some emerging markets, data connections may not be available or usage may be limited due to cost). Moreover, in order to send an SMS message directly from an application on a user equipment, some operating systems require user review or interaction. Specifically, the SMS message contents may be presented on a user interface at the user equipment, so that a user can view the SMS message content and confirm the sending of the SMS message. However, if the SMS message is encrypted (which may be the case to protect financial information), a user may be not be comfortable proceeding with the sending of an SMS message as the SMS message content will appear as garbled, encrypted text.
In some example embodiments, the subject matter disclosed herein may provide an SMS message containing a plaintext descriptor portion and an encrypted portion. The encrypted portion may secure financial transaction information, such as account information and the like. The plaintext descriptor portion may provide plaintext information regarding the transaction, such as the type of transaction being carried by the short message service message. As such, when the SMS message is sent directly from for example an application, such as a mobile payment application, a user can view the SMS message including the plaintext descriptor portion and the encrypted portion. When this SMS message is viewed at a user interface before sending, a user is provided plaintext or human-intelligible information. For example, the user interface at a user equipment may present a plaintext transaction description (for example, a description of the type of transaction, summary information of transaction, and the like) in a plaintext, human-readable form, but any sensitive financial data, such as personal account information, card number, PIN, or other cardholder data, remain encrypted.
The system 100 may include a user equipment 114, such as a smartphone, cell phone, and/or any other type of wireless device. The user equipment 114 may include at least one application, such as a mobile payment application (MPA) 116. When mobile payment application 116 attempts to send a secure SMS message to financial system 198 (via base station 110, backhaul link 120, and/or gateway 199), the mobile payment application may generate message 180. The generated message 180 includes a plaintext descriptor 166 that provides plaintext information regarding the transaction. The generated message 180 also includes an encrypted portion 168 that secures financial transaction information. The generated message 180 may thus enable a user to view human-readable/plaintext information when the generated message 180 is sent. For example, if the operating system at the user equipment requires a user to preview and approve the sending of the SMS message 180, the user will be able to view at least a portion of message 180 and understand the type of message being sent.
Referring again to
The secure container 168 may have a certain size, such as 32 plus 2 characters. The 32 plus 2 characters is equal to AES 128 bit encrypted data in base64 format and 2 additional characters to carry the encryption key index information, although other sized containers may be used as well.
In some example embodiments, symmetric key encryption may be used to secure the cardholder's financial information in the secure container 168, and this symmetric encryption may be in accordance with the symmetric encryption described below with respect to
The following depicts another example of the contents of SMS message 180 where credit card information is carried:
In this example, the plaintext description indicates in a plaintext, human-readable format that card information is being sent (e.g., “SendCard”). The plaintext, human readable information also includes the last four numbers of the credit card, 1231, and the amount of 22312.00. The plaintext “CARD” and “SECRET” give a reader an indication that the unintelligible text that follows is card information in a secret (or cypher) form. Generally, the last four digits of a credit card number can be shared in an unsecure manner per Payment Card Industry Data Security Standard (PCI DSS). However, the credit card information as a whole is encrypted as shown by the scrambled or unintelligible information, such as “6743C3D1519AB4F2CD9A78AB09A511BD1212.”
At 202, when a data connection, such as an IP connection, is not available or allowed to be used at user equipment 114, user equipment 114 (or a communications controller therein) may select use of an SMS connection to the base station (or wireless access point) 110, in accordance with some example embodiments. If however, there is an IP connection available or allowed, the user equipment 114 may select use, at 204, of the data connection, rather than SMS. In some implementations, a communications controller may select the IP connection or SMS connection, although the selection may be performed in other ways (for example, based on a user selection or preference).
If SMS is selected (yes at 202), the sending of an SMS message may be initiated at 205, in accordance with some example embodiments. For example, when mobile payment application 116 seeks to send financial information, such as credit card information to make a payment, a request for token, and/or the like, to gateway 199 and/or financial system 198, an SMS message may be generated to carry the financial information. A portion of the financial information may be encrypted, and the encryption may be symmetric encryption as described further below, although other types of encryption may be used as well. The generated SMS message may thus carry a plaintext descriptor 166 of the transaction as well as an encrypted portion 168 including the encrypted financial information. The plaintext portion enables a user to recognize the type of transaction being carried by the SMS message 180.
At 210, an SMS message may be generated, and the generated SMS message may include a plaintext descriptor portion and an encrypted, in accordance with some example embodiments. For example, the user equipment 114 may generate SMS message 180 which includes a plaintext descriptor 166 and a security container 168. The security container in this example includes“6743C3D1519AB4F2CD9A78AB09A511BD23 23.” The security container may be encrypted using symmetric encryption, although other types of encryption may be used as well. The plaintext descriptor 166 includes a plaintext “SendMoney +38407772071 INR 12323.00.” The “SECRET” is in plaintext to signal to a user that the subsequent symbols/text are encrypted. In some example embodiments, mobile payment application 116 may provide the plaintext used for the plaintext descriptor portion. For example, mobile payment application 116 knows the type of transaction being performed, so mobile payment application 116 may provide the plaintext descriptor(s).
At 215, the generated SMS message may be viewed before the message is sent, in accordance with some example embodiments. The SMS message 180 may be viewed, at 215, in a user interface. For example, before being sent, SMS message 180 may be viewed at a user interface at user equipment 114. Because of the plaintext descriptor 166, the user interface may allow viewing of a general description of the financial information carried by the secure, encrypted portion 168 (which may appear garbled, scrambled, or otherwise unintelligible at the user interface).
Moreover, in some implementations, a user may be prompted by for example the user interface to approve the sending as depicted at
At 230, SMS message 180 may be sent to for example, gateway 199 and financial system 198 for processing.
Although some of the examples described herein refer to SMS to carry the plaintext descriptor 166 of the encrypted portion 168, the plaintext descriptor 166 of the encrypted portion 168 may be carried by other types of messages as well.
The apparatus 300 may also include one or more antennas 320 for receiving a downlink and transmitting via an uplink. The apparatus 300 may also include a radio interface 340, which may include other components, such as filters, converters (e.g., digital-to-analog converters and/or the like), symbol demappers, signal shaping components, an Inverse Fast Fourier Transform (IFFT) module, and/or the like, to process symbols carried by a downlink or an uplink. In some implementations, the apparatus 300 may also be compatible with WiFi, Bluetooth, GERAN, UTRAN, E-UTRAN, first generation (1 G) communication protocols, second generation (2G or 2.5G) communication protocols, third-generation (3G) communication protocols, fourth-generation (4G) communication protocols and/or any other standards, radio access technologies, and specifications as well. Moreover, the apparatus 300 may be configured to support messaging, such as SMS messages. The apparatus 300 may further include at least one data processor, such as data processor 330 (e.g., a microprocessor and/or the like) for controlling apparatus 300 and for accessing and executing program code stored in memory 335. For example, memory 335 may include code for performing one or more of the operations associated with respect to the user equipment.
The following describes an encryption approach which may be used in some example embodiments. Specifically, a mobile payment application (for example, mobile payment application 116) may receive a key collection including a plurality of key parts. These key parts may include key values and indexes. A key value represents a portion of a symmetric key, and an associated index identifies the key value in a certain key collection. For example, when information is received for secure transmission by the mobile application, the mobile application may select 2 key parts (i.e., key values and corresponding indexes) from each of the 4 key collections, although other quantities of key values and key collections may be used as well. The mobile application may then combine the selected key values to form a symmetric key, which is then used to encrypt the received information. The mobile application may then generate a short message service (SMS) message carrying at least a header portion and a payload portion. The payload may include the encrypted information, and the header may represent the indexes identifying which key values were selected to form the symmetric key. The SMS payload portion may also include a plaintext portion 166 as noted above to give a user an indication of whether it is okay to send the SMS message to a destination, such as gateway 199 and the like. The mobile application may then send the SMS message to a preview pane 118 to obtain user approval before sending the SMS message to gateway 199 and the like, where the SMS message can be decrypted.
In some example embodiments, the symmetric key is dynamically generated in the sense that each piece of information, such as financial transaction information, requiring transmission to the server/gateway 199 is encrypted with a unique, one-time key. Moreover, the key collections at the mobile application may be updated with another key collection, when the possible key combinations have been exhausted, when the keys have been compromised, and/or any other time new key collections are desired. The subject matter disclosed herein may, in some example implementations, provide symmetric encryption for SMS communication and the like using a dynamic, one-time use symmetric key formed from key parts shared by the sender and receiver.
In some exemplary embodiments, user equipment 114 may be implemented as a mobile wireless device. The user equipment 114 may be referred to as, for example, a mobile station, a mobile unit, a subscriber station, a wireless terminal, a tablet, a smart phone, a cell phone, and/or the like. The user equipment may be implemented as, for example, a wireless handheld device, a wireless plug-in accessory, and/or the like. In some cases, the user equipment may include a data processor, a computer-readable storage medium (e.g., memory, storage, and/or the like), a radio access mechanism, and/or a user interface. Moreover, the user equipment may include one or more applications, such as application 116 stored as code in memory and executable by a data processor. Furthermore, user equipment 114 may be configured to send SMS messages, via wireless, to an SMS aggregator, which may forward the SMS message to gateway 199.
Server/gateway 199 may include a data processor and a computer-readable storage medium (e.g., memory, storage, and/or the like). In some example embodiments, server 199 may be implemented as gateway having a first interface to a SMS aggregator (and/or SMS provider) and a second interface to other systems, such as financial systems 198, such a mobile payment networks, financial institutions, payment processors, credit card processors, and/or the like.
At 5402, the server 199 may generate and store key collections. For example, server 199 may comprise a data processing device configured to generate key collections. Specifically, server 199 may randomly generate and store key collections, each of which includes indexes and corresponding key values. The key values represent portions of a symmetric key, and when some of these portions are combined, the combined portions form a symmetric key used to encrypt information using a symmetric encryption engine, such as AES and/or the like. In some example embodiments, server 199 includes a security module that generates, or receives from a key generator, 4 key collections, as depicted at
The example of
Referring again to
At 4404, the server 199 may send the key collections generated and stored at 5102 to user equipment 114. For example, server 199 may share the key collections 5202A-D with user equipment 114 including mobile payment application 116 by sending the key collections 5202A-D. In some example embodiments, the key collections may be sent via at least a wireless link carrying an encrypted SMS message as disclosed herein (e.g., an index and an encrypted payload, using for example AES, as disclosed herein), although the key collections may be sent in other ways as well. For example, when the client device, such as user equipment 114, connects to server 199 for the first time, user equipment 114 may obtain the initial key collections (and/or other software and/or data for the application 116) via a secure connection using, for example, a shared service public key. After that initial key collection delivery, the encrypted SMS messages disclosed herein may be used to share the key collections.
Once the user equipment 114 receives the key collections, user equipment 114 may then store at 4104 the key collections. Moreover, the application 116 and/or user equipment 114 may receive key collections 5202A-D and then store the key collections 5202A-D securely using, for example, local encrypted, or otherwise secure, storage.
At 4106, a message may be processed for encryption, in accordance with some example embodiments. For example, mobile payment application 116 and/or user equipment 114 may have a message for transmission, such as a bill pay message (“<billId=xxxx;amount:12.95>”) 5210 at
At 4108, the application 116 at user equipment 114 may select key parts. For example, application 116 may randomly select 2 key parts from each collection, as depicted at 5220A-D at
At 4110, a symmetric key may be generated, based on the selected key parts. For example, user equipment 114 and/or application 116 may select the key values from each of the selected key parts 5220A-D and then combine those key values to form a symmetric key. Referring again to
In some example embodiments, the generated symmetric key may also be hashed using user equipment 110's Mobile Station International Subscriber Directory Number (MSISDN), a Bluetooth universally unique identifier (UUID), or any other identifier (which would also be known by the server 199).
At 4112, the symmetric key may be used to encrypt the message payload, and a plaintext header including indexes may be appended to the payload. The plaintext may also include a plaintext descriptor 166. In the example of
Although the message header 5250 at
In some example embodiments, the message body 5240 may also be signed using, for example, a hash as noted above. This hash may be implemented as a Secure Hash Algorithm (SHA) and/or MD5, although other hash techniques may be used as well.
In the example of
At 4114, the message may be sent to server 199. Referring again to
At 5116, server 199 may decrypt the message based on the index in the header. For example, server 199 may read the header comprising 2, 15, 0, 2, 1, 3, 3, and 15 and then access the key collections to identify the key values forming the symmetric key (e.g., 7613167486354513) used by user equipment 114 to send the message. Using the symmetric key, server 199 may then decrypt the message into plaintext. When hashing is used, the server 199 may hash the symmetric key before decrypting the message.
In some example embodiments, the server 199 may send an acknowledgement message to user equipment 114 to confirm receipt of the message received by server 199 at 4110. This acknowledgement may be sent as an SMS message. Moreover, this SMS acknowledgement message may carry a payload encrypted using the same key used to encrypt the payload of the message received at 4114, although a different key may be generated using the key collections.
In some example embodiments, each generated symmetric key is used only during one request/response sequence before it is discarded. When this is the case, the user equipment 114 may store and keep a record of all the used key parts combinations. Moreover, the record may allow server 199 to reject any incoming messages that use an already-used symmetric key. Furthermore, once a certain amount of key parts combinations have been used or when the key collections (or portions thereof) have been compromised, server 199 may, in some example embodiments, decide to renew the key collections by resending a new set of key collections at 6102.
The subject matter described herein may be embodied in systems, apparatus, methods, and/or articles depending on the desired configuration. For example, the base stations and user equipment (or one or more components therein) and/or the processes described herein can be implemented using one or more of the following: a processor executing program code, an application-specific integrated circuit (ASIC), a digital signal processor (DSP), an embedded processor, a field programmable gate array (FPGA), and/or combinations thereof. These various implementations may include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device. These computer programs (also known as programs, software, software applications, applications, components, program code, or code) include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the term “machine-readable medium” refers to any computer program product, computer-readable medium, computer-readable storage medium, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions. Similarly, systems are also described herein that may include a processor and a memory coupled to the processor. The memory may include one or more programs that cause the processor to perform one or more of the operations described herein.
Although a few variations have been described in detail above, other modifications or additions are possible. In particular, further features and/or variations may be provided in addition to those set forth herein. Moreover, the implementations described above may be directed to various combinations and subcombinations of the disclosed features and/or combinations and subcombinations of several further features disclosed above. In addition, the logic flow depicted in the accompanying figures and/or described herein does not require the particular order shown, or sequential order, to achieve desirable results. Other embodiments may be within the scope of the following claims.
