ES2932500T3 - Select and secure test delegates for cryptographic functions - Google Patents

Abstract

The disclosed technology is generally targeted at cryptographic functions for smart contracts. In one example of the technology, a request for cryptographic resources is received. The request for cryptographic resources includes a binding identity (ID). Cryptographic resources are extracted from at least one cryptographic resource pool of a plurality of cryptographic resource pools in response to the cryptographic resource request. The separate sets of cryptographic resources of the plurality of sets of cryptographic resources are sets of separate types of cryptographic resources. It is determined which type of test delegate code is suitable for each obtained cryptographic resource. For each obtained cryptographic resource, the given type of test delegate code is injected into the obtained cryptographic resource. (Automatic translation with Google Translate, without legal value)

Description

DESCRIPTION

Select and secure test delegates for cryptographic functions

Background

Blockchain systems are systems that have been proposed for a variety of application scenarios, including applications in the financial industry, healthcare, IoT, etc. For example, the Bitcoin system was developed to allow electronic cash to be transferred directly from one party to another without going through a financial institution. A bitcoin (for example, an electronic currency) is represented by a chain of transactions that transfers ownership from one party to another party. To transfer ownership of a bitcoin, a new transaction can be generated and added to a stack of transactions in a block. The new transaction, which includes the new owner's public key, can be digitally signed by the owner with the owner's private key to transfer ownership to the new owner by being represented by the new owner's public key.

Once the block is full, the block can be "topped" with a block header that is a hash digest of all transaction ids within the block. The block header can be recorded as the first transaction in the next block in the chain, creating a mathematical hierarchy called a "block chain." To verify the current owner, you can follow the blockchain of transactions to verify each transaction, from the first transaction to the last transaction. The new owner only needs to have the private key that matches the public key of the transaction that transferred the bitcoin. The blockchain can create a mathematical proof of ownership in an entity represented by a security identity (for example, a public key), which in the case of the bitcoin system is nearly anonymous. According to Tramer Florian et al, "Sealed-Glass Proofs: Using Transparent Enclaves to Prove and Sell Knowledge," 2017 IEEE European Symposium on Security and Privacy, doi:10.1109/EUROSP.2017.28, pages 19-34, certain systems Trusted hardware, such as the new extension to Intel's SGX instruction set architecture, are intended to provide strong guarantees of confidentiality and integrity for applications. The authors propose, formalize, and explore a cryptographic primitive called Sealed Glass Proof (SGP) that models computation possible in an isolated execution environment with unlimited leakage, and thus against arbitrary side channels. An SGP specifically models the capabilities of trusted hardware that can certify the correct execution of a piece of code, its execution being transparent, which means that the secret information and state of an application will be visible to other processes. on the same host. The authors note that SGPs enable secure verifiable computing in zero-knowledge environments, since data leakage only results in the tester learning his own secret information.

Disclosure Summary

The object of the present invention is to provide methods and apparatus for improving information security. This object is solved by the object of the independent claims.

Embodiments are defined by the dependent claims.

This summary is provided to present a selection of concepts in a simplified form that are further described in the detailed description. This summary is not intended to identify the key features or essential features of the claimed item, nor is it intended to be used to limit the scope of the claimed item.

Put briefly, the disclosed technology is generally directed at cryptographic functions for smart contracts. In one example of the technology, a request for cryptographic resources is received. In some examples, the request for cryptographic resources includes a binding identity (ID). In some examples, cryptographic resources are extracted from at least one cryptographic resource group, belonging to a plurality of cryptographic resource groups, and in response to the cryptographic resource request. In some examples, the groups of disaggregated cryptographic resources of the plurality of groups of cryptographic resources are groups of disaggregated types of cryptographic resources. In some examples, it is determined which type of test delegate code is appropriate for each mined cryptographic resource. In some examples, for each mined cryptographic resource, the given type of test delegate code is injected into the mined cryptographic resource.

Other aspects and applications of the disclosed technology will be appreciated by reading and understanding the accompanying figures and description.

Brief description of the drawings

Non-limiting and non-exhaustive examples of the present disclosure are described with reference to the following drawings. In the drawings, like reference numerals refer to like parts in the various figures, unless otherwise specified. The drawings in this document are not necessarily drawn to scale.

For a better understanding of the present disclosure, reference will be made to the following detailed description, which should be read in association with the accompanying drawings, in which:

Figure 1 is a block diagram illustrating an example of a suitable environment in which aspects of the technology may be employed;

Figure 2 is a block diagram illustrating an example of a suitable computing device in accordance with aspects of the disclosed technology;

Figure 3 is a block diagram illustrating an example of a system;

Figure 4 is a block diagram illustrating an example of the system of Figure 3;

Figure 5 is a block diagram illustrating an example of a subassembly of the system of Figure 4;

Figure 6 is an example data flow for a process; and

Figure 7 is an example data flow for another process, in accordance with aspects of the present disclosure.

Detailed description

The following description provides specific details for a complete understanding of and a description that facilitates various examples of the technology. One skilled in the art will understand that the technology can be practiced without many of these details. In some cases, well-known structures and functions have not been shown or described in detail to avoid unnecessarily complicating the description of examples of the technology. The terminology used in this description is intended to be construed as broadly as possible, even though it is used in conjunction with a detailed description of certain examples of the technology. Although emphasis is placed on certain terms later in the description, any terminology intended to be narrowly construed will be clearly and specifically defined as such in the detailed description section. Throughout the specification and claims, the following terms have at least the meanings explicitly associated herein, unless the context otherwise indicates. The meanings identified later in the description do not necessarily limit the terms, but merely provide illustrative examples of the terms. For example, each of the terms "based on" and "is based on" is not exclusive, and is equivalent to the term "based on/is based, at least in part, on", and includes the option of be based on additional factors, some of which may not be described in this document. As another example, the term "through" is not exclusive, and is equivalent to the term "through, at least in part", and includes the option of additional factors, some of which may not be described herein. Regarding the meaning of "in", which includes "in" and "on", let us clarify that the phrase "in one embodiment" or "in an example", as used herein, does not necessarily refer to the same realization or example, although it could be so. The use of particular textual numeric designators does not imply the existence of lower value numeric designators. For example, saying that "a widget selected from the group consists of any third computing entity and a fourth bar" would not by itself imply that there are at least any three entity elements, nor that there are at least four bar elements. Singular references are made merely for clarity of reading, and include plural references, unless plural references are specifically excluded. The term "or" is an inclusive "or" operator, unless specifically stated otherwise. For example, the phrases "A or B" mean "A, B, or A and B." As used herein, the terms "component" and "system" are intended to encompass computer hardware, computer software, or various combinations of hardware and software. Thus, a system or component can be, for example, a process, a process running on a computing device, the computing device, or a portion thereof.

Briefly stated, the disclosed technology is generally directed at cryptographic functions for smart contracts. In one example of the technology, a request for cryptographic resources is received. In some examples, the request for cryptographic resources includes a binding identity (ID). In some examples, cryptographic resources are extracted from at least one cryptographic resource group, belonging to a plurality of cryptographic resource groups, and in response to a request for cryptographic resources. In some examples, the disaggregated cryptographic resource sets of the plurality of cryptographic resource sets are sets of disaggregated cryptographic resource types. In some examples, it is determined which type of test delegate code is appropriate for each mined cryptographic resource. In some examples, for each mined cryptographic resource, the given type of test delegate code is injected into the mined cryptographic resource.

In some examples, the cryptographic helper program or cryptographic applet appears, a code component that can run in a secure environment and communicate using secure channels. One application for cryptographic backends is smart contracts. In some examples, a smart contract is computer code that partially or fully executes and partially or fully enforces an agreement or transaction, such as an exchange of money and/or property, and that may make use of blockchain technology. . Rather than running smart contract logic on the blockchain itself, in some examples, the logic may be performed by cryptographic backends running outside of the blockchain. In some examples, the blockchain may be further involved in some way, such as tracking the status and receipt of the output of the cryptographic backend.

Some or all of the cryptographic backend code may be associated with a restriction to run in a secure environment. Consequently, some of the cryptographic backend code can be executed in an enclave. In some examples, an enclave is an execution environment, provided by hardware or software, that is private, tamper resistant, and secure from outside interference. In some examples, the outputs of the cryptographic backbone program code are signed by at least the host enclave's private enclave key out of a pair of enclave keys stored by the host enclave. The outputs can be certified out of band from the blockchain, for example, with the public key of the cryptographic backbone and the enclave. The enclaves for use by the cryptographic backends can be grouped into a few examples. Enclave pooling can allow enclaves to be provisioned on demand, eg, at runtime, based on the secure computing needs of running applications.

An enclave is an example of a cryptographic resource that may be required by the cryptographic backend. The cryptographic backend program may require other resources and/or additional cryptographic resources, such as a Field Programmable Gate Array (FPGA), configured to perform a particular cryptographic function, an Application Specific Integrated Circuit (ASIC), configured to perform a particular cryptographic function, and/or a composite resource, which may include two or more cryptographic resources combined to perform a particular cryptographic function. In the same way that enclaves can be grouped for use by cryptographic backends, in some examples other cryptographic resources can be grouped, each type of cryptographic resource having a disaggregated group. Pooling of cryptographic resources may allow cryptographic resources to be provisioned on demand, eg, at runtime, based on the secure computing needs of running applications.

A cryptographic backend container may determine the type, quality, and quantity of each cryptographic resource that the cryptographic backend requires, and may send a request for the determined cryptographic resources to a test engine service. The test engine service can then extract the requested cryptographic resources from the corresponding cryptographic resource pool or pools. The test engine service can then inject test generation code, if any, into the crypto resources, which can cause the crypto resources to become test delegates. If the crypto backend requires some secret information, such as keys, the test engine service can cause a secure tunnel to start between the crypto back-end and a hardware security module (HSM) if the crypto back-end can receive secret information through the secure tunnel. The test engine service can then send the requested test delegates to the cryptographic backend container. The cryptographic backend code can then be executed, and the test delegates are to allow the cryptographic functions requested by the cryptographic backend code to be performed, along with the necessary tests.

