End-to-end security for hardware running verified software

Abstract

Some embodiments relate to end-to-end security for hardware running verified software. A verified software system can be executable on secure hardware. The software system can be verified to conform to a software specification before being executed. A first credential attesting to the identity of the software system can be sent to an external application. A second credential signed by a provider of the secure hardware can be sent to the external application. The second credential can attest to the identity of the secure hardware. The external application can securely exchange one or more messages with a software application of the software system. For example, the one or more messages can be decryptable only by the external application and the software application to provide confidentiality for each message. As another example, the attestation can guarantee the identity of the sender of each of the one or more messages to attest to the integrity of each message.

Description

[0001] Divisional

[0002] This application is a continuation-in-part of the application for patent having application number 2015800539170, filing date October 01, 2015, and titled "End-to-End Security for Hardware Running Verified Software." BACKGROUND

[0003] When a user submits personal data to a remote service (e.g., a cloud-based service), there is no guarantee that the personal data will remain secure, or even that the service will produce correct results. At best, the service can have a privacy policy and limit the service's liability in the event of a data breach. However, recent headlines have provided examples of how vulnerabilities in operating systems, libraries, or applications (e.g., software applications) can enable personal data to be accessed. SUMMARY

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

[0005] A verified software system can be executed on secure hardware (e.g., trusted hardware). Properties of the software system can be verified to conform to a software specification before being executed. A first credential attesting to the identity of the software system can be sent to an external application. A second credential signed by a provider (e.g., manufacturer) of the secure hardware can be sent to the external application. The second credential can attest to the identity of the secure hardware. In this way, a system (e.g., a complete software stack) as a whole can be verified at a low level (e.g., assembly language level) and then bootstrapped to and executed by the secure hardware to provide a secure system. The first and second credentials can enable the external application to communicate with a software application of the software system in such a way that messages sent to or received from the software application are encrypted and can be decrypted by the external application and the software application, but cannot be decrypted or modified by other entities. BRIEF DESCRIPTION OF DRAWINGS

[0006] The detailed description is described with reference to the accompanying figures. In the figures, one or more left-most digits of a reference number identifies the figure in which that reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items.

[0007] Figure 1 is an illustrative architecture including a specification translator according to some implementations.

[0008] Figure 2 is an illustrative architecture including an application according to some implementations.

[0009] Figure 3 is an illustrative architecture including a trusted increment (TrInc) application according to some implementations.

[0010] Figure 4 is an illustrative architecture including a verified software stack (e.g., system) according to some implementations.

[0011] Figure 5 is an illustrative architecture of a verified software executing on secure hardware according to some implementations.

[0012] Figure 6 is an illustrative architecture including offline and runtime according to some implementations.

[0013] Figure 7 is a flow diagram of an example process including receiving a public key from a software application according to some implementations.

[0014] Figure 8 is a flow diagram of an example process including executing a software system that has been verified to conform to a software specification according to some implementations.

[0015] Figure 9 is a flow diagram of an example process including performing a verified boot of a software system according to some implementations.

[0016] Figure 10 is an illustrative architecture including a verified software system. DETAILED DESCRIPTION

[0017] Formal verification of software code of a service can provide a mathematical guarantee that the service exactly matches a formally specified security standard. Unfortunately, while software verification can provide strong guarantees about the trustworthiness of software code, the computational cost can be so high that a service provider can not be able to perform software verification of its entire system. Thus, a service provider can at best provide strong guarantees about small programs written in high-level languages that are surrounded by large amounts of unverified software code. For example, a verified transport layer security protocol implementation can rely on an unverified operating system and unverified software libraries. As another example, a machine-checked correctness proof of a public-key encryption system (e.g., RSA or similar system) can assume the correctness of the encryption library that implements the public-key encryption system, the corresponding runtime library, and the operating system. As another example, a microkernel that relies on trusted assembly code can not make claims about the correctness of application-level semantics. Thus, a service can not be able to perform complete formal verification of the software code of the service and, thus, can not be able to provide a mathematical guarantee that the service exactly matches a formally specified security standard.

[0018] The systems and techniques described herein can be used to execute applications that have been verified to be end-to-end secure, such that the verification can cover all software code ("code") that can be executed, e.g., the verified code includes not only the application, but also the operating system, libraries (runtime libraries, program libraries, dynamic libraries), and drivers that can be executed. Thus, in some cases, it is not necessary to assume that any part of the software executing on one or more servers is correct. The code that is subject to verification is the assembly code that is executed, rather than any high-level language(s) that the code can have been written in. The verification process can assume that the hardware is correct, but does not make assumptions about the correctness of the compiler or the runtime execution of the code. The verification process can thus demonstrate a functionally correct version of the high-level abstract state machine of the entire system implementation code. The verification process can demonstrate secure remote equivalence, e.g., a remote user can establish a secure channel to the code whose output cannot be distinguished from the output of the high-level abstract state machine.

[0019] Verifying that the code executing on one or more servers is functionally correct and demonstrating remote equivalence can enable the verification process to provide a complete specification and proof of the behavior of the entire system, detailing how the system (e.g., software code and hardware) will behave in every possible case. Demonstrating remote equivalence can include (i) demonstrating functional correctness of properties and (ii) a non-interference proof, which involves demonstrating relational properties of the code (e.g., properties about how two runs of the same code with different inputs relate to each other). Furthermore, the remote equivalence can be strengthened to provide secure remote equivalence via trusted computing (e.g., as specified by the Trusted Computing Group, which is an international industry standards group that develops and publishes specifications for implementation by the industry). For example, a public key can be attested (e.g., via a proof) to correspond to a private key that is known only to the code executing on one or more servers using secure hardware such as a Trusted Platform Module (TPM). A remote user can use the public key to create a secure channel to the code, enabling security commensurate with direct communication with the abstract state machine of the code. Combining the proof with the fully verified code can thus provide an extremely high guarantee of end-to-end security.

[0020] Compared to using traditional techniques, the techniques and systems described herein can enable software developers to develop verifiably secure applications with modest developer effort. For example, traditional techniques can often require tens of people to spend years to verify a single software layer, so it can be computationally prohibitive to use traditional techniques to verify a complete software stack (e.g., an application, operating system, drivers, etc.). To reduce developer effort, the techniques and systems described herein can be used to perform fast, automated, end-to-end software verification of system software. The term "software stack" refers to an entire software system, e.g., such as an operating system, device drivers, software libraries, applications, and any layers in between.

[0021] To correctly verify code at the assembly level (e.g., with modest developer effort), software developers can use two new tools described herein. First, a specification translator can enable software developers to effectively write specifications in a high-level language and then verify that corresponding assembly code satisfies the specification, as the specification translator can translate high-level specifications (e.g., expressed as state machines) into low-level specifications. Second, a compiler that compiles verifiable code in a high-level language into verifiable assembly language can be used to translate code and corresponding proofs from a high-level language to low-level assembly code (or machine code). Such a compiler can enable software developers to quickly write and check high-level code and prove properties associated with executable assembly code. For example, software for an entire system (including applications, libraries, drivers, and operating systems) (or any subset thereof) can be compiled into a single program consisting of verifiable assembly code. Verifying the correctness of the entire system code (e.g., as a whole) enables there to be no unverified code in the entire system code and no unverified gaps between different components of the system. As an example of a gap, suppose a first component X is described as performing Q and a second component Y is described as performing R using another component (X) that performs Q. If the Q represented by X is not the same thing as the Q represented by Y, then Y’s guarantee that Y performs R cannot hold, creating a gap. The verification process verifies that there are no unverified gaps between two (or more) components of the system.

[0022] Furthermore, the verification process verifies that each component of the system cannot break the specification of another component of the system. For example, an application can be verified not to break the memory management subsystem of an operating system, and the memory management subsystem of the operating system can be verified not to break the application.

[0023] Several software applications, each of which can be used as a standalone service, are provided as examples of verifiable software code. For example, a notary application is described that is used to securely assign logical timestamps to objects (e.g., files, documents, etc.) so that they can eventually be ordered. The notary application includes a state that includes a monotonically increasing counter and responds to a notary request by incrementing the counter, signing (e.g., using a signature) the counter value with a statement linking the request, and replying with the statement and signature. Three other applications include a cryptographic hasher, a trusted counter for use by multiple users, and a differential privacy database that maximizes the accuracy of queries to the database while minimizing the chance of identifying records of the database.

[0024] Accordingly, techniques and systems are described below with reference to the drawings that provide externally verifiable complete verification software at the assembly level via automated complete system verification. A collection of example tools, techniques, and software engineering principles for building relatively large-scale end-to-end verified systems are also described. In addition, example methods for proving information flow based security properties of assembly level code via verification of relational properties and example techniques for system developers for formal verification are provided. Software and hardware can each provide credentials attesting to their respective identities to verify that communications with the software are secure.

[0025] Illustrative Architecture

[0026] Figure 1 is an illustrative architecture 100 including a specification translator according to some implementations. In some implementations, the architecture 100 can be used to provide remote equivalence and end-to-end verification.

[0027] Remote equivalence provides guarantees about the equivalence between each application and its corresponding state machine. For example, a remote device communicating with an application over an untrusted network can be guaranteed to receive the same sequence of messages as a remote device communicating with a corresponding (e.g., corresponding to the application) state machine over an untrusted network. For example, a specification of a notarized application can indicate that the notarized application signs a monotonically increasing counter. Given that the system matches the specification, then a remote device can be provided a guarantee that, for example, the running system (i) does not allow the counter to roll back, (ii) does not share the private key, (iii) does not provide a statement that signs anything other than the notarization, (iv) correctly computes the signature, (v) is not vulnerable to buffer overflows, integer overflows, or other implementation-level vulnerabilities.

