Executing entity-specific cryptographic code in a cryptographic coprocessor

Abstract

Various embodiments are disclosed for executing entity-specific encrypted code in a cryptographic co-processor. In one embodiment, encrypted code is received from a service via a network, the encrypted code implementing an encryption algorithm. The cryptographic co-processor decrypts the encrypted code. The cryptographic co-processor executes the decrypted code to generate a cryptogram, the cryptogram including information encrypted using the encryption algorithm. The cryptogram is sent to the service via the network.

Description

[0001] Related applications

[0002] This application claims priority and the benefit of co-pending U.S. Patent Application No. 16 / 668,973, filed October 30, 2019, entitled "ExECUTING ENTITY-SPECIFIC CRYPTOGRAPHICCODE IN A CRYPTOGRAPHIC COPROCESSOR," which claims priority and the benefit of co-pending U.S. Provisional Patent Application No. 62 / 914,275, filed October 11, 2019, entitled "ExECUTING ENTITY-SPECIFIC CRYPTOGRAPHICCODE IN A CRYPTOGRAPHIC COPROCESSOR," the entire contents of which are incorporated herein by reference.

[0003] This application also claims priority and the benefit of co-pending U.S. Provisional Patent Application No. 16 / 669,002, filed October 30, 2019, entitled "ExECUTING ENTITY-SPECIFIC CRYPTOGRAPHIC CODE IN A TRUSTED EXECUTION ENVIRONMENT," which claims priority and the benefit of co-pending U.S. Provisional Patent Application No. 62 / 914,272, filed October 11, 2019, entitled "ExECUTING ENTITY-SPECIFIC CRYPTOGRAPHIC CODE IN A TRUSTED EXECUTION ENVIRONMENT," the entirety of which is incorporated herein by reference. Background Technology

[0004] A wide variety of encryption algorithms are available. Some encryption algorithms are symmetric, meaning the same key is used to both encrypt plaintext and decrypt ciphertext. Other encryption algorithms are asymmetric, meaning different associated keys are used to encrypt plaintext (e.g., a public key) and decrypt ciphertext (e.g., a private key). With advancements in computing power, some encryption algorithms once considered secure are now considered insecure. For example, the 56-bit Data Encryption Standard (DES) was once considered secure. However, it is now easily broken by brute-force attacks. Furthermore, backdoors and / or other weaknesses can be found in encryption algorithms, making them insecure without requiring a complete brute-force crack of all key combinations.

[0005] Financial institutions, payment issuers, and other organizations that process high-value data may each decide which encryption algorithm they prefer. Furthermore, given newly disclosed vulnerabilities, these organizations' preferred encryption algorithms may change over time. Additionally, not disclosing the encryption algorithms used may have security value. Summary of the Invention

[0006] Various embodiments of a system are disclosed, the system comprising: a computing device including a processor, a memory, and a cryptographic coprocessor; and machine-readable instructions stored in the memory, which, when executed by the processor, cause the computing device to at least: receive encrypted code from a service via a network, the encrypted code implementing an encryption algorithm; decrypt the encrypted code by the cryptographic coprocessor; execute the decrypted code by the cryptographic coprocessor to generate a cipher, the cipher including information encrypted using the encryption algorithm; and send the cipher to the service via the network. In some embodiments of the system, the cryptographic coprocessor conforms to a version of the Trusted Platform Module (TPM) standard. In some embodiments of the system, the cryptographic coprocessor is configured to verify the state of the computing device before decrypting the encrypted code. In some embodiments of the system, the service is operated by an entity, and the encryption algorithm is the entity's preferred encryption algorithm. In some embodiments of the system, the cryptographic coprocessor is configured to verify whether the encrypted code is signed by an entity among a predefined plurality of trusted entities before executing the decrypted code. In some embodiments of the system, the encrypted code is decrypted using a root key of the cryptographic coprocessor, the root key of which is associated with the entity that generated the encrypted code. In some embodiments of the system, the service includes a first service and a second service associated with the entity, the encrypted code being received from the first service and the cipher being sent to the second service. In some embodiments of the system, the cryptographic coprocessor is implemented in the firmware of the computing device, and data is transferred from the secure element of the computing device to the cryptographic coprocessor via an interface to enable the cryptographic coprocessor to decrypt the encrypted code. In some embodiments of the system, the cryptographic coprocessor is configured to support selection from a predefined plurality of cryptographic algorithms to perform encryption operations, and the cryptographic algorithms are excluded from the predefined plurality of cryptographic algorithms. In some embodiments of the system, the cryptographic coprocessor is configured to act as a trusted root to verify the cryptographic algorithm before it is transmitted to the secure element of the computing device.

[0007] Various embodiments of a method are disclosed, the method comprising: receiving encrypted code from a client application by a cryptographic coprocessor, the encrypted code implementing an encryption algorithm; decrypting the encrypted code by the cryptographic coprocessor; and executing the decrypted code by the cryptographic coprocessor to decrypt encrypted data using the encryption algorithm; or, executing the decrypted code by the cryptographic coprocessor to generate a cipher using the encryption algorithm. In some embodiments of the method, the method further includes, before executing the decrypted code, verifying by the cryptographic coprocessor whether the encrypted code is signed by an entity from a predefined plurality of trusted entities. In some embodiments of the method, the encrypted code is received by the client application from a service operated by an entity, and the client application is associated with the entity. In some embodiments of the method, decrypting the encrypted code further includes decrypting the encrypted code using a root key of the cryptographic coprocessor associated with the entity. In some embodiments of the method, the encrypted data and the encrypted code do not include an identifier of the encryption algorithm. In some embodiments of the method, the cryptographic coprocessor is configured to support selection from a predefined plurality of cryptographic algorithms to perform cryptographic operations, and the cryptographic algorithms are excluded from the predefined plurality of cryptographic algorithms. In some embodiments of the method, the cryptographic coprocessor is configured to act as a root of trust to verify the cryptographic algorithm before it is transmitted to a secure element of the computing device.

[0008] Various embodiments of a computer program are disclosed, the computer program including instructions that, when executed by a first computing device, cause the first computing device to at least: encrypt code using an encryption algorithm to create encrypted code; send the encrypted code to a second computing device; receive a password from the second computing device, the password being generated from the encrypted code by the encryption algorithm; and decrypt the password using the encryption algorithm. In some embodiments of the computer program, the encrypted code is sent to the second computing device along with an identifier of an encryption key to decrypt the encrypted code. In some embodiments of the computer program, the encrypted code does not include an identifier of the encryption algorithm. In some embodiments of the computer program, the encrypted code is encrypted using one of a plurality of predefined encryption algorithms supported by a standard for cryptographic coprocessors.

[0009] Various embodiments of a system are disclosed, the system comprising: a computing device including a processor and memory; and machine-readable instructions stored in the memory, which, when executed by the processor, cause the computing device to at least: receive encrypted code from a service via a network, the encrypted code implementing an encryption algorithm; provide the encrypted code to an application executing in a trusted execution environment of the computing device; and obtain a password from the application, the password comprising information encrypted using the encryption algorithm. In some embodiments of the system, the password is obtained through another application executing in an untrusted execution environment of the computing device. In some embodiments of the system, the machine-readable instructions also cause the computing device to send the password to the service via the network at least through another application. In some embodiments of the system, the encrypted code is provided to the application via an interface between the trusted execution environment and the untrusted execution environment of the computing device. In some embodiments of the system, the trusted execution environment includes a cryptographic coprocessor, and the machine-readable instructions further cause the computing device to verify the signature of the encrypted code and the state of the computing device at least through the cryptographic coprocessor before decrypting the encrypted code. In some embodiments of the system, the trusted execution environment includes a cryptographic coprocessor, and the machine-readable instructions further cause the computing device to verify the signature of the application at least through the cryptographic coprocessor. In some embodiments of the system, the trusted execution environment includes a cryptographic coprocessor, and the cryptographic algorithm is not included among a predefined plurality of cryptographic algorithms supported by the cryptographic coprocessor. In some embodiments of the system, the trusted execution environment includes a secure operating system running on a secure virtual processor of the processor. In some embodiments of the system, the cipher corresponds to a payment transaction, and the cipher includes a limited-use payment credential. In some embodiments of the system, the trusted execution environment stores a key for decrypting the encrypted code, the key being associated with an entity operating the service.