Illustrative Devices/Operating Environments

Figure 1 is a diagram of the environment 100 in which aspects of the technology can be practiced. As shown, environment 100 includes computing devices 110, as well as network nodes 120, connected via network 130. Although particular components of environment 100 are shown in Figure 1, environment 100 may also include additional and/or different components. in other examples. For example, in certain examples, environment 100 may also include network storage devices, maintenance managers, and/or other suitable components (not shown). The computing devices 110 shown in Figure 1 may be in various locations, including on-premises, in the cloud, or the like. For example, computing devices 110 may be client-side, server-side, or the like.

As shown in Figure 1, network 130 may include one or more network nodes 120 that interconnect multiple computing devices 110 and connect computing devices 110 to an external network 140, eg, the Internet or an intranet. For example, network nodes 120 may include switches, routers, hubs, network controllers, or other network elements. In certain examples, the computing devices 110 may be organized into frames, action zones, groups, sets, or other suitable divisions. For example, in the illustrated example, computing devices 110 are grouped into three host sets individually identified as first, second, and third host sets 112a-112c. In the illustrated example, each of the host sets 112a-112c is operatively coupled to a corresponding host node 120a-120c. network, respectively, which are commonly referred to as "top-of-the-frame" or "TOR" network nodes. The TOR network nodes 120a-120c can then be operatively coupled to additional network nodes 120 to form a computing network in a hierarchical, flat, mesh topology, or other suitable types of topology that allows communications between the computing devices 110 and the web. external network 140. In other examples, multiple host sets 112a-112c may share a single network node 120. Computing devices 110 can be virtually any type of general or specific purpose computing device. For example, these computing devices can be user devices such as desktop computers, laptops, tablets, displays, cameras, printers, or smartphones. However, in a data center environment, these computing devices may be server devices, such as application server computers, virtual computing host computers, or file server computers. What's more, computing devices 110 can be individually configured to provide suitable computing, storage, and/or other computing services.

In some examples, one or more of the computing devices 110 is an IoT device, a device that comprises part or all of an IoT support service, a device that comprises part or all of an application backend, or the like. , as discussed in more detail later.

Illustrative computing device

Figure 2 is a diagram illustrating an example computing device 200 on which aspects of the technology can be practiced. Computing device 200 can be virtually any type of general or specific purpose computing device. For example, computing device 200 may be a user device such as a desktop computer, laptop computer, tablet computer, display device, camera, printer, or smartphone. Similarly, computing device 200 may also be a server device, such as an application server computer, virtual computing host computer, or file server computer; for example, computing device 200 can be an example of computing device 110 or network node 120 of Figure 1. Computing device 200 can also be an IoT device that connects to a network to receive IoT services. Similarly, computing device 200 can be an example of any of the devices illustrated or referenced in Figures 3-5, as discussed in more detail below. As illustrated in Figure 2, computing device 200 includes processing circuitry 210, working memory 220, memory controller 230, data storage memory 250, input interface 260, output interface 270, and the network adapter 280. Each of these aforementioned components of computing device 200 includes at least one hardware element.

Computing device 200 includes at least one processing circuit 210 configured to execute instructions, such as instructions to implement the workloads, processes, or technology described herein. Processing circuitry 210 may include a microprocessor, microcontroller, graphics processor, coprocessor, field-programmable gate array, programmable logic device, signal processor, or any other suitable circuitry for processing data. Processing circuit 210 is an example of a core. The aforementioned instructions, along with other data (eg, data sets, metadata, operating system instructions, etc.), may be stored in working memory 220 during the execution time of computing device 200. Working memory 220 also it may include any of a variety of data storage devices/components, such as volatile memories, semi-volatile memories, random access memories, static memories, caches, buffers, or other media used to store information at run time. In one example, working memory 220 does not retain information when computing device 200 is turned off. Instead, computing device 200 may be configured to transfer instructions from a non-volatile data storage component (eg, data storage component 250) to working memory 220 as part of a boot or other process. Loading process.

Operating memory 220 may include fourth generation double data rate memory (DDR4), third generation double data rate memory (DDR3), other dynamic random access memory (DRAM), high bandwidth memory (HBM). ), Hybrid Memory Cube (HMC) memory, 3D floppy memory [s/c.], Static Random Access Memory (SRAM) or other memory, and such memory may comprise one or more memory circuits integrated into a DIMM, SIMM, SODIMM or other packaging. Such working memory devices or modules may be organized according to channels, intervals and banks. For example, working memory devices may be coupled to processing circuitry 210 via channelized memory controller 230. An example computing device 200 may include one or two DIMMs per channel, with one or two slots per channel. The working memory within an interval can work with a shared clock and a shared address and command bus. Furthermore, a working memory device can be organized into several banks, where a bank can be thought of as a row and column-addressed array. Based on such organization of working memory, physical addresses within working memory can be referred to by a tuple of channel, interval, bank, row and column.

Despite the foregoing discussion, working memory 220 does not specifically include or encompass, by itself, means of communication, no means of communication, no signal.

Memory controller 230 is configured for processing circuitry 210 to interface with working memory 220. For example, memory controller 230 may be configured to interface commands, addresses, and data between working memory 220 and processing circuitry 210. Memory controller 230 may also be configured to abstract or otherwise manage certain aspects of memory management from or to processing circuitry 210. Although memory controller 230 is illustrated as a single memory controller, unbundled from processing circuitry 210, in other examples multiple memory controllers may be employed, the memory controllers may be integrated with working memory 220, or the like. Furthermore, the memory controller(s) may be integrated into the processing circuit 210. These and other variations fit as well.

In computing device 200, data storage memory 250, input interface 260, output interface 270, and network adapter 280 interact with processing circuitry 210 over bus 240. Although Figure 2 illustrates the bus 240 as a single passive bus, other configurations, such as a collection of buses, a collection of point-to-point links, an input/output controller, a bridge, other interface circuitry, or any collection of these elements may also be suitably employed. so that the data storage memory 250, the input interface 260, the output interface 270 or the network adapter 280 interacts with the processing circuit 210.

In computing device 200, data storage memory 250 is used for long-term non-volatile data storage. Data storage memory 250 may include any of a variety of non-volatile data storage devices/components, such as non-volatile memories, disks, disk drives, hard drives, solid state drives, or any other media that can be used for non-volatile storage of information. However, the data storage memory 250 does not specifically include or encompass, by itself, communication media, or any communication medium, or any signal. Unlike working memory 220, data storage memory 250 is used by computing device 200 for long-term, non-volatile data storage, rather than run-time data storage.

In addition, computing device 200 may include or be coupled to any type of processor-readable media, such as processor-readable storage media (such as working memory 220 and data storage memory 250) or memory media. communication (for example, communication signals and radio waves). While the term "processor-readable storage media" includes operating memory 220 and data storage memory 250, the term "processor-readable storage media" throughout the specification and claims, either whether used in the singular or the plural, is defined herein so that the term "processor-readable storage media" specifically excludes and does not include, by itself, communication media, or any communication medium, or signal some. However, the term "processor-readable storage media" encompasses processor cache, random access memory (RAM), register memory, and/or the like.

Computing device 200 also includes input interface 260, which can be configured to allow computing device 200 to receive input from users or other devices. In addition, computing device 200 includes an output interface 270, which can be configured to provide output from computing device 200. In one example, output interface 270 includes a frame buffer, graphics processor, graphics processor or an accelerator, and is configured to deliver visual representations presented on a disaggregated display device (such as a monitor, projector, virtual computing client computer, etc.). In another example, output interface 270 includes a display device and is configured to present visual representations for viewing. In yet another example, input interface 260 and/or output interface 270 may/n include a universal asynchronous receiver/transmitter ("UART"), a serial peripheral interface ("SPI"), an interintegrated circuit (" I2C"), a general purpose input/output (GPIO), and/or the like. What's more, input interface 260 and/or output interface 270 may include or interact with any number or type of peripherals.

In the illustrated example, computing device 200 is configured to communicate with other computing devices or entities via network adapter 280. Network adapter 280 may include a wired network adapter, for example, an Ethernet adapter, a Token Ring adapter, or a digital subscriber line (DSL) adapter. The network adapter 280 may also include a wireless network adapter, such as a Wi-Fi adapter, a Bluetooth adapter, a ZigBee adapter, a Long Term Evolution (LTE) adapter, or a 5G adapter.

Although the computing device 200 is illustrated with certain components configured in a particular arrangement, these components and arrangement are merely an example of a computing device in which the technology may be employed. In other examples, data storage memory 250, input interface 260, output interface 270, or network adapter 280 may be directly coupled to processing circuitry 210, or coupled to processing circuitry 210, by a data controller. input/output, jumper, or other circuitry interface. Other variations of the technology are also possible.

Some examples of computing device 200 include at least one memory (eg, working memory 220), adapted to store data at run time, and at least one processor (eg, processing unit 210), which is adapted to executing executable code by the processor which, in response to execution, allows the computing device 200 to perform actions.

illustrative systems

Figure 3 is a block diagram illustrating an example of a system (300). System 300 may include network 330, as well as participant devices 311 and 312, member devices 341 and 342, counterpart devices 316 and 317, validation nodes (VNs) 351 and 352, cryptographic resources 371 and 372, cryptographic backend fabric devices 361 and 362, and key repository 365, all of which are connectable to network 330.

Participant devices 311 and 312, counterpart devices 316 and 317, member devices 341 and 342, VNs 351 and 352, cryptographic backend fabric devices 361 and 362, and/or key repository 365 may each include examples of the computing device 200 of Figure 2. Figure 3, and the corresponding description of Figure 3, in the specification, illustrate an example system for illustrative purposes that does not limit the scope of the disclosure.

