JP2022551586A - Execution of entity-specific cryptographic code in cryptographic coprocessors - Google Patents

Abstract

Various embodiments are disclosed for execution of entity-specific cryptographic code in cryptographic coprocessors. In one embodiment, encrypted code implementing an encryption algorithm is received from a service over a network. The encryption coprocessor decrypts the encrypted code. A cryptographic coprocessor executes the decrypted code to produce ciphertext containing information encrypted using an encryption algorithm. The ciphertext is sent over the network to the service.

Description

CROSS REFERENCE TO RELATED APPLICATIONS This application is a co-pending U.S. patent entitled "EXECUTING ENTITY--SPECIFIC CRYPTOGRAPHIC CODE IN A CRYPTOGRAPHIC COPROCESSOR" filed on Oct. 30, 2019 and assigned application number 16/668,973. Claiming priority to and benefit from application Ser. No. 62/914,275, which claims priority to and the benefit of, co-pending US provisional patent application No. 62/914,275, which is hereby incorporated by reference in its entirety.

This application is also a co-pending U.S. Provisional Patent Application entitled "EXECUTING ENTITY-SPECIFIC CRYPTOGRAPHIC CODE IN A TRUSTED EXECUTION ENVIRONMENT," filed Oct. 30, 2019 and assigned application number 16/669,002. 16/669,002, entitled "EXECUTING ENTITY--SPECIFIC CRYPTOGRAPHIC CODE IN A TRUSTED EXECUTION ENVIRONMENT," filed Oct. 11, 2019, and filing no. No. 1/914,272, which is hereby incorporated by reference in its entirety.

A wide variety of encryption algorithms are available. Some encryption algorithms are symmetric, meaning that the same key is used both to encrypt plaintext and to decrypt ciphertext. Other encryption algorithms are asymmetric, meaning that different associated keys are used to encrypt plaintext (e.g. public key) and decrypt ciphertext (e.g. private key). do. With the increasing sophistication of computing power, some cryptographic algorithms that were once considered secure are now considered insecure. For example, the Data Encryption Standard (DES) with a key length of 56 bits was once considered secure. However, it is now easily defeated by brute force attacks. Furthermore, backdoors and/or other weaknesses may be found in encryption algorithms that render all key combinations insecure without a full brute force attack.

Financial institutions, payment issuers, and other organizations dealing with high-value data may each come to their own judgment as to which encryption algorithms are preferable. Also, their individually preferred encryption algorithms may change over time in light of newly disclosed vulnerabilities. Moreover, there is security value in not exposing which encryption algorithm is used.

A computing device that includes a processor, a memory, and a cryptographic coprocessor, and machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to perform at least a service over a network. receiving encrypted code implementing an encryption algorithm; decrypting the encrypted code by an encryption coprocessor; executing the decrypted code by an encryption coprocessor to perform encryption; Various implementations of a system comprising machine-readable instructions that cause ciphertext containing information encrypted using an encryption algorithm to be generated, and the ciphertext to be sent over a network to a service. A form is disclosed. In some implementations of the system, the cryptographic coprocessor complies with a version of the Trusted Platform Module (TPM) standard. In some implementations of the system, the cryptographic coprocessor is configured to verify the state of the computing device prior to decrypting the encrypted code. In some implementations of the system, the service is operated by an entity and the encryption algorithm is the encryption algorithm preferred by the entity. In some implementations of the system, the cryptographic coprocessor ensures that the encrypted code is signed by an entity from a predetermined plurality of trusted entities before executing the decrypted code. configured to validate. In some implementations of the system, the encrypted code is decrypted using the cryptographic coprocessor's root key associated with the entity that generated the encrypted code. In some implementations of the system, the services include a first service and a second service associated with an entity, wherein the encrypted code is received from the first service and the ciphertext is received from the second service. sent to In some implementations of the system, the cryptographic coprocessor is implemented in firmware within the computing device and data is transferred from the secure element of the computing device to the cryptographic coprocessor via an interface to Allows decryption of encrypted code by a cryptographic coprocessor. In some implementations of the system, the cryptographic coprocessor is configured to support selection from a plurality of predetermined cryptographic algorithms for performing cryptographic operations, the cryptographic algorithms being a plurality of predetermined cryptographic algorithms. Not included in encryption algorithms. In some implementations of the system, the Cryptographic Coprocessor acts as a Root of Trust, validating cryptographic algorithms before forwarding them to the secure elements of the computing device. configured as

receiving encrypted code implementing an encryption algorithm from a client application, by a cryptographic coprocessor; decrypting the encrypted code, by a cryptographic coprocessor; , executing the decrypted code to decrypt the encrypted data using the encryption algorithm, or by the encryption coprocessor executing the decrypted code and using the encryption algorithm. Various implementations of a method are disclosed that include generating a ciphertext using a ciphertext. In some implementations of the method, the method ensures that the encrypted code is signed by an entity from a predetermined plurality of trusted entities prior to executing the decrypted code by the cryptographic coprocessor. verifying that the In some implementations of the method, the encrypted code is received by a client application from a service operated by an entity, the client application being associated with the entity. In some implementations of the method, decrypting the encrypted code further comprises decrypting the encrypted code using a root key of an encryption coprocessor associated with the entity. In some implementations of the method, the encrypted data and the encrypted code do not include an encryption algorithm identifier. In some implementations of the method, the cryptographic coprocessor is configured to support selection from a predetermined plurality of cryptographic algorithms for performing cryptographic operations, the cryptographic algorithms being a predetermined plurality of cryptographic algorithms. Not included in encryption algorithms. In some implementations of the method, the cryptographic coprocessor acts as a root of trust and is configured to validate the cryptographic algorithms prior to forwarding the cryptographic algorithms to the secure element of the computing device. .

A computer program comprising instructions, the instructions being encrypted by at least an encryption algorithm to the first computing device when the program is executed by the first computing device. sending the encrypted code to a second computing device; and sending ciphertext generated by an encryption algorithm from the encrypted code to the second computing device. Various implementations of a computer program are disclosed that cause receiving from and decrypting ciphertext with an encryption algorithm. In some implementations of the computer program, the encrypted code is sent to a second computing device along with an identifier for a cryptographic key to decrypt the encrypted code. In some implementations of the computer program, the encrypted code does not include an encryption algorithm identifier. In some implementations of computer programs, the encrypted code is encrypted using one of a plurality of predetermined encryption algorithms supported by standards for cryptographic coprocessors.

A computing device including a processor and memory, and machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to implement at least a cryptographic algorithm from a service over a network. providing the encrypted code to an application executing within the trusted execution environment of the computing device; encrypting the encrypted code using the encryption algorithm; Various implementations are disclosed of a system comprising machine-readable instructions for obtaining, from an application, a ciphertext containing information obtained from the machine. In some implementations of the system, the ciphertext is obtained by another application executing within the untrusted execution environment of the computing device. In some implementations of the system, the machine-readable instructions further cause the computing device to at least send the ciphertext over the network to the service by the other application. In some implementations of the system, the encrypted code is provided to the application via an interface between the trusted execution environment of the computing device and the untrusted execution environment of the computing device. In some implementations of the system, the trusted execution environment includes a cryptographic coprocessor, and the machine-readable instructions are transmitted to the computing device at least prior to decrypting the encrypted code. to further verify the signature of the encrypted code and the state of the computing device. In some implementations of the system, the trusted execution environment includes a cryptographic coprocessor, and the machine-readable instructions further instruct the computing device to at least verify a signature of the application by the cryptographic coprocessor. let it happen In some implementations of the system, the trusted execution environment includes a cryptographic coprocessor and the cryptographic algorithm is not included in a predetermined plurality of cryptographic algorithms supported by the cryptographic coprocessor. In some implementations of the system, the trusted execution environment includes a secure operating system running on secure virtual processors of the processor. In some implementations of the system, the ciphertext corresponds to a payment transaction, and the ciphertext includes limited-use payment credentials. In some implementations of the system, the trusted execution environment stores keys used to decrypt encrypted code, the keys being associated with the entity operating the service.

