Online secret encryption

Abstract

A method includes receiving, by a server computer, a thin client identifier from a thin client on a communication device. The server computer can then retrieve an encrypted first cryptographic key based on the thin client identifier. The encrypted first cryptographic key is a first cryptographic key encrypted with a second cryptographic key. The server computer can initiate sending the encrypted first cryptographic key to the thin client. The server computer then receives an encrypted secret from the thin client, the encrypted secret being a secret encrypted with the first cryptographic key.

Description

[0001] Cross-referencing related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 013,746, filed April 22, 2020, which is incorporated herein by reference in its entirety for all purposes. Background Technology

[0003] Conventional secure input units, such as PIN pads and biometric scanners, are manufactured with a password key stored in a secure location within the unit. The availability of such units may be limited because each unit needs to be custom-manufactured by a specific security agency.

[0004] In some other types of systems, the secure data processing unit is located in the cloud (e.g., on a server computer). A local client unit communicates with the secure data processing unit and can receive secrets (e.g., biometrics, PINs, etc.) from the user. Such a local client unit can be a conventional, commercially available mobile phone. This type of local client unit may not have a sufficiently secure and standardized security mechanism to protect such secrets.

[0005] The embodiments of this disclosure address this problem and other problems individually and collectively. Summary of the Invention

[0006] The embodiments relate to methods and systems for securely encrypting online secrets using a communication device with a thin client. The communication device may be a mobile phone that is not equipped with a special cryptographic key at the time of manufacture.

[0007] One embodiment relates to a method comprising: receiving a thin client identifier from a thin client on a communication device by a server computer; retrieving an encrypted first cryptographic key based on the thin client identifier by the server computer, wherein the encrypted first cryptographic key is a first cryptographic key encrypted with a second cryptographic key; initiating the sending of the encrypted first cryptographic key to the thin client by the server computer; and receiving an encrypted secret from the thin client by the server computer, wherein the encrypted secret is a secret encrypted with the first cryptographic key.

[0008] Another embodiment relates to a server computer comprising: a processor; and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to perform a method comprising: receiving a thin client identifier from a thin client on a communication device; retrieving an encrypted first cryptographic key based on the thin client identifier, wherein the encrypted first cryptographic key is a first cryptographic key encrypted with a second cryptographic key; initiating the sending of the encrypted first cryptographic key to the thin client; and receiving an encrypted secret from the thin client, the encrypted secret being a secret encrypted with the first cryptographic key.

[0009] Another embodiment relates to a method comprising: providing a thin client identifier to a server computer by a thin client on a communication device during an interaction between the communication device and a portable device; receiving an encrypted first cryptographic key from the server computer by the thin client, wherein the encrypted first cryptographic key is a first cryptographic key encrypted with a second cryptographic key; decrypting the encrypted first cryptographic key by the thin client using the second cryptographic key; receiving a secret from a user of the portable device by the thin client; encrypting the secret by the thin client using the first cryptographic key; and providing the encrypted secret to the server computer by the thin client.

[0010] Further details regarding embodiments of this disclosure can be found in the detailed description and the accompanying drawings. Attached Figure Description

[0011] Figure 1 A block diagram of an online secret encryption system according to an embodiment is shown.

[0012] Figure 2 A block diagram of the components of a server computer according to an embodiment is shown.

[0013] Figure 3 A flowchart illustrating the online PIN card holder verification method process according to an embodiment is provided.

[0014] Figures 4A-4B A flowchart illustrating an initialization method according to an embodiment is shown.

[0015] Figures 5A-5B A flowchart is shown, illustrating an online PIN card holder verification method and PIN key refresh process according to an embodiment. Detailed Implementation

[0016] Before discussing the embodiments of this disclosure, some terms may be described in further detail.

[0017] "User" can include an individual. In some embodiments, a user can be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user may also be referred to as a cardholder, account holder, or consumer.

[0018] A "communication device" can be a user-operated device. Examples of communication devices include mobile phones, smartphones, cards, personal digital assistants (PDAs), laptops, desktop computers, server computers, vehicles such as automobiles, simplified client devices, tablet PCs, etc. Additionally, a communication device can be any type of wearable technology device, such as a watch, headphones, glasses, etc. A communication device may include one or more processors capable of processing user input. A communication device may also include one or more input sensors for receiving user input. As is known in the art, various input sensors capable of detecting user input exist, such as accelerometers, cameras, microphones, etc. User input obtained by input sensors can come from various data input types, including but not limited to audio data, visual data, or biometric data. A communication device may include any electronic device that can be operated by the user, and said electronic device may also provide remote communication capabilities with a network. Examples of remote communication capabilities include the use of mobile phone (wireless) networks, wireless data networks (e.g., 3G, 4G, 5G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that can provide access to networks such as the Internet or private networks.

[0019] "Portable device" can include devices that are easily carried or moved. In some embodiments, a portable device can include a device such as a credit card or debit card. A portable device can be used to present credentials or access tokens during interaction. The portable device may have some form of data storage, such as a magnetic stripe or EMVco chip, and the portable device can use data storage to store access tokens or credentials. The portable device may be able to engage with an access device. In some embodiments, a portable device can include a communication device.

[0020] A "thin client" can include an application or software capable of communicating with a server computer. A thin client can process data alongside the server computer, and can offload most of the processing to the server computer. A thin client can reside on a communication device. In some embodiments, a thin client can communicate with a server computer to handle interactions.

[0021] A "thin client identifier" can include a string of characters used to identify or refer to a thin client. The thin client identifier can include any suitable alphanumeric characters. The thin client identifier can be a pre-issued thin client identifier. Pre-issued thin client identifiers can be assigned and provided to thin clients. For example, a server computer can generate thin client identifiers, assign them to thin clients, and provide them to thin clients.

[0022] "Interaction" can include reciprocal effects or influences. "Interaction" can include communication, contact, or exchange between parties, devices, and / or entities. Example interactions include transactions between two parties and data exchange between two devices. In some embodiments, an interaction can include a user requesting access to secure data, a secure webpage, a secure location, etc. In other embodiments, an interaction can include a payment transaction in which two devices can interact to facilitate the payment.

[0023] "Interaction data" can include data related to the interaction and / or data recorded during the interaction. In some embodiments, interaction data can be transaction data of network data. Transaction data can include multiple data elements with data values.

[0024] A "cryptographic key" can include a piece of information that determines the output of a cryptographic algorithm. For encryption algorithms, the cryptographic key can specify the conversion from plaintext to ciphertext. For decryption algorithms, the cryptographic key can specify the conversion from ciphertext to plaintext.

[0025] "Secret" can include things that are kept unknown or intended to be kept from others. Secrets can include a user's biometric template, password, personal identification number, Social Security number, one-time password, and any other data intended to be kept unknown or unseen by others. In some embodiments, a user of a portable device can input a secret into a resource provider's communication device to perform an interaction. Secrets may remain unknown or unseen by the resource provider.

[0026] The "hardware security module" may include a physical computing device for protecting and managing data. The hardware security module can protect and manage digital cryptographic keys, perform encryption and decryption functions for messages and / or digital signatures, and perform authentication and / or any other encryption functions.

[0027] The term "verification" and its derivatives can include the process of using information to determine whether an underlying subject is valid under a given set of conditions. Verification can include any comparison of information to ensure that certain data or information is correct, valid, accurate, legitimate, and / or credible.

[0028] An "authorization request message" can be an electronic message requesting authorization for an interaction. In some embodiments, the message is sent to the transaction processing computer and / or the issuer of the payment card to request authorization for the transaction. According to some embodiments, the authorization request message may comply with International Organization for Standardization (ISO) 8583, a standard for systems that exchange information about electronic transactions associated with payments made by a user using a payment device or payment account. The authorization request message may include an issuer account identifier that can be associated with the payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information," including (by way of example only): service code, card verification value (CVV), dynamic card verification value (dCVV), primary account number or "account number" (PAN), payment token, username, expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as transaction value, merchant identifier, merchant location, acquiring bank identifier (BIN), card acceptor ID, information identifying the item being purchased, etc., and any other information that may be used to determine whether to identify and / or authorize the transaction.

[0029] An "authorization response message" can be a message responding to an authorization request. In some cases, an authorization response message can be an electronic message response to an authorization request message generated by the issuing financial institution or transaction processing computer. For example, an authorization response message may include one or more of the following status indicators: approved – the transaction is approved; rejected – the transaction is not approved; or call center – further information is pending, and the merchant must call the toll-free authorization number. An authorization response message may also include an authorization code, which can be a code indicating approval of the transaction returned by the credit card issuing bank to the merchant's access device (e.g., a POS device) in response to the authorization request message in the electronic message (directly or via the transaction processing computer). This code can serve as evidence of authorization.

[0030] "Authorizing entity" can be the entity requesting authorization. Instances of authorizing entities can be issuers, government agencies, document repositories, access administrators, etc. Authorizing entities can operate authorizing entity computers. "Issuer" can refer to a commercial entity (e.g., a bank) that issues and optionally maintains user accounts. Issuers can also issue payment credentials stored on user devices, such as cellular phones, smart cards, tablets, or laptops, to consumers, or in some embodiments to portable devices.

[0031] A “processor” can include means for performing a task. In some embodiments, a processor can include any suitable one or more data computing means. A processor can include one or more microprocessors that work together to perform a desired function. A processor can include a CPU that includes at least one high-speed data processor sufficient to execute program components for performing user and / or system-generated requests. A CPU can be a microprocessor, such as AMD’s Athlon, Duron, and / or Opteron; IBM and / or Motorola’s PowerPC; IBM and Sony’s Cell processors; Intel’s Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0032] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory may include non-transient computer-readable media whose storage contains instructions executable by a processor to implement a desired method. Instances of memory may include one or more memory chips, disk drives, etc. Such memory can be operated using any suitable electrical, optical, and / or magnetic mode of operation.