Network 330 may include one or more computer networks, either wired and/or wireless networks, where each network may be, for example, a wireless network, a local area network (LAN), a wide area network (WAN) , and/or a global network such as the Internet. In an interconnected set of LANs, including those based on different architectures and protocols, a router acts as a link between the LANs, allowing messages to be sent from one to the other. Furthermore, communication links within LANs typically include coaxial cable or twisted pair cable, while communication links between networks may use analog telephone lines, full or fractional dedicated digital lines, including T1, T2, T3, and T4, integrated services digital networks (ISDN), digital subscriber lines (DSL), wireless links including satellite links, or other communication links known to those skilled in the art. In addition, remote computers and other related electronic devices could be remotely connected to LAN or WAN networks using a modem and a temporary telephone link. Network 330 may include various other networks, such as one or more networks using local network protocols, such as 6LoWPAN, ZigBee, or the like. Some IoT devices may be connected to a user device via a different network, in network 330, to other IoT devices. In essence, network 330 includes any communication technology by which information can travel between participant devices 311 and 312, counterpart devices 316 and 317, member devices 341 and 342, VNs 351 and 352, cryptographic backend fabric devices 361 and 362, the cryptographic resources 371 and 372, and/or the key repository 365 . Although each device or service is shown connected as connected to the network 330, that does not mean that each device communicates with the other devices shown. In some examples, some displayed devices/services only communicate with other displayed devices/services through one or more intermediary devices. Furthermore, while network 330 is illustrated as a single network, network 330 may include, in some examples, multiple networks, which may or may not be connected to each other, some of the devices shown communicating with each other through of a network of the multiple networks, and communicating, other of the devices shown, with each other, with a different network of the multiple networks.

In some examples, VN 351 and VN 352 are part of a blockchain network. In some examples, VNs 351 and 352 are devices that, during normal operation, validate and process enacted blockchain transactions and execute chain code. In some examples, member devices 341 and 342 are devices used by members to communicate over network 330, such as for communication between a member and its corresponding VN, such as to support a VN. In some examples, the participant devices 311 and 312 are devices used by the participants to communicate over the network 330, such as to request a transaction.

In some examples, the counterparty devices 316 and 317 are devices used by the counterparties or as counterparties to a smart contract that makes use of a contract cryptographic backend via the cryptographic backend fabric (where the cryptographic backend fabric includes eg, cryptographic backend fabric device 361 and cryptographic backend fabric device 362). Each of the counterpart devices 316 and 317 may be, represent, and/or act on behalf of a person, company, IoT device, smart contract, and/or the like.

An example arrangement of system 300 can be described as follows. In some examples, each cryptographic resource may be any of a variety of different types of cryptographic resources, such as an enclave, an FPGA configured to perform a particular cryptographic function, an ASIC configured to perform a particular cryptographic function, and/or a composite resource, which may include two or more cryptographic resources combined to perform a particular cryptographic function. Enclaves are execution environments, provided by hardware or software, that are private, tamper resistant, and secure from outside interference. Exits from an enclave are digitally signed by the enclave. Cryptographic backend fabric devices 361 and 362 are part of a cryptographic backend fabric that provides runtime and other functionality for cryptographic backend programs, as discussed in more detail below. Key repository 365 can be used to provide secure persistent storage for keys used by cryptographic backends for identity, digital signature and encryption services, and/or other types of secret information.

System 300 may include more or fewer devices than are illustrated in Figure 3, which is shown by way of example only.

illustrative device

Figure 4 is a block diagram illustrating an example of system 400, which can be used as an example of system 300 of Figure 3. System 400 may include participant devices 411 and 412, counterpart devices 416 and 417, devices 441 and 442 members, 450 blockchain network, 460 cryptographic backbone fabric, 470 cryptographic resource, and 465 key repository.

In some examples, during normal operation, the blockchain network 450 may validate and process completed blockchain transactions. In some examples, member devices 441 and 442 are devices used by members to communicate with the blockchain network 450 . In some examples, the participant devices 411 and 412 are devices used by the participants to communicate with the blockchain network 450, such as to request a transaction. In some examples, cryptographic resources 470 may include enclaves, FPGAs configured to perform a particular cryptographic function, ASICs configured to perform a particular cryptographic function, composite cryptographic resources configured to perform a particular cryptographic function, and/or the like. In some examples, enclaves are execution environments, provided by hardware or software, that are private, tamper-resistant, and secure from outside interference. In some examples, outputs from an enclave are digitally signed by the enclave. Key repository 465 may be used to provide secure persistent storage for keys used by cryptographic backends for identity, digital signature, and encryption services.

In some examples, the counterparty devices 416 and 417 are devices used by counterparties or as counterparties to a smart contract making use of a contract cryptographic backend via the cryptographic backend fabric 460. The counterparty devices 416 and 417 may be, represent, and/or act on behalf of a person, company, IoT device, smart contract, and/or the like, as discussed in more detail below.

Blockchain network 450 may include a number of VN nodes. In some examples, each member of the blockchain network 450 may, through a member device (eg, the 441 or 442), maintain one or more VNs in the blockchain network 450. Participants can request, through participant devices (for example, 411 or 412), transactions to be carried out by the block chain network 450. During normal operation, the Vn's, in the block chain network 450, validate and process the transactions carried out, and execute the logical code.

Transactions performed by the blockchain network 450 may be stored on blockchains. In some examples, blockchains are decentralized ledgers that record transactions made by the blockchain in a verifiable manner. Multiple transactions can be stored in a block. Once a block is full, the block can be covered with a block header that is a hash digest of all the transaction identifiers within a block. The block header can be recorded as the first transaction in the next block in the chain, thus creating a chain of blocks.

A blockchain network can also be used for smart contract processing. In some examples, a smart contract is computer code that partially or fully executes and partially or fully enforces an agreement or transaction, such as an exchange of money and/or property, and that may make use of blockchain technology. Instead of executing the logic of a smart contract on the blockchain itself, the logic can instead, with the help of the cryptographic backend fabric 460, be executed by cryptographic backends running outside the network 450 of block chain. In some examples, a cryptographic backend is a piece of code that can be executed in a secure environment and communicated over secure channels. In some examples, the cryptographic backend fabric 460 is configured to provide runtime and other functions for the cryptographic backends.

In some examples, the cryptographic backbone fabric 460 is a serverless cloud platform that provides a core infrastructure for middleware that enables chain-based applications. blocks with increased functionality. In some examples, the cryptographic backbone fabric 460 is comprised of various components that provide functionality for an enhanced security wrapper of the cloud blockchain application, as well as a common application program interface (API) that abstracts the underlying blockchain and its nuances from the developers.

In some examples, the cryptographic backend fabric 460 manages the scaling, failover, caching, monitoring, and/or management of the cryptographic backends, as well as a runtime secure key platform for cryptographic backends that enable the creation, persistence, and hydration of private keys at scale. (“Hydration” refers to activation and orchestration in memory from persistent storage.) This allows cryptographic backends to create, store, and use key pairs in a secure execution environment to perform a variety of functions including, for example, digital signatures, ring signatures, zero-knowledge proofs, thresholding, and homomorphic encryption.

In some examples, among other components, the cryptographic backend fabric 460 includes a cryptographic backend container service (CCS) and a test engine service, each of which is discussed in more detail below.

In some examples, a cryptographic backend may be a software component inheriting from the base classes that implements interfaces that provide integrations and cryptographic primitives for distributed trust applications. In some examples, it is enough for developers to know the base classes and how to implement required and optional interfaces for cryptographic backends to develop on the platform. Established software development frameworks, patterns, and designs can be used for user interfaces and integration into existing systems.

Cryptographic backend types may include utility cryptographic backends and contract cryptographic backends. Cryptographic utility backends typically perform external data integration using internal or external events, provide data access or reusable logic for blockchain smart contracts, but can also provide service level APIs for other systems to work with chains. of blocks. Cryptographic utility backends whose primary purpose is to inject certified data into blockchains may be referred to as "oracle" cryptographic backend. In some examples, the contract cryptographic backends contain specific smart contract logic that the counterparties signing the contract agree to. Both types of cryptographic backend can provide a blockchain-oriented API and ^a surface-level P ⁱ API.

Regardless of how a smart contract is implemented, cryptographic utility backends can be used to provide additional information and computation for smart contracts in reusable libraries. These libraries can be used to create a framework in which distributed applications are designed and exposed in a common way using the cryptographic backend fabric 460, in both public and private cloud and blockchain environments.

Contract cryptographic backends can redefine the implementation of the logic that executes a smart contract. In some examples, these cryptographic backends prescribe any logic to be executed off-chain, using the underlying blockchain as the database.

Cryptographic utility plugins may provide unobtrusive functionality, such as providing external information, eg, market prices, external data from other systems, or proprietary formulas. These can be called “blockchain oracles” in the sense that they can observe and inject “real world” events and data into blockchain systems. Smart contracts can interact with these using a publish/subscribe pattern in which the cryptographic utility backend publishes an event to subscribe smart contracts. Event triggers can be external to the blockchain (for example, a price change) or internal to the blockchain (for example, a data signal) within a smart contract or opcode.

In some examples, these cryptographic backends may also be called directly by other cryptographic backends within the cryptographic backend fabric, and expose an external or surface-level API that can be called by other systems. For example, an enterprise customer relationship management (CRM) system may publish an event to a subscription cryptographic backend, which, in turn, publishes information to a blockchain on the blockchain network 450 based on that information. In this manner, two-way integration to smart contracts and blockchains can be provided through the cryptographic backend fabric 460.

