Guiding code transparency system

Abstract

The disclosed techniques are generally directed to code transparency. In one example of the technology, evidence associated with a policy is obtained. The evidence includes data including encrypted verifiable evidence associated with the initial source code according to the policy. The initial source code is source code for the CTS. An initial binary based on the initial source code is executed in the TEE for the CTS instance to begin an operation. The CTS instance is configured to register guarantee (s) associated with code approved by the CTS instance. The TEE is used to provide an account book. The evidence is stored on the account book. Measurement value (s) associated with the binary file are provided. A service key associated with the CTS instance is generated. TEE attestation of the measurement value (s), evidence, and service key is provided.

Description

Background Art

[0001] Blockchain systems have been proposed for various application scenarios, including applications in the financial industry, healthcare, the Internet of Things, 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. Bitcoin (e.g., electronic coins) is represented by a series of transactions that transfer ownership from one party to another. In order to transfer the ownership of Bitcoin, a new transaction can be generated and added to the transaction stack in the block. The new transaction including the public key of the new owner can be digitally signed by the owner with the owner's private key to transfer ownership to the new owner as represented by the new owner's public key.

[0002] When a block is filled, the block can be "capped" with a block header, which is a hash digest of all the transaction identifiers within the block. The block header can be recorded as the first transaction in the next block in the chain, creating a mathematical hierarchy known as a "blockchain." To verify the current owner, the blockchain of transactions can be followed to verify each transaction from the first to the last. The new owner only needs to have the private key that matches the public key of the transaction that transferred the bitcoins. The blockchain can create a mathematical proof of ownership in an entity represented by a secure identity (e.g., a public key), which is pseudo-anonymous in the case of the Bitcoin system.

[0003] Blockchain is a type of distributed ledger. A distributed ledger is a consensus record with a cryptographic audit trail that is typically maintained and verified by several individual nodes. Summary of the invention

[0004] This summary is provided to introduce some concepts in a simplified form, which are further described in the detailed description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0005] In short, the disclosed technology is generally directed to code transparency. In some examples, a first evidence associated with a first policy is obtained. In some examples, the first evidence includes data including cryptographically verifiable evidence associated with an initial source code according to the first policy. In some examples, the initial source code is source code for a code transparency service (CTS). In some examples, an initial binary file is provided based on the initial source code. In some examples, the initial binary file is executed in a first trusted execution environment (TEE) so that the first CTS instance begins operation. In some examples, the first CTS instance is configured to implement at least one guarantee associated with a code approved by the first CTS instance. In some examples, at least one guarantee is associated with code transparency. In some examples, the first TEE is used to provide a first account book. The first evidence is stored on the first account book. In some examples, at least one measurement value associated with the binary file is provided. In some examples, a first service key associated with the first CTS instance is generated. In some examples, the first service key is used by the first CTS instance for at least one encryption function. In some examples, a TEE certification of at least one measurement value, the first evidence, and the first service key is provided.

[0006] Other aspects and applications of the disclosed technology will be understood upon reading and understanding the accompanying drawings and descriptions. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Non-limiting and non-exhaustive examples of the present disclosure are described with reference to the following drawings. In the drawings, unless otherwise specified, similar reference numerals refer to similar parts throughout the various drawings. These drawings are not necessarily drawn to scale. In order to better understand the present disclosure, reference will be made to the following detailed description, which will be read in conjunction with the accompanying drawings, wherein:

[0008] Figure 1 is a block diagram illustrating one example of a suitable environment in which aspects of the present technology may be employed;

[0009] Figure 2 is a block diagram illustrating one example of a suitable computing device in accordance with various aspects of the disclosed technology;

[0010] Figure 3 is a block diagram illustrating an example of a network-connected system;

[0011] Figure 4 is a block diagram illustrating an example of a system for bootstrapping a CTS instance; and

[0012] Figure 5 is a flow chart illustrating an example process for bootstrapping a CTS instance in accordance with various aspects of the present disclosure. DETAILED DESCRIPTION

[0013] The following description provides a comprehensive understanding of various examples of the present technology and specific details for implementing the description. It will be understood by one skilled in the art that the present technology can be practiced without many of these details. In some instances, well-known structures and functions are not shown or described in detail to avoid unnecessarily obscuring the description of the examples of the present technology. It is intended that the terms used in this disclosure be interpreted in their most extensive and reasonable manner, even if it is used together with the detailed description of some examples of the present technology. Although some terms may be emphasized below, any term intended to be interpreted in any limited manner will be so publicly and clearly defined in this specific embodiment section. Throughout this specification and claims, unless otherwise indicated by the context, the following terms at least take the meanings clearly associated herein. The meanings identified below do not necessarily limit the term, but only provide illustrative examples for these terms. For example, each of the terms "based on" and "according to" is not exclusive and is equivalent to the term "based at least in part on", and includes options based on additional factors, some of which may not be described in this article. As another example, the term "via" is not exclusive and is equivalent to the term "at least partially via", and includes options as via additional factors, some of which may not be described herein. The meaning of "in..." includes "in..." and "on...". The phrases "in one embodiment" or "in one example" as used herein do not necessarily refer to the same embodiment or example, although it can. The use of specific textual numerical indicators does not mean the presence of numerical indicators of smaller values. For example, the specification "a widget selected from a group, the group consisting of a third foo and a fourth bar" itself does not mean that there are at least three foo elements, nor does it mean that there are at least four bar elements. References in the singular are only for clarity of reading and include plural references unless plural references are explicitly excluded. Unless otherwise explicitly indicated, the term "or" is an inclusive "or" operator. For example, the phrase "A or B" means "A, B or A and B". As used herein, the terms "component" and "system" are intended to cover various combinations of hardware, software, or hardware and software. Thus, for example, a system or component can be a process, a process executed on a computing device, a computing device, or a part thereof. The term "cloud" or "cloud computing" refers to a shared pool of configurable computer system resources and advanced services over a wide area network (usually the Internet). An "edge" device refers to a device that is not itself part of the cloud but acts as an entry point into the core network of an enterprise or service provider. The term "document" refers to a sequence of words, tokens, terms, attributes, or other suitable data units, where the sequence can be indexed and uniquely identified.