[0010] Various embodiments of a method are disclosed, the method comprising: receiving encrypted data and encrypted code via a network through a first application executing in an untrusted execution environment, the encrypted code implementing an encryption algorithm; transmitting the encrypted data and the encrypted code by the first application to a second application executing in a trusted execution environment; decrypting the encrypted code by the second application; executing the decrypted code by the second application to decrypt the encrypted data using the encryption algorithm; and receiving information from the second application by the first application, the information being decrypted from the encrypted data. In some embodiments of the method, the method further comprises: transmitting the encrypted code from the second application to an encryption coprocessor using an interface; and verifying a signature of the encrypted code using the encryption coprocessor. In some embodiments of the method, the execution of the decrypted code is not performed by the encryption coprocessor. In some embodiments of the method, the decryption of the encrypted code is performed by the encryption coprocessor. In some embodiments of the method, the encryption coprocessor includes code implementing a plurality of predefined encryption algorithms, and the encryption algorithms are excluded from the plurality of predefined encryption algorithms. In some implementations of the method, the encrypted code is received from a service operated by the entity, and the first application and the second application are associated with the entity.

[0011] Various embodiments of a computer program are disclosed, the computer program including instructions that, when executed in a trusted execution environment of a computing device, cause the computing device to at least: receive encrypted code via an interface to an untrusted execution environment of the processor, the encrypted code implementing an encryption algorithm; decrypt the encrypted code; execute the decrypted code to generate a password, the password including information encrypted using the encryption algorithm; and return the password via the interface. In some embodiments of the computer program, the computing device further includes a cryptographic coprocessor, and the instructions further cause the computing device to at least: verify a signature of the encrypted code using the cryptographic coprocessor; or verify whether the encryption algorithm is a root of trust before transmitting the encryption algorithm to the trusted execution environment. In some embodiments of the computer program, the trusted execution environment includes a secure operating system executing on a secure virtual processor of the processor. In some embodiments of the computer program, the password corresponds to a payment transaction, and the password includes a limited-use payment credential. Attached Figure Description

[0012] Many aspects of this disclosure can be better understood by referring to the following accompanying drawings. The components in the drawings are not necessarily drawn to scale, but rather the emphasis is on clearly illustrating the principles of this disclosure. Furthermore, in the drawings, the same reference numerals indicate corresponding parts in multiple views.

[0013] Figure 1 This is a diagram of a network environment according to various embodiments of the present disclosure.

[0014] Figure 2A According to various embodiments Figure 1 A diagram of the client devices in the network environment.

[0015] Figure 2B According to various embodiments Figure 1 A diagram of the client devices in the network environment.

[0016] Figure 3 This illustrates various embodiments according to the present disclosure, in Figure 1 Using in network environments Figure 2A A sequence diagram of an example of the functions implemented by a client device.

[0017] Figure 4 This illustrates various embodiments according to the present disclosure, in Figure 1 Using in network environments Figure 2A A sequence diagram of an example of the functions implemented by a client device.

[0018] Figure 5 This illustrates various embodiments according to the present disclosure, in Figure 1 Using in network environments Figure 2B A sequence diagram of an example of the functions implemented by a client device.

[0019] Figure 6 This illustrates various embodiments according to the present disclosure, in Figure 1 Using in network environments Figure 2B A sequence diagram of an example of the functions implemented by a client device. Detailed Implementation

[0020] This disclosure relates to communicating with services associated with an entity on a client device using an encryption algorithm selected by the entity. For example, entities such as financial institutions, payment processors, merchant gateways, payment issuers, or other entities may expect specific information sent to them to be encrypted using a particular encryption algorithm. Furthermore, entities may use specific encryption algorithms when transmitting information to client devices. Entities may wish to keep the identity of the specific encryption algorithm confidential to enhance security. Additionally, entities may decide at their own discretion to update or change the specific encryption algorithm from time to time.

[0021] In the first set of embodiments, the cryptographic coprocessor on the client device (such as a Trusted Platform Module (TPM)) can be configured to support cryptographic flexibility or the ability to use different cryptographic algorithms. For example, the cryptographic coprocessor can support a predefined set of cryptographic algorithms, wherein the algorithms included in this set are selected by the device hardware manufacturer, standards bodies, or operating system developers. The cryptographic algorithms can be permanently included in the hardware cryptographic coprocessor or can be updated in a firmware cryptographic coprocessor or a software cryptographic coprocessor.

[0022] Entities may prefer to use different encryption algorithms instead of those in a predefined group. For example, after an encryption coprocessor is created, the entity's preferred algorithm can be published. Therefore, the encryption coprocessor will not embed support for that algorithm and will have to provide encryption flexibility for its use.

[0023] As will be described, in various embodiments, an entity can send code implementing an encryption algorithm to a client device with a cryptographic coprocessor, which offers cryptographic flexibility. The code implementing the encryption algorithm can itself be encrypted, thereby masking the algorithm's identity and / or its internal operations. The code implementing the encryption algorithm can then be decrypted within the cryptographic coprocessor using a key associated with the entity. The cryptographic coprocessor can then execute code within it to encrypt information to be sent to the entity or to decrypt information sent from the entity. In this way, applications running on the client device cannot access the encryption algorithm, and the code implementing the encryption algorithm executes securely.

[0024] In the second set of embodiments, in addition to the cryptographic coprocessor, the client device also has a separate trusted execution environment. For example, ARM-based devices may include security extensions supporting TrustZone functionality, Intel-based devices may have Trusted Execution Technology and SGX Software Guard Extensions, and AMD-based devices may have a Platform Security Processor and an AMD Secure Execution Environment. This provides a separate virtual processor that executes a secure operating system with hardware-based access control. Signed third-party applications can execute within the trusted execution environment. As will be described, in various embodiments, entities can create trusted applications for execution within the trusted execution environment, which are configured to receive code implementing cryptographic algorithms, wherein the code itself is encrypted. A cryptographic coprocessor can be used to verify the authenticity and integrity of code. After that, the trusted application can then decrypt the code that implements the cryptographic algorithm and execute the code to encrypt information to be sent to an entity or to decrypt information sent from an entity.

[0025] The following discussion provides an overall overview of the system and its components, followed by a discussion of the operation of the system and its components.

[0026] refer to Figure 1 This illustrates a network environment 100 according to various embodiments. Network environment 100 includes a computing environment 103 and client devices 106, which communicate with each other via a network 109. Network 109 may include a wide area network (WAN), a local area network (LAN), a personal area network (PAN), or a combination thereof. These networks may include wired components or wireless components or a combination thereof. Wired networks may include Ethernet networks, cable networks, fiber optic networks, and telephone networks such as dial-up, digital subscriber line (DSL), and integrated services digital network (ISDN) networks. Wireless networks may include cellular networks, satellite networks, and Institute of Electrical and Electronics Engineers (IEEE) 802.11 wireless networks (i.e., ), Networks, microwave transmission networks, and other networks that rely on radio broadcasting. Network 109 may also include combinations of two or more networks 109. Examples of networks 109 may include the Internet, intranets, extranets, virtual private networks (VPNs), and similar networks.

[0027] The computing environment 103 may operate for or on behalf of an entity such as a financial institution, payment processor, payment gateway, payment issuer, or another entity. The computing environment 103 may include one or more computing devices, which include a processor, memory, and / or a network interface. For example, the computing device may be configured to perform computations on behalf of other computing devices or applications. As another example, such a computing device may host content and / or provide content to other computing devices in response to requests for content.

[0028] Furthermore, computing environment 103 may employ multiple computing devices, which may be deployed in one or more server libraries, computer libraries, or other arrangements. Such computing devices may be located in a single facility or distributed across many different geographical locations. For example, computing environment 103 may include multiple computing devices that together may include managed computing resources, grid computing resources, or any other distributed computing deployment. In some cases, computing environment 103 may correspond to elastic computing resources, in which the allocated capacity of processing, networking, storage, or other computing-related resources may vary over time.

[0029] Various applications or other functions can be executed in computing environment 103. Components executing on computing environment 103 include entity service 113 and other applications, services, processes, systems, engines, or functions not discussed in detail herein. Entity service 113 can be operated by or on behalf of an entity to perform functions such as authentication, payment authorization, payment processing, or other functions. Although an entity service 113 is described for discussion purposes, it is understood that multiple services can be implemented to perform parts of these functions.