Contract or control cryptographic backbones can represent the logic or complete state in a contractual agreement between counterparties. In some examples, contract cryptographic backends used in smart contract-based systems may use the ledger of the chain of blocks to authentically store the data of a contract using smart contract logic for data validity, but the surrogate logic of a contract crypto backend provides "separation of concerns" within an application design. The relationship between an on-chain smart contract and a contract cryptographic backend can be referred to as a trust relationship.

For systems that are not based on smart contracts, in some examples, cryptographic contract backends execute logic and write their data to the blockchain without the smart contract or well-defined schema on the blockchain.

In essence, in some examples, contract cryptographic backends can execute the logic of a contractual agreement between counterparties at scale, in a secure private environment, and still store their data on the underlying blockchain, regardless of type.

In some examples, a cryptographic backend has common properties regardless of type:

Identity: For example, a pair of keys. The identity may be created by the cryptographic backend itself or assigned. The public key is also known as the address of the cryptographic backbone in some examples. The private key can be used to sign all transactions of the cryptographic backend. Private keys may be stored in the keystore 465 or extracted via a secure channel by rehydrating or assigning an identity to a cryptographic backend.

Name: A common name that is assigned to the address for a more readable identity in some examples.

Code: Code written in a language that is supported by its parent container in some examples.

Cryptographic backend binding: A small list of bindings that represent the addresses and client parameters (for example, accounts or blockchain contracts) for the binding in some examples.

Events: List of events published or seen by the cryptographic backend in some examples. These event triggers can be seen in data or blockchain events or some external examples.

API – A set of surface-level APIs that can be used by non-blockchain systems or other cryptographic backends, as well as subscriber callback methods in some examples.

Parent container: A cryptographic backend container in which the cryptographic backend runs, in some instances.

Manifest – Simple JavaScript Object Notation (JSON) configuration settings for a cryptographic backend that is used for deployment to the fabric, in some examples.

A cryptographic backend container may provide a runtime for the cryptographic backends to execute. Cryptographic backend wrappers can provide abstractions for cryptographic backends such as I/O, security, key management, and runtime optimization.

Cryptographic backend containers can provide secure key storage and retrieval for cryptographic backends to use for identity, digital signatures, and encryption. Cryptographic backends can automatically store and extract keys through the crypto backend container, which integrates with the key repository 465 via a secure channel or crypto backend tunnel.

A cryptographic backend can declare, in the manifest, its configuration, its enclave, its type, etc. In some examples, the crypto-helper wrapper ensures that the dependencies needed by the crypto-helper are in place for it to run.

The cryptographic resource requirements for a cryptographic backplane can be set in the cryptographic backplane manifest or in the policy. In some examples, cryptographic resource configuration and options are set in the cryptographic backend container service, which is part of the cryptographic backend fabric 460 in some examples.

In some examples, the crypto backend container service is the center of the crypto backend fabric 460. In some examples, the main functions and components of the service cryptographic backend container are:

- The registry of cryptographic backend fabrics, which consists of the registry and the database for configuration.

• Cryptographic backend: name and ID, surface level APIs, and events that expose blockchain networks.

• Block chains or other distributed records: network name, type, list of nodes, metadata.

• Smart Contracts: On-chain smart contract addresses and application binary interfaces (ABIs) or other interface definition that subscribe to or have trust relationships with cryptographic backends as well as the host's blockchain network.

- Cryptographic backend binding, which is a collection of all bindings served by the fabric. A crypto backend binding may assign smart contracts to one crypto back-end or one crypto back-end to other crypto back-end for message validation and routing. A crypto backend binding may represent a unique binding between a smart contract and a crypto back-end (or peer/ring). Details about the binding, such as subscription parameters, interface parameters, and/or smart contract address, are used to route messages between cryptographic backends, their clients, smart contracts, or other cryptographic backends.

- Secure computer registry: it is a registry of enclaves and their attributes such as capacities, version, costs and configuration. Cluster enclave group definitions and additional cryptographic services, provided by enclave groups, such as key derivation, ring signatures, and threshold encryption. The secure computing registry may also include a registry of other types of cryptographic resources and their attributes, as well as group definitions of other types of cryptographic resources.

- Catalog of cryptographic backends, which can be a representational REST API and/or a website for developers to discover and register cryptographic backends in their applications, either to bind a smart contract or to use in the design of an integration or user interface.

- API for abstracting the blockchain transaction format and providing atomicity, consistency, isolation, and durability (ACID), appending transactions, and reading queries from crypto backend and any other system that wants "direct" access to the underlying blockchain. This API can be exposed in a variety of ways, for example, with messaging via service bus, remote procedure calls (RPC), and/or REST.

Cryptographic backends, blockchains, and smart contracts can be registered with the Crypto Backend Fabric Registry Service. The crypto backend container service can publish the crypto backend catalog for the on-chain smart contract, the front end user interface (UI) and system integration developers discover and use the crypto backend. Developers using the service level APIs can interact with the blockchain via cryptographic backend and not care, or even necessarily know, that they are working with blockchain data. User interfaces and integrations with other systems can interact with cryptographic backend surface level APIs to quickly integrate and build applications.

Enclaves can be hardware or software. For example, a software enclave can be formed running a hypervisor or a secure virtual machine (VSM). An example of a hardware enclave is a secure hardware enclave such as Intel's SGX. A hardware enclave can have a set of keys that are burned/etched into the silicon, which can be used to sign out of the enclave to serve as certification of its secure execution. Typically, there is a 1-to-1 ratio of code to the enclave in which it runs. However, in the cloud, cryptographic backends can be instanced dynamically and may or may not get the same hardware enclave.

In some examples, site resources are grouped and categorized based on their capabilities. For example, there may be VSM enclaves and hardware enclaves that may gain different improvements in performance or memory over time. Cryptographic backends can be configured to request any enclave or a specific type of enclave, and potentially a higher performing hardware enclave at run time.

In some examples, enclaves are secure execution environments where code can be executed in a private, isolated environment and the results of secure execution can be certified to have been executed without alterations and in private. This means that secret information, such as private keys, can be created and used within an enclave to sign transactions and prove to third parties that it was executed within an enclave.

In some examples, to provision the crypto backends at scale, the crypto backend fabric 460 bundles the enclaves upon receiving an enclave bundle request. In some examples, other types of cryptographic resources may also be bundled. In some examples, a cryptographic resource pool acts as a resource where, upon receiving a request for cryptographic resources for a cryptographic backend, the cryptographic backplane fabric 460 may extract a cryptographic resource from a cryptographic resource pool and allocate it. to a cryptographic backend at runtime based on the requirements of that cryptographic backend.

For example, you can set the policy that all cryptographic backends running a smart contract between counterparties A and B always require an Intel SGX V2 enclave. Alternatively, the enclave requirement can be left unspecified, so that the least cost enclave (eg, in terms of money, time, already active, etc.) is provided.

In some examples, the enclaves between the cryptographic resources 470 are registered within the set of enclaves. In some examples, an enclave group shared signature is generated for the enclave group, where the enclave group shared signature is derived from the private key of each enclave in the enclave group. In some examples, pool management uses just-in-time (JIT) enclave case enunciation to use them when they are active, but returns them to the pool as soon as the job is done. In some examples, a cryptographic helpmate that has an asynchronous lifetime and will not complete its work, may release its enclave at a checkpoint and relist a case in a different enclave. In some examples, changing enclaves produces different certifications that can be validated by the shared signature of the enclave group.

In some examples, when a set of enclaves registers with the cryptographic backend fabric 460, each enclave public key is recorded in the enclave group registry. In some examples, features are recorded at record time and can be modified for group categories that are not inferred from the hardware. In some examples, once all the enclaves have been registered, the keys of all the enclaves are used to generate a key pair for the group that is stored in the key repository 465 . At runtime, the Cryptographic Backend Container Service can determine the runtime environment dependencies of the Cryptographic backends based on its registry or policy and request an enclave outside of the enclave pool. The enclave group may activate an enclave and return its address to the cryptographic backend container service, which may then inject the appropriate cryptographic backend container. In some examples, the Cryptographic Backchild Container is provided with the Cryptographic Helper ID and an active binding, which the Cryptographic Backhand Container uses to extract the Cryptographic Backend binary from secure storage and run a signature verification of hash code in the cryptographic backend, which may be part of the composite identifier of the cryptographic backend. In some examples, the crypto backend container then extracts any keys requested by the crypto backend from the key repository 465 and passes them along with the active crypto back-end binding to the crypto back-end constructor to state their case within the enclave. . In some examples, the cryptographic backend code is executed in the enclave and the payload is digitally signed with the enclave's private key.

Once a crypto feeder has finished with its synchronous work, it can call its checkpoint method which can pass any new keys generated during its session to the crypto feeder container to persist in the key repository, 465 thus like I release the enclave of the cryptographic backend program back to the group. Returning the enclave then makes the enclave available again for use by another cryptographic backend.

In some examples, if a cryptographic helper requires an enclave, or other cryptographic resource, that is not and will not be available within a defined call window, an error is logged, and an exception is thrown.

New enclaves can be added to the enclave group, which will generate a new shared signature for the group. In some examples, a shared signature is used when the lifetime of a cryptographic backplane spans multiple enclaves and certification continuity needs to be established. In some examples, the shared signature is historical, so if a cryptographic backplane is certified in multiple enclaves, the shared signature is checked, and if the current signature does not match, the previous version of the signature is checked, up to that a match is found. In these examples, if no match is found, the certification chain is invalid.

Thus, in these examples, a malicious enclave cannot lead to a validated transaction. In these examples, if a malicious enclave contributes to a transaction, the signature of the shared enclave will fail, and the certification chain would be invalid.