receiving over a network encrypted data and encrypted code implementing an encryption algorithm by a first application executing within an untrusted execution environment; forwarding the encrypted data and the encrypted code to a second application executing within the trusted execution environment; decrypting the encrypted code by the second application; executing the decrypted code by the application to decrypt the encrypted data using the encryption algorithm; and information decrypted from the encrypted data by the first application to the Various implementations of a method are disclosed that include receiving from two applications. In some implementations of the method, the method comprises transferring encrypted code from the second application to the cryptographic coprocessor using the interface; encrypting using the cryptographic coprocessor; and verifying the signed code. In some implementations of the method, executing the decrypted code is not performed by the cryptographic coprocessor. In some implementations of the method, decrypting the encrypted code is performed by a cryptographic coprocessor. In some implementations of the method, the cryptographic coprocessor includes code that implements a predetermined plurality of cryptographic algorithms, the cryptographic algorithms being performed from the predetermined plurality of cryptographic algorithms. In some implementations of the method, 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.

A computer program comprising instructions that, when executed within a trusted execution environment within a computing device, communicates to the computing device at least via an interface to the untrusted execution environment of a processor Receiving encrypted code implementing an encryption algorithm, decrypting the encrypted code, and executing the decrypted code to retrieve information encrypted using the encryption algorithm Various implementations of a computer program that causes generating a ciphertext containing and returning the ciphertext via an interface are disclosed. In some implementations of the computer program, the computing device comprises a cryptographic coprocessor and the instructions for transmitting to the computing device at least code encrypted using the cryptographic coprocessor. further comprising verifying the signature or verifying the encryption algorithm as a root of trust prior to transferring the encryption algorithm to the trusted execution environment. In some computer program implementations, the trusted execution environment includes a secure operating system executing on a secure virtual processor of the processor. In some implementations of the computer program, the ciphertext corresponds to a payment transaction, and the ciphertext includes limited-use payment credentials.

Many aspects of the disclosure can be better understood with reference to the following drawings. The components of the figures are not necessarily to scale, emphasis instead being placed on clearly illustrating the principles of the disclosure. Further, like reference numerals in the drawings refer to corresponding parts throughout the several views.

1 is a diagram of a network environment, according to various embodiments of the present disclosure; FIG. 2 is a diagram of a client device in the network environment of FIG. 1, according to various embodiments; FIG. 2 is a diagram of a client device in the network environment of FIG. 1, according to various embodiments; FIG. 2B is a sequence diagram illustrating an example of functionality implemented in the network environment of FIG. 1 with the client device of FIG. 2A, according to various embodiments of the present disclosure; FIG. 2B is a sequence diagram illustrating an example of functionality implemented in the network environment of FIG. 1 with the client device of FIG. 2A, according to various embodiments of the present disclosure; FIG. 2B is a sequence diagram illustrating an example of functionality implemented in the network environment of FIG. 1 with the client device of FIG. 2B, according to various embodiments of the present disclosure; FIG. 2B is a sequence diagram illustrating an example of functionality implemented in the network environment of FIG. 1 with the client device of FIG. 2B, in accordance with various embodiments of the present disclosure; FIG.

The present disclosure relates to the use of encryption algorithms selected by an entity on a client device communicating with a service associated with that entity. For example, entities such as financial institutions, payment processors, merchant gateways, payment issuers, or other entities may desire that certain information sent to them be encrypted using specific encryption algorithms. be. Entities may also use certain encryption algorithms when communicating information to client devices. Entities may wish to keep the identity of a particular cryptographic algorithm private in order to improve security. Furthermore, an entity may, at its discretion, decide to update or change a particular encryption algorithm from time to time.

In a first set of embodiments, a cryptographic coprocessor, such as a trusted platform module (TPM) on a client device, is configured to support cryptographic agility, or the ability to use various cryptographic algorithms. may For example, a cryptographic coprocessor may support a predetermined set of cryptographic algorithms, where the algorithms in the set are determined by device hardware manufacturers, standards bodies, and operating system developers. selected. The cryptographic algorithms may be permanently contained in the hardware cryptographic co-processor or may be updateable in firmware or software cryptographic co-processors.

Rather than using an encryption algorithm in a predetermined set, an entity may prefer to use various encryption algorithms. For example, an entity-preferred algorithm may be released after the cryptographic coprocessor is created. Thereby, the cryptographic coprocessor does not have embedded support for algorithms and needs to be provisioned for its use cryptographically agile.

As described, in various embodiments, an entity may send code implementing a cryptographic algorithm to a client device having a cryptographic coprocessor with cryptographic agility. The code implementing the encryption algorithm may itself be encrypted, thus hiding the identity of the algorithm and/or its internal workings. Code implementing the encryption algorithm may then be decrypted in the encryption coprocessor using the key associated with the entity. The cryptographic coprocessor can then execute code within the cryptographic coprocessor to encrypt information sent to the entity or decrypt information sent from the entity. In this way, the application running on the client device does not need to have access to the encryption algorithm and the code implementing the encryption algorithm is executed in a secure manner.

In a second set of embodiments, the client device has a separate trusted execution environment in addition to the cryptographic coprocessor. For example, ARM-based devices may include security extensions that support TRUSTZONE functionality, INTEL-based devices may have TRUSTED EXECUTION TECHNOLOGY and SGX SOFTWARE GUARD EXTENSIONS, AMD-based devices may include PLATFORM SECURITY PROCESSOR and AMD SECURE EXECUTION ENVIRONMENT. It provides a separate virtual processor running a secure operating system with hardware-based access control. Signed third party applications can be executed within a trusted execution environment. As described, in various embodiments an entity can create a trusted application for execution in a trusted execution environment configured to receive code implementing a cryptographic algorithm; If so, the code itself is encrypted. A cryptographic coprocessor can be used to verify the authenticity and integrity of the code, after which the trusted application decrypts the code implementing the encryption algorithm to encrypt the information sent to the entity. or to decode information sent from the entity.

In the discussion that follows, a general description of the system and its components is given, followed by a discussion of their operation.

Referring to FIG. 1, a network environment 100 is shown, according to various embodiments. Network environment 100 includes computing environment 103 and client devices 106 in data communication with each other over network 109 . Network 109 may include a wide area network (WAN), a local area network (LAN), a personal area network (PAN), or combinations thereof. These networks may include wired or wireless components, or a combination thereof. Wireline networks can 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 include cellular networks, satellite networks, Institute of Electrical and Electronics Engineers (IEEE) 802.11 wireless networks (i.e., WI-FI), BLUETOOTH networks, microwave transmission networks, and wireless Other networks that rely on broadcast can be mentioned. Network 109 may also include a combination of two or more networks 109 . Examples of network 109 may include the Internet, intranets, extranets, virtual private networks (VPNs), and similar networks.

Computing environment 103 may be operated for or on behalf of an entity such as a financial institution, payment processor, payment gateway, payment issuer, or another entity. Computing environment 103 may include one or more computing devices including processors, memory, and/or network interfaces. For example, computing devices may be configured to perform computations on behalf of other computing devices or applications. As another example, such computing devices may host content and/or provide content to other computing devices in response to requests for content.

Moreover, computing environment 103 may employ multiple computing devices, which may be configured in one or more server banks or computer banks or other arrangements. Such computing devices may be located at a single facility or distributed over many different geographical locations. For example, computing environment 103 includes multiple computing devices that may together include hosted computing resources, grid computing resources, or any other distributed computing arrangement. It is possible. In some cases, the computing environment 103 can accommodate elastic computing resources, where the allocated capacity of processing, network, storage, or other computing-related resources can change over time. is.

Various applications or other functionality may execute within the computing environment 103 . Components running on computing environment 103 include entity services 113 and other applications, services, processes, systems, engines, or functionality not discussed in detail herein. Entity services 113 may be operated by or on behalf of an entity to perform functions such as authentication, payment authorization, payment processing, or other functions. Although one entity service 113 is described for discussion purposes, it should be understood that multiple services may be implemented to perform some of these functions.

Various data is also stored in data store 116 that is accessible from computing environment 103 . Data stores 116 include relational databases, non-relational databases, object-oriented databases, hierarchical databases, hash tables or similar key-to-value data stores, or other data storage applications or data structures. It is possible to represent multiple data stores 116 to obtain. The data stored in data store 116 is associated with the operations of various applications hosted by computing environment 103 .