[0014] In short, the disclosed technology is generally directed to code transparency. In some examples, a first evidence associated with a first policy is obtained. In some examples, the first evidence includes data including cryptographically verifiable evidence associated with an initial source code according to the first policy. In some examples, the initial source code is source code for a code transparency service (CTS). In some examples, an initial binary file is provided based on the initial source code. In some examples, the initial binary file is executed in a first trusted execution environment (TEE) so that the first CTS instance starts operation. In some examples, the first CTS instance is configured to execute at least one guarantee associated with the code approved by the first CTS instance. In some examples, at least one guarantee is associated with code transparency. In some examples, the first TEE is used to provide a first account book. The first evidence is stored on the first account book. In some examples, at least one measurement value associated with the initial binary file is provided. In some examples, a first service key associated with the first CTS instance is generated. In some examples, the first service key is used by the first CTS instance for at least one encryption function. In some examples, a TEE certification of at least one measurement value, the first evidence, and the first service key is provided.

[0015] Confidential computing can protect the accessibility of data being processed so that the code and data being processed in the confidential computing environment cannot be accessed externally. Confidential computing can be used to prevent external tampering or observation of what is happening at the boundaries of confidential computing so that when confidential computing is used in the cloud, no third party, not even the cloud provider, can access the code and data being processed by confidential computing. A user may want to use code implemented by a third party (such as a cloud provider or other third party) as part of the code being processed within the confidential computing environment. However, this may create a risk that the integrity and confidentiality provided by confidential computing may be compromised by the third-party code without the user being aware of the confidentiality being compromised. For example, the third-party code may have a difficult-to-detect backdoor without the user knowing that the confidentiality has been compromised, which may leak information in the confidential computing environment.

[0016] CTS instances can be used to establish trust in code that will be used in a confidential computing environment. CTS can authorize code in such a way that code authorized by the CTS can be trusted. For example, a CTS instance can store cryptographically verifiable evidence that proves that the code authorized by the instance complies with one or more policies. In some examples, CTS can allow users to know exactly whether code in a confidential computing environment is likely to misbehave, such as misbehavior that violates the confidentiality of the confidential computing environment. In some examples, a CTS instance can provide a guarantee that the authorized code is auditable. The trust established in the code authorized by the CTS instance can enable users to use third-party code in a confidential computing environment without violating the confidentiality of the confidential computing environment.

[0017] In order for the CTS instance to correctly establish trust, in some examples, the CTS instance is booted in such a way that the CTS instance itself can be trusted, and any updates performed on the CTS instance are completed in such a way that the updated CTS instance can be trusted. In some examples, when the CTS is booted, cryptographically verifiable evidence of trust established in the initial source code for the CTS instance is generated. The cryptographically verifiable evidence can be evidence that the code used to operate the CTS instance complies with one or more policies. Different policies can be implemented in different examples. In some examples, one of the policies is an external archive of the initial source code performed by a trusted third-party service. In some examples, one of the policies is evidence that the construction of the CTS code is performed by a trusted third-party reproducible build service (RBS).

[0018] The initial binary file of the CTS instance can be executed in a trusted execution environment (TEE). The TEE can provide a ledger on which evidence can be stored. The ledger can be a blockchain, or it can be an appropriate distributed ledger outside the blockchain. The TEE can determine (multiple) measurements of the binary file. The TEE can generate a CTS service key used for cryptographic operations to be performed by the CTS instance. The TEE can also perform proofs, including the following proofs: (multiple) measurements, cryptographically verifiable evidence used to establish trust in the code for the CTS instance, and the CTS service key. The endorser can also endorse the CTS instance in some ways, for example, by endorsing the CTS service key via a signature. The CTS instance can add additional TEEs so that the ledger becomes a distributed ledger with multiple nodes, and the CTS instance becomes a distributed network. Then, the CTS instance can operate to accept code declarations for registration. In some examples, as discussed above, the code declaration is a declaration associated with third-party code to establish trust in the code.

[0019] The bootstrapping discussed above can allow trust to be established in a CTS instance, which then acts as a root of trust for confidential computing that will be performed on behalf of the user. The CTS instance can then authorize any third-party code used in the confidential computing environment so that the integrity and confidentiality of the confidential computing environment can be ensured despite any third-party code used in the confidential computing environment.

[0020] Equipment / Operating Environment Pictured

[0021] Figure 1 1 is a schematic diagram of an environment 100 in which aspects of the present technology may be practiced. As shown, the environment 100 includes a computing device 110 and network nodes 120 connected via a network 130. Although the specific components of the environment 100 are not limited to the examples in the examples in the examples, the environment 100 may be used in conjunction with the computing device 110. Figure 1 , but in other examples, environment 100 may also include additional and / or different components. For example, in some examples, environment 100 may also include a network storage device, a maintenance manager, and / or other appropriate components (not shown). Figure 1 The computing device 110 shown in FIG. 1 can be in various locations, including a local computer, an on-site computing device, a computing device in the cloud, etc. For example, the computer device 110 can be on the client side, on the server side, etc.