In some examples, the crypto backend container service has a blockchain router that provides the abstraction API for data operations against blockchains. Each different type of blockchain may have a blockchain message provider or connector that plugs into the blockchain router to format messages appropriately for each blockchain. In some examples, the Blockchain Connectors have a valid address on each of the Blockchains that the Blockchain Connector serves and signs transactions with the key for this address. In some examples, blockchain connectors run within an enclave for transaction signing purposes.

The Blockchain Router relies on binding cryptographic backends to route messages to the appropriate Blockchain Connector. The blockchain connector uses the cryptographic backend binding information to format messages correctly and ensure delivery to the intended recipient.

In some examples, the crypto backend binding is a data structure that provides the abstraction between the crypto backend and the underlying blockchain, smart contracts, and accounts. The cryptographic backend binding may or may not itself be secured, as it may only contain bound component identifier(s) (eg, unique identifiers) that are used by authorized parties to look up details of other services. In some examples, used in message routing, the binding provides its own cryptographic backer ID and smart contract ID. In some examples, the smart contract address is looked up and linked to a specific blockchain ID that maps a node address.

Data may be wrapped in multiple layers of digital attestations (for example, signatures) signed by the data producer or "on behalf of" a user or IOT device, the cryptographic backend, its host enclave, and then the Blockchain Connector. This layering of signatures can be understood as being made in the manner of onion layers.

The cryptodelegate, which is a part of the cryptographic backend fabric 460 in some examples, can provide an optimization point for verifying these layered signatures before they are validated by all nodes, thereby reducing verification. of redundant signatures, rejects invalid certification chains and/or frees up computing resources.

Key repository 465 may provide secure persistent storage of keys used by cryptographic backends for identity services, digital signatures, and encryption. Cryptographic backend wrappers can provide abstractions for cryptographic backends to store and extract keys at run time. In some examples, a secure communication channel, called a crypto backend tunnel, is established between the key repository 465 and the enclave hosting the crypto back-end container. In some examples, the cryptographic backend container automatically provides on-demand storage and retrieval of private keys and secret information used by the hosted cryptographic backends.

For example, in some examples, when creating the instance of a crypto-helper inside its crypto-back-to-body container host, if its identity is established by a key pair in the key repository, the crypto-back-to-body container will extract in a secure manner and will provide the key pair to the crypto-backdropper upon enunciation by cases. Or, if the crypto backend creates its own or a new key pair, the crypto back-end container can automatically store these new keys when the crypto back-end is deactivated. In some examples, the cryptographic backend can use the private key to sign transactions and send messages. An example of an assigned key is a cryptographic backend that signs transactions as a specific counterparty, corporation, user, or device/or in a smart contract with the counterparty's private key.

In some examples, cryptographic helpers may request keys or secret information from their container for other cryptographic services such as encryption, decryption, and message signing. In some examples, the Cryptographic Backend Container looks up and locates the keys used by the Cryptographic Backends, either for identity or other cryptographic purposes, using resolving Cryptographic Backend Binding or in a Cryptographic Backend Case ID. cryptographic backend or in a counterparty Id, and requesting or storing via the cryptographic backend tunnel to the key repository 465 . In some examples, a graph of cryptographic backend binding keys for recording key locations to resolve and allocate keys for a different counterparty in an unbundled case of key repository 465 that can be controlled by that counterparty. Derivation of keys for multiple cryptographic backend identities from a single counterparty may provide multiple concurrency cases to be distinguished. In addition, in example scenarios for one-time key derivation scenarios, where the key repository 465 issues or a cryptographic backend creates a derived key for cryptographic backend signing, when signing is performed, the derived key it is destroyed, since it was only in the memory of the enclave. Key lifecycle services, such as key expiration and key reset, can be provided as utilities.

In some examples, developers can build their smart contracts using objects against their logic and simply persist their object state in the blockchain ledger without having to write a smart contract schema. In some examples, the reverse is also true, and an object model can be designed and mapped from an existing smart contract schema. This environment can provide blockchain portability and ease of development for blockchain solutions. In some examples, the crypto delegate is a set of capabilities that are provisioned differently based on the underlying blockchain or ledger. In some examples, the cryptodelegate is part of the cryptographic backend fabric 460. In some examples, the crypto-delegate functions, in essence, as a client-side or node-side integration for the cryptographic backend fabric 460. Among other things, the crypto-delegate can perform certification checks on messages prior to delivery to the underlying node platform, for example, blocking invalid transactions before they propagate through the blockchain network 450 .

As discussed above, when a settlement group is formed, the settlements in the group can register with the settlement group. In some examples, when the enclaves are so registered with the cryptographic backend fabric 460, the cryptographic backend fabric 460 may receive each enclave public key, and each enclave public key may be recorded in the enclave group registry. In addition, as part of the process that occurs when an enclave group is formed, the cryptographic backbone fabric 460 may derive an enclave group shared key from the public key of each enclave in the enclave group. The cryptographic backend fabric 460 may generate a new enclave group shared key if the enclave group membership changes.

A cryptographic backend container may request an enclave from an associated enclave group in response to a need. The request may specify a particular size or type of enclave. For example, some types of enclaves are more secure than others, and may be associated with a higher cost, so an enclave having a particular level of security may be requested according to the particular request. When the request is made, the cryptographic backend fabric 460 may extract a suitable enclave from the enclave pool and assign it to the cryptographic backend container based on the particular request. A cryptographic backend container may also request other types of cryptographic resources from associated cryptographic resource groups in response to a need, such as FPGAs configured to carry particular cryptographic resources, composite cryptographic resources, and/or the like. When the request for crypto resources is made, the crypto back-end fabric 460 may extract the appropriate crypto resources from the corresponding crypto resource pools and allocate them to the crypto back-end container based on the particular request.

The cryptographic backend program code to be executed can then be executed, using the allocated cryptographic resources as necessary. As part of the execution of the cryptographic backbone program code, the cryptographic backbone program code may generate a payload in the host enclave. The host enclave payload can then be signed and/or encrypted by the private key of the cryptographic backend, as well as digitally signed by the private enclave key of the host enclave. The cryptographic resources can then be deallocated from the first cryptographic helper, so that the cryptographic helper is no longer running on the cryptographic resources and the cryptographic resources are available to other cryptographic helpers. The payload can be certified out of band from the blockchain, for example, with the public key of the cryptographic backbone and the public key of the enclave.

In some cases, the cryptographic backend program code may also run in another enclave. For example, in some examples, as discussed above, group management may use just-in-time (JIT) case enunciation of enclaves, but return them to the group once the work is done. In some examples, a cryptographic helpmate that has an asynchronous lifetime and will not complete its work can deallocate its enclave at a checkpoint.

Accordingly, the crypto background fabric 460 can extract a different suitable enclave from the enclave pool, and the crypto background program can re-state an instance in the new one. enclave. The cryptographic backend can then continue to run on the other host enclave (eg, the new enclave). The payload of the other host enclave may be digitally signed by the private enclave key of the other host enclave. The other host enclave can be deallocated so that the cryptographic backend no longer runs in the enclave and the other host enclave is available to other cryptographic backends.

In some examples, the cryptographic backend may be executed by still more enclaves, such as at least a third enclave, in a manner similar to that described above for the second enclave.

Because the crypto background program in this example runs in more than one enclave, the output of the crypto background program code can contain two or more digital signatures, each originating from the private key of different enclaves. of the enclave group, plus a digital signature originating from the private cryptographic backbone program key, as well as possibly other digital signatures as part of the signature onion. In some examples, digital signatures originating from an enclave key of an enclave belonging to the enclave group can be validated by comparing it to the shared enclave group key. In some examples, verification of digital signatures may be performed by the cryptographic backend fabric.

In some examples, the cryptographic handset code is packaged as a cryptographic handset having its own identity, which is a composite of multiple components. In some examples, the cryptographic backend identity is the combination of the compiled cryptographic backend binary hash, the public key of the cryptographic backend, and the binding identifier.

In some examples, the cryptographic backend identity that is composed of these three components allows a single binary to be compiled and reused in many instances of that type of contract.

For example, for a crypto backend binary financial contract that is an interest rate swap, in one example, the exchange crypto back-end would have a public key hash that would uniquely represent that crypto back-end binary in the fabric. . In this example, when a new interest rate swap is created, an instance of that contract represented by a binding Id is created. In some examples, the peg represents the properties/rules of the exchange case, such as the identities of the counterparties, where the crypto backend obtains the interest rate price and how often it occurs, and/or or similar.

Thus, there can be numerous instances of an interest rate swap with a single binary cryptographic backend executing each of these contracts. The unique case is the composite cryptographic backend identity that represents the contract in this example.

Consequently, in some examples, the combination of three components, (1) binary hash, (2) cryptographic backbone public key, and (3) binding id, is the instance identifier which is then represented as a hash digest. for contract that is written to the ledger of the blockchain that represents the version of the logic that controls the smart contract. This cryptographic backer identity can be used regardless of whether or not the enclave pool is used and whether or not the shared key is used. In some examples, a cryptographic backbone instance consists of the three components (1) binary hash, (2) cryptographic backbone public key, and (3) binding id, where a general cryptographic backbone that has not been enunciated in instance consists of two components: (1) binary hash and (2) crypto backend public key, and where an utterance per instance of that crypto back-end would then add the binding id of that instance of the crypto back-end to generate the identity Cryptographic Backgrounder for that instance of the Cryptographic Backgrounder.

Cryptographic backends may be installed and registered in the cryptographic backend fabric 460. During the process of installing a crypto backend on fabric 460, the crypto back-end fabric 460 extracts the crypto back-end binary for the crypto back-end being installed, and generates a hash of the crypto back-end binary. The crypto backbone fabric 460 may also request the key repository 465 to create a key chain that may include, among other things, a key pair for the crypto back-end program, where the key pair includes a program private key. crypto backend and the crypto back-end public key, and request that the crypto back-end public key be sent to the crypto back-end fabric 460. The crypto-backdrop fabric 460 may receive the public key and create a crypto-back-drop identity for the crypto-back-drop, where the crypto-back-drop identity consists of two components (1) the hash of the binary and (2) the key public of cryptographic backend, because the cryptographic backend is not stated in case. The crypto feeder fabric 460 may register the crypto feeder with the crypto feeder identity in a crypto feeder record in the crypto feeder fabric 460, where the crypto feeder identity Cryptographic helper is stored as an entry in the Cryptographic helper registry as part of registration time. In some examples, the cryptographic backend registry may act as a sort of catalog from which cryptographic backends can be selected.