[0028] The architecture 100 can enable a remote device to establish a secure channel to an application. Establishing a secure channel to an application can eliminate the ability of an untrusted network to interfere with communications between the remote device and the application. For example, a specification of a notarized application can state that the notarized application uses randomness from a trusted platform to compute a key pair, then obtains the public key and attestation of the code of the application from the trusted platform. Accordingly, a remote device receiving the attestation can determine that the notarization signed with the corresponding private key was generated by the code of the notarized application on the trusted platform, and thus can be considered as if the notarization signed with the corresponding private key was generated by the state machine corresponding to the notarized application.

[0029] In addition to security guarantees, no implicit trust is placed in any software application running on the system. Accordingly, each software component is either (i) verified to be secure or (ii) executed in a verified sandbox environment that prevents the software component from affecting the security of other components of the system.

[0030] Furthermore, instead of verifying each component of the system independently, the entire system can be verified as a whole. By doing so, the system's security can avoid incorrect assumptions about how the system's software components interact. Implicit trusts are not placed in the compiler used to generate the software to be executed. Therefore, the instructions to be executed (e.g., assembly code) are verified, not just the high-level source code that will be compiled to create those instructions.

[0031] The code for the system can be written in a language designed to support verification (e.g., rather than in traditional computer languages). When designing the code, algorithms and code patterns that support proofs of correctness (e.g., rather than performance) can be chosen to provide an easily verifiable system. The code can be optimized without worrying about errors that optimization might introduce, because verification tools are designed to catch any errors that might be introduced by optimization techniques.

[0032] Verified systems can provide security against software-based attacks. For example, an adversary can execute software on the server before and / or after the verified application terminates. An adversary might compromise the server's firmware, basic input / output system (BIOS), or peripherals (e.g., network interface cards). In some cases, the system can assume that the central processing unit (CPU), memory, chipset, and trusted platform modules behave correctly, and that the adversary does not launch a physical attack (e.g., electrical probe of the memory bus, etc.).

[0033] Architecture 100 may include a high-level specification 102, a specification translator 104, a low-level specification 106, a verifier 108, a verification result 110, a high-level language implementation 112, a compiler 114, an assembly language implementation 116, an assembler 118, and a machine code implementation 120. For example, a user can create a high-level specification 102 and a high-level language implementation 112. The specification translator 104 can translate the high-level specification 102 (e.g., a finite state machine) into a low-level specification 106.

[0034] Compiler 112 can compile high-level language implementation 112 into assembly language implementation 114. Verifier 108 can automatically (e.g., without human interaction) perform various functions, such as verifying that assembly language implementation 116 corresponds to low-level specification 106. After assembly language implementation 114 has been verified by verifier 108 to correspond to low-level specification 106, assembly language implementation 116 can be converted by assembler 118 into executable code in the form of machine code implementation 116. Assembly language is an example of a low-level language for computers or other programmable devices, where there is typically a one-to-one correspondence between assembly language and machine code instructions executed by the hardware processor.

[0035] A verification stack (e.g., based on Floyd-Hoare or similar reasoning) can be used to prove functional correctness of code. The high-level specification 102 and the high-level language implementation 112 can be implemented using a high-level language designed to be verifiable. The high-level language can have built-in specification constructs. The verifier 108 can be a static program verifier that can be used to verify functional correctness of software programs written in the high-level language. The high-level language can be designed to support static verification of programs. The high-level language can include various features such as being imperative, sequential, supporting generic classes, providing dynamic allocation and inductive data types, and having built-in specification constructs. The high-level language specification can enable a user to specify preconditions, postconditions, frame specifications (read and write sets), and termination metrics. The high-level language can provide updatable ghost variables, recursive functions, and types such as sets and sequences. The specification and ghost constructs can be used by the verifier 108 during verification and can be omitted by the compiler 114 when the compiler 114 is creating the assembly language implementation 116.

[0036] In some implementations, the verifier 108 can run as part of the compiler 114. A programmer can interact with the verifier 108 in a similar manner to a static type checker, for example, when the verifier 108 produces an error, the programmer can respond by changing one or more of the type declarations, specifications, or statements in the high-level implementation 112. The verifier 108 can automatically fill in low-level proof details.

[0037] The compiler 114 can take the high-level language implementation 112 corresponding to the high-level specification 102 and automatically (e.g., without human interaction) translate the high-level language implementation 112 into a verifiable assembly language implementation 116. The assembly language implementation 116 can use an intermediate verification language (IVL) for describing proof obligations to be discharged by a reasoning engine such as a satisfiability modulo theories (SMT) solver. The IVL can include a verification engine (e.g., the verifier 108) that takes the assembly language implementation 116 as input, generates verification conditions (VCs) for the proof obligations, and passes the VCs to the reasoning engine. The verifier 108 can be used to verify code for the entire system at the assembly level (e.g., the assembly language implementation 116). Any errors in the high-level language implementation 112 or the compiler 114 can be identified by the verifier 108. Because some security properties cannot be expressed via functional correctness, techniques (e.g., the high-level language implementation 112) are described for verifying relational properties of code. The trusted assembler 118 can be used to convert the assembly language implementation 116 into a machine code implementation 120 (e.g., executable code) when the verification result 110 indicates that the assembly language implementation 116 has been verified to be correct.

[0038] Verifying code using reasoning

[0039] The verifier 108 can use some type of reasoning (e.g., Floyd-Hoare reasoning or other similar reasoning) to perform verification of the assembly language implementation 116. The high-level language implementation 112 can be annotated with assertions about the states that the program can enter, and the verification process can prove that the assertions are valid for all possible inputs to the program when the program is running. For programs that generate multiple outputs, the multiple outputs can be used to verify the specification of the program by annotating the output methods with preconditions that must be true at any time the program code is executed.

[0040] Accordingly, to enable the verifier 108 to verify the assembly language implementation 116, the high-level language implementation 112 can specify one or more preconditions, postconditions, loop invariants, or any combination thereof. In addition to the preconditions and postconditions included in the high-level specification 102, there are preconditions, postconditions, loop invariants in the high-level language implementation.

[0041] Writing a Trustworthy Specification

[0042] To enable end-to-end verification of a system, two types of specifications can be used, such as a hardware specification and a software specification. For the hardware specification, each assembly instruction that can be executed is specified to enable low-level verification. The hardware specification describes the expectations of the instruction (e.g., an ADD that sums multiple registers can expect that the sum of the multiple registers does not cause an overflow) and the one or more effects of the instruction on the system (e.g., the ADD writes the sum of the multiple registers back to a destination register).

[0043] The software specification can include an abstract description of the expected behavior of the corresponding software application. The abstract description can be modularly written in terms of lower-level library specifications. For example, a software specification for a notary application can describe (i) how the state machine of the notary application proceeds and (ii) the outputs that are allowed in each state. To illustrate, the specification can indicate that one output in a particular state is a signed message that is defined for use in a public key encryption system (e.g., RSA) signature.

[0044] The high-level specification 102 can use a conventional type of specification that specifies a subset of the features used by the system, e.g., without specifying features that are not used. For example, a secure hardware (e.g., a trusted hardware such as a Trusted Platform Module (TPM)) can have hundreds of pages of associated documentation. However, a particular system that uses a subset of the functionality of the trusted hardware can specify the subset of the functionality of the trusted hardware without specifying functionality of the trusted hardware that is not used in the particular system. Writing the high-level specification 102 to include functionality used by the system while excluding functionality that is not used can result in a smaller size for the high-level specification 102 (e.g., compared to if the unused functionality were included), thereby enabling easier and more accurate human review of the specification.

[0045] Various additional techniques can be used to reduce bugs / errors in a specification (e.g., the high-level specification 102). For example, a smaller specification that includes functionality used by the system can be easier and faster to verify. As another example, a specification written in a more abstract, declarative manner than implementation code can make specification bugs less likely to occur and easier to find when they do occur.

[0046] Generating verifiable assembly language

[0047] To enable fast, large-scale software development while verifying software code at a low level, the specification and the corresponding assembly language can be verified against each other. For example, the high-level specification 102 can be translated into a low-level specification 106, the high-level language implementation 112 can be compiled into an assembly language implementation 116, and the verifier 108 can verify that the assembly language implementation 116 behaves as specified by the low-level specification 106. This enables the high-level language to be used for the high-level implementation 112 without trusting the compiler 114 and without trusting the runtime environment (e.g., which can use various libraries, runtime components, operating system utilities, etc.).

[0048] Verifying relational properties

[0049] In addition to functional correctness, the verifier 108 can verify that the application does not provide ("leak") information about secret data (e.g., data that is to be kept private or restricted access), such as a private key. The property of not leaking information about secret data is referred to as noninterference. Assume that variable S represents secret data inside the application, and I represents public input to the application. As noted previously, the statement O := (S + S) + (I + I) satisfies the functional correctness specification, e.g., even(O). However, the output O can enable an outside party (e.g., an unauthorized program) to determine the secret S, e.g., by computing O / 2 - I. In this example, the secret S is leaked to the outside. In contrast, the statement O := (S - S) + (I + I) satisfies even(O), but does not provide information about S in the output O, because the value stored in O depends on the value in I, but is independent of S. To verify that a program does not provide information about secret data, the verifier 108 can analyze multiple executions of the program and compare the outputs of the executions of the program to determine which values the outputs depend on. Assume that the public input I is passed to all executions of the program, but the secret S is different in the executions of the program. If all executions of the program produce the same output O, independent of S, then O is independent of S and the program does not provide information about S. If at least one execution of the program produces a different output than the rest of the executions of the program, then the program can provide information about S. Thus, O can be proven to be independent of S by proving that two executions of the program do not produce different O when given the same I but different S. Mathematically, the idea is to prove that for all possible pairs of executions (referred to as two executions in each pair L and R (for left and right)), the output O can be equal if the public input I is equal but the secret S can be different, e.g., When the statement O := (S - S) + (I + I) satisfies the condition, O := (S + S) + (I + I) does not satisfy the condition (e.g., a counterexample, I L = I R = 1 and S L = 2 and S R = 3).