Client device 106 is representative of one or more client devices 106 that may be coupled to network 109 . Client device 106 may include a processor-based system, such as a computer system. Such computer systems include personal computers (e.g., desktop computers, laptop computers, or similar devices), mobile computing devices (e.g., personal digital assistants, mobile phones, smart phones, web pads). , tablet computer systems, music players, portable game consoles, e-readers, and similar devices); media playback devices (e.g., media streaming devices, BluRay players, digital video It may be embodied in the form of a disc (DVD) player, set-top box, and similar devices), video game console, or other device with similar functionality. The client device 106 may be a liquid crystal display (LCD), gas plasma-based flat panel display, organic light emitting diode (OLED) display, electrophoretic ink (“E-ink”) display, projector, or other type of display. One or more displays, such as display devices, may be included. In some cases, the display may be a component of client device 106 or may be connected to client device 106 through a wired or wireless connection.

A general description of the operation of the various components of network environment 100 will now be provided. Although the following description provides an example of the operation of and interactions between the various components of network environment 100, other operations or interactions may occur, as discussed later in the description that accompanies the following figures. be.

First, entity service 113 sends encrypted code 118 to client device 106 over network 109 . Encrypted code 118 includes encryption algorithm 121 and signature 124 . Encryption algorithm 121 may correspond to a symmetric algorithm, an asymmetric algorithm, or a hybrid algorithm that is a combination thereof. Non-limiting examples of encryption algorithms 121 can include Triple Data Encryption Algorithm (Triple DES), Advanced Encryption Standard (AES), ChaCha, Salsa20, Twofish, and the like.

In some cases, encryption algorithm 121 may include a key for use of encryption algorithm 121 to decrypt and/or encrypt data using encryption algorithm 121 . Alternatively, such keys may be available to client device 106 in other manners. Encrypted code 118 includes signature 124 that may be used to verify the authenticity or integrity of encrypted code 118 .

After receiving the encrypted code 118, using one or more keys available to the client device 106, the client device 106 verifies the signature 124 of the encrypted code 118 and then encrypts the encrypted code 118. decode the encrypted code 118; Client device 106 can then use cryptographic algorithm 121 along with the key to perform cryptographic operations, such as generating ciphertext 127 . The ciphertext 127 may represent a payment transaction, including the device's primary account number, transaction amount, limited-use payment credential or limited-use key, unpredictable number, timestamp, transaction counter, and /or may include data such as other information that may be used to authorize payment transactions. Ciphertext 127 is then sent to entity service 113 over network 109 .

Turning now to FIG. 2A, an example of a client device 106 is shown, according to various embodiments. Client device 106 is capable of executing client application 203 as well as other applications. Client device 106 may include cryptographic coprocessor 206, client data store 209, and other components.

A client application 203 may be associated with an entity and may be used to perform functions related to the entity. For example, client application 203 may be executed to initiate or manage payment transactions through the use of payment instruments by entity services 113 (FIG. 1). In this regard, client application 203 receives encrypted code 118 (FIG. 1) from entity service 113, generates ciphertext 127 (FIG. 1) through cryptographic coprocessor 206, and then encrypts A ciphertext 127 containing the information obtained can be sent to the entity service 113 . In addition, client application 203 receives encrypted data from entity service 113, decrypts the encrypted data using encrypted code 118 through encryption coprocessor 206, and decrypts the encrypted data. data can be processed.

Cryptographic coprocessor 206 may represent a dedicated microcontroller, physical or emulated, that secures hardware with unified cryptographic keys and performs various cryptographic operations. Cryptographic coprocessor 206 may implement some version of the TMP standard from the Trusted Computing Group (TCG). Although the cryptographic coprocessor 206 may be implemented in hardware to prevent tampering with or bypassing the cryptographic coprocessor 206, the functionality of the cryptographic coprocessor 206 may be implemented in hardware-based cryptographic coprocessor 206. can be implemented in firmware or software on client device 106 that does not have

Cryptographic coprocessor 206 is capable of performing various cryptographic functions or operations representative of client device 106 or applications executed by client device 106 . For example, cryptographic coprocessor 206 may generate random numbers using a pseudorandom number generator (PRNG) or random number generator (RNG) included in cryptographic coprocessor 206 . As another example, cryptographic coprocessor 206 can securely generate cryptographic keys or key pairs, including symmetric cryptographic keys and asymmetric cryptographic key pairs. Cryptographic coprocessor 206 is also capable of encrypting or decrypting data using cryptographic keys generated by or imported into cryptographic coprocessor 206 . As another example, the cryptographic coprocessor 206 may also generate hashes of the current state of hardware and software settings of the client device 106, and these hashes allow the client device 106 or client device 106 to Remote proof of the identity of the user of device 106 can be considered.

Various cryptographic keys may be stored within cryptographic coprocessor 206 to perform these operations. Such keys may include an endorsement key pair 212 and one or more root key pairs 215, such as a storage root key. The endorsement key pair 212 and root key pair 215 may be stored within the cryptographic coprocessor itself to protect the keys from security breaches.

Endorsement key pair 212 is an asymmetric cryptographic key pair that includes public and private cryptographic keys that are unique to cryptographic coprocessor 206 . The endorsement key pair 212 is used by the cryptographic coprocessor 206 to verify or assert its identity, that is, the identity of the client device 106 or the user of the client device 106, to other parties or devices. be able to. If endorsement key pair 212 becomes known to a third party, the third party could potentially forge the identity of cryptographic coprocessor 206 . Thus, endorsement key pair 212 is generally used to sign other cryptographic keys, which can then be used to assert or verify the identity of cryptographic coprocessor 206 . To preserve the integrity of the endorsement key pair 212 and ensure that this endorsement key pair 212 is unique with respect to other endorsement key pairs 212 installed on other cryptographic coprocessors 206 , the endorsement key pair 212 may be provisioned and stored in the cryptographic coprocessor 206 at the factory.

Root key pair 215 may be an asymmetric cryptographic key pair that can be used by cryptographic coprocessor 206 to encrypt and/or sign data. Root key pair 215 can be replaced if necessary, but any data encrypted using root key pair 215 is unrecoverable once root key pair 215 is replaced with a new root key pair 215. becomes. In some implementations, 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 that can only be accessed by the individual user. As another example, multiple client applications running on client device 106 may use their own root key to encrypt and decrypt application-specific data stored on client device 106 . It is possible to have pairs 215 . Specifically, the entity and client application 203 associated with entity service 115 may have their own root key pair 215 . Additionally, an entity can define its own authorization policy for access to this root key pair 215 . In this way, an entity can maintain exclusive control over the key hierarchy of root key pair 215 .

Cryptographic coprocessor 206 may also include multiple predetermined cryptographic algorithms 218 . A predetermined encryption algorithm 218 may be executed by cryptographic coprocessor 206 to encrypt, decrypt, or verify data using a particular key pair of root key pair 215 . The set of predetermined cryptographic algorithms 218 may be defined by a standard, by the cryptographic coprocessor 206 or the manufacturer of the client device 106 , or by the developer of the client device 106 . As such, the set of predetermined cryptographic algorithms 218 may be hard-coded into the hardware, firmware, or software implementing cryptographic coprocessor 206 and not configurable by client application 203 . good too. A flag may be sent to the cryptographic coprocessor 206 indicating which of the predetermined cryptographic algorithms 218 is selected for the cryptographic operation. Note that predetermined encryption algorithm 218 may not include encryption algorithm 121 (FIG. 1) within encrypted code 118 . However, encrypted code 118 may be encrypted using one of predetermined encryption algorithms 218 .

Approved entities 221 may correspond to a list of entities, such as cryptographic algorithms 121 , that are authorized to execute code within cryptographic coprocessor 206 . Authorized entity 221 may be authorized to store root key pair 215 in cryptographic coprocessor 206 . In some embodiments, there may not be a list of authorized entities 221, but authorized entities 221 may perform any cryptographic algorithm 121 within cryptographic coprocessor 206. has a corresponding root key pair 215 that allows it to have access to