In some examples, when a request is made for a particular crypto backend, and the crypto back-end has yet to be enunciated in case, the crypto back-end fabric 460 intercepts the request. If the cryptographic backend needed to run in a cryptographic backend, then regardless of whether or not enclave pooling is used, the fabric 460

The cryptographic backend can then identify an enclave that will be used to run the cryptographic backend. The crypto backend fabric 460 may send a crypto back-end container to the enclave to be executed in the enclave, and the crypto back-end container may extract the crypto back-end key pair for the crypto back-end. In some examples, as discussed above, this is accomplished by a

secure channel between key repository 465 and cryptographic back-end container running

in the enclave. The crypto backend fabric 460 may also send the crypto back-end binary to the enclave, and the crypto back-end can start executing on the enclave.

The crypto backend fabric 460 may then generate the crypto back-end binding for the crypto back-end, and the binding identification, associated with it.

the binding of the cryptographic background programs, for the cryptographic background program. The cryptographic back-end running on the enclave may generate a payload that may be digitally signed by at least the private enclave key of the host enclave, and signed or encrypted by the enclave.

private key of cryptographic backbone. In some examples, the cryptographic backend fabric 460 receives the payload.

The crypto backend fabric 460 may also generate the crypto back-end identity, as a combination of the binary hash, the crypto back-end public key, and the crypto backend Id.

of linkage. The cryptographic backend fabric 460 can then generate a hash digest

of the crypto feeder identity, and cause the hash digest of the crypto feeder identity to be provided/communicated to the ledger of the blockchain in the network

450 of the blockchain, where the hash digest can be written to the blockchain ledger that represents the version of the logic that controls the smart contract.

A check may be performed periodically to make sure that the version of the cryptographic backend identity is correct, that the signature is correct, and the like. In some examples, it proceeds to ensure that the cryptographic backend is not changed unless all parties agree to the change. In some examples, if all parties agree to a change to a smart contract, the crypto feeder identity changes accordingly to an updated version. In some examples, the version of the cryptographic helper can be checked to ensure that the case of the cryptographic helper has not been modified in a way that has not been agreed upon by all parties.

parts. In these examples, if the cryptographic backend instance is changed without all parties agreeing to the change, the cryptographic backend instance will no longer function.

In some examples, a crypto backbone smart contract includes a contract crypto back-end, the crypto back-bin binding of the contract crypto back-end, and a smart contract instance stored in a ledger, where the ledger instance smart contract backend is also indicated in the contract crypto backend binding of the contract crypto backend. The case of the smart contract ledger is

can be stored on a blockchain, such as the 450 blockchain network, or, instead of being stored

in a blockchain, it can be stored in another data store. In some examples, the case of the smart contract major li has a uniquely identified public address such as "0x9f37b1e1d82ebc0a163cd45f9fa5b384ea7313e8". The smart contract ledger case may include the contract status as well as other relevant information about the contract, as well as the digital signatures of the identities of the contract counterparties. The smart contract ledger case can include various information about the life of the contract, including information such as payments made, and information such as whether the contract is active, complete, awaiting counterparty signatures, or terminated.

In some examples, a smart contract ledger case is generated in part from a schema.

In some examples, a schema is a smart contract ledger template, which is used to generate a smart contract ledger case along with basic information about the contract that needs to be completed.

in order to generate the smart contract ledger case from the template, which may include, for example, the initial seed properties for the smart contract. For example, for an example smart contract that is a loan agreement, the initial seed properties may include, for example, who is the lender, how much money is to be loaned, and/or the like. Subsequent terms of the contract may determined through subsequent contract negotiation, as discussed in more detail below. In some examples, even though the smart contract ledger case includes the state of the smart contract, plus digital signatures and other relevant data related to the smart contract, it will not imply the entire smart contract by not including the smart contract logic. The smart contract logic may be carried out by a contract crypto feeder for which the contract crypto feeder binding of the contract crypto feeder includes a binding that is a unique address mapping of the corresponding smart contract ledger instance . In some examples, cryptographic backend binding also includes mapping a set of contract counterparts represented as public keys that may be bound to other identity systems. These counterparties may represent two or more people, companies, IoT devices, other smart contracts, and/or the like. The cryptographic backend binding may also include external sources. For example, external sources may include one or more cryptographic utility plugins that provide external data that a contract needs for its logic, such as an interest rate or market price, to calculate a payment or fee. A utility cryptographic plugin can be used to present, for example, particular market data, and to certify the value of the presented market data. The cryptographic backend binding may include data, from external sources, that is to be received, as well as, for example, the frequency with which the external information is to be received.

A cryptographic backend fabric 460, with a contract cryptographic backend installed, may receive a message, for example, from the counterpart device 416 and/or 417, to perform a new smart contract.

In some examples, the contracting cryptographic backend may require an enclave. If so, the following may occur in some examples. The cryptographic backend fabric 460 identifies an enclave to be used to execute the contract cryptographic backend. The crypto backend fabric 460 sends a crypto back-end container to the enclave to be executed in the enclave, and the crypto back-end container can extract the crypto back-end key pair for the crypto back-end. This can be accomplished by a secure channel between key repository 465 and the cryptographic backend container running on the enclave. The crypto backend fabric 460 may also send the crypto back-end binary for the contract crypto back-end to the enclave, and the contract crypto back-end can start executing on the enclave.

In other examples, the contract crypto backend does not need an enclave, or it may need an enclave at a later time, but not for initial execution of the contract crypto back-end. For example, it is possible that the contract cryptographic backend needs to run in an enclave during certain time slices and not others, the time slices during which the cryptographic backend needs to run in an enclave may not include the initial execution of the program contract cryptographic backbone, for example. In this case, the cryptographic backend fabric 460 causes the contract cryptographic backend to start executing. At any rate, at this point, in some instances, the contract cryptographic backend begins to run, whether or not it is done in an enclave.

After the contract crypto feeder begins to execute, the contract crypto feeder may make a request for information, such as a request for the initial seed properties of the contract. The cryptographic backend fabric 460 may receive the request and may send a request to the counterparties (eg, via the counterparty 416 and/or 417) for the information requested by the contract cryptographic backend. Then, the cryptographic backend fabric 460 can receive the response to the request. The cryptographic backend fabric 460 can then extract a schema associated with the requested contract. In some examples, the cryptographic backend fabric 460 may already have a stored copy of the schema in the cryptographic backend fabric 460; in other examples, the cryptographic backend fabric 460 requests and receives a

Based on the information received from the request response and the schema, the cryptographic backbone fabric 460 may create a smart contract and then cause a smart contract instance to be used in a ledger. In some examples, the ledger is a blockchain network 450 ledger. In other examples, the ledger is a data warehouse ledger that is not part of a blockchain. After the smart contract ledger is used, the cryptographic backend fabric 460 may receive the unique address of the smart contract ledger, where the address acts as the unique ID of the smart contract ledger instance.

The crypto backend fabric 460 may also generate the crypto back-end binding, which includes bindings for the contract crypto back-end. In some Examples, each of these bindings is a mapping between the contract cryptographic backend and another cryptographic backend, a smart contract, or an identification of a smart contract counterparty. Bindings can be used to route messages between the crypto backend and the other crypto back-end or smart contract, to which the binding maps to the crypto back-end. The cryptographic backend binding may represent the properties and/or rules of the cryptographic backend. For example, in an example of a crypto feeder being an interest rate exchange, the binding of the crypto feed may include the identities (public key) of the interest rate exchange counterparties, where the crypto feed obtains the interest rate pricing and how often the cryptographic back-end gets the interest rate pricing.

The cryptographic backbone binding may include a binding that is a mapping between the contract cryptographic backbone and the unique address of the smart contract ledger instance, which serves as the unique identification of the smart contract ledger instance. The cryptographic backbone program binding may also include a binding for each counterparty that is represented as a public key. The binding of the crypto backend may include a mapping to external data sources, such as a mapping to a utility crypto backend that provides and certifies market data needed by the smart contract crypto backend logic.

The crypto backend fabric 460 may then communicate the binding of the crypto back-end to the contract crypto back-end.

The cryptographic backend fabric 460 may communicate with the smart contract ledger instance to update the smart contract ledger instance when appropriate, such as when there is a change of state, or the like. The crypto backend fabric 460 may also state resource instances to the contract crypto back-end and route messages through the system. The contract cryptographic backend can control the contract negotiation process, and the terms are updated as they are agreed upon during negotiation. Communication for trading may occur, for example, between the crypto contract and one or more counterpart devices (eg, 416 and/or 417) via the crypto backend fabric 460. In some examples, the smart contract ends once all parties digitally sign the smart contract. In some examples, contract binding is complete once all parties have digitally signed the smart contract, and the contract cryptographic backend begins executing the actual contract logic.

In some examples, after the smart contract has been completed, the contract cryptographic backbone instance no longer exists, but the smart contract ledger instance still exists, and the ledger may be reviewed by an authorized party for Obtain historical information about the contract. In some examples, the contract cryptographic backend does not persistently store its state or any other aspect of the contract; rather, the contract crypto backend uses the ledger instance of the smart contract to store the state of the contract crypto back-end and other smart contract data.

As a non-limiting example, an overview of a process employing the use of a cryptographic backend smart contract may include:

1. A request for a new contract that is made to the crypto backbone fabric, which in some cases is made to a contract crypto backend that is running on standby or newly announced in case by the fabric to handle the request for Begin the contract creation process.

2. The contract cryptographic backend takes the new contract request, which includes the initial seed information required to start the contract, which can be as much or as little information as is needed for that contract, such as, for example, name of the contract. contract, description, first counterparty (for example, the lender), etc.) [s/c.] The contract crypto-backdropper may validate this request and generate a contract constructor message that is sent to the crypto-backdrop fabric . This message may be signed with at least the cryptographic backend and its enclave signatures. This message may also be signed with the signature of the first counterparty. This message may also include the public address(es) in the message to the contract cryptographic backend and/or any/any counterparty(s) in the constructor message.

3. The cryptographic backend fabric can validate this request, determine the destination blockchain type, format a specific blockchain transaction, and route this message to the appropriate blockchain. In this example, the transaction flows from the cryptographic backbone fabric, perhaps running in a public or private cloud, to a blockchain node that can run anywhere.

4. The blockchain node may validate this message, which in some cases may first be validated by the crypto-delegate that validates the outer layers of the signature onion, for example, to ensure that this transaction message originates from the valid and secure source(s), using the cryptographic backend signatures and the enclave. The message can then be sent to the blockchain node for execution. In some cases, a crypto-delegate is not available, and only the blockchain-specific signature is verified before the message is sent to the node for execution.

5. The blockchain node, upon receiving this request for a new contract via a constructor message, can execute the code that creates the smart contract instance using the schema defined in the constructor and embedded address(es) public contract(s) held by the crypto backbone and any/any counterparty(s) in the appropriate places within the schema, for example, to ensure that only the contract crypto backplane can update this contract instance, and sets any/ any counterparty(s) in their roles under this contract. This smart contract is given a unique identifier, typically a public key, which serves as an address to which future interaction messages on that blockchain can be sent. This address may be returned from the constructor message and passed back to the cryptographic backend fabric from the node.

6. The Cryptographic Backend Fabric can receive this address and create a Base Contract Cryptographic Backend Binding. In some examples, the binding includes references to the contract cryptographic backend, the smart contract instance address, and any counterparty(s) provided in the constructor message.

7. The crypto backend fabric can then provide this binding to the contracting crypto back-end to activate with a new composite identifier, eg, its binary hash, public address and binding identifier. This contract cryptographic backbone may now be required to service only the binding it is associated with, and will only be allowed to work with secret information, private keys, for those entities listed in its binding.

8. In some cases, this binding ID is then passed back to the sender of the original new contract request, eg a user application or perhaps another system. Additional messages sent to the Cryptographic Backend Fabric that reference this Bind ID should be routed to the Contract Cryptographic Backend bound with that ID. In some cases, these additional messages include additional contract details that are being or will be added, such as the loan term, the amount borrowed, and the counterparty agreement (for example, to the contract terms). Each of these messages can be handled by the contract cryptographic backend, validated, signed, and supplied as status to the address of the underlying smart contract.

9. In some cases, external data is required for a contract to work, such as a variable interest rate that can change from month to month. In these cases, a cryptographic backend fabric may add a utility cryptographic backend to the contract binding. In some examples, this part of the external data provider binding includes the identification of the cryptographic utility backend providing this data, the requirements to receive this external data as an event: time-based, threshold-based, or ad hoc/a order of the contract cryptographic backbone. In some cases, these external data update rules are written into the contract and agreed upon by all counterparties as data related to the source and circumstances for updates to be accepted. For example, a rule might define interest rates to be determined on the 5th day of each month at 4:00 p.m. using the 5-year treasury rate 10 basis points from a source named “rate source”. of interest" and with a given public key. Once agreed, this external data source can be added to the cryptographic backend binding of the contract cryptographic backend, and a binding for the cryptographic utility backend can be created and sent to the cryptographic utility backend. The utility cryptographic backend can use its binding rules to trigger data updates to be sent to the contract cryptographic backend. Any data updates may be signed by the cryptographic utility backend and its host enclave, eg, for validation. External data updates provided by the cryptographic utility backends to the contract cryptographic backends can be persisted in the smart contract address with the signatures of the cryptographic utility backends along with the results of the cryptographic backend computations of contract with signatures, to, for example, provide proofs and certifications of validity of the data.

10. Once a crypto feeder binding has a smart contract ledger address, the counterparty's signatures and optional external data source(s) defined by it become fully operational, and they can normally be executed independently during the entire contract term, interacting, for example, through messages relevant to their binding. Such messages may be associated with payments, receipts, notifications, etc.

Figure 5 is a block diagram illustrating an example of system 500, which may be used as a subset of system 400 of Figure 4. System 500 may include cryptographic backend program container 535, program container service 561 cryptographic subordinate, test engine service 562, key repository 565, test delegate 571, and cryptographic resource groups 579. The cryptographic backend container service 561 and the test engine service 562 may each be a part of a cryptographic backend fabric, such as the cryptographic backend fabric 460 of Figure 4. The program container 535 cryptographic backend may include cryptographic backend program 531.

Grouping cryptographic resources into cryptographic resource groups 579 may allow cryptographic resources to be provisioned on demand, eg, at runtime, based on the secure computing needs of running applications. Cryptographic backbones may have requirements for mathematically strong cryptographic functions performed on hardware configured to perform the mathematically strong cryptographic functions, and cryptographic resource pools may act as a means to allocate hardware configured to perform the mathematically strong cryptographic functions. Cryptographic resource groups 579 may include, for example, a group of enclaves, a group of FPGAs configured to perform an accelerated zero-knowledge proof function, one or more composite cryptographic resource groups, and/or the like. Each of the composite cryptographic resource sets may include a cryptographic resource type that includes one or more combined cryptographic resources configured to perform a cryptographic function. For example, an exemplary composite cryptographic resource group is a cryptographic resource group where each cryptographic resource in the group includes a graphics card, one or more FPGAs, and an enclave, combined in a bundle to together perform a particular cryptographic function.

The cryptographic backend container service 561 may create the cryptographic backend container 535 . The cryptographic helper container 535 can read metadata from the cryptographic helper 531, can determine the types, quality, and quantity of each cryptographic resource required by the cryptographic helper 531, and can send a request for the determined cryptographic resources. to test engine service 562. For example, a particular cryptographic backend program may require an enclave for digital signatures, and an FPGA for accelerated zero-knowledge proof.

The test engine service 562 can then extract the requested cryptographic resources from the cryptographic resource pools 579 . The test engine service 562 may then inject test generation code, if any, into the mined crypto resources, causing the mined crypto resources to become test delegates, such as test delegate 571 . As an example, an enclave may be required to perform an elliptic curve signature. In some of these examples, the code to perform an elliptical code signing is injected into the enclave by the test engine service 562. In some examples, the combination of the mined cryptographic resource and the test generation code is a test delegate. In some examples, the purpose of the test delegate is to perform a particular cryptographic function along with any necessary tests. The test engine service 562 may access a library that includes various types of test generation code, extract the necessary test generation code, and then inject the necessary test generation code into the cryptographic resource.

If secret information, such as keys, is required, the test engine service 562 may cause a secure tunnel to be started between the cryptographic backend 531 and an HSM, such as the key repository 565, so that the cryptographic backend 531 can receive the secret information through the secure tunnel. For example, a signing delegate may require that the private keys stored in the keystore be injected into the signing delegate. In some examples, for at least a first cryptographic resource of the extracted cryptographic resources, the test engine service 562 determines what secret information is required for the first cryptographic resource based on the type of the extracted cryptographic resource, and initiates a secure tunnel between an HSM (eg, key repository 567) and the first cryptographic resource for injecting the secret information into the first cryptographic resource. In some examples, for at least one second of the extracted cryptographic resources, the test engine service 562 determines what secret information is required for the second cryptographic resource, wherein the extracted secret information for the second cryptographic resource is different from the extracted secret information for the first cryptographic resource based on the second cryptographic resource, which is a different type of cryptographic resource than the first cryptographic resource.

The test engine service 562 may then send, to the cryptographic backbone container 535, the requested test delegates, such as test delegate 571. The cryptographic backend code can then be executed, and the test delegates will allow the cryptographic functions required by the cryptographic backend code of the cryptographic backend 531 to be performed, along with any necessary tests.

illustrative processes

For clarity, the processes described in this document are described in terms of operations performed in particular sequences by particular devices or components of a system. However, it is noted that other processes are not limited to the indicated sequences, devices or components. For example, certain acts may be performed in different sequences, in parallel, omitted, or may be supplemented by additional acts or features, whether or not such sequences, parallels, acts, or features are described herein. In addition, any of the technologies described in this disclosure may be incorporated into the described processes or into other processes, whether or not that technology is specifically described in conjunction with a process. The disclosed processes may also be performed on or by other devices, components, or systems, whether or not such devices, components, or systems are described herein. These processes can also be carried out in various ways. For example, they may be embodied in an article of manufacture, eg, as processor-readable instructions stored on a processor-readable storage medium, or performed as a computer-implemented process. As an alternate example, these processes may be encoded as processor-executable instructions and transmitted via a communication medium.

Figure 6 is a diagram illustrating a data flow for a system 600 that can be used as an example of the system 500 of Figure 5. In some examples, system 600 includes test engine service 662, service 661 Cryptographic Backend Container (CCS), the Cryptographic Backend Container 635, and the HSM 665.

In the illustrated example, first, step 681 is taken. In step 681, in some examples, the CCS 661 receives a request to generate a cryptographic backend instance. As shown, step 682 is given in some examples below. In step 682, in some examples, the CCS 661 creates a cryptographic helper container 635 for the requested cryptographic helper. As shown, step 683 is given in some examples below. In step 683, in some examples, the CCS 651 provides, to the cryptographic backend container 635, the cryptographic backend ID and the binding for the requested cryptographic backend. As shown, step 684 is given in some examples below. In step 684, in some examples, the crypto-helper container 635 retrieves, from secure storage, the crypto-helper binary for the requested crypto-helper.