[0033] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers that work like cells. In one instance, a server computer can be a database server coupled to a web server. A server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers.

[0034] I. System

[0035] According to an embodiment, a secret can be input into a communication device with a thin client and securely provided to a downstream computer, such as an authorized entity computer. The secret is encrypted as it is transmitted from the communication device to the downstream computer. If intercepted by a malicious party, the malicious party cannot obtain the secret. In some embodiments, when provided from the thin client to the server computer, the secret can be encrypted with a first cryptographic key. Furthermore, the first cryptographic key is not exposed because it is encrypted with a second cryptographic key when provided between the thin client and the server computer.

[0036] A. System Overview

[0037] Figure 1A system 100 according to an embodiment of the present disclosure is illustrated. System 100 includes a portable device 101 and a communication device 102 including a thin client 104. System 100 also includes a communication network 105, a server computer 106, a transmission computer 108, a network processing computer 110, and an authorized entity computer 112. The communication device 102 can perform operational communication with the server computer 106. In some embodiments, the thin client 104 can perform operational communication with the server computer 106 using the communication elements of the communication device 102. The server computer 106 can perform operational communication with the transmission computer 108, which can perform operational communication with the network processing computer 110. The network processing computer 110 can perform operational communication with the authorized entity computer 112.

[0038] To simplify the explanation, Figure 1 A certain number of components are shown. However, it should be understood that embodiments of the invention may include more than one of each component. Furthermore, some embodiments of the invention may include more than one of each component. Figure 1 All components shown are either fewer or more components.

[0039] Messages between the thin client 104 of communication device 102 and the server computer 106 can be sent via communication network 105 using secure communication protocols, such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS); SSL; ISO (e.g., ISO 8583), etc. Communication network 105 may include any one and / or a combination of: direct interconnection; the Internet; local area network (LAN); metropolitan area network (MAN); Operational Mission as a Node on the Internet (OMNI); secure custom connection; wide area network (WAN); wireless network (e.g., using protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.); etc. Communication network 105 may use any suitable communication protocol to generate one or more secure communication channels. In some cases, the communication channels may include secure communication channels that can be established in any known manner, such as by using mutual authentication and session keys, and establishing a Secure Sockets Layer (SSL) session.

[0040] Portable device 101 may include a device that is easily carried or moved and can be operated and / or used by a user. In some embodiments, portable device 101 may include a device such as a credit card or debit card. Portable device 101 may be used by a user to initiate interaction with a resource provider of communication device 102. For example, portable device 101 may enter the communication range of communication device 102 (e.g., short-range communication). Portable device 101 may provide interactive data to communication device 102 during interaction.

[0041] Communication device 102 may include a device operated by a resource provider. For example, the first communication device 102 may include a smartphone, a laptop computer, etc. Communication device 102 may be configured to perform interactions between the resource provider and the user to provide resources, access resources, offer resources, or provide access to resources to the user. Communication device 102 may be connected to server computer 106 via thin client 104 installed on communication device 102.

[0042] Thin client 104 may include software on a communication device that runs from resources stored on server computer 106 instead of a local hard drive. Thin client 104 can remotely connect to server computer 106 in the presence of various applications and hardware security modules.

[0043] In some embodiments, thin client 104 may prompt a user to enter information into communication device 102. For example, thin client 104 may prompt a user to enter a secret. Thin client 104 may derive (i.e., independently derive) a password key based on information provided from server computer 106, and then encrypt the secret specified by server computer 106, as described in further detail herein. Thin client 104 may provide the encrypted secret to server computer 106 for further processing.

[0044] Server computer 106 may include a computer that provides functionality to thin client 104. Server computer 106 may receive information from thin client 104 and process the information on behalf of thin client 104. Server computer 106 may receive encrypted secrets from thin client 104 during interactions between a user of portable device 101 and a resource provider of communication device 102. Server computer 106 may convert the encrypted secrets from one encryption domain to a second encryption domain. For example, server computer 106 may decrypt the encrypted secrets with a cryptographic key and then encrypt the secrets with a different cryptographic key (e.g., a transmission computer cryptographic key). Server computer 106 may then provide the encrypted secrets to transmission computer 108 in an authorization request message.

[0045] The transmission computer 108 may include any computer used for receiving and forwarding authorization request messages according to embodiments of the present invention. The transmission computer 108 may receive a secret encrypted with a transmission computer cryptographic key from a server computer. The transmission computer 108 may decrypt the secret encrypted with the transmission computer cryptographic key to obtain the secret. In some embodiments, the transmission computer 108 may be a computer of an acquiring entity that enables a resource provider to conduct specific types of transactions. The transmission computer 108 may be operated by the acquiring party, and in this case, may be the acquiring party's computer.

[0046] Network processing computer 110 may include computers, server computers, databases, and / or any combination thereof to coordinate functions for routing, generating, and formatting messages to facilitate the embodiments. In other embodiments, network processing computer 110 may be located in a payment processing network. A payment processing network may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception document services, and clearing and settlement services. An exemplary payment processing network may include VisaNet. TM For example, VisaNet TM Payment processing networks like VisaNet can handle credit card transactions, debit card transactions, and other types of commercial transactions. TM Specifically, this includes the VIP system (Visa Integrated Payment System) that processes authorization requests, and the Base II system that performs clearing and settlement services. The payment processing network can use any suitable wired or wireless network, including the Internet.

[0047] Authorized entity computer 112 may be operated by an issuing and / or authorizing entity (e.g., an issuer). The issuer may maintain accounts on behalf of users. For example, authorized entity computer 112 may maintain accounts on behalf of users of communication device 102. The account associated with the user may be identified by user account data. The first user account data may be a real account number and / or a token.

[0048] B. Server computer

[0049] Figure 2 A block diagram of a server computer 200 according to an embodiment is shown. The exemplary server computer 200 may include a processor 204. The processor 204 may be coupled to a memory 202, a network interface 206, a computer-readable medium 208, a first hardware security module 210, and a second hardware security module 212. The computer-readable medium 208 may include a secret module 208A and an encryption function module 208B. In some embodiments, the server computer 200 may operatively communicate with a database 220.