Various data is also stored in client data store 209 that is accessible from client device 106 . Client data store 209 may include a relational database, an object-oriented database, a hierarchical database, a hash table or similar key-to-value data store, or any other data storage application or data structure. of client data stores 209 can be represented. The data stored in client data store 209 is associated with various application operations performed by client device 106 . This data may include one or more application key pairs 224, encrypted authentication tokens 163, identity key pairs 233, and potentially other data.

Application key pair 224 is an asymmetric cryptographic key pair that may be generated by or imported into cryptographic coprocessor 206 and used for various data encryption functions. Each application key pair 224 may be a child, grandchild, or descendant key of an individual root key pair 215 . Additionally, each root key pair 215 may have one or more application key pairs 224 associated with it. For example, a user may create multiple application key pairs 224 for various uses, and these application key pairs 224 are stored as subkeys or child keys of the root key pair 215 for the user. be able to. Similarly, a client application 203 that has provisioned its own root key pair 215 can use multiple application key pairs 224 for various purposes and one of these application key pairs 224 Or multiple may be stored as subkeys of provisioned root key pair 215 for client application 203 . Each application key pair 224 may include an application public key 227 and an encrypted private key 230 .

Identity key pair 233 represents a locally stored asymmetric cryptographic key pair that can be generated and used by cryptographic coprocessor 206 to verify its identity. For example, a message signed with the private key of identity key pair 233 originates from a particular client device 106 with the unique identity of cryptographic coprocessor 206 installed on client device 106 using the identity public key. It is possible to verify that Thus, identity key pair 233 can be used as an alias for endorsement key pair 212 . This can be signed by cryptographic coprocessor 206 using the private key of endorsement key pair 212 to prove that identity key pair 233 is valid.

Limited-use payment credential 236 may correspond to a limited-use key. Limited-use payment credentials 236 are dynamic keys generated by the server-side master key. A predetermined number of one or more of limited-use payment credentials 236 may initially be provisioned to client device 106 . A limited-use payment credential 236 or a session key derived from a limited-use key can be used to verify that the ciphertext 127 was generated by the client device 106 . Limited-use payment credentials 236 may be sent to client device 106, and each one of limited-use payment credentials 236 may be used once or a predetermined number of times to authorize payment transactions.

Turning to FIG. 2B, an example of client device 106 is shown, according to various embodiments. Client device 106 may include untrusted execution environment 250 , trusted execution environment 253 , and interface 254 between untrusted execution environment 250 and trusted execution environment 253 . The client application 203 can run within the untrusted execution environment 250 along with many applications under the control of the user. A trusted execution environment 253 is a secure environment with its own secure operating system running on a secure virtual processor or a secure physical processor. Untrusted execution environment 250 may run on a different virtual or physical processor than the secure virtual or physical processor of trusted execution environment 253 .

The hardware processor of client device 106 may run a hypervisor or include hardware extensions that mediate or restrict access to trusted execution environment 253 . Interface 254 is an application programming interface (API) supported by a hypervisor or processor hardware extension that allows data to be transferred between trusted execution environment 253 and untrusted execution environment 250 in a secure manner. may be For example, interface 254 may include system calls or messages passed through shared memory.

A trusted application 256 associated with the entity runs within the trusted execution environment 253 . Trusted application 256 may be signed by an entity and verified by cryptographic coprocessor 206 before executing within trusted execution environment 253 . Trusted application 256 executes to receive encrypted code 118 (FIG. 1) from client application 203 via interface 254 and encrypted by cryptographic coprocessor 206 using signature 124 (FIG. 1). It verifies the authenticity and/or integrity of the encrypted code 118 and decrypts the encrypted code 118 using the encryption coprocessor 206 .

After encrypted code 118 is verified and decrypted, trusted application 256 uses encryption algorithm 121 (FIG. 1) to encrypt, decrypt, sign, or perform other cryptographic operations. It can be carried out. In particular, trusted application 256 may generate ciphertext 127 by executing encryption algorithm 121 to encrypt various information. For example, the information may relate to a payment transaction and may include limited-use payment credentials 236 or limited-use keys.

Although FIG. 2B shows a single client data store 209, the client data store 209 is such that one or more of the data stores are accessible only through the trusted execution environment 253. , may be split into multiple data stores.

Referring now to FIG. 3, shown is a sequence diagram providing an example of the interaction between various components of network environment 100, including client device 106 of FIG. 2A. The sequence diagram of FIG. 3 provides only one example of the many different types of functional arrangements that may be employed in network environment 100 . Alternatively, the sequence diagram of FIG. 3 can be viewed as depicting exemplary elements of the method implemented within network environment 100 .

Beginning at square 303, entity service 113 sends encrypted code 118 (FIG. 1) to client application 203 running on client device 106 (FIG. 2A). Encrypted code 118 may be sent along with signature 124 (FIG. 1). A header of signature 124 can be used to identify a particular root key pair 215 (FIG. 2A) for decrypting encrypted code 118 . Alternatively, entity service 113 may send a different type of key identifier. In one embodiment, client device 106 uses a local (e.g., non It may also have a lookup table or mapping stored in a volatile random access memory).

Next, at box 306 , client application 203 provides encrypted code 118 to cryptographic coprocessor 206 of client device 106 . For example, client application 203 may store encrypted code 118 in client data store 209 or other memory, and send commands to cryptographic coprocessor 206 to load encrypted code 118. can be verified and decrypted. When cryptographic coprocessor 206 is implemented in firmware, data (e.g., root keys) stored in secure elements (e.g., secure data storage) is passed through interfaces that mediate access to the secure elements. may be transferred from the secure element to the cryptographic coprocessor 206 of the firmware. The data (eg, root key) allows the firmware's cryptographic coprocessor 206 to perform functions such as verification and decryption.

At box 309 , cryptographic coprocessor 206 verifies encrypted code 118 using signature 124 sent with encrypted code 118 . To this end, cryptographic coprocessor 206 can obtain root key pair 215 associated with the entity for verification using signature 124 . The verification procedure thus verifies the authenticity and integrity of the encrypted code 118 . In some cases, cryptographic coprocessor 206 may verify the state of client device 106 and, based on the state of client device 106 , allow or disallow decryption of encrypted code 118 . For example, cryptographic coprocessor 206 may disallow decryption of encrypted code 118 if client device 106 is rooted. If the verification was not successful, decryption and execution of the encryption algorithm 121 will not proceed.

At box 312 , encryption coprocessor 206 decrypts encrypted code 118 . For example, encryption coprocessor 206 can utilize a particular one of predetermined encryption algorithms 218 (FIG. 2A) along with root key pair 215 associated with the entity to perform decryption. . In decrypting encrypted code 118, encryption coprocessor 206 obtains encryption algorithm 121 (FIG. 1) in unencrypted form. In some examples, encryption algorithm 121 may be different than predetermined encryption algorithm 218 . In another example, encryption algorithm 121 may be one of predetermined encryption algorithms 218, but the identity of encryption algorithm 121 is not apparent from encrypted code 118 itself. Sometimes. In one example, cryptographic coprocessor 206 acts as a root of trust, validating certain proprietary cryptographic algorithms 121 before passing them to the secure element.

At box 315 , client application 203 provides information to cryptographic coprocessor 206 for subsequent encryption by cryptographic coprocessor 206 . For example, the information may relate to a particular payment transaction, such as limited-use payment credentials 236 (FIG. 2A) or limited-use keys, unpredictable numbers, sequential numbers, monotonic counter values, timestamps. , transaction amount, and/or other information. In other examples, client application 203 may provide information to cryptographic coprocessor 206 along with encrypted code 118 or before encrypted code 118 is provided to cryptographic coprocessor 206 . good too. One or more items of this information (eg, unpredictable numbers) may be generated by cryptographic coprocessor 206 itself in some examples.

At box 318 , encryption coprocessor 206 encrypts information from encrypted code 118 using encryption algorithm 121 decrypted at box 312 . To this end, the Cryptographic Coprocessor 206 executes code implementing the Cryptographic Algorithm 121 supplied by the Entity Service 113 and uses a key from the Root Key Pair 215 associated with the Entity or a symmetric key to good too. In this manner, cryptographic coprocessor 206 produces ciphertext 127 (FIG. 1). At box 321 , cryptographic coprocessor 206 returns ciphertext 127 to client application 203 .