As shown, step 685 is given in some examples below. In step 685, in some examples, the cryptographic backend container 635 determines what the requirements of the cryptographic backends are based on the metadata in the code of the cryptographic backends. As shown, step 686 is given in some examples below. At step 686, in some examples, the cryptographic backend container 635 communicates a request to the proof engine service 662. In some examples, the request is a request for the test delegates needed by the cryptographic backend, as previously determined in step 685. In some examples, the request is sent with the binding ID for the cryptographic backend.

As shown, step 687 is given in some examples below. In step 687, in some examples, the test engine service 662 determines if the test engine service can fulfill the request with resources in its cryptographic resource pools. If not, in some examples, the test engine service 662 requests the cryptographic back-end container 635 for more time to fulfill the request, and remains at step 687. If, instead, the determination in step 687 is positive , in some examples, the process continues at step 688.

In step 688, in some examples, the test engine service 662 extracts the cryptographic resources corresponding to the requested test delegates from the corresponding cryptographic delegate groups. As shown, step 689 is given in some examples below. In step 689, in some examples, the test engine service 662 determines, for each of the extracted cryptographic delegates, what type of test generation code will be used for that cryptographic delegate. In some examples, there is a test generation code library that the test engine service 662 uses to select and extract the particular type of test generation code for each extracted cryptographic delegate based on the extracted cryptographic delegate type.

As shown, step 690 is given in some examples below. In step 690, in some examples, for each of the mined cryptographic resources, the test engine service 662 injects the given type of test generation code for the cryptographic resource. In some examples, once the test engine code has been injected into a crypto resource, the crypto resource is already a test delegate. As shown, step 691 is given in some examples below. In step 691, in some examples, the test engine service 662 determines whether or not secret information (eg, keys) is to be used for the test delegates, based on the type of cryptographic resource of each test delegate. proof. Otherwise, in some examples, the process proceeds to step 695. Otherwise, in some examples, the process proceeds to step 692. At step 692, in some examples, the test engine service 662 communicates to the HSM 665 a request to send secret information from the HSM 665 to the test delegates through a secure tunnel.

As shown, step 693 is given in some examples below. In step 693, in some examples, the HSM 665 retrieves the requested secret information. As shown, step 694 is given in some examples below. In step 694, in some examples, the HSM 665 supplies the requested secret information to the test delegates specified by the test engine service via a secure tunnel between the HSM 665 at the specified test delegate. As shown, step 695 is given in some examples below. In step 695, in some examples, the test engine service 662 sends the requested test delegates to the cryptographic backend container 635 . As shown, step 696 is given in some examples below. In step 696, in some examples, the cryptographic backend wrapper 635 causes the cryptographic backend code to execute, and the cryptographic backend code, while executing, requests the cryptographic function(s) that provides the test delegate(s).

As shown, step 697 is given in some examples below. In step 697, in some examples, the crypto backend container 635 handles the payload generated by the crypto back-end code during the execution of the crypto back-end code, and communicates the payload to the CCS 661. As shown , step 698 is given in some examples below. In step 698, in some examples, the cryptographic backend container 661 causes the test delegates to send new secret information to be persistent to the HSM 665 via a secure tunnel. As shown, step 699 is given in some examples below. In step 699, in some examples, the crypto container 635 releases the crypto resource(s) to their respective crypto resource pools.

Figure 7 is a flowchart illustrating an example process (780) for secure transactions and confidential logic execution, which may be performed by a Test Engine Service, such as the Test Engine Service of Figure 5. and/or figure 6.

In the illustrated example, step 786 is given first. At step 786, in some examples, a request for cryptographic resources is received. In some examples, the request for cryptographic resources includes a binding identity (ID). As shown, step 788 is given in some examples below. In step 788, in some examples, cryptographic resources are retrieved from at least one cryptographic resource pool of a plurality of cryptographic resource pools in response to the cryptographic resource request. In some examples, the separate sets of cryptographic resources of the plurality of sets of cryptographic resources are sets of separate types of cryptographic resources.

As shown, step 789 is given in some examples below. In step 789, in some examples, it is determined which type of test generation code is suitable for each mined cryptographic resource. As shown, step 790 is given in some examples below. In step 790, in some examples, for each mined cryptographic resource, the given type of test generation code is injected into the mined cryptographic resource. The process can then proceed to the return block, where other processes are resumed.

Conclusion

While the detailed description above describes certain examples of the technology and describes the best mode envisioned, no matter how detailed the foregoing appears in the text, the technology can be practiced in many ways. Details may vary upon implementation, while still being covered by the technology described in this document. As stated above, particular terminology used when describing certain features or aspects of the technology should not be taken to imply that it is being redefined herein to be restricted to specific features, characteristics, or aspects with which that terminology is associated. In general, the terms used in the following claims should not be construed as limiting the technology to the specific examples disclosed herein, unless the detailed description explicitly defines such terms. Consequently, the actual scope of the technology encompasses not only the disclosed examples, but also all equivalent ways of practicing or implementing the technology.

Claims (15)

1. An apparatus, comprising: a device including at least one memory adapted to store runtime data for the device, and at least one processor that is adapted to execute processor-executable code that, in response to execution, allows the device to perform actions, which include: receiving (686;786) a request for cryptographic resources, wherein the request for cryptographic resources includes a binding identity (ID); extract (688;788) cryptographic resources from at least one cryptographic resource group of a plurality of cryptographic resource groups in response to the cryptographic resource request, where the disaggregated cryptographic resource groups of the plurality of cryptographic resource groups are groups of disaggregated types of cryptographic resources; determining (689; 789) what type of test generation code is suitable for each mined cryptographic resource; and for each extracted cryptographic resource, injecting (690;790) the determined type of test generation code into the extracted cryptographic resource. The apparatus of claim 1, further including: for each mined crypto resource: determining (691) whether secret information is required for the cryptographic resource; and if it is determined that secret information is required for the cryptographic resource: determining what secret information is required for the cryptographic resource based on the type of the extracted cryptographic resource; and initiate (698) a secure tunnel between a hardware security module and the cryptographic resource secret information in the cryptographic resource. The apparatus of claim 1, wherein one of the cryptographic resource sets of the plurality of cryptographic resource sets is an enclave set including a plurality of enclaves, and another of the cryptographic resource sets of the plurality of Cryptographic Resource Sets is a set of a type of cryptographic resources other than enclaves. The apparatus of claim 3, wherein said other set of cryptographic resources is a set of specialized field-programmable gate arrays for an accelerated zero-knowledge proof function. The apparatus of claim 1, wherein one of the cryptographic resource sets of the plurality of cryptographic resource sets is a composite cryptographic resource set, and wherein each cryptographic resource of the composite cryptographic resource set is a composite cryptographic resource that includes a bundle of cryptographic resources configured to work together when performing a cryptographic function. The apparatus of claim 5, wherein the cryptographic resource bundle includes at least one enclave and at least one field-programmable gate array. 7. A method, comprising: extracting (688; 788) cryptographic resources from at least one cryptographic resource group of a plurality of cryptographic resource groups, wherein the disaggregated cryptographic resource groups of the plurality of cryptographic resource groups are disaggregated type groups of cryptographic resources; inject test generation code into the mined cryptographic resources, where inject test generation code into the mined cryptographic resources includes: determining (689; 789) what type of test generation code is suitable for each mined cryptographic resource; and for each cryptographic resource extracted, inject (690; 790) the given type of test generation code in the mined crypto resource. The method of claim 7, wherein the method further comprises, for at least a first one of the extracted cryptographic resources: determining which secret information is to be used for the first cryptographic resource based on the type of the extracted cryptographic resource; and initiating (698) a secure tunnel between a hardware security module and the first cryptographic resource; injecting the secret information into the first cryptographic resource. The method of claim 8, further comprising: for at least one second cryptographic resource of the extracted cryptographic resources, determining which secret information is required for the second cryptographic resource, wherein the extracted secret information for the second cryptographic resource is different from the extracted secret information for the first cryptographic resource based on the second cryptographic resource, being a different type of cryptographic resource than the first cryptographic resource. The method of claim 9, wherein the first cryptographic resource is an enclave, and the second cryptographic resource is at least one of an array of field-programmable gates configured for a cryptographic function, a security-specific integrated circuit application configured for a cryptographic function, and a composite cryptographic resource that includes a bundle of cryptographic resources configured to work together in performing a cryptographic function. The method of claim 10, wherein the enclave is provided by at least one of a secure virtual machine and a secure hardware enclave. The apparatus of claim 1, further including: sending the extracted cryptographic resources to a cryptographic backend container after injecting the given type of test generation code. The apparatus of claim 3, wherein each enclave in the group of enclaves is provided by at least one of a secure virtual machine and a secure hardware enclave. The apparatus of claim 3, wherein the enclaves in the set of enclaves are secure, private, tamper-resistant execution environments, in which code can be executed securely from outside interference, and for which it can be certified that the results of the execution have flowed unaltered and in private. 15. An apparatus, comprising: a device including at least one memory adapted to store runtime data for the device, and at least one processor that is adapted to execute processor-executable code, which, in response to execution, allows the device to perform actions, including: extracting a cryptographic backend binary for a first cryptographic backend (531); determining which test delegates (571) are required by the first cryptographic backend, where a test delegate is a cryptographic resource into which test engine code has been injected; and wherein the test delegates (571) required by the first cryptographic backend program include at least a first test delegate and a second test delegate, where the first test delegate is an enclave, and where the second test delegate is is a type of test delegate other than an enclave; and send a request for the determined test delegates for a test engine service (562).