[0050] Memory 202 can be used to store data and code. Memory 202 can be coupled internally or externally to processor 204 (e.g., a cloud-based data storage device) and can include any combination of volatile and / or non-volatile memory (e.g., RAM, DRAM, ROM, flash memory, or any other suitable memory device). For example, memory 202 can store cryptographic keys, interactive data, etc.

[0051] Computer-readable medium 208 may include code executable by processor 204 to perform a method comprising: receiving a thin client identifier from a thin client on a communication device by a server computer; retrieving an encrypted first cryptographic key by the server computer based on the thin client identifier, wherein the encrypted first cryptographic key is a first cryptographic key encrypted with a second cryptographic key; initiating the sending of the encrypted first cryptographic key to the thin client by the server computer; and receiving an encrypted secret from the thin client by the server computer, the encrypted secret being a secret encrypted with the first cryptographic key.

[0052] The secret module 208A may include code or software executable by the processor 204 for processing secrets. The secret module 208A, in conjunction with the processor 204, can initialize data used to generate a cryptographic key to securely encrypt the secret. The secret module 208A, in conjunction with the processor 204, can receive requests for cryptographic keys from the server computer 200. The secret module 208A, in conjunction with the processor 204, can communicate with the encryption function module 208B, the first hardware security module 210, and the second hardware security module 212 to provide the server computer 200 with a previously generated cryptographic key. The server computer 200 can then provide the thin client with an encrypted first cryptographic key, specifically, the encrypted first cryptographic key is encrypted with a second cryptographic key. The thin client can return the secret encrypted with the first cryptographic key. The secret module 208A, in conjunction with the processor 204, can receive the encrypted secret from the server computer 200. The secret module 208A, in conjunction with the processor 204, can communicate with the database 220 to obtain conversion parameters usable by the second hardware security module 212 to convert the encrypted secret from a first encryption domain (e.g., encrypted with a first cryptographic key) to a second encryption domain (e.g., encrypted with a third cryptographic key). After obtaining the conversion parameters, the secret module 208A, in conjunction with the processor 204, can provide the encrypted secret and conversion parameters to the encryption function module 208B.

[0053] The encryption module 208B may include code or software executable by the processor 204 to provide secure communication between a hardware security module (e.g., a first hardware security module 210 and a second hardware security module 212) and a secret module 208A. The encryption module 208B, in conjunction with the processor 204, can determine which hardware security module to which a message from the secret module 208A is addressed. For example, the encryption module 208B, in conjunction with the processor 204, can provide a cryptographic key generation request message to the first hardware security module 210. The encryption module 208B, in conjunction with the processor 204, can provide an encrypted secret encryption field conversion message to the second hardware security module 212. Furthermore, the encryption module 208B, in conjunction with the processor 204, can perform cryptographic operations on received messages to establish messages in a format and / or cryptographic field readable by the intended components.