At box 324 , client application 203 sends ciphertext 127 to entity service 113 over network 109 . At box 327 , entity service 113 processes ciphertext 127 . For example, entity service 113 may validate the signature of ciphertext 127 . Entity service 113 then decrypts ciphertext 127 using the symmetric key used to encrypt ciphertext 127 or the private key of the key pair used to encrypt ciphertext 127. do. Entity service 113 can then verify the contents of ciphertext 127 . For example, the entity service 113 can verify whether the limited-use payment credential 236 or the limited-use key is valid. Upon verifying the content, Entity Services 113 can then authorize and/or process the corresponding payment transaction.

Turning to FIG. 4, shown is a sequence diagram providing another example of the interaction between various components of network environment 100, including client device 106 of FIG. 2A. The sequence diagram of FIG. 4 provides only one example of the many different types of functional arrangements that may be employed in network environment 100 . Alternatively, the sequence diagram of FIG. 4 can be viewed as depicting example elements of the method implemented within network environment 100 .

Beginning at box 403, entity service 113 sends encrypted code 118 (FIG. 1) to client application 203 running on client device 106 (FIG. 2A). Entity service 113 may also send encrypted data with encrypted code 118, before encrypted code 118, or after encrypted code 118, in which case the encrypted data The encrypted data is encrypted using encryption algorithm 121 (FIG. 1) encrypted within encrypted code 118 . The encrypted code 118 and encrypted data may be sent along with the signature 124 (FIG. 1). The header of signature 124 can be used to identify a particular root key pair 215 (FIG. 2A) for decrypting encrypted code 118 and encrypted data. Alternatively, entity service 113 may send a different type of key identifier. In one embodiment, client device 106 links entity service 113 to a particular root key pair 215 to verify signature 124 and to decrypt encrypted code 118 and encrypted data. It may also have a lookup table or mapping stored locally (eg, in non-volatile random access memory).

Next, at box 406 , client application 203 provides encrypted code 118 to cryptographic coprocessor 206 of client device 106 . For example, client application 203 may store encrypted code 118 in client data store 209 or other memory, and send commands to cryptographic coprocessor 206 to load encrypted code 118. can be verified and decrypted. When cryptographic coprocessor 206 is implemented in firmware, data (e.g., root keys) stored in secure elements (e.g., secure data storage) is passed through interfaces that mediate access to the secure elements. may be transferred from the secure element to the cryptographic coprocessor 206 of the firmware. The data (eg, root key) allows the firmware's cryptographic coprocessor 206 to perform functions such as verification and decryption.

At box 409 , cryptographic coprocessor 206 verifies encrypted code 118 using signature 124 sent with encrypted code 118 . To this end, cryptographic coprocessor 206 can obtain root key pair 215 (FIG. 2A) associated with the entity for verification using signature 124 . The verification procedure thus verifies the authenticity and integrity of the encrypted code 118 . In some cases, cryptographic coprocessor 206 may verify the state of client device 106 and, based on the state of client device 106 , allow or disallow decryption of encrypted code 118 . For example, cryptographic coprocessor 206 may disallow decryption of encrypted code 118 if client device 106 is rooted. If the verification was not successful, decryption and execution of the encryption algorithm 121 will not proceed.

At box 412 , encryption coprocessor 206 decrypts encrypted code 118 . For example, encryption coprocessor 206 can utilize a particular one of predetermined encryption algorithms 218 (FIG. 2A) along with root key pair 215 associated with the entity to perform decryption. . In decrypting encrypted code 118, encryption coprocessor 206 obtains encryption algorithm 121 in unencrypted form. In some examples, encryption algorithm 121 may differ from predetermined encryption algorithm 218 . In another example, encryption algorithm 121 may be one of predetermined encryption algorithms 218, but the identity of encryption algorithm 121 is not apparent from encrypted code 118 itself. Sometimes. In one example, cryptographic coprocessor 206 acts as a root of trust, validating certain proprietary cryptographic algorithms 121 before passing them to secure elements.

At box 415 , client application 203 provides encrypted data to encryption coprocessor 206 . The encrypted data may be arbitrary data. The encrypted data may include one or more limited-use payment credentials 236 (FIG. 2A) or limited-use keys, or other information related to the payment transaction. For example, client application 203 stores encrypted data in client data store 209 or other memory and sends commands to cryptographic coprocessor 206 to load the encrypted data; It can be verified and decrypted.

At box 418 , encryption coprocessor 206 decrypts the information in the encrypted data using encryption algorithm 121 . To this end, cryptographic coprocessor 206 executes entity-supplied code that implements cryptographic algorithm 121 and may use keys from root key pair 215 associated with the entity. At box 421 , encryption coprocessor 206 returns the decrypted information to client application 203 . At box 424, client application 203 processes the decrypted data, which may include re-encrypting the data, storing the data in client data store 209, and/or performing other actions. may include

Continuing with FIG. 5, a sequence diagram is shown that provides an example of the interaction between the various components of the network environment 100, including the client device 106 of FIG. 2B. The sequence diagram of FIG. 5 provides only one example of the many different types of functional arrangements that may be employed in network environment 100 . Alternatively, the sequence diagram of FIG. 5 can be viewed as depicting exemplary elements of the method implemented within network environment 100 .

Beginning at box 503, entity service 113 sends encrypted code 118 (FIG. 1) to a client application running on client device 106 (FIG. 2B) in untrusted execution environment 250 (FIG. 2B). 203. Encrypted code 118 may be sent along with signature 124 (FIG. 1). A header of signature 124 can be used to identify a particular root key pair 215 (FIG. 2B) for decrypting encrypted code 118 . Alternatively, entity service 113 may send a different type of key identifier. In one embodiment, client device 106 uses a local (e.g., non It may have a lookup table or mapping stored in a volatile random access memory).

Next, at box 506 , client application 203 provides encrypted code 118 to trusted application 256 running within trusted execution environment 253 via interface 254 (FIG. 2B). For example, client application 203 may store encrypted code 118 in client data store 209 or other memory, and send commands to cryptographic coprocessor 206 to load encrypted code 118. can be verified and decrypted.

At box 509 , trusted application 256 provides encrypted code 118 to cryptographic coprocessor 206 of client device 106 . For example, trusted application 256 may store encrypted code 118 in a secure portion of client data store 209 or other secure memory and send commands to cryptographic coprocessor 206 to encrypt it. The encrypted code 118 can be loaded, verified and decrypted. Encrypted code 256 may be provided to cryptographic coprocessor 206 via an interface between trusted execution environment 253 and cryptographic coprocessor 206 .

At box 512 , cryptographic coprocessor 206 verifies encrypted code 118 using signature 124 ( FIG. 1 ) sent with encrypted code 118 . To this end, cryptographic coprocessor 206 can obtain root key pair 215 (FIG. 2B) associated with the entity for verification using signature 124 . The verification procedure thus verifies the authenticity and integrity of the encrypted code 118 . In some cases, cryptographic coprocessor 206 may verify the state of client device 106 and, based on the state of client device 106 , allow or disallow decryption of encrypted code 118 . For example, cryptographic coprocessor 206 may disallow decryption of encrypted code 118 if client device 106 is rooted. If the verification was not successful, decryption and execution of the encryption algorithm 121 will not proceed.

At box 515 , encryption coprocessor 206 decrypts encrypted code 118 . For example, encryption coprocessor 206 can utilize a particular one of predetermined encryption algorithms 218 (FIG. 2B) along with root key pair 215 associated with the entity to perform decryption. . In decrypting encrypted code 118, encryption coprocessor 206 produces encryption algorithm 121 (FIG. 1) in unencrypted form. In some examples, encryption algorithm 121 may be different than predetermined encryption algorithm 218 . In another example, encryption algorithm 121 may be one of predetermined encryption algorithms 218, but the identity of encryption algorithm 121 is not apparent from encrypted code 118 itself. Sometimes. At box 518 , cryptographic coprocessor 206 returns the decrypted code for cryptographic algorithm 121 to trusted application 256 via the interface between cryptographic coprocessor 206 and trusted execution environment 253 . In one example, cryptographic coprocessor 206 acts as a root of trust, validating certain proprietary cryptographic algorithms 121 before passing them to trusted execution environment 253 .