[0030] Furthermore, various types of data are stored in data storage 116, which is accessible to the computing environment 103. Data storage 116 can represent multiple data storage systems, including relational databases, non-relational databases, object-oriented databases, hierarchical databases, hash tables or similar key-value data stores, and other data storage applications or data structures. The data stored in data storage 116 is associated with the operations of various applications hosted by the computing environment 103.

[0031] Client device 106 refers to one or more client devices 106 that can connect to network 109. Client device 106 may include processor-based systems, such as computer systems. Such computer systems may be implemented as: personal computers (e.g., desktop computers, laptop computers, or similar devices), mobile computing devices (e.g., personal digital assistants, cellular phones, smartphones, netbooks, tablet computer systems, music players, portable game consoles, e-book readers, and similar devices), media playback devices (e.g., media streaming devices, etc.). The client device 106 may include a media player, a digital video disc (DVD) player, a set-top box, or similar devices; a video game console; or other devices with similar functionality. The client device 106 may include one or more displays, such as a liquid crystal display (LCD), a gas plasma-based flat panel display, an organic light-emitting diode (OLED) display, an electrophoretic ink (“E-ink”) display, a projector, or other types of display devices. In some cases, the display may be a component of the client device 106, or may be connected to the client device 106 via a wired or wireless connection.

[0032] Next, a general overview of the operation of the various components of network environment 100 is provided. Although the following description provides an example of the operation of the various components of network environment 100 and the interaction between them, other operations or interactions may also occur, as discussed in the accompanying description of the accompanying figures.

[0033] First, entity service 113 sends encrypted code 118 to client device 106 via network 109. Encrypted code 118 includes encryption algorithm 121 and signature 124. Encryption algorithm 121 can correspond to a symmetric algorithm, an asymmetric algorithm, or a hybrid algorithm combining both. Non-limiting examples of encryption algorithm 121 may include Triple Data Encryption (DES), Advanced Encryption Standard (AES), ChaCha, Salsa 20, Twofish, etc.

[0034] In some cases, encryption algorithm 121 may include a key used in conjunction with encryption algorithm 121 to decrypt and / or encrypt data using encryption algorithm 121. Alternatively, such a key may be available to client device 106 in other ways. The encrypted code 118 includes a signature 124, which can be used to verify the authenticity or integrity of the encrypted code 118.

[0035] Upon receiving the encrypted code 118, the client device 106 verifies the signature 124 of the encrypted code 118 using one or more keys available to the client device 106, and then decrypts the encrypted code 118. The client device 106 can then perform encryption operations, such as generating a cryptogram 127, using encryption algorithm 121 and a key. Cryptogram 127 may correspond to a payment transaction and may include data such as the device master account, transaction volume, limited-use payment credentials or limited-use keys, unpredictable numbers, timestamps, transaction counters, and / or other information that can be used to authorize payment transactions. Cryptogram 127 is then sent to entity service 113 via network 109.

[0036] Turn now Figure 2A The illustration shows an example of a client device 106 according to various embodiments. Client device 106 can execute client application 203 and other applications. Client device 106 may include a cryptographic coprocessor 206, client data storage 209, and other components.