[0054] Network interface 206 may include an interface that allows server computer 200 to communicate with external computers. Network interface 206 enables server computer 200 to transmit data to and from another device or module (e.g., communication device 102, thin client 104, transmission computer 108, etc.). Some examples of network interface 206 may include a modem, a physical network interface (e.g., an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a PCMCIA slot and card, etc. Wireless protocols enabled by network interface 206 may include Wi-Fi. TM Data transmitted via network interface 206 may be in the form of signals, which may be electrical signals, electromagnetic signals, optical signals, or any other signals that can be received by an external communication interface (collectively, "electronic signals" or "electronic messages"). These electronic messages, which may include data or instructions, may be provided between network interface 206 and other devices via a communication path or channel. As described above, any suitable communication path or channel may be used, such as wires or cables, optical fibers, telephone lines, cellular links, radio frequency (RF) links, WAN or LAN networks, the Internet, or any other suitable medium.

[0055] In some embodiments, server computer 200 may operationally communicate with database 220. Database 220 may include any suitable database. The database may be a general-purpose, fault-tolerant, relational, scalable, and secure database, such as one available from Oracle. TM or Sybase TM The database.

[0056] II. Methods

[0057] The embodiments may use the systems and devices described herein to securely provide secrets from thin clients to a transmitting computer, at least via a server computer. Figure 3 , 4A -4B and 5A-5B describe some instances of this type of method.

[0058] A. Summary

[0059] Before discussing the details of the method, we will refer to... Figure 3 A summary of the discussion process. Figure 3 A flowchart illustrating the online PIN card holder verification method process according to an embodiment is provided. Figure 3 The process shown can be performed by a communication device 302 including a thin client 304, a server computer 306, and a transmission computer 308. Further details regarding steps 1-7 can be found in [reference needed]. Figure 4A , 4B As described in 5A and 5B.

[0060] In step 1, the communication device 302 can receive secret input from the user of the communication device 302. For example, the secret can be a personal identification number (PIN), a one-time password (OTP), biometrics, etc. The user can input the secret into the communication device 302 in any suitable manner (e.g., keypad, biometric scanner, one or more buttons, touch screen, etc.).

[0061] At step 2, the thin client 304 of the communication device 302 can encrypt the secret using the first cryptographic key. In some embodiments, the communication device 302 can obtain the first cryptographic key from the server computer 306. The first cryptographic key can be a symmetric key.

[0062] In step 3, after encrypting the secret, the thin client 304 can provide the server computer 306 with the secret encrypted with the first cryptographic key.

[0063] In step 4, after receiving the secret encrypted with the first cryptographic key, the server computer 306 can use the first cryptographic key to decrypt the secret.

[0064] At step 5, server computer 306 can encrypt the secret using a transmitting computer cryptographic key (e.g., a third cryptographic key). The transmitting computer cryptographic key can be a symmetric key.

[0065] In step 6, after encrypting the secret with the transmitting computer's cryptographic key, the server computer 306 can provide the encrypted secret to the transmitting computer 308.

[0066] At step 7, after receiving the encrypted secret from server computer 306, transmission computer 308 can decrypt the secret encrypted with transmission computer cryptographic key using transmission computer cryptographic key. Transmission computer 308 can process the secret in any suitable manner. For example, in some embodiments, the secret can be provided to an authorizing entity computer (not shown) via a network processing computer in an authorization request message to authorize interaction between the user of the portable device and the resource provider of communication device 302.

[0067] As an example, a secret encrypted with a third cryptographic key can be provided from server computer 306 to transmission computer 308 in an authorization request message. Transmission computer 308 can decrypt the encrypted secret using the third cryptographic key. Transmission computer 308 can encrypt the secret using a fourth cryptographic key, which may be the cryptographic key of the authorizing entity computer. Transmission computer 308 can modify the authorization request message to include the encrypted secret and provide the modified authorization request message to the authorizing entity computer. The authorizing entity computer can decrypt the encrypted secret using the fourth cryptographic key and can then determine whether to authorize the interaction associated with the secret. The authorizing entity computer can generate an indication of whether the interaction is authorized and generate an authorization response message including the indication of whether the interaction is authorized. The authorizing entity computer can provide the authorization response message to server computer 306 via transmission computer 308. After receiving the authorization response message, server computer 306 can provide the authorization response message to thin client 304 of communication device 302.

[0068] B. Initialization

[0069] Thin clients can register with the system (e.g., using a server computer) to use server-based services, such as secure online clandestine communication. During registration, the server computer can generate and provide an issued thin client identifier, which is then assigned to the thin client.

[0070] After creating the issued thin client identifier, several parameters and security assets can be pre-generated and initialized so that the thin client can use the server computer's online secret verification method. For example, the server computer can at least initialize the underlying exported key and interaction count.

[0071] Figures 4A-4B A flowchart illustrating an initialization method according to an embodiment is shown. The method includes... Figure 4A In the brief registration process and Figure 4B The situation after the login process. Figures 4A-4BThe diagram illustrates a thin client 402, a server computer 404, a secret module 406, a database 408, an encryption module 410, a first hardware security module 412, and a second hardware security module 414. As shown, messages can be transmitted between these devices. In some embodiments, the secret module 406, database 408, encryption module 410, first hardware security module 412, and second hardware security module 414 may be components included within the server computer 404. For example, the secret module 406, database 408, encryption module 410, first hardware security module 412, and second hardware security module 414 may be a server computer backend. In other embodiments, each of the secret module 406, database 408, encryption module 410, first hardware security module 412, and second hardware security module 414 may be located at a different computer.

[0072] In some embodiments, a single hardware security module may be used instead of two hardware security modules. For example, the first hardware security module 412 and the second hardware security module 414 may be integrated into a single hardware security module.

[0073] At step 420, secret module 406 may initialize cryptographic key parameters. For example, secret module 406 may initialize the interaction count (TX_counter) and the derivation identifier (Derivation_id). Secret module 406 may further initialize any additional cryptographic key parameters that may be used during the generation of one or more cryptographic keys. Secret module 406 may also create commands for the hardware security module to generate the base derivation key (BDK).

[0074] A base exported key can be generated by the hardware security module, allowing a unique cryptographic key to be derived from the base exported key. The exported unique key can be unique for each interaction. The exported unique key can be a first cryptographic key (K_PIN). Based on the unique key derived according to the interaction method [DUKPT], the base exported key can be a 128-bit 3DES key. In some embodiments, the base exported key can be generated internally within a second hardware security module 414 (e.g., a Payshield HSM) and exported to a first hardware security module 412. In some embodiments, the base exported key can be different and unique for each transmitting computer. In some embodiments, the base exported key can be known in plaintext only to the first hardware security module 412 and the second hardware security module 414.

[0075] The interaction count can be a counter used as one of the cryptographic key parameters for generating the first cryptographic key. For each subsequent update of the first cryptographic key, the interaction count increments by 1 (or another predetermined increment). Upon thin client registration, the interaction count is initialized to 0. Figure 5B The update of the first cryptographic key is discussed in more detail.

[0076] The exported identifier can be part of the issued thin client identifier. For example, the exported identifier can be the rightmost 32 bits of the issued thin client identifier. The exported identifier can also be one of the parameters used to export the key based on the DUKPT method.

[0077] After initializing the base exported key, the secret module 406 can introduce the base exported key into the second hardware security module 414. For example, at step 422, the secret module 406 can provide the base exported key to the encryption function module 410 in an import base exported key command (e.g., Import_BDK(BDK)), which causes the encryption function module 410 to provide the base exported key to the second hardware security module 414.

[0078] At step 424, after receiving the basic exported key, the encryption function module 410 can provide the basic exported key to the second hardware security module 414. Therefore, the basic exported key can be introduced into the second hardware security module 414.

[0079] At step 426, after receiving the basic exported key, the second hardware security module 414 can store the basic exported key.

[0080] At step 428, the second hardware security module 414 may provide the encryption function module 410 with a base exported key identifier (e.g., BDK_id) in response to receiving the base exported key.

[0081] At step 430, after receiving the basic derived key identifier from the second hardware security module 414, the encryption function module 410 may provide the basic derived key identifier to the secret module 406.

[0082] At step 432, after receiving the basic derived key identifier from the encryption function module 410, the secret module 406 may store the basic derived key identifier. In some embodiments, the secret module 406 may store the basic derived key identifier in the database 408.

[0083] At step 434, the secret module 406 may provide the basic exported key to the encryption function module 410 in an import basic exported key command (e.g., Import_BDK(BDK)), which instructs the encryption function module 410 to provide the basic exported key to the first hardware security module 412.

[0084] At step 436, after receiving the basic exported key, the encryption function module 410 can provide the basic exported key to the first hardware security module 412.

[0085] At step 438, after receiving the basic exported key, the first hardware security module 412 can store the basic exported key.

[0086] At step 440, the first hardware security module 412 may provide a base exported key identifier (e.g., BDK_id) to the encryption function module 410 in response to receiving the base exported key.

[0087] At step 442, after receiving the basic derived key identifier from the first hardware security module 412, the encryption function module 410 may provide the basic derived key identifier to the secret module 406.

[0088] At step 444, after receiving the base derived key identifier from the encryption function module 410, the secret module 406 may store the base derived key identifier. In some embodiments, the secret module 406 may store the base derived key identifier in the database 408.

[0089] At step 446, the secret module 406 can query the database 408 to obtain the thin client public key (K). D-ENC-PUB The thin client public key can be a static public key of thin client 402. The thin client public key can be used to negotiate a second cryptographic key (K_KPIN_ENC), which can be a session key, to protect the first cryptographic key (K_PIN) between server computer 404 and thin client 402. Queries provided to database 408 can include an issued thin client identifier (VAC_device_id). After successful profile registration, the issued thin client identifier can be an identifier assigned to thin client 402. In some embodiments, the issued thin client identifier can be a 128-bit unique identifier.

[0090] Secret module 406 can use the thin client identifier (VAC_device_id) to query the database 408 in any suitable way to obtain the thin client public key (K). D-ENC-PUBFor example, secret module 406 can provide database 408 with lookup commands, API calls (e.g., Lookup_Device_public_key), etc. The second password key can then be exported at thin client 402. The second password key can be a symmetric key.

[0091] At step 448, upon receiving a query from secret module 406, database 408 can determine the appropriate response to the query at least by searching the thin client public key using the issued thin client identifier.

[0092] At step 450, after obtaining the thin client public key, database 408 can provide the thin client public key (K) to secret module 406. D-ENC-PUB ).

[0093] At step 452, after receiving the thin client public key from database 408, secret module 406 can generate a cryptographic key request message (e.g., gen_PINkey_wrapped). The cryptographic key request message can request the relevant hardware security module (e.g., a first hardware security module) to generate a first cryptographic key (K_PIN). Secret module 406 can generate a cryptographic key request message including the issued thin client identifier, derived identifier, interaction count, base derived key identifier (BDK_id), and the thin client public key. The base derived key identifier from each hardware security module can identify the same base derived key. In some embodiments, each base derived key identifier can be the same value. In other embodiments, each base derived key identifier can be different, but can still identify the same base derived key.

[0094] At step 454, after generating the cryptographic key request message, the secret module 406 can provide the cryptographic key request message to the encryption function module 410.

[0095] At step 456, after receiving the password key request message, the encryption function module 410 can provide the password key request message to the first hardware security module 412.