[0022] like Figure 1As shown in , the network 130 may include one or more network nodes 120, which interconnect multiple computing devices 110 and connect the computing devices 110 to an external network 140, such as the Internet or an intranet. For example, the network node 120 may include a switch, a router, a hub, a network controller or other network element. In some examples, the computing devices 110 may be organized into racks, action zones, groups, sets or other appropriate divisions. For example, in the example shown, the computing devices 110 are grouped into three host sets that are identified as first, second and third host sets 112a to 112c, respectively. In the example shown, each host set in the host set 112a to 112c is operably coupled to a corresponding network node 120a to 120c, which are generally referred to as "top of rack" or "TOR" network nodes. The TOR network nodes 120a to 120c may then be operably coupled to additional network nodes 120 to form a computer network in a hierarchical, flat, mesh, or other appropriate type of topology that allows communication between the computing device 110 and the external network 140. In other examples, multiple host sets 112a to 112c may share a single network node 120. The computing device 110 may be virtually any type of general-purpose or specific-purpose computing device. For example, these computing devices may be user devices, such as desktop computers, laptop computers, tablet computers, display devices, cameras, printers, or smart phones. 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. In addition, the computing device 110 may be configured individually to provide computing, storage, and / or other appropriate computing services.

[0023] In some examples, one or more of computing devices 110 are devices configured to boot at least part of the process of a code transparency service.

[0024] Computing equipment shown

[0025] Figure 2 2 is a schematic diagram illustrating one example of a computing device 200 in which various aspects of the present technology can be practiced. The computing device 200 can be virtually any type of general-purpose or special-purpose computing device. For example, the computing device 200 can be a user device, such as a desktop computer, a laptop computer, a tablet computer, a display device, a camera, a printer, or a smart phone. Similarly, the computing device 200 can also be a server device, such as an application server computer, a virtual computing host computer, or a file server computer. For example, the computing device 200 can be Figure 1Likewise, computing device 200 may be an example of any device within any of the distributed systems shown or referred to in any of the following figures, as discussed in more detail below. Figure 2 As shown in , computing device 200 may include processing circuit 210, operating memory 220, memory controller 230, bus 240, data storage memory 250, input interface 260, output interface 270, and network adapter 280. Each of these previously listed components of computing device 200 includes at least one hardware element.

[0026] The computing device 200 includes at least one processing circuit 210 configured to execute instructions, such as instructions for implementing the workloads, processes and / or techniques described herein. The processing circuit 210 may include a microprocessor, a microcontroller, a graphics processor, a coprocessor, a field programmable gate array, a programmable logic device, a signal processor and / or any other circuit suitable for processing data. The above instructions and other data (e.g., data sets, metadata, operating system instructions, etc.) can be stored in an operating memory 220 during the runtime of the computing device 200. The operating memory 220 may also include any of a variety of data storage devices / components, such as volatile memory, semi-volatile memory, random access memory, static memory, cache memory, buffer and / or other media used to store runtime information. In one example, when the computing device 200 is powered off, the operating memory 220 does not retain information. Instead, the computing device 200 may be configured to transfer instructions from a non-volatile data storage component (e.g., data storage component 250) to the operating memory 220 as part of a boot or other loading process. In some examples, other forms of execution may be employed, such as executing directly from data storage component 250, such as execute-in-place (XIP).

[0027] The operating memory 220 may include a fourth generation double data rate (DDR4) memory, a third generation double data rate (DDR3) memory, other dynamic random access memory (DRAM), a high bandwidth memory (HBM), a hybrid memory cube memory, a 3D stacked memory, a static random access memory (SRAM), a magnetoresistive random access memory (MRAM), a pseudo random access memory (PSRAM), and / or other memory, and such memory may include one or more memory circuits integrated in a DIMM, a SIMM, a SODIMM, a known good die (KGD), or other package. Such operating memory modules or devices may be organized according to channels, ranks, and libraries. For example, the operating memory device may be coupled to the processing circuit 210 via a memory controller 230 in a channel. An example of a computing device 200 may include one or two DIMMs per channel, each channel having one or two ranks. The operating memory within a rank may be operated using a shared clock, a shared address, and a command bus. In addition, the operating memory device may be organized into several libraries, where the library may be considered as an array addressed by rows and columns. Based on this organization of the operational memory, a physical address within the operational memory can be referred to by a tuple of channel, rank, bank, row, and column.

[0028] Notwithstanding the above discussion, the operational memory 220 expressly does not include or encompass communications media, any communications media, or any signals per se.

[0029] The memory controller 230 is configured to interface the processing circuit 210 to the operating memory 220. For example, the memory controller 230 may be configured to interface commands, addresses, and data between the operating memory 220 and the processing circuit 210. The memory controller 230 may also be configured to abstract certain aspects of memory management from or otherwise manage certain aspects of memory management for the processing circuit 210. Although the memory controller 230 is shown as a single memory controller separate from the processing circuit 210, in other examples, multiple memory controllers may be employed, the memory controller(s) may be integrated with the operating memory 220, etc. In addition, the memory controller(s) may be integrated into the processing circuit 210. These and other variations are possible.

[0030] In computing device 200, data storage memory 250, input interface 260, output interface 270, and network adapter 280 are interfaced to processing circuit 210 by bus 240. Figure 2The bus 240 is shown as a single passive bus, but other configurations, such as a collection of busses, a collection of point-to-point links, input / output controllers, bridges, other interface circuit devices and / or any collection thereof, may also be appropriately used to interface the data storage memory 250, input interface 260, output interface 270 and / or network adapter 280 to the processing circuit 210.