[0037] Client application 203 can be associated with an entity and can be used to perform functions related to that entity. For example, client application 203 can be executed to use a payment instrument through entity service 113 ( Figure 1 To initiate or manage payment transactions, the client application 203 can receive encrypted code 118 from the entity service 113. Figure 1 ), and the cryptographic coprocessor 206 generates cipher 127 ( Figure 1 Then, the password 127, which includes the encrypted information, is sent to the entity service 113. Additionally, the client application 203 can receive the encrypted data from the entity service 113, decrypt the encrypted data using the encrypted code 118 via the encryption coprocessor 206, and then process the decrypted data.

[0038] The cryptographic coprocessor 206 can represent a physical or analog dedicated microcontroller that uses an integrated cryptographic key to protect the hardware and provides various cryptographic operations. The cryptographic coprocessor 206 can implement a version of the Trusted Computing Group (TCG) TPM standard. Although the cryptographic coprocessor 206 can be implemented in hardware to prevent tampering or circumvention of the cryptographic coprocessor 206, its functionality can be implemented in firmware or software on client devices 106 that lack a hardware-based cryptographic coprocessor 206.

[0039] The cryptographic coprocessor 206 can perform various cryptographic functions or operations on behalf of the client device 106 or an application executed by the client device 106. For example, the cryptographic coprocessor 206 can generate random numbers using a pseudo-random number generator (PRNG) or random number generator (RNG) included in the cryptographic coprocessor 206. As another example, the cryptographic coprocessor 206 can securely generate cryptographic keys or key pairs, including symmetric and asymmetric cryptographic key pairs. The cryptographic coprocessor 206 can also encrypt or decrypt data using cryptographic keys generated by the cryptographic coprocessor 206 or cryptographic keys imported into the cryptographic coprocessor 206. As another example, the cryptographic coprocessor 206 can also generate a hash of the current state of the hardware and software configuration of the client device 106, which can allow remote authentication of the identity of the client device 106 or the identity of the user of the client device 106.

[0040] To perform these operations, various encryption keys can be stored within the encryption coprocessor 206. These encryption keys may include endorsement key pairs 212 and one or more root key pairs 215 (such as stored root keys). The endorsement key pairs 212 and one or more root key pairs 215 may be stored within the encryption coprocessor 206 itself to protect the keys from being disclosed.

[0041] Endorsement key pair 212 is an asymmetric encryption key pair comprising a public encryption key and a private encryption key that are unique to the cryptographic coprocessor 206. Endorsement key pair 212 can be used by the cryptographic coprocessor 206 to verify or claim its identity to other parties or devices, thereby verifying or claiming the identity of client device 106 or the user of client device 106. If endorsement key pair 212 is disclosed to a third party, the third party may potentially forge the identity of the cryptographic coprocessor 206. Therefore, endorsement key pair 212 is typically used to sign other encryption keys, which can then be used to claim or verify the identity of the cryptographic coprocessor 206. To maintain the integrity of endorsement key pair 212 and ensure that it is unique relative to other endorsement key pairs 212 installed on other cryptographic coprocessors 206, endorsement key pair 212 can be supplied and stored on the cryptographic coprocessor 206 at the factory.

[0042] One or more root key pairs 215 may be asymmetric encryption key pairs, which can be used by the cryptographic coprocessor 206 to encrypt and / or sign data. Root key pairs 215 can be replaced if needed, although any data encrypted using that root key pair 215 will be unrecoverable if it is replaced with a new root key pair 215. In some implementations, the cryptographic coprocessor 206 may support the use of multiple independent root key pairs 215. For example, multiple users of client device 106 may each have their own root key pair 215, which is accessible only to the respective user. As another example, multiple client applications executing on client device 106 may have their own root key pairs 215 for encrypting and decrypting application-specific data stored on client device 106. Specifically, entities associated with entity service 115 and client application 203 may have their own root key pairs 215. Furthermore, entities may define their own authorization policies for access to that root key pair 215. In this way, the entity can maintain exclusive control over the key hierarchy of the root key pair 215.

[0043] The cryptographic coprocessor 206 may also include multiple predefined cryptographic algorithms 218. These predefined cryptographic algorithms 218 can be executed by the cryptographic coprocessor 206 to encrypt, decrypt, or verify data using a specific key pair from the root key pair 215. The set of predefined cryptographic algorithms 218 can be defined by standards, by the manufacturer of the cryptographic coprocessor 206 or client device 106, or by the developer of client device 106. Therefore, the set of predefined cryptographic algorithms 218 can be hardcoded within the hardware, firmware, or software implementing the cryptographic coprocessor 206 and cannot be configured by the client application 203. A flag can be sent to the cryptographic coprocessor 206 indicating which predefined cryptographic algorithm 218 will be selected for the encryption operation. It should be noted that the predefined cryptographic algorithms 218 may not be included in the encrypted code 118. Figure 1 However, the encrypted code 118 can be encrypted using one of the predefined encryption algorithms 218.

[0044] Approved entity 221 may correspond to a list of entities authorized to execute code, such as cryptographic algorithm 121, within cryptographic coprocessor 206. Approved entity 221 may be permitted to store root key pair 215 within cryptographic coprocessor 206. In some embodiments, a list of approved entities 221 may not exist, but each approved entity 221 will have a corresponding root key pair 215 that enables the approved entity 221 to execute any cryptographic algorithm 121 within cryptographic coprocessor 206.

[0045] Furthermore, various types of data can be stored in client data storage 209, which is accessible to client device 106. Client data storage 209 can represent multiple client data storage systems 209, which may include relational databases, object-oriented databases, hierarchical databases, hash tables or similar key-value data storage systems, and other data storage applications or data structures. The data stored in client data storage 209 is associated with operations performed by various applications executed by client device 106. This data may include one or more application key pairs 224, encrypted authentication tokens 163, identity key pairs 233, and possibly other data.

[0046] Application key pair 224 is an asymmetric encryption key pair that can be generated by or imported into the cryptographic coprocessor 206 and used for various data encryption functions. Each application key pair 224 can be a subkey, grandchild key, or descendant key of a corresponding root key pair 215. Furthermore, each root key pair 215 can have one or more application key pairs 224 associated with it. For example, a user can create multiple application key pairs 224 for various purposes, and these application key pairs 224 can be stored as subordinate keys or subkeys of the user's root key pair 215. Similarly, a client application 203 that has provided its own root key pair 215 can use multiple application key pairs 224 for various purposes, and one or more of these application key pairs 224 can be stored as subordinate keys of the root key pair 215, which is provided for the client application 203. Each application key pair 224 may include an application public key 227 and an encrypted private key 230.

[0047] Identity key pair 233 represents a locally stored asymmetric encryption key pair that can be generated and used by cryptographic coprocessor 206 to verify its identity. For example, due to the unique identity of cryptographic coprocessor 206 installed on client device 106, a message signed using the private key of identity key pair 233 can be verified using the public key of identity originating from specific client device 106. Therefore, identity key pair 233 can be used as an alias for endorsement key pair 212. To prove that identity key pair 233 is valid, it can be signed by cryptographic coprocessor 206 using the private key of endorsement key pair 212.

[0048] Limited-use payment credential 236 may correspond to a limited-use key. Limited-use payment credential 236 is a dynamic key generated from the server-side master key. A predefined number of one or more limited-use payment credentials 236 may be initially provided to client device 106. A session key derived from the limited-use key or a limited-use payment credential 236 may be used to verify whether password 127 was generated by client device 106. Limited-use payment credentials 236 may be sent to client device 106, and each individual credential in the limited-use payment credential 236 may be used once or a predefined number of times to authorize payment transactions.

[0049] Turn Figure 2B The illustration shows examples of a client device 106 according to various embodiments. The client device 106 may include an untrusted execution environment 250, a trusted execution environment 253, and an interface 254 between the untrusted execution environment 250 and the trusted execution environment 253. A client application 203 may execute in the untrusted execution environment 250 along with a number of applications under user control. The trusted execution environment 253 is a secure environment whose own secure operating system executes on a secure virtual processor or a secure physical processor. The untrusted execution environment 250 may execute on a different virtual processor or physical processor than the secure virtual processor or secure physical processor of the trusted execution environment 253.

[0050] The hardware processor of client device 106 may execute a monitoring program or include hardware extensions to mediate or restrict access to the trusted execution environment 253. Interface 254 may be an application programming interface (API) supported by the processor's monitoring program or hardware extensions to allow secure data transfer between the trusted execution environment 253 and the untrusted execution environment 250. For example, interface 254 may include system calls or messages passed via shared memory.

[0051] The trusted application 256 associated with the entity executes in the trusted execution environment 253. Prior to execution in the trusted execution environment 253, the trusted application 256 may be signed by the entity and verified by the cryptographic coprocessor 206. The trusted application 256 is executed to receive encrypted code 118 from the client application 203 via interface 254. Figure 1 ), using signature 124 ( Figure 1 The authenticity and / or integrity of the encrypted code 118 are verified by the encryption coprocessor 206, and the encrypted code 118 is decrypted by the encryption coprocessor 206.

[0052] After the encrypted code 118 has been verified and decrypted, the trusted application 256 is then able to use encryption algorithm 121 ( Figure 1 This information can be used to encrypt, decrypt, sign, or perform other encryption operations. Specifically, the trusted application 256 can generate a password 127 by encrypting various information using encryption algorithm 121. For example, the information may relate to a payment transaction and may include a limited-use payment credential 236 or a limited-use key.

[0053] although Figure 2B A single client data store 209 is shown, but it will be understood that the client data store 209 may be divided into multiple data stores, wherein one or more data stores may only be accessed through the trusted execution environment 253.

[0054] Next reference Figure 3 , Figure 3 A sequence diagram is shown, which provides information on the various components of the network environment 100 (including...). Figure 2A An example of interaction between client devices 106. Figure 3 The sequence diagram provides only examples of many different types of functional arrangements that can be employed in network environment 100. As an alternative, Figure 3 The sequence diagram can be viewed as an example depicting the elements of the methods implemented in the network environment 100.

[0055] Starting from box 303, entity service 113 will use the encrypted code 118 ( Figure 1 ) sent to client device 106 ( Figure 2A The client application 203 executed on ) . The encrypted code 118 can be compared with the signature 124 ( Figure 1 Send together. The header of signature 124 can be used to identify the specific root key pair 215 used to decrypt the encrypted code 118. Figure 2AAlternatively, entity service 113 may send different types of key identifiers. In one embodiment, client device 106 may have a lookup table or mapping stored locally (e.g., in non-volatile random access memory) that links entity service 113 to a specific root key pair 215 for verifying signature 124 and decrypting encrypted code 118.

[0056] Next, in box 306, client application 203 provides the encrypted code 118 to the cryptographic coprocessor 206 of client device 106. For example, client application 203 may store the encrypted code 118 in client data storage 209 or other memory and send commands to cryptographic coprocessor 206 to load the encrypted code 118 and verify and decrypt it. When cryptographic coprocessor 206 is implemented in firmware, data (e.g., a root key) stored in a secure element (e.g., a secure data storage) can be transferred from the secure element to firmware cryptographic coprocessor 206 via an interface that mediates access to the secure element. The data (e.g., the root key) enables firmware cryptographic coprocessor 206 to perform functions such as verification and decryption.

[0057] In box 309, the cryptographic coprocessor 206 uses a signature 124 sent along with the encrypted code 118 to verify the encrypted code 118. To do this, the cryptographic coprocessor 206 can obtain the root key pair 215 associated with the entity to perform verification using the signature 124. Therefore, this verification process verifies the authenticity and integrity of the encrypted code 118. In some cases, the cryptographic coprocessor 206 can verify the state of the client device 106 and allow or disallow decryption of the encrypted code 118 based on the state of the client device 106. For example, if the client device 106 is rooted, the cryptographic coprocessor 206 may disallow decryption of the encrypted code 118. If verification fails, the decryption and execution of the cryptographic algorithm 121 will not continue.

[0058] In box 312, the cryptographic coprocessor 206 decrypts the encrypted code 118. For example, the cryptographic coprocessor 206 can use a predefined encryption algorithm 218 ( Figure 2A The encryption coprocessor 206 uses a specific encryption algorithm and a root key pair 215 associated with the entity to perform decryption. When decrypting the encrypted code 118, the encryption coprocessor 206 obtains the encryption algorithm 121 in its unencrypted form. Figure 1In some examples, encryption algorithm 121 may differ from the predefined encryption algorithm 218. In other examples, encryption algorithm 121 may be one of the predefined encryption algorithms 218, although the identity of encryption algorithm 121 may not be obvious from the encrypted code 118 itself. In one example, encryption coprocessor 206 acts as a root of trust to verify a proprietary encryption algorithm 121 before handing it over to the secure element.

[0059] In box 315, client application 203 provides information to cryptographic coprocessor 206 for subsequent encryption. For example, this information may relate to a specific payment transaction and may include, for instance, limited-use payment credentials 236. Figure 2A This information may include, but is not limited to, keys, unpredictable numbers, serial numbers, monotonic counter values, timestamps, transaction volumes, and / or other information. In other examples, client application 203 may provide the information to cryptographic coprocessor 206 along with encrypted code 118, or provide the information to cryptographic coprocessor 206 before providing encrypted code 118. In some examples, one or more of this information (e.g., unpredictable numbers) may be generated by cryptographic coprocessor 206 itself.

[0060] In box 318, the cryptographic coprocessor 206 encrypts the information using cryptographic algorithm 121, which is then decrypted from the encrypted code 118 at box 312. To do this, the cryptographic coprocessor 206 executes code that implements the cryptographic algorithm 121 (provided by entity service 113), and can use either a key from the root key pair 215 associated with the entity or a symmetric key. In this way, the cryptographic coprocessor 206 generates cipher 127 (…). Figure 1 In box 321, the cryptographic coprocessor 206 returns the cipher 127 to the client application 203.

[0061] In box 324, client application 203 sends password 127 to entity service 113 via network 109. In box 327, entity service 113 processes password 127. For example, entity service 113 may verify the signature of password 127. Entity service 113 then decrypts password 127 using the symmetric key used to encrypt password 127 or the private key of the key pair used to encrypt password 127. Entity service 113 may then verify the content of password 127. For example, entity service 113 may verify whether the limited-use payment credential 236 or the limited-use key is valid. After verifying the content, entity service 113 may then authorize and / or process the corresponding payment transaction.

[0062] Continue to refer to Figure 4 , Figure 4 This is a sequence diagram that provides information about the various components of network environment 100 (including...). Figure 2A Another example of interaction between client devices 106. Figure 4 The sequence diagram provides only examples of many different types of functional arrangements that can be employed in network environment 100. As an alternative, Figure 4 The sequence diagram can be viewed as an example depicting the elements of the methods implemented in the network environment 100.

[0063] Starting from box 403, entity service 113 will use the encrypted code 118 ( Figure 1 ) sent to client device 106 ( Figure 2A The client application 203 executed on the entity service 113 can also send encrypted data along with encrypted code 118, or send encrypted data before or after sending encrypted code 118, wherein the encrypted data is encrypted using encryption algorithm 121 (encrypted in encrypted code 118). Figure 1 The encrypted code 118 and the encrypted data can be encrypted with signature 124. Figure 1 Send together. The header of signature 124 can be used to identify the specific root key pair 215 used to decrypt the encrypted code 118 and the encrypted data. Figure 2A Alternatively, entity service 113 may send different types of key identifiers. In one embodiment, client device 106 may have a lookup table or mapping stored locally (e.g., in non-volatile random access memory) that links entity service 113 to a specific root key pair 215 for verifying signature 124 and decrypting encrypted code 118 and encrypted data.

[0064] Next, in box 406, client application 203 provides the encrypted code 118 to the cryptographic coprocessor 206 of client device 106. For example, client application 203 may store the encrypted code 118 in client data storage 209 or other memory and send commands to cryptographic coprocessor 206 to load the encrypted code 118 and verify and decrypt it. When cryptographic coprocessor 206 is implemented in firmware, data (e.g., a root key) stored in a secure element (e.g., a secure data storage) can be transferred from the secure element to firmware cryptographic coprocessor 206 via an interface that mediates access to the secure element. The data (e.g., the root key) enables firmware cryptographic coprocessor 206 to perform functions such as verification and decryption.

[0065] In box 409, the cryptographic coprocessor 206 uses the signature 124 sent along with the encrypted code 118 to verify the encrypted code 118. To do this, the cryptographic coprocessor 206 can obtain the root key pair 215 associated with the entity. Figure 2A The encryption coprocessor 206 verifies the authenticity and integrity of the encrypted code 118 by using signature 124 for verification. In some cases, the encryption coprocessor 206 can verify the state of the client device 106 and allow or disallow decryption of the encrypted code 118 based on the state of the client device 106. For example, if the client device 106 is rooted, the encryption coprocessor 206 may disallow decryption of the encrypted code 118. If verification fails, the decryption and execution of the encryption algorithm 121 will not continue.

[0066] In box 412, the cryptographic coprocessor 206 decrypts the encrypted code 118. For example, the cryptographic coprocessor 206 can use a predefined encryption algorithm 218 ( Figure 2A The cryptographic coprocessor 206 performs decryption using a specific encryption algorithm and a root key pair 215 associated with the entity. Upon decryption of the encrypted code 118, the cryptographic coprocessor 206 obtains the encryption algorithm 121 in its unencrypted form. In some examples, the encryption algorithm 121 may differ from the predefined encryption algorithm 218. In other examples, the encryption algorithm 121 may be one of the predefined encryption algorithms 218, although the identity of the encryption algorithm 121 may not be obvious from the encrypted code 118 itself. In one example, the cryptographic coprocessor 206 acts as a root of trust to verify a proprietary encryption algorithm 121 before handing it over to the secure element.

[0067] In box 415, client application 203 provides encrypted data to cryptographic coprocessor 206. The encrypted data can be any data. The encrypted data may include one or more limited-use payment credentials 236. Figure 2A This could include a limited-use key or other information related to the payment transaction. For example, client application 203 could store the encrypted data in client data storage 209 or other memory and send commands to cryptographic coprocessor 206 to load the encrypted data and verify and decrypt it.

[0068] In box 418, the cryptographic coprocessor 206 decrypts the information in the encrypted data using cryptographic algorithm 121. To do this, the cryptographic coprocessor 206 executes code provided by the entity that implements cryptographic algorithm 121, and may use a key from the root key pair 215 associated with that entity. In box 421, the cryptographic coprocessor 206 returns the decrypted information to the client application 203. In box 424, the client application 203 may process the decrypted data, which may include re-encrypting the data, storing the data in the client data store 209, and / or performing other actions.

[0069] Continue to refer to Figure 5 , Figure 5 This is a sequence diagram that provides various components of the network environment 100 (including...). Figure 2B An example of interaction between client devices 106. Figure 5 The sequence diagram provides only examples of many different types of functional arrangements that can be employed in network environment 100. As an alternative, Figure 5 The sequence diagram can be viewed as an example depicting the elements of the methods implemented in the network environment 100.

[0070] Starting from box 503, entity service 113 will use the encrypted code 118 ( Figure 1 ) is sent to client application 203, which is executed in untrusted execution environment 250. Figure 2B Client device 106 in ) Figure 2B ) is executed. The encrypted code 118 can be compared with the signature 124. Figure 1 Send together. The header of signature 124 can be used to identify the specific root key pair 215 used to decrypt the encrypted code 118. Figure 2B Alternatively, entity service 113 may send different types of key identifiers. In one embodiment, client device 106 may have a lookup table or mapping stored locally (e.g., in non-volatile random access memory) that links entity service 113 to a specific root key pair 215 for verifying signature 124 and decrypting encrypted code 118.

[0071] Next, in box 506, client application 203 communicates via interface 254 ( Figure 2B The encrypted code 118 is provided to the trusted application 256 executing in the trusted execution environment 253. For example, the client application 203 may store the encrypted code 118 in the client data store 209 or other memory, and send commands to the cryptographic coprocessor 206 to load the encrypted code 118 and verify and decrypt it.

[0072] In box 509, the trusted application 256 provides the encrypted code 118 to the cryptographic coprocessor 206 of the client device 106. For example, the trusted application 256 may store the encrypted code 118 in a secure portion of the client data storage 209 or other secure memory, and send commands to the cryptographic coprocessor 206 to load, verify, and decrypt the encrypted code 118. The encrypted code 118 may be provided to the cryptographic coprocessor 206 via the interface between the trusted execution environment 253 and the cryptographic coprocessor 206.

[0073] In box 512, the cryptographic coprocessor 206 uses the signature 124 sent along with the encrypted code 118. Figure 1 The encrypted code 118 is verified using the encryption coprocessor 206. To do this, the encryption coprocessor 206 can obtain the root key pair 215 associated with the entity. Figure 2B The encryption coprocessor 206 verifies the authenticity and integrity of the encrypted code 118 by using signature 124 for verification. In some cases, the encryption coprocessor 206 can verify the state of the client device 106 and allow or disallow decryption of the encrypted code 118 based on the state of the client device 106. For example, if the client device 106 is rooted, the encryption coprocessor 206 may disallow decryption of the encrypted code 118. If verification fails, the decryption and execution of the encryption algorithm 121 will not continue.

[0074] In box 515, the cryptographic coprocessor 206 decrypts the encrypted code 118. For example, the cryptographic coprocessor 206 can use a predefined encryption algorithm 218 ( Figure 2B The encryption coprocessor 206 performs decryption using a specific encryption algorithm and a root key pair 215 associated with the entity. When decrypting the encrypted code 118, the encryption coprocessor 206 generates an unencrypted form of the encryption algorithm 121. Figure 1 In some examples, encryption algorithm 121 may differ from the predefined encryption algorithm 218. In other examples, encryption algorithm 121 may be one of the predefined encryption algorithms 218, although the identity of encryption algorithm 121 may not be obvious from the encrypted code 118 itself. In box 518, the cryptographic coprocessor 206 returns the decrypted code of encryption algorithm 121 to the trusted application 256 via the interface between the cryptographic coprocessor 206 and the trusted execution environment 253. In one example, the cryptographic coprocessor 206 acts as a root of trust to verify a proprietary encryption algorithm 121 before handing it over to the trusted execution environment 253.

[0075] In box 521, client application 203 provides information to trusted application 256 for subsequent encryption by trusted application 256. For example, this information may relate to a specific payment transaction and may include, for example, a limited-use payment credential 236. Figure 2A This information may include, but is limited to, a key, unpredictable numbers, serial numbers, monotonic counter values, timestamps, transaction volumes, and / or other information. In other examples, client application 203 may provide this information to trusted application 256 along with encrypted code 118, or provide the information to trusted application 256 before providing encrypted code 118. In some examples, one or more of this information (e.g., unpredictable numbers) may be generated by cryptographic coprocessor 206 or trusted application 256.

[0076] In box 524, the trusted application 256 encrypts the information using encryption algorithm 121. To do this, the trusted application 256 executes code provided by the entity that implements encryption algorithm 121, and can use a key or a symmetric key from the application key pair 224 associated with that entity. In this way, the trusted application 256 generates cipher 127 (…). Figure 1 In box 527, trusted application 256 returns password 127 to client application 203 via interface 254.

[0077] In box 530, client application 203 sends password 127 to entity service 113 via network 109. In box 533, entity service 113 processes password 127. For example, entity service 113 may verify the signature of password 127. Entity service 113 then decrypts password 127 using the symmetric key used to encrypt password 127 or the private key of the key pair used to encrypt password 127. Entity service 113 may then verify the content of password 127. For example, entity service 113 may verify whether the limited-use payment credential 236 or the limited-use key is valid. After verifying the content, entity service 113 may then authorize and / or process the corresponding payment transaction.

[0078] Turn now Figure 6 , Figure 6 This is a sequence diagram that provides various components of the network environment 100 (including...). Figure 2B Another example of interaction between client devices 106. Figure 6 The sequence diagram provides only examples of many different types of functional arrangements that can be employed in network environment 100. As an alternative, Figure 6The sequence diagram can be viewed as an example depicting the elements of the methods implemented in the network environment 100.

[0079] Starting from box 603, entity service 113 will use the encrypted code 118 ( Figure 1 ) is sent to client application 203, which is executed in untrusted execution environment 250. Figure 2B Client device 106 in ) Figure 2B ) is executed on. Entity service 113 can also send encrypted data together with encrypted code 118, or send encrypted data before or after sending encrypted code 118, wherein the encrypted data is encrypted using encryption algorithm 121 (which is encrypted in encrypted code 118). Figure 1 The encrypted code 118 and the encrypted data can be sent together with the signature 124. Figure 1 The header of signature 124 can be used to identify the specific root key pair 215 used to decrypt the encrypted code 118. Figure 2B Alternatively, entity service 113 may send different types of key identifiers. In one embodiment, client device 106 may have a lookup table or mapping stored locally (e.g., in non-volatile random access memory) that links entity service 113 to a specific root key pair 215 for verifying signature 124 and decrypting encrypted code 118 and encrypted data.

[0080] Next, in box 606, client application 203 communicates via interface 254 ( Figure 2B ) to the trusted execution environment 253 ( Figure 2B The trusted application 256, executed in ), provides encrypted code 118.

[0081] In box 609, the trusted application 256 provides the encrypted code 118 to the cryptographic coprocessor 206 of the client device 106. For example, the trusted application 256 may store the encrypted code 118 in a secure portion of the client data storage 209 or other secure memory, and send commands to the cryptographic coprocessor 206 to load, verify, and decrypt the encrypted code 118. The encrypted code 118 may be provided to the cryptographic coprocessor 206 via the interface between the trusted execution environment 253 and the cryptographic coprocessor 206. In box 612, the cryptographic coprocessor 206 verifies the encrypted code 118 using a signature 124 sent along with it. To do this, the cryptographic coprocessor 206 may obtain a root key pair 215 associated with the entity to perform verification using the signature 124. Thus, the verification process verifies the authenticity and integrity of the encrypted code 118. In some cases, the cryptographic coprocessor 206 may verify the state of the client device 106 and allow or disallow the decryption of the encrypted code 118 based on the state of the client device 106. For example, if client device 106 is rooted, cryptographic coprocessor 206 may disallow decryption of encrypted code 118. If verification fails, decryption and execution of cryptographic algorithm 121 will not continue.

[0082] In box 615, the cryptographic coprocessor 206 decrypts the encrypted code 118. For example, the cryptographic coprocessor 206 can use a predefined encryption algorithm 218 ( Figure 2B The cryptographic coprocessor 206 performs decryption using a specific encryption algorithm and a root key pair 215 associated with the entity. When decrypting the encrypted code 118, the cryptographic coprocessor 206 generates an encryption algorithm 121 in its unencrypted form. In some examples, the encryption algorithm 121 may differ from the predefined encryption algorithm 218. In other examples, the encryption algorithm 121 may be one of the predefined encryption algorithms 218, although the identity of the encryption algorithm 121 may not be obvious from the encrypted code 118 itself. In one example, the cryptographic coprocessor 206 acts as a trusted root to verify a proprietary encryption algorithm 121 before handing it over to the trusted execution environment 253.

[0083] In box 618, the cryptographic coprocessor 206 returns the decrypted code of the cryptographic algorithm 121 to the trusted application 256 via the interface between the trusted execution environment 253 and the cryptographic coprocessor 206. In other examples, the trusted application 256 may then decrypt the encrypted code 118 after the cryptographic coprocessor 206 verifies it.

[0084] In box 621, client application 203 provides encrypted data to trusted application 256 via interface 254. The encrypted data can be any data. The encrypted data may include one or more limited-use payment credentials 236. Figure 2A This could include a limited-use key or other information related to the payment transaction.

[0085] In box 624, the trusted application 256 uses encryption algorithm 121 to decrypt information in the encrypted data. To do this, the trusted application 256 executes code provided by the entity that implements encryption algorithm 121, and can use application key pair 224 associated with that entity. Figure 2B The trusted application 256 returns the decrypted information to the client application 203 via interface 254 in box 627. In box 630, the client application 203 can process the decrypted data, which may include re-encrypting the data, storing the data in client data storage 209, and / or performing other actions.

[0086] Many of the software components discussed above are stored in the memory of the corresponding computing device and are executable by the processor of the corresponding computing device. In this regard, the term "executable" refers to a program file that exists in a form that can ultimately be run by the processor. Examples of executable programs can be: compiled programs that can be converted into machine code, which is presented in a format that can be loaded into the random access portion of memory and executed by the processor; source code that can be represented in a suitable format, such as object code that can be loaded into the random access portion of memory and executed by the processor; or source code that can be interpreted by another executable program to generate instructions to be executed by the processor in the random access portion of memory. Executable programs can be stored in any part or component of memory, including random access memory (RAM), read-only memory (ROM), hard disk drives, solid-state drives, universal serial bus (USB) flash drives, memory cards, optical discs (such as compact optical discs (CDs) or digital versatile optical discs (DVDs)), floppy disks, magnetic tapes, or other memory components.

[0087] Memory includes volatile memory and non-volatile memory, as well as data storage components. A volatile component is one that does not retain data values ​​when power is lost. A non-volatile component is one that retains data when power is lost. Therefore, memory can include random access memory (RAM), read-only memory (ROM), hard disk drives, solid-state drives, USB flash drives, memory cards accessed via a memory card reader, floppy disks accessed via an associated floppy disk drive, optical disks accessed via an optical disk drive, magnetic tapes accessed via a suitable magnetic tape drive, non-volatile random access memory (NVRAM), or other storage components, or any combination of two or more of these storage components. Furthermore, RAM can include static random access memory (SRAM), dynamic random access memory (DRAM), or magnetic random access memory (MRAM), and other such devices. ROM can include programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or other similar memory devices.

[0088] Although, as discussed above, the applications and systems described herein can be implemented in software or code executed by general-purpose hardware, alternatively, they can also be implemented in dedicated hardware or a combination of software / general-purpose hardware and dedicated hardware. If implemented in dedicated hardware, the various applications and systems can be implemented as circuits or state machines employing any one or more of a variety of techniques. These techniques can include, but are not limited to: discrete logic circuits having logic gates for implementing various logical functions when one or more data signals are applied; application-specific integrated circuits (ASICs) having suitable logic gates; field-programmable gate arrays (FPGAs) or other components, etc. Such techniques are generally known to those skilled in the art and therefore are not described in detail herein.

[0089] The sequence diagram illustrates the functionality and operation of portions of various embodiments of this disclosure. If implemented in software, each block may represent a module, segment, or portion of code comprising program instructions for implementing one or more specified logical functions. The program instructions may be implemented as source code, which includes human-readable statements written in a programming language or machine code comprising numerical instructions recognizable by a suitable execution system, such as a processor in a computer system. Machine code can be derived from source code through various processes. For example, machine code can be generated from source code using a compiler before executing the corresponding application. As another example, machine code can be generated from source code and executed using an interpreter. Other methods may also be used. If implemented in hardware, each block may represent a circuit or multiple interconnected circuits for implementing one or more specified logical functions.

[0090] Although the sequence diagram illustrates a specific execution order, it is understood that the execution order may differ from the order described. For example, the execution order of two or more blocks may be shuffled relative to the order shown. Furthermore, two or more blocks shown consecutively may be executed simultaneously or partially simultaneously. Additionally, in some embodiments, one or more blocks shown in the sequence diagram may be skipped or omitted. Moreover, any number of counters, state variables, warning signals, or messages may be added to the logic flow described herein for purposes such as enhancing usability, billing, performance measurement, or providing troubleshooting assistance. It is understood that all such variations are within the scope of this disclosure.

[0091] Furthermore, any logic or application program including software or code described herein can be implemented in any non-transitory computer-readable medium for use by or in conjunction with an instruction execution system, such as a processor in a computer system or other system. In this sense, logic can include statements containing instructions and statements that can be extracted from a computer-readable medium and executed by an instruction execution system. In the context of this disclosure, "computer-readable medium" can be any medium that can contain, store, or maintain the logic or application program described herein for use by or in conjunction with an instruction execution system. Furthermore, a collection of distributed computer-readable media located on multiple computing devices (e.g., storage area networks, distributed file systems or databases, or clustered file systems or databases) can also be collectively regarded as a single non-transitory computer-readable medium.

[0092] Computer-readable media can include any of a number of physical media, such as magnetic media, optical media, or semiconductor media. More specific examples of suitable computer-readable media will include, but are not limited to, magnetic magnetic disks, magnetic hard disks, memory cards, solid-state drives, USB flash drives, or optical discs. Furthermore, computer-readable media can be random access memory (RAM) or magnetic random access memory (MRAM), which includes static random access memory (SRAM) and dynamic random access memory (DRAM). Additionally, computer-readable media can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or other types of memory devices.

[0093] Furthermore, any logic or application described herein can be implemented and constructed in a variety of ways. For example, one or more applications described herein can be implemented as modules or components of a single application. Additionally, one or more applications described herein can execute on shared computing devices, independent computing devices, or a combination thereof. For example, multiple applications described herein can execute on the same computing device, or on multiple computing devices within the same computing environment 103.

[0094] Unless otherwise explicitly stated, disjunctive languages ​​such as “at least one of X, Y, or Z” are understood through the context typically used to represent items, terms, etc., and can be X, Y, or Z, or any combination thereof (e.g., X, Y, or Z). Therefore, such disjunctive languages ​​are generally not intended and should not imply that certain embodiments require each of at least one X, at least one Y, or at least one Z to be present.

[0095] Examples of embodiments of this disclosure can be described as follows.

[0096] Example 1: A system comprising: a computing device including a processor, a memory, and a cryptographic coprocessor; and machine-readable instructions stored in the memory, which, when executed by the processor, cause the computing device to at least: receive encrypted code from a service via a network, the encrypted code implementing an encryption algorithm; decrypt the encrypted code by the cryptographic coprocessor; execute the decrypted code by the cryptographic coprocessor to generate a password, the password including information encrypted using the encryption algorithm; and send the password to the service via the network.

[0097] Example 2: The system according to Example 1, wherein the cryptographic coprocessor conforms to a version of the Trusted Platform Module (TPM) standard.

[0098] Example 3: The system according to Example 1, wherein the encryption coprocessor is configured to verify the state of the computing device before decrypting the encrypted code.

[0099] Example 4: The system according to Example 1, wherein the service is operated by an entity, and the encryption algorithm is the entity's preferred encryption algorithm.

[0100] Example 5: According to the system of Example 1, the cryptographic coprocessor is configured to verify whether the encrypted code is signed by an entity among a predefined plurality of trusted entities before executing the decrypted code.

[0101] Example 6: According to the system of Example 1, the encrypted code is decrypted using the root key of the encryption coprocessor, wherein the root key of the encryption coprocessor is associated with the entity that generated the encrypted code.

[0102] Example 7: According to the system of Example 1, the service includes a first service and a second service associated with an entity, the encrypted code is received from the first service, and the password is sent to the second service.

[0103] Example 8: According to the system of Example 1, wherein the encryption coprocessor is implemented in the firmware of the computing device, and data is transmitted from the secure element of the computing device to the encryption coprocessor via an interface, so that the encryption coprocessor can decrypt the encrypted code.

[0104] Example 9: The system according to Example 1, wherein the cryptographic coprocessor is configured to support selection from a predefined plurality of cryptographic algorithms to perform cryptographic operations, and the cryptographic algorithms are excluded from the predefined plurality of cryptographic algorithms.

[0105] Example 10: The system according to Example 1, wherein the cryptographic coprocessor is configured to act as a root of trust to verify the cryptographic algorithm before transmitting the cryptographic algorithm to a secure element of the computing device.

[0106] Example 11: A method comprising: receiving encrypted code from a client application by an encryption coprocessor, the encrypted code implementing an encryption algorithm; decrypting the encrypted code by the encryption coprocessor; and executing the decrypted code by the encryption coprocessor to decrypt the encrypted data using the encryption algorithm; or, executing the decrypted code by the encryption coprocessor to generate a password using the encryption algorithm.

[0107] Example 12: The method according to Example 11 further includes: before executing the decrypted code, the encryption coprocessor verifies whether the encrypted code is signed by an entity among a predefined plurality of trusted entities.

[0108] Example 13: According to the method of Example 11, wherein the encrypted code is received by the client application from a service operated by an entity, and the client application is associated with the entity.

[0109] Example 14: According to the method of Example 13, the decryption of the encrypted code further includes: decrypting the encrypted code using the root key of the encryption coprocessor, wherein the root key of the encryption coprocessor is associated with the entity.

[0110] Example 15: According to the method of Example 13, wherein the encrypted data and the encrypted code do not include the identifier of the encryption algorithm.

[0111] Example 16: According to the method of Example 13, wherein the cryptographic coprocessor is configured to support selection from a predefined plurality of cryptographic algorithms to perform cryptographic operations, and the cryptographic algorithms are excluded from the predefined plurality of cryptographic algorithms.

[0112] Example 17: A non-transitory computer-readable medium comprising machine-readable instructions that, when executed by a processor of a first computing device, cause the first computing device to at least: encrypt an encryption algorithm to create encrypted code; send the encrypted code to a second computing device; receive a password from the second computing device, the password being generated from the encrypted code by the encryption algorithm; and decrypt the password using the encryption algorithm.

[0113] Example 18: According to the non-transitory computer-readable medium of Example 17, the encrypted code, together with an identifier of the encryption key, is sent to the second computing device to decrypt the encrypted code.

[0114] Example 19: A non-transitory computer-readable medium according to Example 17, wherein the encrypted code does not include the identifier of the encryption algorithm.

[0115] Example 20: A non-transitory computer-readable medium according to Example 17, wherein the encrypted code is encrypted using one of a plurality of predefined encryption algorithms supported by a standard cryptographic coprocessor.

[0116] Example 21: A system comprising: a computing device including a processor and a memory; and machine-readable instructions stored in the memory, which, when executed by the processor, cause the computing device to at least: receive encrypted code from a service via a network, the encrypted code implementing an encryption algorithm; provide the encrypted code to an application executing in a trusted execution environment of the computing device; and obtain a password from the application, the password comprising information encrypted using the encryption algorithm.

[0117] Example 22: The system according to Example 21, wherein the password is obtained by another application executed in the untrusted execution environment of the computing device.

[0118] Example 23: The system according to Example 22, wherein the machine-readable instructions further cause the computing device to send the password to the service via the network at least through other applications.

[0119] Example 24: The system according to Example 21, wherein the encrypted code is provided to the application via an interface between the trusted execution environment and the untrusted execution environment of the computing device.

[0120] Example 25: The system according to Example 21, wherein the trusted execution environment includes a cryptographic coprocessor, and the machine-readable instructions further cause the computing device to at least: verify the signature of the encrypted code and the state of the computing device by the cryptographic coprocessor before decrypting the encrypted code.

[0121] Example 26: The system according to Example 21, wherein the trusted execution environment includes a cryptographic coprocessor, and the machine-readable instructions further cause the computing device to at least: verify the signature of the application through the cryptographic coprocessor.

[0122] Example 27: The system according to Example 21, wherein the trusted execution environment includes a cryptographic coprocessor, and the cryptographic algorithm is not included in a plurality of predefined cryptographic algorithms supported by the cryptographic coprocessor.

[0123] Example 28: The system according to Example 21, wherein the trusted execution environment includes a secure operating system executed on a secure virtual processor of the processor.

[0124] Example 29: The system according to Example 21, wherein the password corresponds to a payment transaction, and the password includes a limited-use payment credential.

[0125] Example 30: The system according to Example 21, wherein the trusted execution environment stores a key for decrypting the encrypted code, the key being associated with an entity operating the service.

[0126] Example 31: A method comprising: receiving encrypted data and encrypted code via a network through a first application running in an untrusted execution environment, the encrypted code implementing an encryption algorithm; transmitting the encrypted data and the encrypted code through the first application to a second application running in a trusted execution environment; decrypting the encrypted code through the second application; executing the decrypted code through the second application to decrypt the encrypted data using the encryption algorithm; and receiving information from the second application through the first application, the information being decrypted from the encrypted data.

[0127] Example 32, the method according to Example 31, further includes: using an interface to transfer the encrypted code from the second application to the encryption coprocessor; and using the encryption coprocessor to verify the signature of the encrypted code.

[0128] Example 33: According to the method of Example 32, the execution of the decrypted code is not performed by the encryption coprocessor.

[0129] Example 34: According to the method of Example 32, the decryption of the encrypted code is performed by the encryption coprocessor.

[0130] Example 35: According to the method of Example 32, wherein the cryptographic coprocessor includes code that implements a plurality of predefined cryptographic algorithms, and the cryptographic algorithms are excluded from the plurality of predefined cryptographic algorithms.

[0131] Example 36: According to the method of Example 31, wherein the encrypted code is received from a service operated by an entity, and the first application and the second application are associated with the entity.

[0132] Example 37. A non-transitory computer-readable medium comprising machine-readable instructions that, when executed in a trusted execution environment of a processor of a computing device, cause the computing device to at least: receive encrypted code via an interface to an untrusted execution environment of the processor, the encrypted code implementing an encryption algorithm; decrypt the encrypted code; execute the decrypted code to generate a password, the password comprising information encrypted using the encryption algorithm; and return the password via the interface.

[0133] Example 38: A non-transitory computer-readable medium according to Example 37, wherein the computing device further includes a cryptographic coprocessor, and the machine-readable instructions further cause the computing device to at least: verify the signature of the encrypted code using the cryptographic coprocessor; or verify whether the cryptographic algorithm is a trusted root before transmitting the cryptographic algorithm to the trusted execution environment.

[0134] Example 39: A non-transitory computer-readable medium according to Example 37, wherein the trusted execution environment includes a secure operating system executed on a secure virtual processor of the processor.

[0135] Example 40: A non-transitory computer-readable medium according to Example 37, wherein the password corresponds to a payment transaction, and the password includes a limited-use payment credential.

[0136] It should be emphasized that the above embodiments of this disclosure are merely possible examples of implementation methods, and they are described for the purpose of clearly understanding the principles of this disclosure. Many variations and modifications can be made to the above embodiments without substantially departing from the spirit and principles of this disclosure. All such modifications and variations are intended to be included within the scope of this disclosure and are protected by the following claims.

Claims

1. A system comprising: A first computing device, the first computing device including a processor, a memory and a cryptographic coprocessor; as well as Machine-readable instructions, stored in the memory, which, when executed by the processor, cause the first computing device to perform at least the following: Encrypted executable code is received via a network from a service running on a second computing device, the encrypted executable code implementing an encryption algorithm; The encrypted executable code is decrypted by the encryption coprocessor; The cryptographic coprocessor executes decrypted executable code to generate a password, the password comprising information encrypted using the cryptographic algorithm; as well as The password is sent to the service via the network.

2. The system according to claim 1, wherein, The encrypted coprocessor conforms to a version of the Trusted Platform Module (TPM) standard.

3. The system according to claim 1 or 2, wherein, The encryption coprocessor is configured to verify the state of the first computing device before decrypting the encrypted executable code.

4. The system according to claim 1 or 2, wherein, The service is operated by an entity, and the encryption algorithm is the entity's preferred encryption algorithm.

5. The system according to claim 1 or 2, wherein, The cryptographic coprocessor is configured to verify whether the encrypted executable code has been signed by an entity among a predefined plurality of trusted entities before executing the decrypted executable code.

6. The system according to claim 1 or 2, wherein, The encrypted executable code is decrypted using the root key of the cryptographic coprocessor, which is associated with the entity that generated the encrypted executable code.

7. The system according to claim 1 or 2, wherein, The service includes a first service and a second service associated with the entity, wherein the encrypted executable code is received from the first service and the password is sent to the second service.

8. The system according to claim 1 or 2, wherein, The encryption coprocessor is implemented in the firmware of the first computing device, and data is transmitted from the secure element of the first computing device to the encryption coprocessor via an interface, so that the encryption coprocessor can decrypt the encrypted executable code.

9. The system according to claim 1 or 2, wherein, The cryptographic coprocessor is configured to support the selection of a predefined plurality of cryptographic algorithms to perform cryptographic operations, and the cryptographic algorithms are excluded from the predefined plurality of cryptographic algorithms.

10. The system according to claim 1 or 2, wherein, The cryptographic coprocessor is configured to act as a root of trust to verify the cryptographic algorithm before transmitting it to a secure element of the first computing device.

11. A method comprising: The encrypted executable code is received by the encryption coprocessor of the first computing device from a service executed on the second computing device via a client application, the encrypted executable code implementing an encryption algorithm; The encrypted executable code is decrypted by the encryption coprocessor; The encrypted coprocessor executes the decrypted executable code to generate a password, the password comprising information encrypted using the encryption algorithm; as well as The cryptographic coprocessor sends the password to the service.

12. The method of claim 11, further comprising: Before executing the decrypted executable code, the cryptographic coprocessor verifies whether the encrypted executable code has been signed by an entity among a predefined plurality of trusted entities.

13. The method according to claim 11 or 12, wherein, The encrypted executable code is received by the client application from the service operated by the entity, and the client application is associated with the entity.

14. The method according to claim 13, wherein, Decrypting the encrypted executable code further includes: using the root key of the encryption coprocessor, the root key of the encryption coprocessor being associated with the entity.

15. The method according to claim 13, wherein, The encrypted data and the encrypted executable code do not include the identifier of the encryption algorithm.

16. The method according to claim 13, wherein, The cryptographic coprocessor is configured to support the selection of a predefined plurality of cryptographic algorithms to perform cryptographic operations, and the cryptographic algorithms are excluded from the predefined plurality of cryptographic algorithms.

17. A computer program comprising instructions that, when executed in a trusted execution environment in a first computing device, cause the first computing device to perform at least the following: Encrypted executable code is received from a service executing on a second computing device via an interface with an untrusted execution environment of the processor, the encrypted executable code implementing an encryption algorithm; Decrypt the encrypted executable code; Execute the decrypted executable code to generate a password, the password comprising information encrypted using the encryption algorithm; as well as The password is returned to the service via the interface.

18. The computer program according to claim 17, wherein, The first computing device further includes a cryptographic coprocessor, and the instructions also cause the first computing device to verify the signature of the encrypted executable code at least using the cryptographic coprocessor.

19. The computer program according to claim 17 or 18, wherein, The trusted execution environment includes a secure operating system running on a secure virtual processor of the processor.

20. The computer program according to claim 17 or 18, wherein, The password corresponds to a payment transaction, and the password includes a limited-use payment credential.

Images