[0096] At step 458, after receiving the cryptographic key request message, the first hardware security module 412 can generate a first cryptographic key (K_PIN). The first cryptographic key can be a 128-bit 3DES-ECB key (Triple Data Encryption Algorithm-Codebook) generated using a derived unique key according to the interaction method [DUKPT]. The derived unique key according to the interaction method can be implemented within the first hardware security module 412 (e.g., the NShield hardware security module). The initial first cryptographic key (e.g., K_PIN) is generated after thin client profile registration. Three parameters can be used to generate the initial first cryptographic key: a derived identifier (e.g., a portion of the thin client's public key), a base derived key identifier / base derived key, and an interaction count.

[0097] At step 460, after generating the first cryptographic key (e.g., K_PIN), the first hardware security module 412 can generate a second cryptographic key (K_KPIN_ENC). The second cryptographic key (K_KPIN_ENC) is used to protect the first cryptographic key. The first cryptographic key (K_PIN) can be protected when in transit between the thin client 402 and the server computer 404, and when stored in a backend database of the server computer (e.g., database 408). The second cryptographic key can be generated internally within the first hardware security module 412 based on the following steps.

[0098] First, the first hardware security module 412 generates a temporary 256-bit ECC key pair. The temporary key pair includes a temporary server computer private key (K... VAC-PIN-PVT ) and temporary server computer public key (K VAC-PIN-PUB Using the static public key (K) of the thin client. D-ENC-PUB Elliptic Curve Diffie-Helman Cryptography (ECDH) is used to negotiate and share a secret between the thin client 502 and the server computer 504. For example, the first hardware security module 412 can determine Z = ECDH(K VAC-PIN-PVT ,K D-ENC-PUB The shared secret of the key. Then, a second cryptographic key (e.g., a session key) and an initialization vector (IV) can be derived. pinThe first hardware security module 412 can derive a second cryptographic key by creating a hash-based message authentication code (HMAC), as described in [FIPS-198]. The HMAC can have three inputs: a key input (K), a hash function input (HF), and a message input (M). The first hardware security module 412 can determine the hash-based message authentication code used as the shared secret (Z) for the key input (K), the SHA-256 hash function used as the hash function input (HF), and the issued thin client identifier (VAC_device_id) used as the message input (M). The HMAC can be set to be equal to the concatenation of the second cryptographic key to be determined and the initialization vector. The first hardware security module 412 can determine the second cryptographic key, which is equal to the HMAC when concatenated with the initialization vector. For example, the first hardware security module 412 can derive the second cryptographic key (K_KPIN_ENC) using the following equation: K_KPIN_ENC (128 bits) || IV pin (96 bits)=HMAC[K:Z,HF:SHA-256,M:VAC_device_id].

[0099] Second, the first hardware security module 412 encrypts the first cryptographic key (K_PIN) using the second cryptographic key (K_KPIN_ENC). For example, the first hardware security module 412 can encrypt the first cryptographic key with the second cryptographic key using the Advanced Encryption Standard - Galois / Counter mode (AES-GCM):

[0100] [{K_PIN}K_KPIN_ENC||GCM_Auth_TAG]=AES_GCM[K:K_KPIN_ENC,PT:K_PIN,IV:IV pin AAD: No additional authentication data (AAD)]

[0101] At step 462, after generating the first and second cryptographic keys, the first hardware security module 412 can provide a cryptographic key response message to the encryption function module 410. The cryptographic key response message may include the first cryptographic key (K_PIN), the second cryptographic key (K_KPIN_ENC), and the initialization vector (IV) encrypted with the second cryptographic key (K_KPIN_ENC). PIN ) and server computer temporary public key (K VAC-PIN-PUB Thin clients can use the server computer's temporary public key (K). VAC-PIN-PUBThe first cryptographic key (K_PIN_ENC) is used to determine the second cryptographic key. When the first cryptographic key (K_PIN) is sent between the server computer 404 and the thin client 402, it is protected by the second cryptographic key (K_PIN_ENC). Initialization Vector (IV) PIN This can later be used by thin clients to decrypt the first key (K_PIN) with the second key (K_KPIN_ENC).

[0102] At step 464, after receiving the cryptographic key response message, the encryption function module 410 provides the cryptographic key response message to the secret module 406.

[0103] At step 466, after receiving the cryptographic key response message, the secret module 406 can store the issued thin client identifier, the first cryptographic key encrypted with the second cryptographic key, the interaction count, the second cryptographic key, the server computer temporary public key, and the initialization vector in association with each other in the database 408.

[0104] For example, the following data entries can be created in database 408 and can be associated with the following uniquely issued thin client identifier:

[0105] {K_PIN}K_KPIN_ENC,K_KPIN_ENC,Tx_Counter,IV pin ,K VAC-PIN-PUB ,BDK_id,andDerivation_id.

[0106] When an updated first cryptographic key is created (for each subsequent secret used in the interaction), the updated first cryptographic key can be wrapped with a second cryptographic key and stored in a backend database on the server computer (e.g., database 408). Additionally, when the first cryptographic key is updated, the initialization vector (IV) is... pin Each encryption using the first cryptographic key has a unique value. Therefore, to encrypt an updated first cryptographic key, the initialization vector is incremented by 1 (e.g., the new IV). pin =IV pin +1). In Figure 5B The paper further discusses the updating of cryptographic keys.

[0107] Figure 4B A flowchart of an initialization method according to an embodiment is shown. Figure 4B The method shown can be used in Figure 4A The method shown is executed after the user logs in. Figure 4BThe method shown can provide the thin client 402 with a temporary public key of the server computer, so that the thin client 402 can derive a second cryptographic key in part based on the temporary public key of the server computer.

[0108] During user login, the thin client 402 can mutually authenticate with the server computer 404. Furthermore, a secure channel can be established between the thin client 402 and the server computer 404. In some embodiments, after successful login, three cryptographic keys can be exported for the confidentiality and integrity protection of interactive data (e.g., transaction data, data transfer data, etc.). The keys exported after successful login may include a signing key (K_mac), a sensitive data key (K_key), and an interactive payload key (K_enc). The signing key (K_mac) may be a 256-bit key used to sign the transaction payload in JSON Web Signature (JWS) form (e.g., HMAC with SHA-256). The sensitive data key (K_key) may be a 128-bit AES-GCM key used for the confidentiality protection of sensitive data. The interactive payload key (K_enc) may be a 128-bit AES-GCM key used for the confidentiality protection of the transaction payload. These three cryptographic keys can be generated by the thin client 402 and provided to the server computer 404.

[0109] At step 468, after logging in, the thin client 402 may provide a PIN public key request message to the server computer 404. The PIN public key request message may be a function of the server computer 404 exposed to the thin client 402 for use.

[0110] At step 470, after receiving the PIN public key request message from the thin client 402, the server computer 404 can request the PIN public key from the secret module 406 using any appropriate message or function call. For example, the server computer 404 can provide the PIN public key request message to the secret module 406.

[0111] At step 472, after receiving the public key request message, the secret module 406 can query the database 408 to obtain the server computer's temporary public key (e.g., K). VAC-PIN-PUB ).exist Figure 4A In step 466, the server computer's temporary public key was previously stored in database 408.

[0112] At step 474, after receiving a request for the server computer's temporary public key, database 408 can identify and obtain the server computer's temporary public key.

[0113] At step 476, after obtaining the temporary public key of the server computer, the database 408 can provide the temporary public key of the server computer to the secret module 406.

[0114] In step 478, after receiving the server computer's temporary public key, the secret module 406 can generate a security message generation request message. The security message generation request message can be generated using the server computer's temporary public key (K... VAC-PIN-PUB This involves a request to generate a JWS_JWE (JSON Web Signature_JSON Web Encryption) message and deliver a secure message (e.g., a JWS_JWE message) to the thin client 402. The secure message generation request message may include a temporary public key of the server computer received from the database 408. In some embodiments, the secure message generation request message may include a signing key (K_mac) and a sensitive data key (K_key).

[0115] At step 480, after generating the security message generation request message, the secret module 406 can provide the security message generation request message to the encryption function module 410.

[0116] At step 482, after receiving the security message generation request message, the encryption function module 410 may provide the security message generation request message to the first hardware security module 412. In some embodiments, the encryption function module 410 may verify the signature key (K_mac) and the sensitive data key (K_key) before providing the security message generation request message to the first hardware security module 412.

[0117] At step 484, after receiving the security message generation request message, the first hardware security module 412 can generate a security message. In some embodiments, the first hardware security module 412 can generate the security message using a signature key (K_mac) and a sensitive data key (K_key). For example, the security message can be in a JWS_JWE message generated using the signature key (K_mac) and the sensitive data key (K_key). The security message may include a temporary public key of the server computer.

[0118] At step 486, after generating the security message, the first hardware security module 412 may provide the security message to the encryption function module 410 in response to the security message generation request message.

[0119] At step 488, after receiving the security message, the encryption module 410 can provide the security message to the secret module 406.

[0120] At step 490, after receiving a security message from the encryption module 410, the secret module 406 can provide a security message to the server computer 404.

[0121] At step 492, after receiving the security message, the server computer 404 can provide the security message to the thin client 402.

[0122] At step 494, after receiving the security message, the thin client 402 can verify the security message. For example, the thin client 402 can verify the JWE and JWS of the security message known to those skilled in the art. The thin client 402 can verify the received JWS-JWE token included in the JWS-JWE message.

[0123] At step 496, after verifying the security message, thin client 402 can derive a second cryptographic key (K_KPIN_ENC). For example, thin client 402 can generate the same shared secret as described above in Elliptic Curve Diffie-Hellman Cryptography (ECDH). For example, thin client 402 can execute Z = ECDH(K D-ENC-PVT ,K VAC-PIN-PUB ), and derive the second cryptographic key (K_KPIN_ENC) (128 bits) ||IV pin (96-bit) = HMAC[K:Z,HF:SHA-256,M:VAC_device_id], as described herein. The thin client 402 then securely stores the second cryptographic key for its lifetime and uses the stored second cryptographic key and initialization vector to decrypt the received first cryptographic key. The thin client can increment the initialization vector by 1 to decrypt the encrypted, updated first cryptographic key.

[0124] At step 498, after exporting the second cryptographic key, the thin client 402 can use the second cryptographic key to decrypt the first cryptographic key encrypted with the second cryptographic key.

[0125] When the second cryptographic key (K_KPIN_ENC) expires, it will be refreshed. A new set of temporary keys can be generated on the hardware security module, and the new public key can be sent to the thin client to generate a new second cryptographic key (K_KPIN_ENC) and initialization vector (IV). pin ).

[0126] When the first cryptographic key is sent to the thin client 402, the server computer backend begins generating an updated first cryptographic key in the first hardware security module 412 using a unique key derived from the interaction algorithm and an updated interaction count (e.g., incremented by 1). The first cryptographic key is encrypted using a second cryptographic key and stored in a server computer backend database (e.g., database 408) for use in the next online secret user authentication method event. Figures 5A-5B The process will be described in further detail below.

[0127] C. Secret Conversion

[0128] Figures 5A-5B This illustrates an online PIN card holder verification method and PIN key refresh process according to an embodiment. It will be described within the context of a user-initiated interaction with a resource provider. Figures 5A-5B The method is illustrated. A user can operate a portable device. A resource provider can operate a communication device including thin client 502. The portable device can provide interactive data to the communication device. Upon receiving an indication that an interaction has been initiated, thin client 502 can communicate with server computer 504 to process the interaction at step 520. However, it should be understood that the invention can be applied to other situations.

[0129] At step 520, thin client 502 may provide an interaction request message to server computer 504. The interaction request message includes an issued thin client identifier (VAC_device_id). The interaction request message may also include interaction data received from and / or generated by the thin client for interaction between the user and the resource provider. The issued thin client identifier may be an identifier previously issued to thin client 502 by server computer 504 or its subsystems.

[0130] At step 522, after receiving the interaction request message from the thin client 502, the server computer 504 may provide the issued thin client identifier to the secret module 506. The server computer 504 may provide the issued thin client identifier to the secret module 506 in a password key request message. For example, the server computer 504 may request a password key from the secret module 506, which can be provided to the thin client 502 so that the thin client 502 can encrypt the secret.

[0131] At step 524, after receiving a cryptographic key request message including the issued thin client identifier from server computer 504, secret module 506 may provide the cryptographic key request message to database 508.

[0132] In step 526, after receiving the key request message, the database 508 can obtain the first encrypted cryptographic key, which is obtained by using the second cryptographic key ({K_Pin}K_KPIN_ENC) and the server computer's temporary public key (K... VAC-PIN-PUB The encryption is performed. Database 508 can obtain the first encryption key via any suitable lookup procedure. Database 508 can identify the first encryption key using a issued thin client identifier. Database 508 can obtain the server computer's temporary public key by identifying the most recent server computer's temporary public key in database 508. In some embodiments, the second encryption key can be a session key.

[0133] At step 528, after obtaining the encrypted first cryptographic key and the server computer's temporary public key, the database 508 can provide the encrypted first cryptographic key and the server computer's temporary public key to the secret module 506.

[0134] At step 530, after receiving the encrypted first cryptographic key and the server computer's temporary public key from the database 508, the secret module 506 can generate a security message generation request message. The security message generation request message may include the encrypted first cryptographic key. The encrypted first cryptographic key is encrypted using a second cryptographic key. In some embodiments, the security message generation request message may include a signature key (K_mac) and a sensitive data key (K_key). The security message generation request message may request a secure hardware module (HSM), specifically a first hardware security module 512, to generate a security message including the first cryptographic key and to be sent to the thin client 502. The security message may be in JWS_JWE format and can be created and / or formatted according to the signature key and the sensitive data key.

[0135] At step 532, after creating the security message generation request message, the secret module 506 can provide the security message generation request message to the encryption function module 510.

[0136] At step 534, after receiving the security message generation request message, the encryption function module 510 may provide a security message generation request message to the first hardware security module 512. The message may request that the encrypted first cryptographic key be sent to the thin client 502 in the security message.

[0137] At step 536, after receiving the security message generation request message, the first hardware security module 512 can generate a security message. The security message may include an encrypted first cryptographic key, which is encrypted using a second cryptographic key. In some embodiments, the security message may also include a server computer temporary public key (K). VAC-PIN-PUB(and / or any other suitable data. For example, a security message may be in JSON Web Signature_JSONWeb Encryption(JWS_JWE) format and may be represented as (JWS_JWE({K_Pin}K_KPIN_ENC)).

[0138] At step 538, after generating the security message, the first hardware security module 512 can provide the security message to the encryption function module.

[0139] At step 540, after receiving the security message, the encryption module 510 can provide the security message to the secret module 506.

[0140] At step 542, the secret module 506 may provide a secure message including a first encrypted cryptographic key to the server computer 504 in response to the cryptographic key request message.

[0141] At step 544, after receiving a security message from the secret module 506, the server computer 504 can provide a security message to the thin client 502.

[0142] At step 546, after receiving the security message from server computer 504, thin client 502 can verify the security message. For example, if the security message is in JWS_JWE format, thin client 502 can verify the JWE and JWS tokens.

[0143] At step 548A, after verifying the security message, thin client 502 can decrypt the encrypted first cryptographic key. For example, thin client 502 can derive a second cryptographic key and use the second cryptographic key to decrypt the encrypted first cryptographic key. Thin client 502 can derive the second cryptographic key using Elliptic Curve Diffie-Hellman Cryptography (ECDH). Thin client 502 can also derive the second cryptographic key based on the thin client static private key (K). D-ENC-PVT ), server computer temporary public key (K VAC-PIN-PUB An initialization vector (IV) maintained by the thin client and incremented after each interaction. pin The thin client 502 determines the second cryptographic key using the issued thin client identifier (VAC_device_id). For this purpose, the thin client 502 can generate a key that corresponds to the identifier on the thin client. Figure 4A Step 460 generates the same shared secret (Z) at the first hardware security module 512. The thin client 502 can then use the thin client static private key (K). D-ENC-PVT ), server computer temporary public key (K VAC-PIN-PUB Generate a shared secret (Z). For example, a thin client can compute Z = ECDH(K) D-ENC-PVT ,K VAC-PIN-PUB ).

[0144] After determining the shared secret, thin client 502 can derive a second cryptographic key using the shared secret, the initialization vector, and the issued thin client identifier. For example, thin client 502 can derive the second cryptographic key in a manner similar to how the first hardware security module 512 derives the second cryptographic key. Thin client 502 can determine a hash-based message authentication code (HMAC). The HMAC can have three inputs, including a key input (K), a hash function input (HF), and a message input (M). Thin client 502 can determine the hash-based message authentication code of the shared secret (Z) used as the key input (K), the SHA-256 hash function used as the hash function input (HF), and the issued thin client identifier (VAC_device_id) used as the message input (M). The HMAC can be set to be equal to the concatenation of the second cryptographic key to be determined and the initialization vector. Thin client 502 can determine a second cryptographic key, which is equal to the HMAC when concatenated with the initialization vector. For example, thin client 502 can derive the second cryptographic key using the following equation: K_KPIN_ENC (128 bits) || IV pin (96 bits)=HMAC[K:Z,HF:SHA-256,M:VAC_device_id].

[0145] At step 548B, the thin client 502 can obtain a secret from the user of the portable device who is interacting with the resource provider of the communication device. For example, the thin client 502 can prompt the user to enter the secret on the screen of the communication device. The user can enter the secret using any input element on the communication device. For example, the user can use a touchscreen and displayed buttons to enter the secret. The secret can be, for example, the user's biometric template, password, personal identification number, social security number, one-time password, etc.

[0146] At step 548C, after obtaining the secret, the thin client 502 can encrypt the secret using the first cryptographic key.

[0147] At step 550, after encrypting the secret with the first cryptographic key, the thin client 502 provides the encrypted first cryptographic key to the server computer 504.

[0148] At step 552, after receiving the encrypted secret, the server computer 504 may provide a request to the secret module 506 to convert the secret. The request to convert the secret (e.g., a conversion request message) includes the encrypted secret and the issued thin client identifier.

[0149] At step 554, after receiving the conversion request message from server computer 504, secret module 506 may generate a conversion parameter request message including the issued thin client identifier. The conversion parameter request message may request parameters associated with converting the encrypted secret from a first encryption domain (e.g., encrypted with a first cryptographic key) to a second encryption domain (e.g., encrypted with a third cryptographic key). The third encryption key may be a key from the transmitting computer or acquiring computer (or other downstream entity) that can encrypt data when it is transmitted to said entity.

[0150] In step 556, after generating the conversion parameter request message, the secret module 506 can provide the conversion parameter request message to the database 508.

[0151] At step 558, after receiving the conversion parameter request message from the secret module 506, the database 508 can obtain the conversion parameters. For example, the database 508 can look up the conversion parameters using the issued thin client identifier. The conversion parameters may include an encrypted first cryptographic key, an initialization vector (IV), a transport computer identifier, a second cryptographic key, a base derived key identifier, an interaction count, and a derived identifier.

[0152] At step 560, after obtaining the conversion parameters, the database 508 can provide the conversion parameters to the secret module 506 in response to the conversion request message.

[0153] At step 562, after receiving the conversion parameters from database 508, secret module 506 may modify the conversion request message (or create a similar message) to include one or more conversion parameters. For example, secret module 506 may modify the conversion request message to include a secret encrypted with a first cryptographic key, an encrypted first cryptographic key encrypted with a second cryptographic key, a transmitting computer identifier, an initialization vector, a base derived key identifier, an interaction count, a derived identifier, and a issued thin client identifier.

[0154] At step 564, after modifying the conversion request message, the secret module 506 can provide the conversion request message to the encryption function module 510.

[0155] At step 566, after receiving the conversion request message from the secret module 506, the encryption function module 510 may provide the conversion request message to the second hardware security module 514. In some embodiments, the encryption function module 510 may determine which hardware security module to provide the message to based on the message content, the message format, and / or identifiers included in the message.

[0156] At step 568A, after receiving the conversion request message from the encryption function module 510, the second hardware security module 514 can decrypt the encrypted first cryptographic key. The second hardware security module 514 can use the second cryptographic key to decrypt the encrypted first cryptographic key to obtain the first cryptographic key.

[0157] At step 568B, after obtaining the first cryptographic key, the second hardware security module 514 can use the first cryptographic key to decrypt the encrypted secret.

[0158] At step 568C, the second hardware security module 514 can encrypt the secret using a third cryptographic key (e.g., a transmission computer cryptographic key). The second hardware security module 514 can obtain the third cryptographic key from memory using a transmission computer identifier, which can be stored in association with the transmission computer cryptographic key. The third cryptographic key can be a symmetric key.

[0159] At step 570, after encrypting the secret with the third cryptographic key, the second hardware security module 514 can provide the encrypted secret to the encryption function module 510.

[0160] At step 572, after receiving the encrypted secret encrypted with the third cryptographic key, the encryption function module 510 can provide the encrypted secret to the secret module 506.

[0161] exist Figure 5A After step 572 and in Figure 5B Prior to step 574, the secret module 506 may send the encrypted secret to a transmitting computer (not shown). As described herein, the transmitting computer can process the encrypted secret by decrypting it using a third cryptographic key stored by the transmitting computer. The transmitting computer may re-encrypt the secret using an authorized entity computer cryptographic key and send the encrypted secret to the authorized entity computer to authorize interactions associated with the secret.

[0162] Figure 5B The diagram illustrates updating the cryptographic key after processing the encrypted secret and providing it to the transmitting computer. At step 574, the secret module 506 may update one or more transformation parameters. Updating one or more transformation parameters may include incrementing one or more transformation parameters. For example, the secret module 506 may increment the interaction counter. The interaction counter may be set after each interaction (e.g., after each execution). Figure 5A (After the process shown) increment the value by 1 (or other predetermined increment). Secret module 506 can increment the initialization vector. For example, secret module 506 can increment the initialization vector by 1 or other predetermined increment, the initialization vector being a 96-bit value.

[0163] At step 576, after incrementing one or more transformation parameters, the secret module 506 can generate a cryptographic key refresh message. The cryptographic key refresh message includes an encrypted first cryptographic key encrypted with a second cryptographic key, an updated initialization vector, a base derived key identifier, an updated interaction count, a derived identifier, a issued thin client identifier, and the second cryptographic key.

[0164] At step 578, after generating the password key refresh message, the secret module 506 can provide the password key refresh message to the encryption function module 510.

[0165] At step 580, after receiving the password key refresh message from the secret module 506, the encryption function module 510 can provide the password key refresh message to the first hardware security module 512.

[0166] At step 582, the first hardware security module 512 may generate an updated first cryptographic key using at least the updated interaction count. The first hardware security module 512 may generate the updated first cryptographic key in a similar manner to generating the first cryptographic key, and this will not be repeated here.

[0167] At step 584, after generating the updated first cryptographic key, the first hardware security module 512 can encrypt the updated first cryptographic key with the second cryptographic key using the updated initialization vector.

[0168] At step 586, after encrypting the updated first cryptographic key, the first hardware security module 512 provides the encrypted updated first cryptographic key to the encryption function module 510.

[0169] At step 588, after receiving the encrypted updated first cryptographic key, the encryption module 510 provides the encrypted updated first cryptographic key to the secret module 506.

[0170] At step 590, after receiving the encrypted updated first cryptographic key in response to the cryptographic key refresh message, the secret module 506 may generate a storage request message, which includes the issued thin client identifier, the encrypted updated first cryptographic key, the updated interaction count, and the updated initialization vector.

[0171] At step 592, after generating the storage request message, the secret module 506 can provide the storage request message to the database 508.

[0172] At step 594, after receiving the storage request message, database 508 may store the issued thin client identifier, the encrypted updated first cryptographic key, the updated interaction count, and the updated initialization vector in the database in association with each other. The issued thin client identifier, the encrypted updated first cryptographic key, the updated interaction count, and the updated initialization vector may later be retrieved by database 508 during future interactions.

[0173] The table below lists abbreviations, terms, notes, and references.

[0174] Table 1. Abbreviations

[0175]

[0176]

[0177] Table 2. Terms and Notes

[0178]

[0179]

[0180] Table 3. Cryptographic Key Annotations

[0181]

[0182]

[0183] Table 4. Reference

[0184]

[0185] The embodiments of this disclosure have numerous advantages. For example, the embodiments allow for secure online communication of secrets during interaction. The embodiments provide the advantage of receiving user secrets at a communication device operated by a resource provider. For example, a user can input a secret, such as a personal identification code, into the resource provider's communication device. Even after the secret is input into the resource provider's device and provided to a server computer over the air (e.g., online), the secret remains secure to the resource provider.

[0186] The embodiment allows for the secure provisioning of a first cryptographic key from a server computer to a thin client. The first cryptographic key is encrypted during transmission with a second cryptographic key, which can be derived from a Diffie-Helman shared secret that can be exported by the thin client. This provides the advantage of restricting access to the first cryptographic key to malicious parties during communication, as it is beneficial that the secret is encrypted with the first cryptographic key.

[0187] Furthermore, the embodiment securely provides a rotating cryptographic key to a thin client on the communication device. For example, during each subsequent interaction, the thin client can receive an encrypted, updated first cryptographic key. This provides the advantage of limiting malicious activity in the event of a password breach. For instance, if a malicious party intercepts the encrypted first cryptographic key and is able to crack the encryption, the malicious party will only obtain information from that single interaction. The malicious party will be unable to perform malicious interactions because the first cryptographic key is updated after each interaction. Therefore, the malicious party cannot use the stolen first cryptographic key to perform malicious interactions.

[0188] Although the steps in the flowcharts and process flows above are shown or described in a specific order, it should be understood that embodiments of the invention may include methods with steps in a different order. Furthermore, steps may be omitted or added, and they may still be present in embodiments of the invention.

[0189] Any software component or function described in this application may be implemented as software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python, employing techniques such as conventional or object-oriented methods. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable media include random access memory (RAM), read-only memory (ROM), magnetic media (e.g., hard disk drive or floppy disk), or optical media (e.g., optical disc (CD) or digital versatile optical disc (DVD)), flash memory, etc. The computer-readable medium may be any combination of such storage or transmission means.

[0190] Such programs can also be encoded and transmitted using carrier signals suitable for transmission over wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Therefore, a computer-readable medium according to an embodiment of the invention can be created using data signals encoded with such programs. Computer-readable media encoded with program code can be packaged with a compatible device or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard disk drive, CD, or an entire computer system) and can exist on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing a user with any of the results mentioned herein.

[0191] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art after reading this disclosure. Therefore, the scope of the invention should not be determined by reference to the foregoing description, but rather by reference to the pending claims together with their full scope or equivalents.

[0192] Without departing from the scope of the invention, one or more features from any embodiment may be combined with one or more features from any other embodiment.

[0193] As used herein, unless explicitly indicated otherwise, the terms “a,” “an,” or “the” are intended to mean “at least one / a kind.”

Claims

1. A method for encryption, comprising: The server computer receives the thin client identifier from the thin client on the communication device. The server computer retrieves an encrypted first cryptographic key based on the thin client identifier, wherein the encrypted first cryptographic key is a first cryptographic key encrypted with a second cryptographic key. The server computer initiates the sending of the encrypted first password key to the thin client; as well as The server computer receives an encrypted secret from the thin client, the encrypted secret being a secret encrypted using the first cryptographic key; The server computer initiates a conversion of the secret from encryption using the first cryptographic key to encryption using the third cryptographic key, wherein the third cryptographic key is the transmission computer cryptographic key; After the conversion of the secret is initiated, the server computer obtains the secret encrypted with the third cryptographic key; as well as The server computer provides the transmission computer with the secret encrypted using the third cryptographic key. The secret, encrypted with the third cryptographic key, is provided to the transmitting computer in an authorization request message. The transmitting computer decrypts the secret encrypted with the third cryptographic key and encrypts the secret with a fourth cryptographic key, wherein the fourth cryptographic key is an authorization entity computer cryptographic key. The transmitting computer modifies the authorization request message to include the secret encrypted with the fourth cryptographic key and provides the modified authorization request message to the authorization entity computer. The authorization entity computer: determines whether to authorize an interaction associated with the secret, generates an indication of whether the interaction is authorized, generates an authorization response message including the indication of whether the interaction is authorized, and provides the authorization response message to the server computer via the transmitting computer. The method further includes: The authorization response message is received by the server computer; as well as The server computer provides the authorization response message to the thin client.

2. The method according to claim 1, wherein the first cryptographic key, the second cryptographic key and the third cryptographic key are symmetric keys.

3. The method according to claim 1, wherein the secret is a user's biometric template, password, personal identification number, social security number, or one-time password.

4. The method according to claim 1, wherein the thin client receives the encrypted first cryptographic key, decrypts the encrypted first cryptographic key to obtain the secret, encrypts the secret with the first cryptographic key, and provides the secret encrypted with the first cryptographic key to the server computer.

5. The method according to claim 1, wherein the second cryptographic key is independently derived by the thin client and used by the thin client to decrypt the encrypted first cryptographic key.

6. The method of claim 1, wherein the second cryptographic key is independently derived by the thin client and used by the thin client to decrypt the encrypted first cryptographic key, wherein the second cryptographic key is independently derived using an initialization vector, a thin client identifier, and a shared secret, the shared secret being obtained by the thin client using a Diffie-Hellman elliptic curve cryptography compilation process.

7. The method according to claim 1, further comprising: During the interaction, the server computer receives interaction data from the thin client; as well as The server computer provides the interactive data to the transmitting computer.

8. A server computer, comprising: processor; as well as A computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to carry out a method comprising: Receive the thin client identifier from the thin client on the communication device; Based on the thin client identifier, the encrypted first password key is retrieved, wherein the encrypted first password key is a first password key encrypted with a second password key; Initiate sending the encrypted first password key to the thin client; Receive an encrypted secret from the thin client, the encrypted secret being a secret encrypted using the first cryptographic key; The encrypted secret is decrypted using the first cryptographic key to obtain the secret; The secret is encrypted using a third cryptographic key, wherein the third cryptographic key is a transmission computer cryptographic key; and The authorization request message provides the secret encrypted with the third cryptographic key to the transmitting computer, wherein the transmitting computer decrypts the secret encrypted with the third cryptographic key to obtain the secret, encrypts the secret using the authorization entity computer cryptographic key, modifies the authorization request message to include the secret encrypted with the authorization entity computer cryptographic key, and provides the modified authorization request message to the authorization entity computer, wherein the authorization entity computer decrypts the secret encrypted with the authorization entity computer cryptographic key using the authorization entity computer cryptographic key, determines whether to authorize the interaction associated with the secret, generates an indication of whether the interaction is authorized, generates an authorization response message including the indication of whether the interaction is authorized, and provides the authorization response message to the server computer via the transmitting computer; Receive the authorization response message; and The server computer provides the authorization response message to the thin client.

9. The server computer according to claim 8, in, The computer-readable medium further includes: Secret module; Encryption function module; The first hardware security module; and The second hardware security module, and The method further includes: Initiating the conversion of the secret from encryption using the first cryptographic key to encryption using the third cryptographic key, wherein initiating the conversion of the secret from encryption using the first cryptographic key to encryption using the third cryptographic key further includes: The server computer provides the secret, encrypted using the first cryptographic key and the thin client identifier, to the secret module; The secret module uses the thin client identifier to query the conversion parameters in the database; The conversion parameters are received by the secret module; and The secret module provides the secret encrypted with the first cryptographic key and the conversion parameters to the second hardware security module through the encryption function module. Specifically, the decryption of the secret encrypted using the first cryptographic key is performed in the second hardware security module using the conversion parameters. The encryption of the secret using the third cryptographic key is performed in the second hardware security module. The second hardware security module provides the secret, encrypted using the third cryptographic key, to the secret module through the encryption function module, and... The secret module provides the server computer with a secret encrypted using the third cryptographic key.

10. The server computer of claim 9, wherein the conversion parameters include the encrypted first cryptographic key, initialization vector, transmission computer identifier, second cryptographic key, base derived key identifier, interaction count, and derived identifier.

11. The server computer of claim 8, wherein before receiving the thin client identifier from the thin client, the method further comprises: The thin client identifier is assigned to the thin client by the server computer.

12. The server computer of claim 8, wherein before receiving the thin client identifier from the thin client, the method further comprises: Receive a public key request from the thin client, wherein the public key request includes a request for a temporary public key for the server computer; Obtain the temporary public key of the server computer; as well as The thin client is provided with the temporary public key of the server computer, wherein the thin client derives the second cryptographic key based on at least the temporary public key of the server computer.

Images