[0031] 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 memory, disks, disk drives, hard disk drives, solid-state drives, and / or any other medium that may be used for non-volatile storage of information. However, data storage memory 250 explicitly does not include or encompass communication media, any communication media, or any signal itself. In contrast to operating memory 220, data storage memory 250 is used by computing device 200 for non-volatile long-term data storage, rather than for runtime data storage.

[0032] In addition, the computing device 200 may include or be coupled to any type of processor-readable media, such as processor-readable storage media (e.g., operating memory 220 and data storage memory 250) and communication media (e.g., communication signals and radio waves). Although the term processor-readable storage medium includes operating memory 220 and data storage memory 250, the term "processor-readable storage medium" throughout this specification and claims, whether used in the singular or in the plural, is defined herein so that the term "processor-readable storage medium" expressly excludes and does not encompass communication media, any communication media, or any signal itself. However, the term "processor-readable storage medium" does encompass processor cache memory, random access memory (RAM), register memory, and the like.

[0033] The computing device 200 also includes an input interface 260, which can be configured to enable the computing device 200 to receive input from a user or from other devices. In addition, the computing device 200 includes an output interface 270, which can be configured to provide output from the computing device 200. In one example, the output interface 270 includes a frame buffer, a graphics processor, a graphics processor, or an accelerometer, and is configured to render a display for presentation on a separate visual display device (e.g., a monitor, a projector, a virtual computing client computer, etc.). In another example, the output interface 270 includes a visual display device, and is configured to render and present a display for viewing. In yet another example, the input interface 260 and / or the output interface 270 may include a universal asynchronous receiver / transmitter (UART), a serial peripheral interface (SPI), an internal integrated circuit (I2C), a general purpose input / output (GPIO), etc. In addition, the input interface 260 and / or the output interface 270 may include or be interfaced to any number or type of peripherals.

[0034] In the example shown, 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, such as an Ethernet adapter, a token ring adapter, or a digital subscriber line (DSL) adapter. 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, SigFox, LoRa, Powerline, or a 5G adapter.

[0035] Although computing device 200 is shown with certain components configured in a particular arrangement, these components and arrangements are merely one example of a computing device in which the present technology may be employed. In other examples, data storage memory 250, input interface 260, output interface 270, or network adapter 280 may be coupled directly to processing circuit 210, or via an input / output controller, bridge, or other interface circuitry. Other variations of the present technology are possible.

[0036] Some examples of computing device 200 include at least one memory (e.g., operating memory 220) having processor-executable code stored therein, and at least one processor (e.g., processing unit 210) adapted to execute the processor-executable code, wherein the processor-executable code includes processor-executable instructions that, in response to execution, enable computing device 200 to perform actions, wherein in some examples, the actions may include actions for one or more of the processes described herein, such as Figure 5 The process shown in , as discussed in more detail below.

[0037] The system shown

[0038] Figure 3 is a block diagram illustrating an example of a system ( 300 ). System 300 may include a network 330 , as well as client devices 341 and 342 ; policy evidence devices 351 and 352 ; cloud provider devices 361 and 362 ; and audit devices 371 and 372 , all of which, in some examples, are connected to network 330 .

[0039] Each of the client devices 341 and 342; the policy evidence devices 351 and 352; the cloud provider devices 361 and 362; and the audit devices 371 and 372 may include Figure 2 An example of a computing device 200. Figure 3 and in this manual Figure 3 The corresponding description shows an example system for illustration purposes, which does not limit the scope of the present disclosure.

[0040] In some examples, cloud provider devices 361 and 362 provide cloud services. In some examples, cloud provider devices 361 and 362 may be part of one or more distributed systems that provide various services including cloud services and confidential computing services on the cloud. Alternatively, one of the cloud provider devices may boot a CTS instance that first starts with a single TEE, and additional TEEs are being added after the CTS instance is booted to form a distributed network. In some examples, policy evidence devices 351 and 352 are part of one or more trusted third-party services that can generate cryptographically verifiable evidence associated with code that complies with one or more policies. In some examples, audit devices 371 and 372 are part of one or more audit services that can provide auditing and endorsement of code.

[0041] The network 330 may include one or more computer networks, including wired and / or wireless networks, each of which 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. On an interconnected collection of LANs, including those based on different architectures and protocols, a router acts as a link between LANs, enabling information to be sent from one LAN to another. In addition, the communication links within a LAN typically include twisted pairs or coaxial cables, although the communication links between networks may utilize analog telephone lines, including all or part of dedicated digital lines of T1, T2, T3, and T4, integrated services digital networks (ISDN), digital subscriber lines (DSL), wireless links including satellite links, and / or other communication links known to those skilled in the art. In addition, remote computers and other related electronic devices may be remotely connected to a LAN or WAN via a modem and a temporary telephone link. The network 330 may include various other networks, such as one or more networks using local network protocols, such as 6LoWPAN, ZigBee, etc. Essentially, network 330 may include any appropriate network-based communication method whereby information may be transmitted between client devices 341 and 342; policy evidence devices 351 and 352; cloud provider devices 361 and 362; and audit devices 371 and 372. Although each device is shown as being connected to network 330, this does not necessarily mean that each device is in communication with each other device shown. In some examples, some of the devices shown communicate only with some of the other devices / services shown via one or more intermediary devices. Furthermore, although network 330 is shown as one network, in some examples, network 330 may instead include multiple networks that may or may not be interconnected, wherein some of the devices shown communicate with each other via one of the multiple networks, and other of the devices shown communicate with each other instead with different ones of the multiple networks.

[0042] System 300 may include Figure 3 More or less equipment than shown in Figure 3 It is shown by way of example only.