At box 521 , client application 203 provides information to trusted application 256 for subsequent encryption by trusted application 256 . For example, the information may relate to a particular payment transaction, such as limited-use payment credentials 236 (FIG. 2A) or limited-use keys, unpredictable numbers, sequential numbers, monotonic counter values, timestamps. , transaction amount, and/or other information. In other examples, client application 203 may provide information to trusted application 256 along with encrypted code 118 or before encrypted code 118 is provided to trusted application 256 . . One or more items of this information (eg, unpredictable numbers) may be generated by cryptographic coprocessor 206 or trusted application 256 in some examples.

At box 524 , trusted application 256 encrypts the information using encryption algorithm 121 . To this end, trusted application 256 executes entity-supplied code that implements encryption algorithm 121 and may use a key or symmetric key from application key pair 224 associated with the entity. In this manner, trusted application 256 generates ciphertext 127 (FIG. 1). At box 527 , trusted application 256 returns ciphertext 127 to client application 203 via interface 254 .

At box 530 , client application 203 sends ciphertext 127 to entity service 113 over network 109 . At box 533 , entity service 113 processes ciphertext 127 . For example, entity service 113 may validate the signature of ciphertext 127 . Entity service 113 then decrypts ciphertext 127 using the symmetric key used to encrypt ciphertext 127 or the private key of the key pair used to encrypt ciphertext 127. do. Entity service 113 can then verify the contents of ciphertext 127 . For example, the entity service 113 can verify that the limited-use payment credential 236 or the limited-use key is valid. Upon verifying the content, Entity Services 113 can then authorize and/or process the corresponding payment transaction.

Turning now to FIG. 6, shown is a sequence diagram providing another example of the interaction between various components of network environment 100, including client device 106 of FIG. 2B. The sequence diagram of FIG. 6 provides only one example of the many different types of functional arrangements that may be employed in network environment 100 . Alternatively, the sequence diagram of FIG. 6 can be viewed as depicting example elements of the method implemented within network environment 100 .

Beginning at square 603, entity services 113 transmit encrypted code 118 (FIG. 1) to client applications running on client device 106 (FIG. 2B) in untrusted execution environment 250 (FIG. 2B). 203. Entity service 113 may also send encrypted data with encrypted code 118, before encrypted code 118, or after encrypted code 118, in which case the encrypted data The encrypted data is encrypted using encryption algorithm 121 (FIG. 1) encrypted within encrypted code 118 . The encrypted code 118 and encrypted data may be sent along with the signature 124 (FIG. 1). A header of signature 124 can be used to identify a particular root key pair 215 (FIG. 2B) for decrypting encrypted code 118 . Alternatively, entity service 113 may send a different type of key identifier. In one embodiment, client device 106 links entity service 113 to a particular root key pair 215 to verify signature 124 and to decrypt encrypted code 118 and encrypted data. It may also have a lookup table or mapping stored locally (eg, in non-volatile random access memory).

Next, at box 606, client application 203 submits encrypted code 118 to trusted application 256 running within trusted execution environment 253 (FIG. 2B) via interface 254 (FIG. 2B). offer.

At box 609 , trusted application 256 provides encrypted code 118 to cryptographic coprocessor 206 of client device 106 . For example, trusted application 256 may store encrypted code 118 in a secure portion of client data store 209 or other secure memory and send commands to cryptographic coprocessor 206 to encrypt it. The encrypted code 118 can be loaded, verified and decrypted. Encrypted code 256 may be provided to cryptographic coprocessor 206 via an interface between trusted execution environment 253 and cryptographic coprocessor 206 . At box 612 , cryptographic coprocessor 206 verifies encrypted code 118 using signature 124 sent with encrypted code 118 . To this end, cryptographic coprocessor 206 can obtain root key pair 215 associated with the entity for verification using signature 124 . The verification procedure thus verifies the authenticity and integrity of the encrypted code 118 . In some cases, cryptographic coprocessor 206 may verify the state of client device 106 and, based on the state of client device 106 , allow or disallow decryption of encrypted code 118 . For example, cryptographic coprocessor 206 may disallow decryption of encrypted code 118 if client device 106 is rooted. If the verification was not successful, decryption and execution of the encryption algorithm 121 will not proceed.

At box 615 , encryption coprocessor 206 decrypts encrypted code 118 . For example, encryption coprocessor 206 can utilize a particular one of predetermined encryption algorithms 218 (FIG. 2B) along with root key pair 215 associated with the entity to perform decryption. . In decrypting encrypted code 118, encryption coprocessor 206 produces encryption algorithm 121 in unencrypted form. In some examples, encryption algorithm 121 may be different than predetermined encryption algorithm 218 . In another example, encryption algorithm 121 may be one of predetermined encryption algorithms 218, but the identity of encryption algorithm 121 is not apparent from encrypted code 118 itself. Sometimes. In one example, cryptographic coprocessor 206 acts as a root of trust, validating certain proprietary cryptographic algorithms 121 before passing them to trusted execution environment 253 .

At box 618 , cryptographic coprocessor 206 returns the decrypted code for cryptographic algorithm 121 to trusted application 256 via the interface between trusted execution environment 253 and cryptographic coprocessor 206 . In another example, once encrypted code 118 is verified by cryptographic coprocessor 206 , trusted application 256 then decrypts encrypted code 118 .

At box 621 , client application 203 provides encrypted data to trusted application 256 via interface 254 . The encrypted data may be arbitrary data. The encrypted data may include one or more limited-use payment credentials 236 (FIG. 2A) or limited-use keys, or other information related to the payment transaction.

At box 624 , trusted application 256 decrypts the information in the encrypted data using encryption algorithm 121 . To this end, trusted application 256 may execute entity-supplied code that implements encryption algorithm 121 and use keys from application key pair 224 (FIG. 2B) associated with the entity. At box 627 , trusted application 256 returns the decrypted information to client application 203 via interface 254 . At box 630, client application 203 processes the decrypted data, which may re-encrypt the data, store the data in client data store 209, and/or perform other actions. may include

Some of the software components discussed above are stored in the memory of the respective computing device and executable by the processor of the respective computing device. In this regard, the term "executable" means a program file that is ultimately in a form executable by a processor. Examples of executable programs include compiled programs that can be converted to machine code in a format that can be loaded into a random-access portion of memory and executed by a processor; Source code, which may be expressed in a suitable format, such as object code, executable by a processor, or interpreted by another executable program to generate instructions in a random access portion of memory to be executed by the processor I can cite the source code that can be used. An executable program can be stored in any portion or component of memory, including random access memory (RAM), read only memory (ROM), hard drives, solid state drives, universal serial buses ( USB) flash drives, memory cards, optical discs such as compact discs (CD) or digital versatile discs (DVD), floppy discs, magnetic tapes, or other memory components.

Memory includes both volatile and non-volatile memory and data storage components. A volatile component is a component that does not retain its data value when power is lost. A non-volatile component is a component that retains its data value when power is lost. Thus, the memory may be random access memory (RAM), read only memory (ROM), hard disk drives, solid state drives, USB flash drives, memory accessed through memory card readers. Card, Floppy Disk Accessed Through Associated Floppy Disk Drive, Optical Disk Accessed Through Optical Disk Drive, Magnetic Tape Accessed Through Suitable Tape Drive, Non-Volatile Random Access Memory (NVRAM), other memory components, or a combination of any two or more of these memory components. Additionally, RAM may include static random access memory (SRAM), dynamic random access memory (DRAM), or magnetic random access memory (MRAM) and other such devices. is possible. ROM may include programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or other similar memory devices. There is

The applications and systems described herein may be embodied as software or code executed by general-purpose hardware as discussed above, but alternatively, as described herein Applications and systems can also be embodied in special purpose hardware or a combination of software/general purpose and special purpose hardware. When embodied as dedicated hardware, each may be implemented as a circuit or state machine employing any combination of several techniques. These technologies include, but are not limited to, discrete logic circuits having logic gates that implement various logic functions upon application of one or more data signals, application specific integrated circuits (ASICs) having appropriate logic gates. , field programmable gate arrays (FPGAs), or other components. Such techniques are generally well known to those skilled in the art and, as a result, are not described in detail herein.