[0050] To determine that an application does not expose secret data, a developer can annotate the code with explicit relations annotations. For example, xL can be written as left(x), and xR can be written as right(x):

[0051]

[0052] In this example, the relation precondition left(I) == right(I) instruction verifier 108 determines whether IL = IR everywhere the Test is called, and the relation postcondition left(O) == right(O) instruction verifier 108 determines whether IL = IR => OL = OR. For most code, the verifier 108 can leverage existing functional correctness annotations, and thus the developer can not provide relation annotations. For example, the verifier 108 can use the functional postcondition in the code:

[0053] program ComputeIpChecksum(I) returns (O) ensures O == IpChecksum(I);

[0054] to determine that if IL = IR, then IpChecksum(IL) = IpChecksum(IR), and thus OL = OR.

[0055] Proving security properties

[0056] Requiring (and verifying) that the output of a program is independent of secret data in the program can be too stringent (e.g., impractical and unnecessary) a condition for most real-world systems. Typically, a program can allow for limited influence of secret data on the output, such as using a secret key to sign the output. The security policy for such a program can explicitly decrypt certain values, e.g., the signature, so that the signature can be included in the output.

[0057] Figure 2 is an illustrative architecture 200 including clients, networks, applications, and decrypters according to some implementations. The architecture 200 shows the structure of a verified system, including a client 202, a network 204, an application 206, and a decrypter 208. The decrypter 208 can authorize release of selected outputs derived from secret data. The decryption policy of an application can be represented as a state machine corresponding to the high-level behavior specified by the application’s specification. The client 202 can communicate with the (verified) application 206 across the network 204. For example, the client 202 can send input data I through the network 204. The network 204 can drop, delay, duplicate, or corrupt the input data I. The network 204 can not access the secret data of the application 206. The application 206 can receive a corrupted version I* of the input data I, and respond by sending an output O across the network 204. The network 204 can corrupt the output O and provide a corrupted version O* to the client.

[0058] When computing the output O, the application 206 can invoke the decrypter 208 policy one or more times. Each time the decrypter 208 is invoked, the application 206 can pass the secret data S, the input i, and the expected decrypted output d to the decrypter 208. To successfully verify, the expected decrypted output d will equal the output according to the decrypter policy of the state machine stipulating d = StateMachineOutput(S; i). When the verifier 108 performs static verification and determines that the decrypter policy of the state machine is satisfied, the decrypter 208 produces a decrypted output o that the application 206 can use as part of the output O.

[0059] In some implementations, o can equal d, such that the decrypter 208 is a no-op (no operation) during runtime. However, the information that the decrypter 208 is a no-op can not be disclosed to the verifier 108, such that oL= oR can be disclosed without disclosing dL= dR. In some cases, for example, if the secret data S can be determined using a brute force search of d (e.g., by factoring a public key), then dL= dR can imply SL= SR, which is undesirable.

[0060] Secure application examples

[0061] Four examples of verified secure applications (e.g., referred to as Ironclad applications) are discussed. The proof for each application is based on proofs of previously proven low-level libraries, drivers, and operating systems. Each application can be compiled as a standalone system image that communicates with other machines via a protocol such as, for example, the User Datagram Protocol (UDP). Each example application is a useful and complete application that can be worth at least one dedicated machine in a data center. Hardware support for fine-grained secure execution environments can enable multiplexing multiple Ironclad applications.

[0062] Notarized applications

[0063] Notarized applications securely assign a logical timestamp to a document, such that the document can be finally ordered. In traditional systems, users of such a timestamp service assume that machines are executing correct software. The notarized applications described herein do not require such an assumption.

[0064] Notarized remote equivalence. A notarized application is equivalent to a state machine with the following states:

[0065] • a key generation algorithm using an encryption system (e.g., RSA) that computes a (PublicKey, PrivateKey) pair from a first contiguous sequence of random bytes read from the trusted hardware.

[0066] • a trusted hardware platform in which a platform configuration register (e.g., PCR 19) has been extended with the public part of the key pair; and

[0067] • A counter Counter initialized to 0;

[0068] And the state machine has the following transitions:

[0069] • Given input (connect, Nonce), change the trusted hardware state by taking a quote Quote on PCRs 17-19 and an external random number Nonce. The output is (PublicKey; Quote).

[0070] • Given input (notarize, Hash), increment Counter and return SigPrivateKey(OP-CTR-ADV || RFC4251 Encode(Counter) || Hash).

[0071] A PCR is a register that allows secure storage and reporting of security-related metrics. Part of the specification for the notarization application can include a predicate to be satisfied before out_sig is decrypted (which otherwise cannot be output due to a dependency on secret data):

[0072]

[0073] Proving notarization equivalence can include proofs that (1) input noninterference, (2) functional correctness of the Connect procedure, (3) functional correctness of the notarization procedure, and (4) output noninterference. (1) Input noninterference: The random numbers and messages passed to the decryptor 208 by the notarization application are based on public data. (2) Functional correctness of Connect: The application correctly derives keys from randomness, and when the PCRs of the trusted hardware are in the required state, the trusted hardware quote obtained by the application is from the trusted hardware. (3) Functional correctness of notarization: The application increments the counter and correctly computes the signature. (4) Output noninterference: The writes to unprotected memory only depend on public data and the computed state machine output.

[0074] TRINC application

[0075] Figure 3 is an illustrative architecture 300 including a TrInc application 302 according to some implementations.

[0076] A trusted increment application, referred to as TrInc 302, generalizes the notarization application. TrInc 302 maintains a counter (e.g., per application) for each user such that each user (e.g., each application) receives consecutive values with no gaps in between. TrInc 302 is a general tool in distributed systems because TrInc 302 can be used for various functions such as, for example, tamper-proof audit logs, Byzantine fault-tolerant replicated state machines, verifying that untrusted file servers behave correctly, etc. TrInc 302 can include a create counter 304 module for enabling creation of a counter 306. The counter 306 can include N counters (where N > 0), such as a first counter 308 through an Nth counter 310. TrInc 302 can include a private key module 312, a public key certificate module 314, an encryption processing module 316, a meta counter 318, and a TrInc state indicator 320.

[0077] TRINC Remote Equivalence. Except that TrInc has multiple counters (each counter has a tuple (Ki; vi)) and a meta counter that is initially set to 0, the TrInc application 302 is remotely equivalent to a state machine like the notarization application. Instead of a notarization transition, TrInc has:

[0078] • Given input (create; K,

[0079] o Set i := meta_counter,

[0080] o Increment meta_counter, and

[0081] o Set (Ki, vi) := (K, 0).

[0082] • Given input (advance; i, v new , Msg, UserSig), set V old = vi in counter tuple i.

[0083] o If vold <= vnew and VerifySigKi(v new || Msg, UserSig), set v i := v new and output Sig PrivateKey (OP-CTR-ADV || encode(i) || encode(V old ) || encode(V new ) || Msg.

[0084] Password Hash ("PASSHASH") application. The password hash application can make loss of a password database harmless. For example, an attacker can steal the database and mount an offline attack. Even if the database is properly hashed and salted, low-entropy passwords can make the database vulnerable. By using password hashing, unauthorized access to the hashed password does not compromise security.

[0085] PASSHASH remote equivalence. The PassHash application is remotely equivalent to the following state machine. The state consists of a byte string Secret, which is initialized to the first 32 random bytes read from trusted hardware. Given input (hash, Salt, Password), the passhash application outputs SHA256(Secret || Salt || Password). Here, SHA256 is used as an example of a hashing algorithm. It should be understood that other similar hashing techniques can be used in place of SHA.

[0086] Based on this specification, a password hashed without a secret is useless to an offline attacker, and brute force guessing attacks are infeasible even for low-entropy passwords.

[0087] Differential Privacy ("DIFFPRIV") service. The differential privacy application provides a differential privacy service and is an example of a larger application with a more abstract specification (e.g., compared to TrInc, etc.). The differential privacy application can collect sensitive data from contributors and allow an analyst to study the aggregated database. The differential privacy application can guarantee differential privacy for each contributor, e.g., the answers provided to the analyst cannot be distinguished from the answers provided if the data of the contributor was omitted. An algorithm A is differentially private with privacy ε if for any set of answers S and any pair of databases D1 and D2 differing in a single row, there exists P[A(D1) ∈ S] <= λ · [A(D2) ∈ S], where the privacy parameter λ = e ε

[0088] Multiple queries with small privacy parameters can be equivalent to a single query with the product of the parameters. Starting with the privacy budget b = λ guaranteed to the contributor, each query Q with parameter λ Q is divided by the budget b' := b / λ Q (e.g., queries with λ Q >b can be rejected). For noisy computations, the sensitivity Δ of the query is computed, which is the maximum amount by which the query result can change if a single database row is changed. The analyst receives the true answer and a random noise value from a distribution parameterized by Δ. Noise distributions that only include rational numbers can be used because the noise distribution can be sampled exactly using an instruction set (e.g., the x86 instruction set).​

[0089] DIFFPRIV Remote Equivalence. DiffPriv applications are remotely equivalent to state machines with the following states:

[0090] • Key pair and trusted hardware are initialized similarly to Notary applications;

[0091] • Remaining budget b, a real number; and

[0092] • Sequence of rows, each row consisting of a list of duplicate detection random numbers and integer column values;

[0093] and including transitions to connect to the application, initialize the database, add rows, and execute queries.

[0094] Sensitivity. The value Δ used as the sensitivity parameter in the noise calculation formula of the specification can be the actual sensitivity of the query result. For example, if A(D) is defined as the answer computed by the application when the database is D, then for any two databases D1 and D2, |A(D1) - A(D2)| < Δ.

[0095] For verifiability, Airavat-style queries can be used, where each query is a mapper that transforms rows to a single value, and a reducer that aggregates the result set, such that only the reducer affects sensitivity. Analysts can provide arbitrary mappers; DiffPriv can provide sensitivity properties for individual reducers and. DiffPriv applications can take RowMin and RowMax parameters to clip each mapper output value to a certain range. For example:

[0096]

[0097]

[0098] DiffPriv applications are verified to satisfy the predicate that associates the reducer output sensitivity with D used in noise generation.

[0099] Full System Verification

[0100] Figure 4is a diagram of a illustrative architecture of a verified software stack (e.g., system) 400 according to some implementations. The software stack 400 includes one or more applications 402, one or more common applications 404, standard libraries 406, a user datagram protocol / internet (UDP / IP) 408 protocol module, an Ethernet 410 protocol module, a network driver 412, one or more data types 414, a hash algorithm 416 module, a trusted hardware driver 418, a public key encryption system 420 encryption system, a BigNum library 422 (e.g., for performing encryption functions), a CoreMath library 424 (e.g., for performing scientific, engineering, or computationally intensive calculations), and an operating system 426 (e.g., a verified microkernel). In some cases, the hash algorithm 416 can use a secure hash algorithm (SHA). Of course, different implementations can use other different hash algorithms. The applications 402 can include verified applications 428 and unverified applications 430. The unverified applications 430 can execute in a verified environment (e.g., a sandbox) 432 that prevents the unverified applications 430 from maliciously harming (e.g., corrupting) the remainder of the software stack 400, such as the verified applications 428, the operating system 426, etc.

[0101] The applications 402 can include PassHash, Notary, TrInc, DiffPriv, another application, or any combination thereof. The operating system 426 can include lazy launch, IOMMU, segmentation, page tables, another operating system utility, or any combination thereof. When a computer is running in a trusted state, e.g., verified software is executing on trusted hardware, loading unverified software can cause the state of the entire computer to become untrusted. Thus, the computer can switch between a trusted state and an untrusted state. A central processing unit (CPU) of the hardware can provide a hardware instruction that takes a memory location as a parameter, resets the hardware platform, atomically measures the unverified software located at that memory location, extends the unverified software into one of the computer’s PCRs, and begins executing the unverified software in a hardware-protected environment. This process of executing unverified software in a hardware-protected environment is referred to as lazy launch. As part of the lazy launch, the CPU can disable direct memory (DMA) access to the physical memory page containing the secure bootloader, disable interrupts and hardware debuggers to prevent previously-executing code from regaining control, reset the dynamic registers of PCRs 17 through 23 to 0, and execute the unverified software in protected mode. The lazy launch can provide security benefits similar to rebooting the computer (e.g., starting from a clean slate) while bypassing the overhead of a full reboot (i.e., peripherals remain enabled, the BIOS and bootloader are not invoked, memory contents remain intact, etc.).

[0102] The software code can include annotations, such as loop invariants, preconditions, and postconditions, to enable verification of the software code. The annotations can be viewed as lemmas built into the high-level theorems.

[0103] To illustrate the steps for end-to-end verification of the system 400, several propositions are described. For ease of understanding, these propositions are briefly described in simple English below. It should be understood that the actual propositions can take the form of annotations in the high-level implementation 112. The propositions described below are several key propositions that can be used in verifying the system 400.

[0104] IOMMU configuration. A verified application (e.g., a solid application) can configure an input-output memory management unit (IOMMU) to partition memory into device-accessible and application- specific private memory, such that non-device operations access the application-specific private memory. Assembly language instruction specifications can be used to determine that non-device memory operations only access the application-specific private memory that has been protected by a device exclusion vector (simple IOMMU) of the hardware.

[0105] Some central processing units (CPUs) can provide features such as dynamic root of trust for measurement (DRTM), also known as delayed launch, for measurement. The DRTM can reset the CPU to a known state, store a measurement (e.g., hash code) of in-memory code pointed to by an argument of an instruction, and jump to the code. After the delayed launch, the hardware can provide software program control of the CPU and 64 kilobytes (KB) of protected memory. To use more than 64 KB, the software program can first extend the protection of the IOMMU based on specifications associated with the configuration of the IOMMU. After extending the protection of the IOMMU, the program can satisfy preconditions for assembly language instructions to access memory outside the 64 KB region.

[0106] Devices cannot see secret data, e.g., only non-secret data can be passed to the devices. Assembly language instruction specifications can indicate that data is stored to device-accessible memory, i.e., memory that the IOMMU allows the devices to access, only stores non-secret data O (e.g., O L = O R ). More specifically, the left and right executions can generate the same sequence of devices that store the same values to the same addresses, modulo timing and liveness. Informally, liveness is the requirement that "good things eventually happen" in a system or algorithm (i.e., the system "makes progress"). Eventual consistency of a database is an example of a liveness property.

[0107] To prove O L = O RThe input and output paths of the implementation code can be annotated with relationship annotations. The input and output paths can include the application event loop and network stack. For example, the Ethernet, Internet Protocol (IP), and UDP layers can maintain relationship attributes on packets.

[0108] Key in TPM. The application can correctly extend the public key into the PCR of the trusted hardware (e.g., PCR 19). The private key can be generated using a random number generator (e.g., TPM randomness) and never leaves the trusted hardware platform.

[0109] Proof. The application can generate a correct trusted hardware proof after extending its public key into the PCR.

[0110] Inference 2 - Secure Channel. If the client receives the public key and proof, and has verified that the PCR code values (e.g., PCR 17, PCR 18) match the verified application’s PCR code values, and has verified that the PCR data values (e.g., PCR 19) match the public key, and the credentials (e.g., certificates, tokens, etc.) show that the proof came from a trusted hardware provider, then the client can use the public key to establish a secure channel directly to the verified application.

[0111] Encryption library

[0112] Hash. The hash algorithm 416 can conform to various standards (e.g., FIPS 180-4 and FIPS 198-1).

[0113] Lemma 11 - Encryption System Operations. The public key encryption system 420 can generate keys using continuous randomness (e.g., not selectively sampled) from trusted hardware, and pass primality tests (e.g., Miller-Rabin primality or similar tests). The public key encryption system 420 can include commands for encryption, decryption, signing, and verification (including padding), and can produce byte arrays that conform to standards (e.g., PKCS 1.5 and RSA standards).

[0114] For some types of encryption primitives, such as hash functions, the verifier 108 can verify functional correctness. Encryption system specifications derived from RFC 2313 (e.g., RSA specifications) define encryption and signing operations as modular exponentiation operations on keys composed of ideal integers. Key generation specifications can use keys derived from two random prime numbers. The BigNum 420 library can be used to implement encryption primitives. The BigNum 420 library can use arrays of 32-bit words to implement integers of arbitrary precision, providing operations for public key encryption systems (e.g., RSA, etc.) such as division and computation modulo. The BigNum 420 library can include BigRat, which extends the provided operations to rational numbers, which can be used for differential privacy.

[0115] BIGNUM / BIGRAT correctness. Each BigNum / BigRat operation can produce a value that represents a correct infinite-precision integer or real number.

[0116] In some implementations, the compiler 114 can not be included in the trusted computing base (TCB). If the compiler 114 is not part of the TCB, then the assembly language implementation 116 can be verified by the verifier 108. The verifier 108 can use several invariants produced by the compiler 114, such as type safety, array bound safety, and passing stack safety.

[0117] Type safety. The contents of each value and heap object can be verified to accurately represent the expected contents according to the type system used by the high-level language, such that operations on each value and heap object do not cause a runtime type error.

[0118] Array bound safety. Array operations can use indices that are within the bounds of the array.

[0119] Passing stack safety. When a particular program is called, the stack has sufficient stack space remaining for stack operations by the particular program and any additional programs that the particular program can call. The stack can include a data structure for storing information about the program. For example, when a program calls a subprogram (e.g., a subroutine), a snapshot of the program can be stored in the stack before the subprogram is called. The snapshot can include, for example, values of variables used by the program, etc. When the subprogram has completed execution, the snapshot stored in the stack can be used to restore the state of the program so that execution of the program can continue. The term “stack” refers to a collection of one or more entities stored in a data structure. Operations on the collection can include a CALL operation (also referred to as a push) for adding an entity to the collection and a RET operation (also referred to as a pop) for removing an entity from the collection. The relationship between the push and pop operations is such that the stack can be implemented as a last-in-first-out (LIFO) data structure. In a LIFO data structure, the last entity added to the structure can be the first entity to be removed. This is equivalent to performing push and pop operations at only one end of the data structure storing the collection, which is referred to as the top of the stack.

[0120] Even if the high-level language is a type-safe language, the verifier 108 can not assume that the compiler 114 preserves type safety. Thus, the verifier 108 can verify type safety at the assembly language level by establishing type invariants for data structures representing high-level language values. For example, pointers in a data structure can point to values of an expected type, and arbitrary integers can not be used as pointers. Such type invariants can be maintained throughout the assembly language code and can exist in loop invariants, preconditions, postconditions, or any combination thereof. Thus, an external assembly language type checker can not be used to check the compiled assembly language implementation 116. Instead, a single verification process (e.g., performed by the verifier 108) can be used for both hand-written assembly language code and compiled code (e.g., the assembly language implementation 116).

[0121] High-level properties are preserved. Given a high-level language precondition, each program proof output stack state and registers satisfy the high-level language postcondition. The compiler 114 can maintain high-level language annotations, such as preconditions, postconditions, and loop invariants. In addition, the compiler 114 can link the high-level annotations to low-level stack and register values, such that operations on the stack and register values satisfy the correctness theorems associated with the high-level language implementation 112 and the corresponding high-level specification 102.

[0122] Operating system invariants. Operating system data structure invariants can be maintained.

[0123] Garbage collection correctness. The memory manager of the operating system 426 can create object representations for the high-level language that conform to the semantics of the high-level language. The garbage collector of the operating system 426 can maintain correct object data and can not leave dangling pointers, even if the garbage collector moves objects in memory. The garbage collector can reclaim garbage stored in memory, e.g., objects in memory that have been allocated but are no longer in use. For example, if the system does not have any pointers to an allocated portion of memory, the allocated portion of memory can be reclaimed by the garbage collector for use by another program.

[0124] Figure 5Is an illustrative architecture 500 of verified software executing on secure hardware according to some implementations. The trusted hardware 502 can include hardware that provides a hardware-based root of trust, such as a trusted platform module (TPM). For example, the trusted hardware 502 can record information associated with software execution on the trusted hardware 502 during a boot cycle in a manner that can be securely reported to a remote party via an attestation protocol. The trusted hardware 502 can maintain records about the current boot cycle in the form of a chain of hashes maintained in platform configuration registers (PCRs). Software applications executing on the trusted hardware 502 can add new information to the PCRs via an extend operation. The extend operation can update the PCR to include a hash of the previous PCR value concatenated with the new information. The trusted hardware can hold a private key 552 (e.g., an RSA key) that does not leave the trusted hardware and that can be used to sign the values in the PCRs to attest to the current state of the trusted hardware. The trusted hardware can attest that the corresponding public key is held by the authentic hardware trusted hardware to prevent impersonation of the software.

[0125] The architecture 500 can use delayed launch, also known as dynamic root of trust for measurement (DRTM). To help remove boot code from the trusted computing base (TCB) of the secure operating system and hypervisor, the central processing unit (CPU) can provide an instruction to reset the CPU to a known state, store a measurement (hash) of code in memory pointed to by an argument of the instruction in the trusted hardware, and jump to the code. This "delayed launch" or DRTM allows untrusted software to boot on a newly reset CPU, configure the device, load software, and then verifiably launch trusted software. The CPU instruction can put the CPU into a well-specified reset state, leaving the device and memory as-is. The CPU instruction can disable interrupts, configure the CPU's device exclusion vector (DEV) and bit-based vector IOMMU to prevent devices from accessing a portion of memory, reset the trusted hardware's PCR 17 to a fixed value, and extend the register with a hash of a portion of memory. Finally, execution can jump to the code. Thus, a software application can take advantage of any booting before its execution while protecting the software application from other software applications and other devices. In this way, the trusted hardware can attest to a remote verifier that the code is running in a protected environment.

[0126] Hardware 502 can execute verified boot 504 of verified low-level code 506 (e.g., a microkernel or low-level operating system). Hardware 502 can execute and record verified launch 508 of verified low-level code 506. Verified low-level code 506 can include verified device interfaces 510, verified interrupt handlers 512, verified threads 514, and verified garbage collector 516. Verified device interfaces 510 can provide various types of input / output (I / O) to enable architecture 500 to communicate with other devices. Verified interrupt handlers 512 can be used to perform various actions when an interrupt is received. Verified threads 514 can be part of a verified microkernel or other low-level operating system. Verified garbage collector 516 can collect allocated portions of memory that are no longer in use (e.g., no longer referenced) and can be reclaimed and reused.

[0127] Verified high-level code 518 (e.g., applications, utilities, libraries, etc.) can execute on top of verified low-level code 506. Verified high-level code 518 can include hash algorithm (e.g., SHA or similar algorithm) module 520, code to modify bits and arrays 522, code to perform cryptographic system (e.g., RSA) encryption and signing 524, large integer module 526, math module 528, trusted hardware driver 530, UDP / IP module 532, Ethernet module 534, and network driver 536. It should be understood that hash algorithm module 520 is merely an example of one type of hash algorithm that can be used, and other implementations can use other types of hash algorithms.

[0128] Various applications can execute on top of verified high-level code 518, such as trusted components 538 (e.g., TrInc, etc.), cryptographic vault 540, and privacy database 542 (e.g., providing differential privacy).

[0129] At runtime, the application 544 can provide the public key 546 and a credential 548 (e.g., a certificate, a token, etc.) to a user (or a second application). The credential 548 can be signed by the trusted hardware 502 (e.g., using a hash 550) to show that the public key 546 is provided by a binary with a particular hash (e.g., corresponding to the entire software system). The user (or second application) can check that the hash 550 matches a previously observed hash (e.g., observed in the offline step). The trusted hardware 502 can provide a credential 548 signed by the hardware provider that indicates that the public key 546 is held exclusively by a trusted hardware platform (e.g., the trusted hardware 502). If the credential 548 is valid and the hash 550 is correct, then the verified (e.g., verifiably secure) binary that includes the application 544 creates the public key 546, and the recipient (e.g., the user or second application) can interact with trust and trust that messages signed with the public key 546 come from the application 544 and trust that messages sent to the application 544 encrypted with the public key 546 will only be seen by the application 544.

[0130] Thus, at runtime, the user (or second application) trusts that the core hardware 502 is not tampered with but does not need to trust the software or peripherals associated with the hardware 502. Messages from the application 544 can be signed with the public key 546 of the application 544. The trusted hardware 502 can attest that the public key 546 comes from an executable with a cryptographic hash code (e.g., SHA1, SHA256, etc.) that should match a hash code obtained previously (e.g., from the offline step). The provider of the trusted hardware 502 can attest that the public key 546 is held by the hardware 502, e.g., a trusted hardware platform.

[0131] An operating system (e.g., the operating system 426 of the Figure 4 The operating system can be modified and / or extended to eliminate unverified boot code and provide a security-oriented memory model. The operating system can also verifiably adhere to security specifications for applications executing at higher levels. For example, a conventional operating system can depend on unverified boot loaders and unverified basic input / output systems (BIOS) for system configuration (e.g., device enumeration, device configuration, memory segmentation, memory paging, etc.). In some implementations, a verified BIOS and boot loader can be provided. In other implementations, rather than verifying an existing BIOS and boot loader, a delayed launch (e.g., DRTM) can be used to verifiably place the architecture 500 in a secure state and begin execution of the verified low-level code 506 and the verified high-level code 518. While a delayed launch simplifies the boot process, the delayed launch can use verified code to configure the CPU after launch.

[0132] After the delay start, the application can have control of a portion of the CPU and memory (e.g., 64 kb). However, code running before the delay start can theoretically replace the device firmware or maliciously configure the device direct memory access (DMA) buffers. A CPU-based input / output memory management unit (IOMMU) can protect this portion of memory from being accessed by unauthorized entities.

[0133] The ESP can be a register pointing to the top of the stack. The EAX can be an accumulator register. In an example of the x86 processor architecture, memory addresses can be specified with two parts called a segment and an offset. The segment can specify the beginning of a block of memory allocated by the system, and the offset can be an index into the block of memory. Segment values can be stored in segment registers, such as the CS register, which can include the segment of the current instruction, and the SS register, which can include the stack segment. Memory can be accessed using implicit or explicit segment descriptors. A segment descriptor can include a base address and a limit. If an attempt is made to access a memory address M using a descriptor with base B and limit L, the actual memory address accessed is B + M, unless B + M > L. In the latter case, a segment fault can occur. Access to the stack (e.g., via push and pop instructions) can use the SS segment, and access to code (e.g., to read the next instruction) can use the CS segment.

[0134] The formal specification of the architecture 500 can specify that upon booting to the verified low-level code 518, the EAX can point to the verified low-level code 518, the ESP can include EAX + 64 KB, and the SS and CS can describe flat segments. The DEV can be configured to protect the EAX and the ESP from external devices. The EAX mode is a mode of operation for block ciphers that is designed to provide both authentication and privacy for messages (authenticated encryption) with a two-pass scheme, one pass for privacy and one pass for authenticity for each block.

[0135] The idiomatic specification can describe how to navigate and protect a large portion of memory. For example, satisfying the specification can provide upper and lower bounds of memory that the application can access cover a larger portion of memory. The DEV is a type of IOMMU that can be configured to prevent a device from reading or writing a specified range of memory, such as (EAX, EAX + 64 KB).

[0136] Conventional specification can not describe all behaviors of a PCI or DEV, but can describe the effect of a particular sequence of operations; for example, rather than showing a complete roadmap to a particular destination (e.g., with all possible paths) and step-by-step pointing. Code attempting to use the hardware 502 can not be verifiable, although the hardware 502 can support other configurations. Using conventional specification can reduce the complexity of the specification, making the specification faster and easier to verify. For example, a conventional specification for x86 segmentation can specify that a segment descriptor can have any base address, but a length of 232and a privilege level (DPL) of 0.

[0137] A microkernel or operating system specification can specify the effect of segment access, including SS for CALL and RET instructions. CALL and RET instructions affect the stack, e.g., CALL pushes a previous instruction pointer value onto the stack, and RET pops a stored instruction pointer value from the stack to know where to continue execution. Both CALL and RET can access memory via SS.

[0138] The specification can also specify descriptor shadow cache behavior; for example, segment behavior can depend on a shadow value cached in the processor when using a selector register rather than a descriptor in memory. Such a specification enables verification that after a late launch, software code accesses the correct memory region, and that an unauthorized application and / or device cannot tamper with (e.g., access) the memory region. For example, in some implementations, a DEV can be configured to expose 128MB of protected memory to a verified operating system (e.g., a microkernel), and the remainder of the memory can be used for I / O to devices.

[0139] To provide information flow guarantees about an application (e.g., to prove that an application cannot determine secret data), a boundary between verified code and the outside world (e.g., unverified code) can be defined. For example, a memory region protected by a DEV can be considered internal, while other memory regions (e.g., I / O and memory-mapped device regions) are considered unverified, as a malicious device can read or write memory at any time, and even a benign device (e.g., a network card) can expose data to unverified code and unverified devices by design. The boundary between verified and unverified code can be specified at the assembly code level.

[0140] For memory regions that can be proven to be protected by the DEV, the specification can dictate a standard model of loads and stores, e.g., a value written to memory via a store instruction can later be read back via a load instruction. In contrast, when reading and writing to memory that is not protected by the DEV, there is no such guarantee, as a malicious device could in theory change the value in memory at any time. The specification can dictate that a software instruction that has a visible effect on untrusted memory has a precondition that the argument provided to the instruction is public. For example, the arguments (e.g., address and value) of a store instruction can have the precondition that the arguments are public. As another example, the address argument of a load instruction can have the precondition that the argument is public, as other devices can be able to observe the address being accessed. A public value can be obtained via a load from untrusted memory, a constant value in the code, or a value decrypted by a trusted application-specific policy (e.g., a policy that causes an encrypted secret to be transmitted). Any value that does not originate from the outside world (e.g., a random value obtained from trusted hardware used to generate the key) can not be marked as public, and thus can not leave the system except via a decryption policy.

[0141] Because the information flow can be enforced at the machine code level on load and store instructions, the specification for correctness of the network card or other network layer can not be used in the trusted computing base (TCB). Instead, the architecture 500 can repeatedly prove that the interaction with the network produces public data. For example, a driver can propagate a public input received from a network card through the network stack, where the packet is processed by the Ethernet, IP, and UDP layers. Each layer can prove that the layer did not pollute the packet with non-public data, so that the application ends up receiving a stream of public packets. When transmitting, the top of the network stack implementation (e.g., the UDP layer) can request that the data received from the application has been specified as public data. This allows the network stack implementation to prove that the data provided to the IP layer is public, and so on, until the network driver eventually proves that the individual bytes stored by the network driver to untrusted memory are public data and thus safe to release.

[0142] To enable applications to provide remote attestation and obtain secure randomness, a convention specification is used for trusted hardware and verified trusted hardware drivers 530. The trusted hardware specification can include pseudo-instructions that drive state machines of trusted hardware of a two-level (e.g., low-level and high-level) model. In the low-level state machine, instructions can write or read to a data buffer one byte at a time, and commands are executed using data and control registers loading. In the higher-level state machine, command execution can interpret commands according to trusted hardware semantics. For example, commands that can be conventioned can include trusted hardware commands such as Extend (e.g., add data to a PCR), Object Independent Attestation Protocol (OIAP), LoadKey (e.g., load a key into trusted hardware), Quote2 (e.g., perform a quote operation), and GetRand (e.g., random number generator).

[0143] Extend, OIAP, LoadKey, and Quote2 can be included in a standard library (e.g., Figure 4 of the standard library 406) and can be used to attest that a private key held by a verified application treats the private key as secure data (e.g., by making it impossible to determine the private key). The GetRand command can provide a source of strong randomness for generating cryptographic keys. The specification can specify a stream of random values that can be sequentially displayed by GetRand. For example, a specification for a library routine to create a public key (e.g., RSA) that uses random input can sequentially draw from the stream of random values provided by GetRand, thereby preventing malicious cherry-picking.

[0144] Figure 6 is an illustrative architecture 600 including offline operations 602 and runtime operations 604 according to some implementations. The offline operations 602 can include verifying that a software system (e.g., software stack) complies with a corresponding system specification. The runtime operations 604 can include enabling an external application 606 or a user 608 to attest that a software system executing on hardware (e.g., trusted hardware) is secure and unimpaired. For example, the runtime operations 604 can enable the external application 606 (or the user 608) to send and receive messages to and from an application of a verified software system without other parties (e.g., other applications or other hardware devices) being able to access the content of the sent and received messages. For example, the sent and received messages can be encrypted using a key that enables the application and the external application to decrypt the messages. Other entities (e.g., other software or other hardware) can not be able to decrypt the messages.

[0145] In offline operation 602, the external application 606 or user 608 can accept the formal high-level specification 102, can trust the verification tool (e.g., the verifier 108), can trust that the service provider will not physically alter the hardware 502, and can trust that the hardware specification (e.g., the hardware specification of the instruction set and the trusted hardware) models the hardware 502. Any other thing, such as one or more of the application (e.g., the application 544), cryptographic libraries, sequence and math libraries, the operating system (e.g., the operating system 426), and the compiler, can be considered untrusted because they are only verified against the high-level specification 102.

[0146] In Figure 1 After the high-level implementation 112 has been compiled to the assembly language implementation 116 and verified by the verifier 108 against the low-level specification 106, the assembler 118 can be used to create the machine code implementation 120. The machine code implementation 120 can be used to create a binary file (e.g., executable by one or more processors of the trusted hardware), such as the software system binary file 612. A hash function (e.g., a cryptographic hash function or other hash function) can be used to create a hash code 550 (e.g., a cryptographic hash code) based on the software system binary file 612. The software system binary file 612 can include the verified software stack 400.

[0147] During runtime operation 604, the application 544 can send the public key 546 and the first credential 548 to the external application 606 or user 608. The first credential 548 can include the trusted hardware signature 614 (e.g., signed by the trusted hardware 502) to indicate that the public key 546 is provided by the software system binary file 612. The external application 606 (or the user 608) can verify that the hash code 616 associated with the trusted hardware signature 614 matches the hash code 550 generated during offline operation 602.

[0148] The trusted hardware 502 can provide a second credential 618 that includes a signature 620 of a trusted hardware provider signed by a provider of the trusted hardware 502. The second credential 618 can indicate a trusted hardware key 622 that is exclusively held by a legitimate hardware trusted hardware (e.g., the trusted hardware 502).

[0149] External application 606 (or user 608) can authenticate (e.g., verify) that credentials 548 and 618 are valid. External application 606 (or user 608) can verify that hash code 616 matches hash code 550, for example, indicating that the verified software system binary 612 is used to create public key 546. After authenticating the first credential 548, the second credential 618, and hash code 616, external application 606 (or user 608) can securely interact with the application of the verified software stack 400. For example, when external application 606 (or user 608) receives a message (such as a first message 624 including public key 546), the recipient can authenticate the first message 624 as being sent by application 544 using public key 546. External application 606 (or user 608) can trust that the content of the first message 624 cannot be accessed by other entities, such as other applications 626, other external applications, other external hardware, etc. As another example, when an external application 606 (or user 608) sends a message (such as a second message 628 including public key 546), the external application 606 (or user 608) can decrypt the second message 628, while other entities (e.g., other applications 626, other external applications, other external hardware, etc.) cannot decrypt the second message 628. In this way, the external application 606 (or user 608) can securely interact with the verified software stack 400 executing on trusted hardware 502 in a manner that allows the content of messages (e.g., messages 624 and 628) to be accessible to the sender and receiver but not to other entities (e.g., other software applications, external hardware, etc.).

[0150] Example process

[0151] exist Figure 7 , 8 In the flowcharts of Figures 9 and 9, each box represents one or more operations that can be implemented using hardware, software, or a combination thereof. In the context of software, a box represents a computer-executable instruction that, when executed by one or more processors, causes the processor to perform the operation. Typically, computer-executable instructions include routines, programs, objects, modules, components, data structures, etc., that perform a specific function or implement a specific abstract data type. The order in which the boxes are described is not intended to be construed as limiting, and any number of the described operations can be combined in any order and / or in parallel to implement the process. For the purposes of discussion, as mentioned above, processes 700, 800, and 900 are described with reference to architectures 100, 200, 300, 400, or 500; however, other models, frameworks, systems, and environments may implement these processes.

[0152] Figure 7 This is a flowchart based on some implementations, including an example process 700 for receiving a public key from a software application. Process 700 can be... Figure 6 External applications 606 execution.

[0153] At 702, a public key can be received from a software application executing on trusted hardware. For example, in Figure 6 application 606 can receive the public key 546 from the application 544. The public key 546 can be generated based on a private key 552 of the application 544.

[0154] At 704, a first credential (e.g., certificate, token, etc.) signed by the trusted hardware can be received. The first credential can identify that the public key is provided by a binary associated with a particular hash code. At 706, the first credential can be authenticated. For example, in Figure 6 application 606 can receive the first credential 548 and authenticate the first credential 548 (e.g., using the trusted hardware signature 614).

[0155] At 708, a second credential can be received from the trusted hardware. At 710, the second credential can be authenticated. For example, in Figure 6 application 606 can receive the second credential 618 and authenticate the trusted hardware provider’s signature 620.

[0156] At 712, a determination can be made that the particular hash matches the second hash provided offline (e.g., prior to execution of a software system including the software application). For example, in Figure 6 application 606 can determine that the hash code 616 received during the runtime operation 604 matches the hash code 550 received during the offline operation 602.

[0157] At 714, a first message signed with the public key can be received from the software application. For example, in Figure 6 application 606 can receive the first message 624 signed with the public key 546. The public key 546 can indicate that the contents of the first message 624 are accessible to the application 544 and the external application 606, but not accessible to other applications and other devices.

[0158] At 716, a second message signed with the public key can be sent to the software application. For example, in Figure 6 application 606 can send the second message 628 signed with the public key 546. The public key 546 can indicate that the contents of the second message 628 are accessible to the application 544 and the external application 606, but not accessible to other applications and other devices.

[0159] Accordingly, after receiving the credentials 548 and 618 attesting to the identity of the verified software and the identity of the trusted hardware on which the verified software is executed, the external application can send and receive messages using the public key. The contents of the sent and received messages can be accessible to the sender and receiver, but not accessible to other entities, providing a secure interaction.

[0160] Figure 8 is a flowchart including an example process 800 of executing a software system that has been verified to conform to a software specification, according to some implementations. The process 800 can be performed by trusted hardware, such as Figure 5 and 6 trusted hardware 502.

[0161] At 802, a verified software system can be executed. For example, in Figure 6 , the verified software stack 400 can be executed by the trusted hardware 502.

[0162] At 804, a public key can be sent by the software application. At 806, a first credential (e.g., a certificate, a token, etc.) signed by the trusted hardware can be sent. The first credential can identify the public key as being associated with a binary (e.g., a binary of system software). Thus, the first credential can attest to the identity of the software. At 808, a second credential signed by a provider of the trusted hardware can be sent. The second credential can attest to the identity of the hardware (e.g., the trusted hardware) on which the software is executing. For example, in Figure 6 , the application 544 can send the public key 546, the first credential 548, and the second credential 618 to the external application 606. The first credential 548 can attest to the identity of the verified software stack 400, and the second credential 618 can attest to the identity of the trusted hardware 502. In this way, the external application 606 is guaranteed to be interacting with the application 544, and not with other software and / or other hardware that is impersonating the identity of the application 544.

[0163] At 810, a first message signed with the public key can be sent. At 812, a second message signed with the public key can be received. The application 544 can send the first message 624 to the external application 606. The external application 606 can send the second message 628 to the application 544. The credentials 548, 618, and the public key 546 can enable the external application 606 and the application 544 to interact knowing that the contents of the messages 624 and 628 are accessible to the external application 606 and the application 544, but not accessible to other entities, including other applications 626 of the verified software stack 400, as well as other software applications and / or hardware.

[0164] Thus, the credentials 548 and 618 can be used to attest to the identity of a verified software system (e.g., a verified software stack) and a trusted hardware, respectively. An application of the software system and an external application can exchange messages using the public key. The contents of the exchanged messages can be accessible to the application and the external application, but not accessible to other entities, providing a secure interaction.

[0165] Figure 9is a flow diagram including an example process 900 of performing verified boot of a software system, according to some implementations. Process 900 can be performed by trusted hardware, such as Figure 5 and 6 trusted hardware 502.

[0166] At 902, verified boot of a software system can be performed. The software system can have been previously verified (e.g., during an offline operation) to conform to a software specification. For example, in Figure 5 trusted hardware device 502 can perform verified boot 504 of at least verified low-level code 506.

[0167] At 904, a public key can be sent from the software application. The public key can be generated based on a private key known only to the software application. For example, in Figure 6 application 544 can generate public key 546 based on private key 552 and send public key 546 to external application 606.

[0168] At 906, a first credential signed by a trusted platform module can be sent. The first credential can identify that the public key is associated with (e.g., created using) a binary file. For example, in Figure 6 application 544 can send first credential 548 to external application 606. First credential 548 can attest to the identity of software system binary file 612, for example, by determining that hash code 616 (received during runtime operation 604) matches hash code 550 (provided during offline operation 602).

[0169] At 908, a second credential signed by a provider of the trusted hardware can be sent. The second credential can attest to the identity of the trusted hardware. For example, application 544 can send second credential 618 attesting to the identity of trusted hardware 502.

[0170] At 910, a first message signed with the public key can be sent. The public key can indicate that the first message was sent by the software application. At 912, the public key can be verified via attestation to correspond to a private key known only to the software system. At 914, a second message signed using the public key can be received. The second message can be readable by the software application, but not by other entities. For example, in Figure 6 application 544 can send first message 624 to external application 606. First message can include public key 546. Public key 546 can be verified via attestation to correspond to private key 552. Application 544 can receive second message 628 signed using public key 546. The contents of first message 624 and second message 628 can be accessible to application 544 and external application 606, but not accessible to other applications 626 and other external software and / or external devices.

[0171] Thus, the first credential 548 can attest to the identity of the verified software stack 400, and the second credential 618 can attest to the identity of the trusted hardware. Applications of the software system and external applications can exchange messages using public keys derived from private keys known only to the applications. The content of the exchanged messages can be accessible to the applications and external applications, but not accessible to other entities, providing a secure interaction.

[0172] Example Computing Devices and Environments

[0173] Figure 10 An example configuration of a computing device 1000 (e.g., a trusted computing base or trusted platform module) and environment that can be used to implement the modules and functionality described herein is shown. The computing device 1000 can include at least one processor 1002, memory 1004, a communication interface 1006, a display device 1008, other input / output (I / O) devices 1010, and one or more mass storage devices 1012, which are able to communicate with one another, such as via a system bus 1014 or other suitable connection.

[0174] The processor 1002 can be a single processing unit or multiple processing units, all of which can include single or multiple computing units or multiple cores. The processor 1002 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and / or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 1002 can be configured to fetch and execute computer-readable instructions stored in the memory 1004, the mass storage device 1012, or other computer-readable media.

[0175] The memory 1004 and the mass storage device 1012 are examples of computer storage media for storing instructions that are executed by the processor 1002 to perform the various functions described above. For example, the memory 1004 can generally include both volatile memory and nonvolatile memory (e.g., RAM, ROM, etc.). In addition, the mass storage device 1012 can generally include a hard disk drive, a solid state drive, removable media including external and removable drives, memory cards, flash memory, floppy disks, optical disks (e.g., CD or DVD), storage arrays, network attached storage, storage area networks, etc. Both the memory 1004 and the mass storage device 1012 can be collectively referred to herein as the memory or computer storage media, and can be non-transitory media that are capable of storing computer-readable, processor-executable program instructions as computer program code that can be executed by the processor 1002 as a particular machine configured for performing the operations and functionality described in the implementations herein.

[0176] The computing device 1000 can also include one or more communication interfaces 1006 for exchanging data to and from other devices, such as via a network, a direct connection, as described above. The communication interface 1006 can facilitate communication within a variety of network and protocol types, including wired networks (e.g., LAN, cable, etc.) and wireless networks (e.g., WLAN, cellular, satellite, etc.), the Internet, etc. The communication interface 1006 can also provide for communication with external storage devices (not shown), such as in a storage array, network attached storage, storage area network, etc.

[0177] In some implementations, a display device 1008, such as a monitor, can be included for displaying information and images to a user. Other I / O devices 1010 can be devices that receive various inputs from a user and provide various outputs to the user, and can include a keyboard, remote control, mouse, printer, audio input / output devices, etc.

[0178] The memory 1004 can include modules and software components that can be used to create a verified software system. For example, in a trusted computing environment that includes a software system that has been verified, the memory 1004 can include the application 402, the public application 404, the standard library 406, the UDP / IP 408, the Ethernet 410, the network driver 412, the data types 414, the hash algorithm 416, the trusted hardware driver 418, the public key encryption system 420, the BigNum 422, the CoreMath 424, and the operating system 426. In a software development system, as shown, the memory 1004 can also include the high-level specification 102, the specification translator 104, the low-level specification 106, the verifier 108, the verification results 110, the high-level implementation 112, the compiler 114, the assembly language implementation 116, the assembler 118, and the machine code implementation 120. Figure 1

[0179] ​The example systems and computing devices described herein are only examples of suitable environments and are not intended to suggest any limitation as to the scope of use or functionality of the processes, components, and features described herein. Thus, implementations herein can be operational with numerous environments or architectures, and the example discussed herein is not intended to limit the scope of the processes, components, and features described herein. Therefore, the implementations herein can be implemented in a variety of environments and architectures, and are not limited to just the environment and architecture described herein. For example, a process described herein can be implemented in software, hardware (e.g., fixed logic circuitry), or a combination of these implementations. As used herein, the term "module," "mechanism," or "component" refers to software, hardware, or a combination of these that is configured to implement prescribed functions. For example, in the case of a software implementation, the term "module," "mechanism," or "component" can refer to program code (and / or declarative-type instructions) that is executed on one or more processing devices (e.g., CPUs or processors) to perform prescribed tasks or operations. The program code can be stored in one or more computer-readable memory devices or other computer storage devices. Thus, the processes, components, and modules described herein can be implemented by a computer program product.

[0180] As used herein, "computer-readable media" includes computer storage media and communication media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read only memory (ROM), electrically erasable programmable ROM (EEPROM), flash memory or other memory technology, compact disc ROM (CD-ROM), digital versatile disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device.

[0181] In contrast, communication media can embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave. As defined herein, computer storage media does not include communication media.

[0182] Furthermore, the present disclosure provides various example implementations as described and illustrated in the accompanying drawings. The present disclosure is not, however, limited to the implementations described and illustrated herein, but can extend to other implementations as would be known or become known to those skilled in the art. References in the specification to "one implementation," "the implementation," "these implementations," "an example," "some examples," "some implementations," etc. indicate that the particular feature, structure, or characteristic being described is included in at least one implementation or example, and the appearances of such phrases in various places in the specification are not necessarily all referring to the same implementation or example. Provided various implementations and examples are not intended to be mutually exclusive, but can be used individually or in combination with each other, unless otherwise specified.

[0183] Examples

[0184] As a first example, a software system that has been verified to conform to a software specification can be executed by secure hardware. The software system can include an operating system and a software application. A public key can be sent from the software application to an external application that is external to the software system. A first credential signed by the secure hardware can be sent to the external application. The first credential can identify that the public key is associated with the software system. A second credential signed by a provider of the secure hardware can be sent to the external application. The second credential can attest to an identity of the secure hardware. The public key can be generated based on a private key that is known to the software system but unknown to other software systems. The second credential can be signed by the secure hardware using a second key. A first message signed with the public key can be sent. The public key can indicate that the first message was sent by the software system. A second message signed using the public key can be received. The second message can be readable by the software system but not by other software systems. The software system can be verified to conform to the software specification by determining that an assembly language implementation of the software system is capable of implementing a functionally correct version of the software specification. Verifying that the software system conforms to the software specification can include proving remote equivalence. Proving remote equivalence can include determining functional correctness of properties described in the software specification and proving non-interference between at least two components of the software system. As a second example, a verified boot of a software system can be performed. The software system can be verified to conform to a software specification. The software system can include a software application. A public key can be sent from the software application to an external application that is external to the software system. The public key can be generated based on a private key that is known to the software application but unknown to other software systems. A first credential signed by the secure hardware can be sent to the external application. The first credential can identify that the public key is provided by a binary of the software system. A second credential signed by a provider of the secure hardware can be sent to the external application. The second credential can attest to an identity of the secure hardware. Sending the second credential signed by the provider of the secure hardware to the external application can include: (1) signing the second credential using a second key to create a signed second credential, and (2) sending the signed second credential. A first message signed with the public key can be sent. The public key can indicate that the first message was sent by the software system. An attestation can attest to (1) the public key corresponds to the private key and (2) the private key is known only to the software system. A second message signed using the public key can be sent. The second message can be readable by the software system but not by other software systems. The software system can be verified to conform to the software specification prior to performing the verified boot of the software system. For example, the software system can be verified to conform to the software specification by proving remote equivalence. A server can include the secure hardware. The verification can include proving secure remote equivalence. A first component of the software system can be verified to be incapable of compromising a second component of the software system. As a third example, a public key can be received from a software system that is executed by secure hardware. A first credential signed by the secure hardware can be received. The first credential can attest that the public key is provided by a binary of the software system. A second credential that attests to an identity of the secure hardware can be received from the secure hardware.The first and second credentials can be authenticated to determine whether the public key is provided by a software system that is being executed by the secure hardware. The public key can be based on a private key that is known only to the software system. The second credential can be signed by a provider of the secure hardware. A system hash associated with the software system can be determined to match a prior hash that was provided prior to the software application beginning execution on the secure hardware. A first message signed with the public key can be received from the software system. The public key can be used to authenticate that the first message was sent by the software application. A second message signed with the public key can be sent to the software system. The second message can be decrypted using a private key maintained by the software application.

[0185] CONCLUSION

[0186] Although the subject matter has been described in language specific to structural features and / or methodological acts, the subject matter defined in the appended claims is not limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. The disclosure is intended to cover any and all modifications and variations from the example features and acts described, and the appended claims should be interpreted in the broadest and intended scope of the claims.

Claims

1. One or more computer-readable storage devices storing instructions that, when executed by one or more processors, program the one or more processors to perform actions against end-to-end secure hardware executing verified software, the actions comprising: A software system is executed by secure hardware. This software system has been verified at a low language level to conform to low-level software specifications. The software system includes an operating system and a notary application. The notary application includes a linker, a notary program, and a monotonically increasing counter. The notary program is configured to increment the monotonically increasing counter in response to a notary request and generate a signature based on the monotonically increasing counter. Certain components of the software system cannot corrupt other components of the software system. The software system, after verification, is used to generate a software system binary file. The software system is verified at the low language level to conform to the low-level software specifications by: Obtain a high-level specification and a high-level language implementation for the software system, wherein the high-level specification and the high-level language implementation are implemented using a high-level language designed to be verifiable; Use a compiler to compile the high-level language implementation into a low-level language implementation; The high-level specification is translated into the low-level software specification using a specification translator. as well as Use a validator to verify that the low-level language implementation conforms to the low-level software specification; Prove the remote equivalence between the software system and the low-level software specification, wherein the remote equivalence includes notarized remote equivalence, and proving the notarized remote equivalence includes: Prove that the input is non-interference, wherein the non-interference of the input indicates that the random numbers and messages transmitted by the notary application are based on public data; The correctness of the connection procedure is verified, wherein the correctness of the connection procedure indicates that the notary application uses a trusted hardware reference from the security hardware obtained by the notary application when the configuration register is in the required state. To prove the functional correctness of the notarization procedure, wherein the functional correctness of the notarization procedure instructs the notarization procedure to increment a counter and calculate the signature; and Prove that the output is non-interfering, wherein the non-interfering output indicates that the state machine output written to unprotected memory depends on the data and computation. The public key is sent from the notary application to an external application outside the software system, wherein the public key corresponds to a private key, and the private key is known to the software system. Sending a first credential signed by the secure hardware to the external application, wherein the first credential includes a trusted secure hardware signature, and the first credential indicates that the public key is associated with the software system by determining that the hash code of the software system binary file matches the hash code associated with the secure hardware signature; and A second credential is sent to the external application. The second credential includes a second certificate, which is signed using a second key provided by the provider of the security hardware. The second credential proves the identity of the security hardware.

2. The computer-readable storage device according to claim 1, wherein the action further comprises: Send a first message signed using the public key, the public key indicating that the first message was sent by the software system.

3. The computer-readable storage device according to claim 1, wherein the action further comprises: Receive a second message signed using the public key, the second message being readable by the software system but not readable by other software systems.

4. The computer-readable storage device according to claim 1, wherein the action further comprises: Determine the correct version of the assembly language implementation of the software system that implements the functionality of the low-level software specification.

5. A server for end-to-end secure hardware executing verified software, comprising: One or more processors; as well as A memory device storing instructions executable by the one or more processors to perform actions on end-to-end security hardware executing verified software, the actions including: The verified bootstrap of a software system is executed. This software system is verified at the low language level to conform to low-level software specifications. The software system includes an operating system and a notary application. The notary application includes a linker, a notary program, and a monotonically increasing counter. The notary program is configured to increment the monotonically increasing counter in response to a notary request and generate a signature based on the monotonically increasing counter. Furthermore, certain components of the software system do not corrupt other components of the software system. After verification, the software system is used to generate a software system binary file. The software system is verified at the low language level to conform to the low-level software specifications by the following: Obtain a high-level specification and a high-level language implementation for the software system, wherein the high-level specification and the high-level language implementation are implemented using a high-level language designed to be verifiable; Use a compiler to compile the high-level language implementation into a low-level language implementation; The high-level specification is translated into the low-level software specification using a specification translator; and Use a validator to verify that the low-level language implementation conforms to the low-level software specification; Prove the remote equivalence between the software system and the low-level software specification, wherein the remote equivalence includes notarized remote equivalence, and proving the notarized remote equivalence includes: Prove that the input is non-interference, wherein the non-interference of the input indicates that the random numbers and messages transmitted by the notary application are based on public data; The correctness of the connection procedure is verified, wherein the correctness of the connection procedure indicates that the notary application uses a trusted hardware reference from the security hardware obtained by the notary application when the configuration register is in the required state. To prove the functional correctness of the notarization procedure, wherein the functional correctness of the notarization procedure instructs the notarization procedure to increment a counter and calculate the signature; and Prove that the output is non-interfering, wherein the non-interfering output indicates that the state machine output written to unprotected memory depends on the data and computation. The public key, which is generated based on and corresponds to a private key, is sent from the notary application to an external application outside the software system. The private key is known to the software system. Sending a first certificate signed by secure hardware to the external application, wherein the first certificate includes a trusted secure hardware signature, and the first certificate identifies the public key associated with the software system by determining that the hash code of the software system binary matches the hash code associated with the secure hardware signature; and A second certificate is sent to the external application. The second certificate is signed using a second key provided by the provider of the security hardware. The second certificate proves the identity of the security hardware.

6. The server according to claim 5, wherein the action further includes: Determine the correct version of the assembly language implementation of the software system that implements the functionality of the low-level software specification.

7. The server according to claim 5, wherein the action further includes: Send a first message signed using the public key, the public key indicating that the first message was sent by the software system.

8. The server according to claim 7, wherein the action further includes: Prove that there is no interference between at least two components of the software system.

9. The server according to claim 5, wherein the action further includes: Send a second message signed using the public key, which is readable by the software system but not readable by other software systems.

10. The server according to claim 5, wherein: The server includes security hardware.

11. A computer-implemented method for end-to-end secure hardware executing verification software, comprising: An external application outside the software system receives a public key from the software system, which is executed by secure hardware and verified at a low language level to conform to a low-level software specification. The software system includes an operating system and a notary application. The notary application includes a connector, a notary program, and a monotonically increasing counter. The notary program is configured to increment the monotonically increasing counter in response to a notary request and generate a signature based on the monotonically increasing counter. Certain components of the software system cannot corrupt other components of the software system, and the public key corresponds to a private key known to the software system. The software system, after verification, is used to generate a software system binary file. The software system is verified at the low language level to conform to the low-level software specification by: Obtain a high-level specification and a high-level language implementation for the software system, wherein the high-level specification and the high-level language implementation are implemented using a high-level language designed to be verifiable; Use a compiler to compile the high-level language implementation into a low-level language implementation; The high-level specification is translated into the low-level software specification using a specification translator. as well as Use a validator to verify that the low-level language implementation conforms to the low-level software specification; Prove the remote equivalence between the software system and the low-level software specification, wherein the remote equivalence includes notarized remote equivalence, and proving the notarized remote equivalence includes: Prove that the input is non-interference, wherein the non-interference of the input indicates that the random numbers and messages transmitted by the notary application are based on public data; The correctness of the connection procedure is verified, wherein the correctness of the connection procedure indicates that the notary application uses a trusted hardware reference from the security hardware obtained by the notary application when the configuration register is in the required state. To prove the functional correctness of the notarization procedure, wherein the functional correctness of the notarization procedure instructs the notarization procedure to increment a counter and calculate the signature; and Prove that the output is non-interfering, wherein the non-interfering output indicates that the state machine output written to unprotected memory depends on the data and computation. The external application receives a first credential signed by the secure hardware, wherein the first credential includes a trusted secure hardware signature, and the first credential proves that the public key is associated with the software system by determining that the hash code of the software system binary file matches the hash code associated with the secure hardware signature; The external application receives a second credential, which includes a second certificate signed using a second key provided by the provider of the security hardware. The second credential verifies the identity of the security hardware. The external application authenticates the first credential and the second credential to determine that the public key was provided by the software system.

12. The computer-implemented method according to claim 11, further comprising: The system hash associated with the software system is determined to match a prior hash provided before the notary application begins execution on the security hardware.

13. The computer-implemented method according to claim 11, further comprising: Receive a first message signed using the public key from the software system; as well as The first message is sent by the notary application using the public key.

14. The computer-implemented method according to claim 11, further comprising: Send a second message signed using the public key to the software system, wherein the second message can be decrypted using a private key maintained by the notary application.

Images