[0043] Figure 4 is a block diagram showing an example of a system (400). The system 400 may be Figure 3System 400 may be a system for booting a CTS instance. "Booting" a CTS instance refers to the process of starting a CTS instance until the CTS instance is operational. System 400 may include client device 441, client device 442, policy evidence service 451, policy evidence service 452, cloud provider service 460, audit service 470, and application provider 480. Client devices 441 and 442 may be Figure 2 An example of client devices 341 and 342.

[0044] In some examples, cloud provider service 460 may include a device that includes Figure 3 In some examples, policy evidence service 451 and policy evidence service 452 may each include a distributed system that includes one or more policy evidence service devices (e.g., Figure 3 The audit service 470 may include one or more distributed systems, including Figure 3 One or more examples of audit devices 371 and 372. Application provider 480 may include one or more devices that provide third-party applications submitted to the CTS service for registration.

[0045] In some examples, cloud provider service 460 can provide a confidential computing environment on the cloud on behalf of the client. The confidential computing can protect the accessibility of the data being processed so that the code and data being processed in the provided confidential computing environment cannot be accessed externally. However, the user may be concerned that third-party code (e.g., an application provided by application provider 480) operating in the confidential computing environment may violate the confidentiality provided by the confidential computing environment.

[0046] The cloud provider service 460 can operate a CTS instance that can be used to establish trust in code that will be used in a confidential computing environment (e.g., an application provided by an application provider 480). For example, a CTS instance can store cryptographically verifiable evidence that proves that the code authorized by the instance complies with one or more policies. In some examples, CTS can allow a user to know exactly whether the code in the confidential computing environment will misbehave, such as misbehavior by violating the confidentiality of the confidential computing environment. In some examples, a CTS instance can provide a guarantee that the authorized code is auditable. The trust established in the code authorized by the CTS instance can enable users to use third-party code in a confidential computing environment without the risk that the cloud provider or third-party code may violate the confidentiality of the confidential computing environment.

[0047] In this way, trust in third-party code can be enabled by code transparency. Code transparency can refer to, for example, the ability to securely attach a set of statements to a given piece of software code that describe the content of the code, document the provenance of the code, and provide additional evidence, such as code reviews or audit reports. Code transparency can also refer to the ability to publish some of these statements in a way that enables third parties to verify some of these statements before relying on the code.

[0048] In order to correctly establish a trusted CTS instance, in some examples, the CTS instance is booted in such a way that the CTS instance itself can be trusted, and any updates performed on the CTS instance are completed in such a way that the updated CTS instance can be trusted. In some examples, the booting of the CTS instance can be completed as follows.

[0049] The booting of a CTS instance can first begin in a single device (in cloud provider service 460) with a TEE. In some examples, the TEE enables the creation of a protected area inside the processor so that the memory in the protected area is encrypted and only decrypted inside the TEE. TEE attestation can be used to verify the code running in the TEE. In some examples, the TEE allows for the integrity of computations that occur inside the TEE and the confidentiality of what happens inside the TEE.

[0050] Some examples of TEEs are hardware-based, and other examples are software-based. Examples of hardware-based TEEs use hardware-based protection of memory ranges that define the address range of the TEE. In some examples, writes to the TEE are encrypted. In some examples, the CPU does not allow anything outside the address range of the TEE to see the address range in plain text, and writes from outside the address range area are not allowed within the TEE address range.

[0051] When CTS boot is executed, in some examples, first the initial source code for the CTS instance is provided. Next, in some examples, cryptographically verifiable evidence of establishing trust in the initial source code for the CTS instance is generated. Cryptographically verifiable evidence can be evidence that the CTS code (i.e., the code used to operate the CTS instance) complies with one or more policies. Cryptographically verifiable evidence can take different forms for different examples. For example, in various examples, the cryptographic verifiability of the evidence may include a signature, a zero-knowledge proof, or other appropriate form of cryptographic verifiability. In addition, the evidence can take various forms, such as cryptographic commitments, pointers, cryptographic hashes, and the like. For example, in some examples, evidence of the storage of the CTS initial source code may include a pointer to an external storage location, which has an encrypted commitment to the CTS initial source code stored at the external storage location.

[0052] Different policies may be implemented in different examples. In some examples, one of the policies is for external archiving of initial source code by a trusted third-party service. In some examples, one of the policies is for evidence of building CTS code by a trusted third-party reproducible build service (RBS). In some examples, one of the policies is for code review of CTS code by a third party. In some examples, one of the policies is for a statement by an external build audit system that the CTS pipeline is secure during operation of the CTS code. Other appropriate policies may be implemented in other examples.

[0053] In some examples, the policy used in the bootstrap of a CTS instance is an external archive of CTS code, and the CTS code is a reproducible build. As discussed above, in some examples, compliance with each of these policies is established by a separate trusted third party. In some examples, by ensuring compliance with these two policies, the CTS instance ensures that the CTS code is auditable. Therefore, by using these two policies, trust can be established in the CTS code because the client is able to determine at any time which code is accessing client data in a confidential computing environment.

[0054] The initial binary file of the CTS instance can be executed in a trusted execution environment (TEE) in a device in the cloud provider service 460 used to boot the CTS instance. The TEE can provide a ledger on which evidence can be stored. The TEE can determine (multiple) measurements of the binary file. The TEE can generate a CTS service key, which is used for cryptographic operations to be performed by the CTS instance. The CTS service key can be generated as a runtime value generated by the TEE. The CTS service key can be a public-private key pair that is used during normal operation of the CTS service to sign statements on behalf of the CTS service. In some examples, the CTS service key represents the identity of the CTS service and is used to endorse statements on behalf of the CTS service.

[0055] The TEE may also perform attestations, including attestations of: (multiple) measurement values, cryptographically verifiable evidence used to establish trust in the code for the CTS instance, and the CTS service key. The audit service 470 may endorse the CTS instance in some ways, for example, by endorsing the CTS service key via a signature. The CTS instance may be endorsed in other appropriate ways in other examples. In some examples, the endorsement is recorded on the ledger. Endorsement may also be done in different parts of the boot process in various examples.

[0056] The CTS instance can add additional TEEs so that the ledger becomes a distributed ledger with multiple nodes, and the CTS instance becomes a distributed network. The distributed ledger can be a blockchain, or a suitable distributed ledger other than a blockchain. In some examples, when a new node is added to the CTS instance, evidence of the code identity of the new node must already exist on the ledger for the new node so that only nodes matching the latest code identity are accepted.

[0057] After booting, the CTS instance can begin normal operation, where the CTS instance begins accepting code declarations to register. In some examples, when the CTS instance has begun running, the CTS implements policies in an automatic, self-sufficient manner, including implementing policies for upgrades to the CTS code itself, and implementing policies for other code submitted to the CTS instance for registration.

[0058] When a user wishes to verify the suitability of a CTS instance, the user may request a receipt from the CTS instance via a client device (e.g., client device 441 or client device 442) for an endorsement of the CTS instance by an auditor of the CTS instance. In some examples, the receipt proves that the CTS instance has been bootstrapped and authorized by the auditor. In some examples, verification may be performed online or offline.

[0059] An application provider, such as application provider 480, can provide application code to be registered by a CTS instance. Application provider 480 can then calculate the expected binary file measurements to be produced by the TEE. Application provider 480 can then obtain evidence of trust in the application, which will be included in the declaration to be registered for the application.

[0060] The evidence may include cryptographically verifiable evidence used to establish trust in the application, including, for example, cryptographically verifiable evidence that the code complies with one or more policies. For example, in some examples, the evidence includes evidence that the code is externally archived from a trusted third-party archiving service, and evidence from a trusted third-party reproducible build service (RBS) that the build is reproducible. In some examples, the evidence may also include any other evidence that an auditor may use in order to audit the code. For example, if the code is in GitHub, the evidence may include a GitHub commit link to the code.

[0061] Next, the application provider 480 can write a declaration to submit for registration. In some examples, the declaration is a signed document containing the expected binary file measurements of the application to be registered by the CTS instance and evidence for the application. In some examples, the declaration is signed using distributed identity (DID) key management. Next, the application provider 480 can submit the declaration to the CTS instance.

[0062] A CTS instance (running on cloud provider service 460) can receive the declaration, and then the TEE on the CTS instance can verify the declaration. In some examples, the verification of the declaration includes verification of the signature on the declaration. The verification of the declaration can also include proof of the code being registered. The verification of the declaration can also include verifying that the declaration satisfies the registration policy required for the code to be approved by the CTS service. When the declaration is successfully verified, the CTS instance can attach the declaration to the distributed ledger of the CTS instance. In some examples, the distributed ledger is an immutable ledger and the CTS has the sole ability to update it.

[0063] The CTS instance may then generate a receipt for the claim. In some examples, the receipt is a ledger countersignature that is a signed statement that the claim is registered on the distributed ledger. In some examples, the receipt is signed by a key that is endorsed by the CTS service key. In some examples, the receipt contains (1) a cryptographic structure to prove that the evidence has been stored on the ledger, and (2) a signature of the root of the distributed ledger that indicates the state of the CTS service at the time the receipt was issued. The CTS instance may then provide the proof and receipt to the application provider 480.

[0064] Application provider 480 can then use the receipt to prove to users of client devices (e.g., client devices 441 and 442) that the application complies with the policy. For example, in some examples, the receipt can be used to prove to the user that the application can be audited.

[0065] Various guarantees can be provided by CTS in various examples. For example, in some examples, a guarantee that CTS has trusted behavior is provided. In some examples, this is done by CTS guaranteeing policy compliance using a policy that establishes that CTS code must be trusted.

[0066] In some examples, a guarantee of detection of any erroneous behavior of the CTS code is provided. In some examples, this guarantee is achieved by having one of the policies implemented be a requirement for evidence that the code is reproducibly buildable from a trusted third party RBS that has been endorsed by the audit service 470, which evidence is registered in the CTS (including being stored on the immutable ledger of the CTS). In some examples, if a user shows a service attestation signed by the CTS, and the evidence for the service is not available, then the upgraded design proof lineage and any violation of the policy for the service will be clearly guaranteed in the CTS ledger, thereby providing a guarantee of detection of erroneous behavior. In some examples, if the implementation of erroneous behavior is on the ledger, then they will be auditable because it is possible to reproducibly build them, and the only reason they are not on the ledger is that the ledger has been truncated or the evidence of the build has been withheld, which is itself evidence of possible erroneous behavior.

[0067] In some examples, the auditability of the code is guaranteed. In some examples, this is achieved by having an implemented policy that includes at least two of the following policies. In some examples, one of the implemented policies is a requirement for evidence that the code is reproducibly constructible from a trusted third party RBS that has been endorsed by the audit service 470, and the evidence is registered in the CTS (including being stored in the immutable ledger of the CTS). In some examples, another policy in the implemented policy is a requirement for evidence from an external archive of a trusted third party. In some examples, the external archive is outside the control of the CTS operator or application provider. In some examples, the external archive is located in a public location, such as a public ledger or source code repository, rather than a trusted third party. In some examples, when the archive service has archived code, it signs its endorsement on the evidence to ensure that the customer can obtain access to the code.

[0068] A user who wishes to use confidential computing provided by cloud provider service 460 and who wishes to use an application from application provider 480 in a confidential computing environment can use a client device (e.g., client device 441 or 442) to perform the following operations. The user can use a client device (e.g., client device 441 or 442) to connect to application provider 480. In response, application provider 480 can return a proof and receipt of the code to the user's client device. The user can then verify whether the (multiple) binary file measurements in the statement match the proof and verify the receipt. The user can also verify whether the statement complies with the usage policy required by the user. In some examples, the usage policy indicates the evidence required by the user in order to establish trust in the application.

[0069] In some examples, the policies used in the declaration include evidence that the code is archived externally, and evidence that the code is reproducibly buildable. As discussed above, in some examples, compliance with each of these policies is established by a trusted third party. In some examples, by ensuring compliance with these two policies, the CTS instance ensures that the code is auditable. Therefore, by using these two policies, trust can be established in the code because the client is able to determine at any time which code is accessing client data in a confidential computing environment. In some examples, these two policies ensure that the complete record of the code (and evidence of confidentiality) is recorded immutably so that the client can audit the code, including inspecting the source code.

[0070] In some examples, some of the third-party code may be code provided by cloud provider service 460 rather than code provided by a third-party application provider other than the cloud service provider.

[0071] The cloud provider service 460 can also provide a confidential computing environment on behalf of its clients by providing a TEE in the cloud, and third-party applications registered by the CTS service can run in the confidential computing environment without risking the client that the confidentiality of the confidential computing environment has been breached. In these examples, either the policy will have been enforced or there will be evidence that the policy was not enforced.

[0072] In some examples, as discussed above, a CTS instance can be used to register claims for confidential code that will be run in a confidential computing environment. However, a CTS instance can be used to register claims for any appropriate code, not just code that is run in a confidential computing environment.

[0073] In some examples, a CTS instance can be updated based on a new version of the CTS code as follows. First, in some examples, an updated CTS update code for the CTS instance is provided. Next, in some examples, cryptographically verifiable evidence of trust established in the CTS update code is generated. The cryptographically verifiable evidence can be evidence that the code used to update the CTS instance complies with one or more policies, which can be the same policies used during CTS boot.

[0074] Next, in some examples, the CTS binary is updated based on the CTS code update, and the updated CTS code is registered on the CTS instance. Upon successful registration of the updated CTS code, a receipt may be provided. Next, in some examples, the updated CTS binary, the evidence, and the CTS registered receipt are submitted to the CTS governance endpoint. Next, in some examples, the TEE on the CTS instance verifies the evidence and the CTS registered receipt.

[0075] In some examples, the TEE verifies not only the current update, but also the entire lineage for the CTS code. Therefore, in some examples, the TEE verifies all updates in the update to the CTS code until the boot of the CTS code. After successful verification, in some examples, the CTS code update can be approved. In some examples, after approval, the binary file hash is written to the authorized measurement value table. In some examples, after the code is approved, the CTS update can be deployed. In this way, the CTS system can provide fully automated updates to the CTS code.

[0076] The above examples discuss a cloud provider service that both (1) performs cloud services, including providing a confidential computing environment, and (2) performs CTS services to ensure code transparency in third-party code used in the confidential computing environment. However, in other examples, the confidential computing service and the CTS service may be separate services provided by separate entities.

[0077] The process of diagramming

[0078] Figure 5 is a schematic diagram showing an example data flow for a process (590) for booting a CTS instance. In some examples, process 590 may be performed by Figure 3 An example of a server device in server device 361 and / or 362, by Figure 4 Examples of cloud provider services 460, Figure 2 The example of device 200 and the like are used to perform the above.

[0079] In the illustrated example, step 591 occurs first. At step 591, in some examples, first evidence associated with a first policy is obtained. In some examples, the first evidence includes data including cryptographically verifiable evidence associated with initial source code according to the first policy. In some examples, the initial source code is source code for a code transparency service (CTS). As shown, in some examples, step 592 occurs next. At step 592, in some examples, an initial binary file is provided based on the initial source code.

[0080] As shown, in some examples, step 593 occurs next. At step 593, in some examples, the initial binary file is executed in the first trusted execution environment (TEE) so that the first CTS instance begins operation. In some examples, the first CTS instance is configured to implement at least one guarantee associated with code approved by the first CTS instance. In some examples, at least one guarantee is associated with code transparency. As shown, in some examples, step 594 occurs next. At step 594, in some examples, the first TEE is used to provide a first ledger. The TEE can also be used to perform steps 595 to 598.

[0081] As shown, in some examples, step 595 occurs next. At step 595, in some examples, the first evidence is stored on the first ledger. As shown, in some examples, step 596 occurs next. At step 596, in some examples, at least one measurement associated with the initial binary file is provided. As shown, in some examples, step 597 occurs next. At step 597, in some examples, a first service key associated with the first CTS instance is generated. In some examples, the first service key is used by the first CTS instance for at least one cryptographic function. As shown, in some examples, step 598 occurs next. At step 598, in some examples, a TEE proof of at least one measurement, the first evidence, and the first service key is provided. The process can then proceed to a return block where other processes are resumed.

[0082] in conclusion

[0083] Although the above specific embodiments describe certain examples of the present technology and describe the best mode considered, no matter how detailed the above appears in the text, the present technology can be practiced in many ways. The details may vary in implementation, but are still covered by the technology described herein. As described above, when describing certain features or aspects of the technology, the specific terms used should not be regarded as implying that the terms are redefined in this article to be limited to any specific characteristics, features, or aspects associated with the terms. In general, the terms used in the above claims should not be interpreted as limiting the present technology to the specific examples disclosed herein unless the specific embodiments clearly define these terms. Therefore, the actual scope of the present technology covers not only the disclosed examples, but also all equivalent methods of practicing or implementing the present technology.

Claims

1. A device comprising: A device comprising at least one memory having processor-executable code stored therein, and at least one processor adapted to execute the processor-executable code, wherein the processor-executable code comprises processor-executable instructions that, in response to being executed, enable the device to perform actions comprising: obtaining first evidence associated with a first policy, wherein the first evidence comprises data comprising cryptographically verifiable evidence associated with initial source code according to the first policy, wherein the initial source code is source code for a code transparency service (CTS); Providing an initial binary file based on the initial source code; executing the initial binary in a first trusted execution environment (TEE) so that a first CTS instance begins operation, wherein the first CTS instance is configured to enforce at least one guarantee associated with code approved by the first CTS instance, and wherein the at least one guarantee is associated with code transparency; and Use the first TEE to: Provide the first ledger; Storing the first evidence in the first ledger; providing at least one measurement value associated with the initial binary file; generating a first service key associated with a first CTS instance, wherein the first service key is used by the first CTS instance for at least one cryptographic function; and Providing TEE attestation of the at least one measurement, the first evidence, and the first service key.

2. The apparatus of claim 1, wherein the at least one guarantee comprises a guarantee of auditability of the approved code.

3. The apparatus of claim 1, wherein the at least one guarantee comprises a guarantee of approved detection of erroneous behavior of the code.

4. The apparatus of claim 1 , wherein the actions further comprise recording an endorsement of the first CTS instance on the first ledger.

5. The apparatus according to claim 1, wherein the actions further comprise: receiving a request for a receipt of the endorsement for the first CTS instance; In response to the request for the receipt for the endorsement for the first CTS instance, providing the receipt for the endorsement for the first CTS instance.

6. The apparatus according to claim 1, wherein the actions further comprise: obtaining second evidence associated with a second policy, wherein the second evidence comprises data including cryptographically verifiable evidence associated with the initial source code according to the second policy; Storing the second evidence on the first ledger; as well as Execute the TEE proof of the second proof.

7. The apparatus of claim 6, wherein the first strategy is a strategy to archive the initial source code, and wherein the second strategy is a strategy to repeatably build the initial binary file.

8. The apparatus according to claim 1, wherein the actions further comprise: Receive CTS code updates; obtaining second evidence associated with the first policy, wherein the second evidence comprises data including cryptographically verifiable evidence associated with the CTS code update according to the first policy; registering an updated CTS code, wherein the updated CTS code is based on the CTS code update; providing a receipt of said registration of said updated CTS code; as well as Verification of the registration of the updated CTS code is performed using a second TEE.

9. A method comprising: obtaining first evidence associated with a first policy, wherein the first evidence comprises data comprising cryptographically verifiable evidence associated with initial source code according to the first policy, wherein the initial source code is source code for a code transparency service (CTS); executing a first binary file in a first trusted execution environment (TEE), wherein the first binary file is based on the initial source code so that a first CTS instance begins operating, wherein the first CTS instance is configured to enforce at least one guarantee associated with code approved by the first CTS instance, and wherein the at least one guarantee is associated with code transparency; as well as Use the first TEE to: Provide the first ledger; Storing the first evidence in the first ledger; calculating at least one measurement associated with the initial binary file; creating a first service key associated with a first CTS instance, wherein the first service key is used by the first CTS instance for at least one cryptographic function; as well as Performing TEE attestation of the at least one measurement, the first evidence, and the first service key.

10. A processor-readable storage medium having processor-executable code stored thereon, the code, when executed by at least one processor, performing actions comprising: providing first evidence, wherein the first evidence comprises data including cryptographically verifiable evidence that code associated with a first code transparency service (CTS) instance complies with a first policy; executing a binary file in a first trusted execution environment (TEE) so that the first CTS instance begins operation, wherein the first CTS instance is configured to enforce at least one guarantee associated with code approved by the first CTS instance, and wherein the at least one guarantee is associated with code transparency; as well as Use the first TEE to: Provide the first ledger; Storing the first evidence in the first ledger; calculating at least one measurement associated with the binary file; generating a first service key associated with a first CTS instance, wherein the first service key is used by the first CTS instance for at least one cryptographic operation; as well as Providing TEE attestation of the at least one measurement, the first evidence, and the first service key. 11 . The processor-readable storage medium of claim 10 , wherein the first strategy is a strategy of archiving an original source code of the binary file or a strategy of repeatedly building the binary file.

12. The device of claim 8, wherein the second TEE is the first TEE.

13. The method of claim 9, wherein the first strategy is at least one of a strategy of archiving the initial source code or a strategy of repeatably building the first binary file.

14. The method according to claim 9, further comprising: obtaining second evidence associated with a second policy, wherein the second evidence comprises data including cryptographically verifiable evidence associated with the initial source code according to the second policy; Storing the second evidence on the first ledger; as well as Execute the TEE proof of the second proof.

15. The method according to claim 9, further comprising: Receive CTS code updates; obtaining second evidence associated with the first policy, wherein the second evidence comprises data including cryptographically verifiable evidence associated with the CTS code update according to the first policy; registering an updated CTS code, wherein the updated CTS code is based on the CTS code update; providing a receipt of said registration of said updated CTS code; as well as Verification of the registration of the updated CTS code is performed using the first TEE.

Images