The sequence diagrams illustrate the functionality and operation of implementations of portions of various embodiments of the present disclosure. When embodied in software, each block can represent a module, segment, or portion of code that contains program instructions for implementing specified logical functions. Program instructions may be embodied in the form of source code comprising 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. is. Machine code can be converted from source code through various processes. For example, machine code can be generated from source code using a compiler prior to execution of a corresponding application. As another example, machine code can be generated from source code concurrently with execution by an interpreter. Other approaches are also available. When embodied in hardware, each block can represent a circuit or several interconnected circuits to implement one or more specified logical functions.

Although the sequence diagrams show a specific order of execution, it should be understood that the order of execution may differ from that depicted. For example, the order of execution of two or more blocks may be scrambled relative to the order shown. Also, two or more blocks shown in succession can be executed concurrently or with partial concurrence. Additionally, in some embodiments, one or more of the blocks shown in the sequence diagrams may be skipped or omitted. Additionally, any number of counters, state variables, warning semaphores, or messages may be added to the logic flow described herein for purposes such as improving utility, billing, measuring performance, or providing troubleshooting assistance. may be It is to be understood that all such variations are within the scope of this disclosure.

Also, any logic or application described herein, including software or code, may be used by or in combination with an instruction execution system, such as a processor in a computer system or other system, in any non-compliant form. It can be embodied as a transitory computer-readable medium. In this sense, logic can include statements, including instructions and declarations, that can be fetched from a computer-readable medium and executed by an instruction execution system. In the context of this disclosure, a "computer-readable medium" contains, stores, or maintains the logic or applications described herein for use by or in conjunction with an instruction execution system. can be any medium in which Moreover, a distributed collection of computer-readable media located across multiple computing devices (e.g., a storage area network or a distributed or clustered file system or database) is also collectively , can also be considered as a single non-transitory computer-readable medium.

Computer readable media can include any of a number of physical media such as magnetic, optical, or semiconductor media. More specific examples of suitable computer-readable media include, but are not limited to, magnetic tapes, magnetic floppy diskettes, magnetic hard drives, memory cards, solid state drives, USB flash drives, or optical discs. Let me mention The computer-readable medium also includes random access memory (RAM), including static random access memory (SRAM) and dynamic random access memory (DRAM) or magnetic random access memory (MRAM). ). Additionally, the computer readable medium may 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 type of memory device.

Moreover, any logic or application described herein can be implemented and structured in a variety of ways. For example, one or more of the described applications could be implemented as modules or components of a single application. Moreover, one or more applications described herein can run on a shared computing device or separate computing devices, or a combination thereof. For example, multiple applications described herein may execute on the same computing device or on multiple computing devices within the same computing environment 103 .

Disjunctive phrases, such as the phrase "at least one of X, Y, or Z," imply that items, terms, etc. are either X, Y, or Z, unless stated otherwise. It is understood in the context as commonly used to suggest that it can be obtained or a combination of any of them (eg, X, Y, or Z). Thus, such disjunctive phrases generally mean that certain embodiments are present when at least one of X, at least one of Y, or at least one of Z is present. It is not intended, nor should it be implied, that you require

An example embodiment of the present disclosure can be described as follows.

Embodiment 1
A computing device that includes a processor, a memory, and a cryptographic coprocessor, and machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to perform at least a service over a network. receiving encrypted code implementing an encryption algorithm; decrypting the encrypted code by an encryption coprocessor; executing the decrypted code by an encryption coprocessor to perform encryption; machine-readable instructions for generating ciphertext containing information encrypted using an encryption algorithm; and sending the ciphertext to a service over a network.

Embodiment 2
2. The system of embodiment 1, wherein the cryptographic coprocessor conforms to a version of the Trusted Platform Module (TPM) standard.

Embodiment 3
2. The system of embodiment 1, wherein the cryptographic coprocessor is configured to verify the state of the computing device prior to decrypting the encrypted code.

Embodiment 4
2. The system of embodiment 1, wherein the service is operated by an entity and the encryption algorithm is an encryption algorithm preferred by the entity.

Embodiment 5
An implementation wherein the cryptographic coprocessor is configured to verify that the encrypted code is signed by an entity from a predetermined plurality of trusted entities before executing the decrypted code A system according to aspect 1.

Embodiment 6
2. The system of embodiment 1, wherein the encrypted code is decrypted using a cryptographic coprocessor root key associated with the entity that generated the encrypted code.

Embodiment 7
2. Embodiment 1 as described in embodiment 1, wherein the services include a first service and a second service associated with an entity, wherein the encrypted code is received from the first service and the ciphertext is sent to the second service. system.

Embodiment 8
A cryptographic coprocessor is implemented in firmware within the computing device such that data is transferred from a secure element of the computing device to the cryptographic coprocessor via an interface and encrypted by the cryptographic coprocessor 2. A system as in embodiment 1, wherein the system enables decoding of the code.

Embodiment 9
the cryptographic coprocessor is configured to support selection from a predetermined plurality of cryptographic algorithms for performing cryptographic operations, wherein the cryptographic algorithm is not included in the predetermined plurality of cryptographic algorithms; 2. The system of embodiment 1.

Embodiment 10
2. The system of embodiment 1, wherein the cryptographic coprocessor acts as a root of trust and is configured to verify the cryptographic algorithms prior to forwarding the cryptographic algorithms to a secure element of the computing device.

Embodiment 11
receiving, from a client application, encrypted code implementing an encryption algorithm, by a cryptographic coprocessor; decrypting the encrypted code, by a cryptographic coprocessor; , executing the decrypted code to decrypt the encrypted data using the encryption algorithm, or by the encryption coprocessor executing the decrypted code and using the encryption algorithm. generating a ciphertext using a

Embodiment 12
An embodiment further comprising, prior to executing the decrypted code by the cryptographic coprocessor, verifying that the encrypted code is signed by an entity from a predetermined plurality of trusted entities. 11. The method according to 11.

Embodiment 13
12. The method of embodiment 11, wherein the encrypted code is received by a client application from a service operated by an entity, the client application being associated with the entity.

Embodiment 14
14. The method of embodiment 13, wherein decrypting the encrypted code further comprises decrypting the encrypted code using a root key of an encryption coprocessor associated with the entity.

Embodiment 15
14. The method of embodiment 13, wherein the encrypted data and encrypted code do not include an encryption algorithm identifier.

Embodiment 16
the cryptographic coprocessor is configured to support selection from a predetermined plurality of cryptographic algorithms for performing cryptographic operations, wherein the cryptographic algorithm is not included in the predetermined plurality of cryptographic algorithms; 14. The method of embodiment 13.

Embodiment 17
A non-transitory computer-readable medium containing machine-readable instructions that, when executed by a processor of a first computing device, instruct the first computing device to at least an encryption algorithm. encrypting to produce encrypted code; sending the encrypted code to a second computing device; and ciphertext generated with an encryption algorithm from the encrypted code. A non-transitory computer-readable medium causing receiving from a second computing device and decrypting the ciphertext with an encryption algorithm.

Embodiment 18
18. The non-transitory computer-readable medium of embodiment 17, wherein the encrypted code is sent to the second computing device along with an identifier for a cryptographic key to decrypt the encrypted code.

Embodiment 19
18. The non-transitory computer-readable medium of embodiment 17, wherein the encrypted code does not include an encryption algorithm identifier.

Embodiment 20
18. The non-transitory computer of embodiment 17, wherein the encrypted code is encrypted using one of a plurality of predetermined encryption algorithms supported by standards for cryptographic coprocessors. readable medium.

Embodiment 21
A computing device including a processor and memory, and machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to implement at least a cryptographic algorithm from a service over a network. providing the encrypted code to an application executing within the trusted execution environment of the computing device; encrypting the encrypted code using the encryption algorithm; and machine-readable instructions for obtaining from an application a ciphertext containing the information obtained from the application.

Embodiment 22
22. The system of embodiment 21, wherein the ciphertext is obtained by another application executing within an untrusted execution environment of the computing device.

Embodiment 23
23. The system of embodiment 22, wherein the machine-readable instructions further cause the computing device to send the ciphertext over the network to a service with at least another application.

Embodiment 24
22. The system of embodiment 21, wherein the encrypted code is provided to the application via an interface between the trusted execution environment of the computing device and the untrusted execution environment of the computing device.

Embodiment 25
The trusted execution environment includes a cryptographic coprocessor, and the machine-readable instructions are sent to the computing device to at least sign the encrypted code by the cryptographic coprocessor prior to decrypting the encrypted code. , and verifying the state of the computing device.

Embodiment 26
22. As recited in embodiment 21, wherein the trusted execution environment includes a cryptographic coprocessor and the machine-readable instructions further cause the computing device to verify a signature of the application with at least the cryptographic coprocessor. system.

Embodiment 27
22. The system of embodiment 21, wherein the trusted execution environment includes a cryptographic coprocessor, and the cryptographic algorithm is not included in a predetermined plurality of cryptographic algorithms supported by the cryptographic coprocessor.

Embodiment 28
22. The system of embodiment 21, wherein the trusted execution environment comprises a secure operating system executing on a secure virtual processor of the processor.

Embodiment 29
22. The system of embodiment 21, wherein the ciphertext corresponds to a payment transaction, and wherein the ciphertext includes limited-use payment credentials.

Embodiment 30
22. The system of embodiment 21, wherein the trusted execution environment stores keys used to decrypt encrypted code, the keys associated with the entity operating the service.

Embodiment 31
receiving over a network encrypted data and encrypted code implementing an encryption algorithm by a first application executing within an untrusted execution environment; forwarding the encrypted data and the encrypted code to a second application executing within the trusted execution environment; decrypting the encrypted code by the second application; executing the decrypted code by the application to decrypt the encrypted data using the encryption algorithm; and information decrypted from the encrypted data by the first application to the receiving from 2 applications.

Embodiment 32
Further transferring encrypted code from the second application to the cryptographic coprocessor using the interface and verifying a signature of the code encrypted using the cryptographic coprocessor. 32. The method of embodiment 31, comprising:

Embodiment 33
33. The method of embodiment 32, wherein executing the decrypted code is not performed by a cryptographic coprocessor.

Embodiment 34
33. The method of embodiment 32, wherein decrypting the encrypted code is performed by a cryptographic coprocessor.

Embodiment 35
33. The method of embodiment 32, wherein the cryptographic coprocessor includes code implementing a plurality of predetermined cryptographic algorithms, and wherein the cryptographic algorithms are performed from a plurality of predetermined cryptographic algorithms.

Embodiment 36
32. The method of embodiment 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.

Embodiment 37
A non-transitory computer-readable medium containing machine-readable instructions that, when executed within a trusted execution environment of a processor of a computing device, provides the computing device with at least an untrusted execution environment of the processor. Receiving encrypted code implementing an encryption algorithm via an interface to the execution environment, decrypting the encrypted code, and executing the decrypted code using the encryption algorithm a non-transitory computer-readable medium that causes a ciphertext containing encrypted information to be generated by the ciphertext and returning the ciphertext via an interface.

Embodiment 38
A computing device comprising a cryptographic coprocessor and machine-readable instructions to instruct the computing device to at least verify a signature of code encrypted using the cryptographic coprocessor; 38. The non-transitory computer-readable medium of embodiment 37, further comprising machine-readable instructions that further cause the cryptographic algorithm to be validated as a root of trust prior to transferring the algorithm to a trusted execution environment.

Embodiment 39
38. The non-transitory computer-readable medium of embodiment 37, wherein the trusted execution environment comprises a secure operating system executing on a secure virtual processor of the processor.

Embodiment 40
38. The non-transitory computer-readable medium of embodiment 37, wherein the ciphertext corresponds to a payment transaction, and the ciphertext includes limited-use payment credentials.

It should be emphasized that the above-described embodiments of the disclosure are merely possible examples of implementations set forth for a clear understanding of the principles of the disclosure. Many variations and modifications may be made to the above-described embodiments without departing substantially from the spirit and principles of this disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.

Claims (20)

a computing device that includes a processor, memory, and a cryptographic coprocessor;
Machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to:
receiving encrypted code implementing an encryption algorithm from a service over a network;
decrypting the encrypted code by the encryption coprocessor;
executing the decrypted code by the encryption coprocessor to generate ciphertext containing information encrypted using the encryption algorithm;
sending the ciphertext over the network to the service; and machine-readable instructions for: 2. The system of claim 1, wherein the cryptographic coprocessor conforms to a version of the Trusted Platform Module (TPM) standard. 3. The system of claim 1 or 2, wherein the cryptographic coprocessor is configured to verify the state of the computing device prior to decrypting the encrypted code. 4. A system according to any preceding claim, wherein said service is operated by an entity and said encryption algorithm is an encryption algorithm preferred by said entity. the cryptographic coprocessor is configured to verify that the encrypted code is signed by an entity from a predetermined plurality of trusted entities before executing the decrypted code; 5. A system according to any one of claims 1-4. 6. The encrypted code as claimed in any one of claims 1 to 5, wherein the encrypted code is decrypted using the cryptographic coprocessor's root key associated with the entity that generated the encrypted code. system. The service comprises a first service and a second service associated with an entity, wherein the encrypted code is received from the first service and the ciphertext is sent to the second service. Item 7. The system according to any one of Items 1 to 6. The cryptographic coprocessor is implemented in firmware within the computing device, data is transferred from the secure element of the computing device to the cryptographic coprocessor via an interface, and the cryptographic coprocessor is 8. A system as claimed in any one of the preceding claims, allowing decryption of the encrypted code by a. wherein the cryptographic coprocessor is configured to support selection from a predetermined plurality of cryptographic algorithms for performing cryptographic operations, wherein the cryptographic algorithm is included in the predetermined plurality of cryptographic algorithms; 9. The system of any one of claims 1-8, wherein the system is not The cryptographic coprocessor acts as a Root of Trust and is configured to validate the cryptographic algorithm prior to forwarding the cryptographic algorithm to a secure element of the computing device. 10. The system according to any one of claims 1-9. receiving, by a cryptographic coprocessor, encrypted code implementing a cryptographic algorithm from a client application;
decrypting the encrypted code by the encryption coprocessor;
and executing, by the cryptographic coprocessor, the decrypted code to generate ciphertext using the encryption algorithm. further comprising, prior to executing the decrypted code by the cryptographic coprocessor, verifying that the encrypted code is signed by an entity from a predetermined plurality of trusted entities. Item 12. The method according to Item 11. 13. A method according to claim 11 or 12, wherein said encrypted code is received by said client application from a service operated by an entity, said client application being associated with said entity. 14. The method of claim 13, wherein decrypting the encrypted code further comprises decrypting the encrypted code using a root key of the cryptographic coprocessor associated with the entity. Method. 15. A method according to claim 13 or 14, wherein said encrypted data and said encrypted code do not contain an identifier of said encryption algorithm. wherein the cryptographic coprocessor is configured to support selection from a predetermined plurality of cryptographic algorithms for performing cryptographic operations, wherein the cryptographic algorithm is included in the predetermined plurality of cryptographic algorithms; 16. The method of any one of claims 13-15, wherein A computer program comprising instructions that, when executed in a trusted execution environment within a computing device, cause the computing device to at least:
receiving encrypted code implementing an encryption algorithm via an interface to an untrusted execution environment of the processor;
decrypting the encrypted code;
executing the decrypted code to generate ciphertext containing information encrypted using the encryption algorithm;
and returning said ciphertext via said interface. The computing device further includes a cryptographic coprocessor, and the instructions instruct the computing device to at least verify a signature of the encrypted code using the cryptographic coprocessor. 18. The computer program product of claim 17, causing further execution. 19. A computer program product according to claim 17 or 18, wherein said trusted execution environment comprises a secure operating system running on a secure virtual processor of said processor. 20. A computer program product as claimed in any one of claims 17 to 19, wherein the ciphertext corresponds to a payment transaction and the ciphertext comprises a limited-use payment credential.

Images