Patent Grant
8914648
This disclosure relates generally to cryptography, and in particular but not exclusively, relates to the faithful execution of a software program.
Today's general-purpose processors, based on the Von Neumann Architecture, allow the execution of any arbitrary sequence of instructions. While this has lead to wide spread use, it also represents a major vulnerability as malicious code can easily be substituted and executed (as in a software virus). Since current processor architectures permit code and data to exist in the same memory space, it is relatively easy for one program to insert malicious code (as data) into the area in memory where another program is executing code. Programs that attempt to protect data from disclosure (for instance by using an encryption algorithm) are fraught with difficulty since the keys and instructions used by the program to encrypt its data can be inspected and reverse-engineered.
There are three general models of software development: waterfall, spiral, and evolutionary.
Non-limiting and non-exhaustive embodiments of the invention are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.
Embodiments of an architecture and various techniques for faithful execution of a software program are described herein. In the following description numerous specific details are set forth to provide a thorough understanding of the embodiments. One skilled in the relevant art will recognize, however, that the techniques described herein can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring certain aspects.
Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
Throughout this specification, several terms of art are used. These terms are to take on their ordinary meaning in the art from which they come, unless specifically defined herein or the context of their use would clearly suggest otherwise. A “trusted volume” or “protected volume” is defined herein as the computing machinery within which instructions and data are assumed to be physically protected from an adversary. “Program integrity” is the protection, which enables the detection of changes in the bits comprising a program as specified by a developer, for the time that the program is outside a trusted volume. Program integrity may include the aggregation of two elements: “instruction integrity” and “sequence integrity.” “Instruction integrity” is the detection of changes in the bits within an instruction or block of instructions. “Sequence integrity” is the detection in the locations of instructions within a program. “Faithful Execution” (FE) describes the protection of software that begins when the software leaves the control of the developer and ends with its proper execution within the trusted volume of a target processor. FE may be characterized as providing privacy, value integrity, and location integrity, as discussed below. A “translation” is an encryption process. Throughout this document a custom cipher is used; however, other ciphers may be used, such as Electronic Code Book (“ECB”), Data Encryption Standard (“DES”), Advanced Encryption Standard (“AES”), or otherwise. An “algorithm” describes the method by which plain text data is modified, in some embodiments forming a one-to-one relationship between the input bits and output bits. This is normally achieved by an arrangement of translations and XORs or XNORs (referring to the logic functions). It should be appreciated that the XOR function described throughout this document may be substituted for an XNOR function or other invertible logic functions. A “scheme” is the manner in which protection is applied and removed & checked. A scheme is based on an algorithm.
FE may be implemented using any of a number of “stateless” schemes or “stateful” schemes. The “state” described here refers to a connection between lexically adjacent instructions, or equivalently, groups of instructions (as in insuring that one instruction follows another during execution). The stateless implementation schemes protect each instruction individually: there is no connection between the protection applied to individual instructions. The stateful implementation schemes, on the other hand, protect a sequence of instructions, i.e. state is carried from one instruction to the next. In general, stateful implementations apply to memory regions that are accessed sequentially (e.g., instructions).
CAPA system 220 provides both the integrity (protection from illicit modification) and the confidentiality (privacy) of the instructions within trusted objects 205 even if the adversary owns CAPA system 220. In other words, the adversary cannot determine the sequence of instructions 240 within trusted objects 205, nor can the adversary change the instruction sequence in a goal-oriented way. FE protects instruction sequences from corruption or subversion during code distribution and storage by cryptographically sealing instructions 240, and at execution time, decrypting and authenticating instructions 240 within protected volume 215 of CAPA system 220. FE can be implemented by cryptographically “shrink-wrapping” executable code in a trusted verification facility (e.g., protected volume 210) where the correctness of the code has been determined. The shrink-wrap process may be performed using a compiler capable of performing the encryption algorithms/schemes discussed below.
At run-time, protection engine 230 (within protected volume 215), fetches the encrypted instructions (ciphertext) 240 from the unprotected system memory 225 of CAPA system 220, removes the protection to retrieve the original unencrypted or “plaintext instruction(s),” authenticates the instruction(s) and insures sequence integrity of a particular instruction, and provides the plaintext instruction(s) to target process 235 for execution, if the authentication is successful. In other words, protection engine 230 is a mechanism that removes cryptographic protection from instructions and data as they move from system memory 225 into target processor 235 and applies cryptographic protection as data moves in the other direction. This method of protection (i.e., FE) provides significant code assurance and privacy over a large portion of the software lifecycle. This lifecycle includes the period from the time the instructions are shrink-wrapped in a trusted facility (e.g., protected volume 210) through the distribution, installation, loading, and fetching phases, up to the point where the instructions or data are decoded by target processor 235.
FE differs from previous attempts to ensure code correctness in a variety of ways. For example, in addition to providing privacy, FE provides “sequence integrity” and “instruction integrity.” FE can be tailored to provide transparency (integrity only) and non-transparency (privacy and integrity) and for use with exportable algorithms.
In one embodiment CAPA system 220 may be implemented as a server, desktop computer, laptop computer, a special purpose processing system, various types of remotely located processing systems (e.g., satellite processor, surveillance processor, etc.), or otherwise. In one embodiment, protection engine 230 is a separate hardware processor core coupled between target processor 235 and system memory 225. Protection engine 230 may be implemented as an application specific integrated circuit (“ASIC”) or a general purpose programmable processor including its own programmable code store (e.g., flash memory). Protection engine 230 may be integrated onto a single semiconductor die along with target processor 235 or coupled to target processor 235 with a secure communication link. In yet another embodiment, target processor 235 may be a multiple core processor and protection engine 230 may be implemented as a virtual processor core, such as a virtual machine operating on a dedicated one of the processing cores of target processor 235.
In the illustrated embodiment, protection engine 230 includes an initialization vector (IV) register 250 for temporarily storing IV values. These IV values are periodically used by protection engine 230 to initialize the decryption algorithms for select instructions, discussed in detail below. The IV values may be cryptographically shrink-wrapped within trusted objects 205 using conventional encryption techniques, and/or securely stored within protected volume 215.
Value fields 405 represent memory fields for storing encrypted executable instructions (also referred to as encrypted plaintext instructions). The instructions encrypted within value fields 405 may be encrypted with a variety of different B Series or C Series protection schemes as discussed below. Integrity fields 410 represent memory fields for storing integrity values. In one embodiment, there is a one-to-one correspondence between value fields 405 and integrity fields 410. The integrity values are used as an integrity check to determine whether the contents of their corresponding value fields 405 have been modified, or in some cases, reordered. IV fields 415 store initialization vectors for initializing the decryption algorithms used in stateful encryption schemes. IV fields 415 are not used for some protection schemes, as is discussed below. Data fields 420 store encrypted program data, such as constants and variables. The program data may be protected using different encryption techniques than that applied to the instructions within values fields 405. However, since data is not typically accessed sequentially, the stateful C Series protection (disclosed below) is generally not suitable to protect data fields 420, while the stateless B Series (disclosed below), or other conventional encryption techniques may be used. Indication of encryption scheme 425 is accessed by protection engine 230 to determine which protection scheme and encryption algorithms are used by the instant trusted object to protect its instructions. In some embodiments, the protection scheme and encryption algorithms may be assumed and therefore indication of encryption scheme 425 may be omitted. Field mapping 430 provides a mapping for associating value fields 405 with their corresponding integrity fields 410 and IV fields 415 (when used). Field mapping 430 may be implemented using a variety of techniques including simple offsets and/or pointers. In some embodiments, the mapping may be assumed by protection engine 230 and therefore omitted. In some embodiments, one or more compression techniques may be applied to integrity fields 410 and/or IV fields 415 to reduce the protection/encryption overhead associated with these fields.
As described above, FE is a type of software protection that begins when the software leaves the control of a developer and ends within the Protected Volume of a target processor. FE can be provided by stateless or stateful schemes. The protected program is so protected for the entire time that it is in transit and while it sits in memory, even while it is in execution. The same may be true of all of the data used and generated by the program. Protection is removed from program instructions and data when they are within a Protected Volume (e.g., protected volume 215).
1.0 Scheme Series
FE is implemented on instructions and data via the use of special operations and special memory fields. There are a number of ways to arrange and use those operations and fields. As noted above, an arrangement of translations and XORs (or XNORs) is referred to as an “algorithm.” An algorithm and a particular use of fields is referred to as a “scheme.” Within this document a name is given to each such scheme as well as to (1) the default arrangement that uses no special operations and has no special fields and (2) the intermediate arrangements that use no special operations but do have special fields. The schemes are grouped into the following three “series”: (1) the A series consists of one scheme that is the default format (no protection provided), (2) the B series consists of stateless schemes, and (3) the C series consists of stateful schemes.
The A series consists of one scheme, for the default format. Instructions and data in this scheme are in plaintext; the instructions can run on a general purpose processor. The “geometry” for this scheme (i.e., the number of fields for each value) consists of a Value Field only. The scheme in this series does not use any special operations and has no special fields. As a consequence this scheme implements no protection and thus does not implement FE. The scheme is intended as a reference point for the other schemes.
The B series includes seven schemes, named B0, B1, . . . , B6. The digit in each name indicates the number of translations used in the scheme: scheme Bi+1 can be thought of as scheme Bi with an additional translation. In this way scheme Bi+1 “builds on” scheme Bi. Scheme B0, like A, does not implement FE. Its purpose is to provide a stepping stone to the other B series schemes. The geometry for all of the B series schemes is the same and includes two fields: (1) a Value Field that holds either an instruction or data, and (2) an associated Integrity Field.
The C series includes four schemes, named C0, C1, C2, and C3. The C series schemes, like the schemes in the B series, “build on” each other but, unlike the schemes in the B series, they do so by providing “Location Integrity” (discussed in section 3.0 ELEMENTS OF FE PROTECTION) over increasingly larger areas of memory. The C series schemes can all use the same algorithms, but scheme C3 has a memory scheme that more fully implements FE. C0, like A and B0, does not implement FE. Its purpose is to provide a stepping stone to the other C series schemes. The geometry for all of the C series schemes is the same and includes three fields: (1) a Value Field, (2) an associated Integrity Field, and (3) an associated IV Field.
The protection schemes are summarized in TABLE 1 (
The IV Field is used for removing protection from and applying protection to the Value and Integrity Fields. The IV Field may thus be protected separately from those two fields. In one embodiment, conventional protection/encryption techniques are used to protect and securely transmit the IV values/fields. The IV Field is retrieved into the Protected Volume prior to removing/applying protection to the Value and Integrity Fields.
2.0 Value Types & Notation
In this section we present the relationship between “value” and the following items: (1) memory types, (2) access patterns, (3) protection types, and (4) replay protection. For our purposes there are three types of “values”: (1) instructions, (2) constants, and (3) variables, where the union of constants and variables is the set called “data.” There are two types of memory: (1) read-only and (2) writable. And there are two types of access patterns: (1) sequential and (2) random.
All of the information in memory consists of “values.” The universe of values is partitioned into instructions and “data.” And data is further partitioned into “constants”—values that can be stored in read-only memory—and “variables”—values stored in writable memory and which includes the stack and the heap.
Instructions, like constants, may be stored in read-only memory. The access pattern for instructions is sequential. That is, we presume that if the current instruction is at address j, then the next instruction will be at address j+1. The access pattern for data—both constants and variables—is typically random. Stateless protection can be used for either access pattern. Stateful protection can also be used for either access pattern also, but the associated protection overhead practically constrains it to be used with the sequential access pattern.
Writable memory is subject to replay attacks since the value stored in any given location can change over the lifetime of the program. Read-only memory, on the other hand, is not subject to such attacks. The details presented above are summarized in TABLE 2, while TABLE 3 is a transposition of TABLE 2 (see
In this patent application we presume an ECB implementation of a substitution cipher for a translation function, T. For example, let the key, k, be 64 bits, consisting of 16 nibbles (each of which is 4 bits). Number the nibbles in k from 0 through 15 inclusive. If the 0th nibble of the input is for example 7, then the 0th nibble of the output is the value of the 7th nibble of the key. If the 1st nibble of the input is for example 3, then the 1st nibble of the output is the value of the 3rd nibble of the key. And so on for each nibble of the input. Thus, the 16 nibbles of k form a “translation table” for conversion of each input nibble into the corresponding output nibble and hence the name of this function. Note that this implementation of T is a bijection if and only if the key is invertible. If the key is non-invertible, then it is possible that T is neither injective nor surjective. Other implementations of T are possible, of course, such as DES and AES. However, for simplicity of discussion, the ECB implementation of a substitution cipher is assumed herein.
The notations used throughout this document are summarized in TABLE 4 (
3.0 Elements of FE Protection
FE may include the following three types of protection: (1) Privacy, (2) Value Integrity, and (3) Location Integrity. “Privacy” means that an adversary cannot determine the plaintext bits that comprise either a program (i.e., a sequence of instructions) or its associated data. Privacy implies encryption of some kind. “Value Integrity” means that the processor can determine the integrity of a value. That is, the processor can detect tampering of values during the time that values are outside of a Protected Volume. Value Integrity implies that there is an additional field in memory, called the “Integrity Field,” associated with each storage location and that the contents of the Integrity Field are a cryptographic function of the value stored at that location. The processor can use that additional field to determine the integrity of the value. “Location Integrity” means that an adversary cannot undetectably move any part of a program or its data either within the program (or its data space) or between programs (and their data spaces). This also means that the adversary cannot undetectably move parts of a program to a data space or vice versa. Location Integrity implies that each value is either directly associated with an address or else with another value that is recursively associated with an address.
4.0 No Protection: the A Series
The A series provides no inherent protection and is included in this nomenclature only for comparison with the schemes that do. There are no algorithms or schemes for this series. This section is included for the sake of completeness.
5.0 Stateless Protection: the B Series
Stateless protection, comprising the B series of schemes, implements FE by the use of: (1) a translation function, (2) an Integrity Field, and (3) “address anchoring.” In this section, the geometry, address anchoring, and algorithms, for the B series of schemes are described.
5.1 Geometry
Two fields are assumed for the B series schemes: (1) Value Field, and (2) Integrity Field. The Value Field holds a value—either an instruction or data (see TABLE 2,
5.2 Address Anchoring
Address anchoring provides Location Integrity by binding a value to an address. Address anchoring may be implemented by XORing (or other logic functions such as XNORing) the Integrity Field with a possibly encrypted form of the address. Let “programs” include for the nonce both instructions and data. With address anchoring, if two programs use different keys, then the adversary is unable to swap two values between the two programs undetectably, even if the adversary swaps the associated Integrity Fields as well, even if the values are identical and are at the same address in each program, because the keys are different. That is, address anchoring provides Location Integrity.
If the Integrity Field is anchored to the address, and if the Integrity Field is a function of the Value Field, then this mechanism implicitly anchors the Value Field as well. However Privacy may still need to be provided for the Value Field. One approach for providing Privacy is to use a translation function. That is, use “e(s)” for the Value Field. Unfortunately, this may be inadequate for instructions. Since the translation function operates in ECB mode, e(s) enables the adversary to use frequency analysis to determine s and then e (and d), thereby breaking the privacy protection. The value should thus be provided with additional protection. One approach is to address anchor the Value Field. The result is that both the Integrity Field and the Value Field are explicitly anchored but for different reasons—the former for Location Integrity; the latter for Privacy. For simplicity of implementation the same algorithm is used in the stateless schemes for both instructions and data, though some embodiments may use different protection algorithms for instructions versus data.
Address anchoring suggests that the address used to remove protection be the same as the address that was used to apply protection. When protection is applied, which occurs at compile time, the Protection Engine uses the logical address (i.e., the address as viewed by the program, where the first address is usually zero) for each value. When protection is removed, which occurs at run time, the Protection Engine is given a physical address (i.e., the address as viewed by the hardware). The Protection Engine uses the physical address to specify to memory the set of bits to fetch. But when the bits arrive, the Protection Engine removes protection from them, and for this step, the Protection Engine uses the logical address, the address used when protection was applied. The determination of the logical address depends on the organization of the memory of the particular platform in use, namely on the use of pages and segments. There are four cases, as shown in TABLE 5 (
In case 1, memory is neither paged nor segmented and as a consequence the logical and physical addresses are the same. In this case the address at which the code is loaded (i.e., the physical address) is the relocated address (i.e., the base address of the code). Memory on early Cray computers, for example, was of this type.
In the other three cases the logical address is different from the physical address. In cases 2 and 3 memory is paged, possibly with segments, and as a consequence the logical address can be computed by the expression (P*S)+D, where P is the page number (starting at zero) of the program or segment, S is the page size, and D is the offset within the page. In case 4, memory uses segments without pages; as a consequence the logical address is the offset within the segment.
In cases 2, 3, and 4, the Protection Engine obtains from the target processor information in addition to the physical address, namely either the logical address itself or the values that will enable the Protection Engine to compute the logical address. The provision of this additional data by the target processor breaks the transparency of the Protection Engine.
Note that in case 1 the adversary can learn the logical address: it is the physical address sent to memory outside of the Protected Volume. However, for cases 2 through 4, the adversary cannot find out the logical address since (1) it differs from the physical address and (2) the adversary does not have access to the data within the Protected Volume that the processor sends to the Protection Engine that enables Protection Engine to determine the logical address. In this document, the conservative stand is taken, and case 1 assumed.
Some of the algorithms for the C series of schemes (described below), use address anchoring; other C series algorithms provide Location Integrity based on an instruction's place in a sequence of instructions—that is, they use “chaining.”
5.3 Stateless Algorithms
In this section the algorithms for the B series of schemes are constructed using the translation function and the XOR operation (or other logical operations such as XNOR). The algorithms are constructed based on the number of translations they use. The minimum number of translations is one, the maximum used herein is six, which correspond to Algorithm 1 and Algorithm 6, respectively. One of the considerations in the design of these schemes is to minimize the computational overhead required to perform the translations as instructions and data are being fetched (and, in the case of data, stored). The purpose of the “incremental” exploration here of these algorithms is to provide the minimum acceptable protection for an application while incurring the least computational overhead, thus maximizing the instruction processing rate.
The following discussion presents the application of protection, not its removal. The process for removing protection is presented in TABLE 8 (
Below it is shown that Algorithm 1 uses one XOR operation for each value and Algorithms 2-6 use two XOR operations. Algorithms 1 and 3-6 use at least three parallel steps; Algorithm 2 uses at least two parallel steps. In all of the algorithms in this section key k1 is invertible—otherwise we cannot recover the plaintext contents of the value—and in Algorithms 5 and 6 key k5 also is invertible for the same reason. All the other keys—i.e., k2, k3, k4, and k6—may be non-invertible.
Recall from the discussion in Section 5.2 that the Integrity Field is a function of the Value Field and that both the Value and the Integrity Fields are address anchored. This means that both fields are a function of both the value and the address.
Algorithm 1 uses one translation. Algorithm 1 is created by building on B0 (no protection) with the addition of one translation:
Value Field: k1(v⊕a); Integrity Field: k1(v⊕a) (Algorithm 1)
In order to limit Algorithm 1 to one translation, the Integrity Field is assumed to be a copy of the Value Field (as opposed to the Integrity Field being computed independently of the Value Field). As a result, for this algorithm, the Integrity Field is superfluous—a “don't care” field—providing only a rudimentary form of Value Integrity.
Before moving on to Algorithm 2, the possibilities for an Integrity Field within the set of algorithms that have exactly one translation is explored. An Identity Field is constructed that is different from the Value Field in two ways, but, as will be shown, neither way is satisfactory. The first way is to XOR the Integrity Field with the address, as shown in Algorithm 1a:
Value Field: k1(v⊕a); Integrity Field: a⊕(k1(v⊕a)). (Algorithm 1a)
The adversary is assumed to know the address, so this algorithm provides no increase in Value Integrity over Algorithm 1. Another way to construct an Integrity Field with only one translation is to use the value, as shown in Algorithm 1b:
Value Field: k1(v⊕a); Integrity Field: v⊕(k1(v⊕a)). (Algorithm 1b)
But this has the effect of eliminating Privacy since it enables the adversary to obtain v with one XOR operation:
Value Field⊕Integrity Field=(k1(v⊕a))⊕(v⊕(k1(v⊕a)))=v
An alternative to Algorithm 1 is to apply the XOR operation as the last step in the algorithm instead of the first:
Value Field: v⊕k1(a); Integrity Field: v⊕k1(a) (Algorithm 1c)
Value Field: k1(v)⊕a; Integrity Field: k1(v)⊕a (Algorithm 1d)
However, this is weak since this would allow the adversary to exploit re-use. In the case of Algorithm 1c, the adversary can use frequency analysis on v to isolate k1(a). Since the adversary knows the address, a, he can then easily determine k1. In the case of Algorithm 1d, the adversary can eliminate “a” by an XOR—this provides no Location Integrity.
Algorithm 2 allows two translations. Algorithm 2 is created by building on Algorithm 1 with the addition of a second translation. This second translation allows Algorithm 2 to make meaningful use of the Integrity Field:
Value Field: k1(v⊕a); Integrity Field: k2(v⊕a) (Algorithm 2)
As noted above, k1 is invertible (to recover the value) but k2 need not be invertible, since, when it comes time to check the Value Integrity, the Integrity Field can be recalculated and matched, rather than inverted (decrypted).
Algorithm 3 allows three translations. Algorithm 3 is created by building on Algorithm 2 with the addition of a third translation. One of Algorithm 2's weaknesses is its reuse of the input (v⊕a). Another weakness is its use of only two keys. There are four choices of where to apply the third translation: to either the value or the address argument in either the Value or the Integrity Field. The address argument needs protection more than the value argument since the adversary knows the address but not the value. And the Value Field needs protection more than the Integrity Field since k1 is an invertible key and invertible keys are weaker than non-invertible keys (based on keyspace size). So the third translation is applied to the address argument in the Value Field to arrive at Algorithm 3:
Value Field: k1(v⊕k3(a)); Integrity Field: k2(v⊕a) (Algorithm 3)
Note that in Algorithm 3 (as in all of the algorithms presented in this section) k1 is invertible, but both k2 and k3 may be non-invertible.
Algorithm 4 allows four translations. Algorithm 4 is created by building on Algorithm 3 with the addition of a fourth translation. Using the same reasoning used in deciding where to place the third translation in Algorithm 3, a desirable place to apply the fourth translation is to the address argument of the Integrity Field:
Value Field: k1(v⊕k3(a)); Integrity Field: k2(v⊕k4(a)) (Algorithm 4)
Algorithm 5 allows five translations. Algorithm 5 is created by building on Algorithm 4 with the addition of a fifth translation. The fifth translation may be added to the value argument in either the Value Field or the Integrity Field. The weakest part of Algorithm 4 is the Value Field since k1 is invertible (and translations are already applied to both address arguments). So the fifth translation is added to the value argument in the Value Field:
Value Field: k1(k5(v)⊕k3(a)); Integrity Field: k2(v⊕k4(a)) (Algorithm 5)
Algorithm 6 allows six translations. Algorithm 6 is created by building on Algorithm 5 with the addition of a translation in the only remaining place, to the value argument in the Value Field:
Value Field: k1(k5(v)⊕k3(a)); Integrity Field: k2(k6(v)⊕k4(a)) (Algorithm 6)
Since kx(ky(v)) can be reduced to kz(y) for all x and y, there is no gain in strength in algorithms that allow more than six translations. In addition there is no gain in strength in algorithms that use more than two XOR operations (or other logic operations such as XNOR) for any of the algorithms.
Algorithms 1 through 6 presented above are summarized in TABLE 6 (
5.4 Stateless B Series Schemes
In this section the stateless schemes are identified. Scheme Bi uses Algorithm i, for 1≦i≦6, as described above. This section converts the generic keys such as “k1” used in the description of the algorithms into specific key types such as “e” and “ƒ” (see Table 4,
For each algorithm a set of specific keys defines a scheme. Each such set of chosen keys is called a “configuration” and is uniquely described by an ordered tuple of keys. For example the configuration for Algorithm 2 as shown in Table 6 (
The configurations for schemes B1 through B6 are <e>, <ef>, <egf>, <egfh>, <ecgfh>, and <ecgfih>, respectively, as shown in Table 7 (
As an aside, it is possible to develop schemes for Algorithms 2 through 6 using only one invertible key and its inverse. To maximize strength, the same key is not applied to the same argument within a given scheme, as shown in Table 9 (
6.0 Stateful Protection: the C Series
Stateful protection, comprising the C series of schemes, provides protection by linking instructions together via “state” as explained below.
6.1 Geometry
The C series schemes use three fields: (1) Instruction Field, (2) Integrity Field, and (3) Initialization Vector (IV). The Instruction Field holds the instruction. Since stateful protection applies to the sequential access pattern only (see Table 2,
6.2 Stateful Algorithms
Before presenting the algorithms for the C series of schemes, the keys that these schemes use are first described. Recall from Table 4 (
The basis for FE in the stateful schemes is “chaining,” which is the cryptographic association of one instruction Pi with some other instruction Pj, which in turn is associated with yet another instruction Pk to form a chain of instructions where normally i=j−1 and j=k−1. The cryptographic mode used as the basis for the association between instructions is Plaintext Block Chaining (“PBC”) and is shown diagrammatically in
PBC mode provides Privacy by the use of the translation function. The PBC mode provides location integrity by chaining one instruction to its lexically succeeding instruction. As long as the first instruction in the sequence is at the correct address, Location Integrity is provided. The IV for the decryption of a given sequence is the same as the IV used when the sequence was encrypted. Unlike stateless protection algorithms, there is no address explicitly included in PBC. Unfortunately, the PBC mode by itself provides only a weak form of Value Integrity. Because PBC does not self-synchronize, an error in a given ciphertext input continues to propagate to subsequent inputs, corrupting all subsequent outputs (for this reason PBC is not a good candidate for use in communication channels). A single violation of integrity will cause PBC to generate random instructions, sending the computation off the rails. It cannot be predicted in an off-the-rails situation when (or even if) PBC will generate an illegal instruction that will halt the program, but it can be predicted with certainty that PBC will never right itself and get the program back on track. However for high-consequence applications even stronger control is needed. For those applications the processor should halt with certainty on the bad instruction itself, not possibly halt and not later on. For this purpose the implementation of PBC mode is augmented with an Integrity Field.
The Integrity Field is a function of the instruction itself. Re-use of either the plaintext or ciphertext instruction is avoided, since re-use is weak cryptographically. The Integrity Field should thus use an otherwise-unused translation of the plaintext instruction. One way to implement PBC with an Integrity Field is to combine the Integrity Field with the Instruction Field, folding both into the same chain. That is, the chain of state is formed by interleaving the sequence of Instruction Fields with their associated Integrity Fields, as shown in Algorithm 8, which, for ease of reference, is named “Combined Chain,” in Table 11 (
Note the use of f(P0) as the argument for the second term in the Integrity Field. The translation prevents re-use of P0. When removing protection, P0 is not simply extracted from f(P0) because f is non-invertible. Note also that the application-of-protection-portion of Algorithm 8 uses three translations and two XOR operations (or other logical operations) in at least three parallel steps for each value.
The alternative to the “combined” chain approach shown in Table 11 is a “separate” chain approach in which the Integrity Field is not included in the combined chain. The possibilities for this approach are explored in Algorithms 9 through 13. In each case, the Instruction Chain uses PBC mode, as in Algorithm 7 shown in Table 7. The variation in the algorithms is in the handling of the Integrity Fields.
In the separate chain approach there are two chains, the Instruction Chain and the Integrity Chain. If one imagines these two chains hanging vertically, then each link in each chain is connected to its vertically adjacent links in that chain. The problem that needs to be solved is providing a connection horizontally between the chains. Each link in an Integrity Chain should have some connection—direct or indirect—with the link in the Instruction Chain corresponding to the associated instruction. If there is no such connection, then the Integrity Chain is of little or no value.
The Integrity Chain uses the value of its associated instruction as an argument. In this way the horizontal linkage is provided. Granted, this allows the adversary to swap two chains without detection, but only if the instruction sequences (and the keys used to provide the protection) are identical, and both sequences start at the same address, in which case the adversary has gained no ground.
A technique for providing additional horizontal linkage is to use the address of the associated instruction in the Integrity Chain. This technique has been previously introduced as “address anchoring.” If address anchoring is used, then algorithms with “unchained” Integrity Fields (see Algorithms 12 and 13 below) can be considered.
Algorithm 9, “Two Chains,” illustrated in Table 12, uses the instruction value to provide the horizontal connection and does not use address anchoring. The other four algorithms presented in this section, Algorithms 10 through 13, use address anchoring to provide additional horizontal connection.
Algorithm 9 uses two separate chains: one for instructions and the other for integrity values. Horizontal connections between links in the two chains are made by the shared use of the instruction. The first element of the Integrity Chain translates the IV instead of using it raw, so to speak, in order to avoid re-use. And note that the second element of the ith link in the Integrity Chain is different than the first element of the i+1st link, again to avoid re-use. Algorithm 9 requires three translations and two XOR operations (or other logical operations) in at least two parallel steps for each value.
The remainder of the algorithms in this section use address anchoring in the Integrity Chain or Field, depending upon the algorithm. If the Integrity Fields are anchored in Algorithm 9, we arrive at Algorithm 10, “Anchored Chain,” shown in Table 13 (the “Chain” in the title of the algorithm refers to the Integrity Chain). Note that there are two independent chains in Algorithm 10, just as there were in Algorithm 9—one for instructions and the other for integrity values. Like Algorithm 9, the first element of the Integrity Chain in Algorithm 10 translates the IV to avoid re-use. Algorithm 10 uses three translations (except for the first value which requires four) and three XOR operations in at least four parallel steps for each value.
If the maximum reasonable translations are applied to Algorithm 10, then Algorithm 11, “Anchored Chain (Maximized)” is obtained, shown in Table 14 (
If the constraint for the Integrity Fields to be chained is removed, we arrive at Algorithm 12, “Anchored Fields,” so named since the Integrity Fields are address anchored but do not form a chain, shown in Table 15 (
If all reasonable translations are applied to Algorithm 12, we arrive at Algorithm 13, “Anchored Fields (Maximized),” shown in Table 16 (
The Algorithms for stateful protection are summarized in Table 17 (
6.3 IV Types
In this Section the three types of initialization vectors (IVs) used by the C series schemes are described: (1) instruction IV, (2) block IV, and (3) jump IV. All three IV types are of the same form and all are stored in an IV Field inside a Protected Volume. The types differ in three respects: (1) the nature of the associated instruction, (2) the instruction that uses the IV, (3) whether duplicate IV values in the same program are either discouraged or required.
An “instruction IV” may be specified for any instruction. The instruction IV is used to help decode and verify the associated instruction. Duplicate IV values in the same program are discouraged. A “block IV” is just like an instruction IV except that a block IV may be specified only for the first instruction in a block. A “block” is a sequence of instructions for which both of the following two conditions hold: (1) no instruction in the sequence is the target of a jump except possibly the first instruction, and (2) there is no jump instruction in the sequence except possibly the last instruction. That is, blocks are defined such that (a) jump targets, if any, are at the beginning of a block and (b) jump instructions, if any, are at the end of a block. A “jump IV” may be specified only for a jump instruction. The jump IV is used by the target of the associated instruction. Duplicate IV values in the same program are required for multiple jump instructions with the same target since the jump instruction must have the same IV, regardless of the origin of the jump. The jump IV for different targets in the same program should be different. The C1 scheme uses instruction IVs, one for each instruction. The C2 scheme uses block IVs, one for each block. The C3 scheme uses one block IV (for the first block) and multiple jump IVs, one value for each jump target. In all cases, IV fields should be stored within a Protected Volume, safe from the adversary. The characteristics of the three IV types are summarized in Table 19 (
6.4 Stateful C Series Schemes
As noted above, all of the diagrams in this section are shown using Algorithm 8, “Combined Chain.” The diagrams in this section show the formulas for applying protection only, while the formulas for removing protection are shown in Table 11.
6.4.1 C1 Bit-Chaining Stageful (BiCF)
Scheme C1 uses only instruction IVs. There is an instruction IV for every instruction. As a conceptual aide and to provide a foundation for the “instruction-chaining” and “block-chaining” terms introduced below, this scheme can be considered to perform “bit-chaining,” that is, to chain the bits of an instruction together. However, this description is inaccurate since each link of the chain consists of an entire instruction. If the name bit-chaining were accurate, then each link of the chain would consist of a single bit: the first bit would be encrypted and then XORed with an IV consisting of a single bit, then the second bit would be encrypted and subsequently XORed with the plaintext for that first bit, and so on.
This scheme does not protect against instruction-swapping (i.e., swapping two instructions along with their corresponding IV and Integrity Fields) (see C2 for that) nor block-swapping (i.e., swapping two entire blocks along with their corresponding IV and Integrity Fields) (see C3 for that).
Note that C1, unlike C2 and C3, can be appropriately used for data (i.e., for a random memory-access pattern), since C1 does not connect adjacent memory locations via state. C1 is thus actually a stateless scheme, with a separate key (the IV) for each value field, even though the way it is presented gives it the appearance of a stateful scheme. This is acceptable since the purpose of C1 is to serve as a stepping stone to C2 and then on to C3, both of which are truly stateful schemes.
A fragment of the beginning of a program in the C1 format is shown diagrammatically in Table 20 (
When a program in C1 executes, the Protection Engine recovers the ith plaintext, Pi, as follows:
Pi=d(VFi⊕ivi),
where
Scheme C2 uses block IVs. There is one block IV for each block. This scheme chains together instructions, hence the name. This scheme protects against both bit—and instruction—swapping but not against block-swapping (see C3 for that).
A fragment of the beginning of a program in the C2 format is shown diagrammatically in Table 21 (
This scheme and the next both use a register (e.g., IV register 250 in
In the C2 scheme the Protection Engine uses as IVs all IV fields that are non-zero. If an instruction's IV field is zero, the Protection Engine uses the IV register instead. At end of each instruction's execution, the Protection Engine sets the IV register with a freshly-computed value that will be used as the IV (i.e., for the first element of the formula for the Instruction Field for the next instruction), if the IV field for that next instruction is zero. If this freshly-computed value is also zero, the Protection Engine should halt on a bad IV. Note, the IV field for the first instruction of a program should be non-zero.
When a program using C2 executes, the Protection Engine recovers the ith plaintext, Pi, as follows:
Pi=d(VFi⊕iv)
where
Scheme C3 uses one block IV (for the first block) and possibly multiple jump IVs (one value for each jump target). For example, if addresses 20 and 80 of a given program both jump to the block beginning at address 50, then in the C3 format the plaintext value of the IV Field for addresses 20 and 80 is the same and is the IV used by instruction 50. Recall that IVs are considered “cryptovariables” or “critical variables” and are thus encrypted when outside of a Protected Volume. This scheme chains blocks together, hence the name. This scheme protects against bit-, instruction-, and block-swapping.
A fragment of the beginning of a program in the C3 format is shown diagrammatically in Table 22 which shows (1) the beginning of two blocks, one starting at address 0 and a second starting at address 50, and (2) two jump instructions, one at address 20 and a second at address 80, both of which jump to address 50.
As noted above, the C2 and C3 schemes both use a register to hold an IV. However the two schemes differ in their use of an instruction's IV field: the C2 scheme uses it to find the IV for the current instruction; the C3 scheme uses it to find the IV for the next instruction.
In this scheme, C3, the IV for the current instruction is always in the IV register. At the end of each instruction's execution, the Protection Engine sets the IV register with the freshly-computed IV, if the IV field is zero; otherwise, it sets the IV register with the IV field. Note that the IV for the first instruction of a program must be in the IV register prior to execution. If <address, IV> pairs are used to specify IVs, then an out-of-range address such as −1 could be used for the address for this initial IV.
When a program using C3 executes, the Protection Engine recovers the ith plaintext, Pi, as follows:
Pi=d(VFi⊕ivr)
where
In a process block 2105, software code to which protection is to be applied is selected. In a decision block 2110, the stateless or stateful encryption type is selected. As mentioned above, stateless encryption may be applied to both sequential values (e.g., instructions) and non-sequential values (e.g., data), while stateful is best suited for sequential values.
If stateless protection is selected, then process 2100 continues to a process block 2115. In process block 2115, the stateless encryption algorithm and scheme are selected (e.g., Algorithms 1 through 6 summarized in Table 6 and B Series Schemes B1-B6 summarized in Table 7). Once the protection algorithm and scheme are selected, the encryption of the software code can commence. In a process block 2120, the protection algorithm is applied to each value to generate encrypted values for insertion into the value fields. In the case of instructions, each plaintext instruction is encrypted and inserted into a value field (e.g., value fields 405) of the ciphertext. In a process block 2125, an integrity value is generated for each value field. The integrity value may be a function of its corresponding plaintext instruct or a function of its corresponding plaintext instruction and its corresponding memory location or address (if address anchoring is applied). Once generated, each integrity value is inserted into an integrity field (e.g., integrity fields 410) of the ciphertext.
In a process block 2130, a field mapping (e.g., field mapping 430) is optionally generated. The field mapping enables the decryptor or protection engine to map value fields to their corresponding integrity fields during removal of protection. In embodiments where the field mapping is assumed, creation of the field mapping may be omitted. In some embodiment, the field mapping may also be encrypted using techniques described herein or other conventional techniques. In some embodiments, the field mapping is not encrypted.
In a process block 2135, an indication of the encryption scheme (e.g., indication of encryption scheme 425) is generated and appended to the ciphertext. In embodiments where the encryption scheme is assumed, creation of the indication may be omitted.
Finally, in process block 2140, the various fields are shrink-wrapped into a single ciphertext entity (e.g., trusted object 400) for distribution or communication outside of a trusted volume. Shrink-wrapping may include compressing or otherwise bundling the various fields for collective distribution outside a trusted volume.
Returning to decision block 2110, if stateful protection is selected, then process 2100 continues to a process block 2145. In process block 2145, the stateful encryption algorithm and scheme are selected (e.g., Algorithms 7 through 13 summarized in Table 17 and C Series Schemes C1-C3 summarized in Table 23). Once the protection algorithm and scheme are selected, the encryption of the software code can commence. In a process block 2150, IV values are generated. The IV values may include instruction IV values, block IV values, and/or jump IV values, as discussed above. Once generated, the IV values are inserted into IV fields of the ciphertext (e.g., IV fields 415). Furthermore, it should be noted that there is not necessarily a one-to-one correspondence between IV fields and value fields, since a single block IV value corresponds to a block if sequential instructions. In a process block 2155, the protection algorithm is applied to each value to generate encrypted values for insertion into the value fields. In the case of instructions, each plaintext instruction is encrypted and inserted into a value field (e.g., value fields 405) of the ciphertext. Each value field is a function of at least its corresponding plaintext instruction and an IV value or a previous plaintext instruction. In a process block 2160, an integrity value is generated for each value field. The integrity value is a function of at least its corresponding plaintext instruct. Once generated, each integrity value is inserted into an integrity field (e.g., integrity fields 410) of the ciphertext. Once the value fields, integrity fields, and IV fields of the trust object have been populated, process 2100 continues to process block 2130, as described above.
In a process block 2205, the protection (encryption) scheme used to protect the ciphertext or trusted object is identified. In one embodiment, the protection scheme is identified by protection engine 230 with reference to indication of encryption scheme 425 embedded within or appended to trusted object 400. In alternative embodiments, the encryption scheme may be assumed by protection engine 230. In a process block 2210, protection engine 230 inspects field mapping 430 to determine how the various fields of trusted object 400 have been stored to associate value fields 405 with their corresponding integrity fields 410 and IV fields 415. If the mapping is assumed or otherwise already available to protection engine 230, then process block 2210 may be omitted.
Once the protection scheme has been identified and the field mappings determined, process 2200 enters a loop 2215-2250 to fetch, decrypt, and execute each instruction of the ciphertext. In some embodiments, protection engine 230 may operate transparently to target processor 235 who executes the decrypted instructions provided to it by protection engine 230.
In a process block 2215, protection engine 230 fetches instruction/from a value field in system memory 225. In some embodiments, protection engine 230 may also prefetch an integrity field and IV field corresponding to the current value field at the same time. In some embodiments, all IV fields may be prefetched in advance as a group. In a decision block 2220, protection engine 230 determines whether the decryption algorithm needs to be initialized with an IV value for the fetched instruction j. The decryption algorithm may need to be initialized if the fetch instruction is the first instruction of a sequential instruction block, if the instruction is the target of a jump instruction, as well as, other scenarios as described above. If initialization is required, then the corresponding IV value is fetched in a process block 2225.
In a process block 2230, the fetched value field j is decrypted to extract its corresponding plaintext instruction. In a process block 2235, the corresponding integrity field j is re-computed based at least in part on the decrypted plaintext instruction, and in some embodiments depending upon the protection scheme and protection algorithm also based at least in part on the memory address location of instruction j. In decision block 2240, the re-computed integrity value is compared to an integrity value fetched from an integrity field within the ciphertext mapped to the current value field being decrypted. If the two integrity values match, then the plaintext instruction is authenticated. If they do not match, then execution is terminated by protection engine 230 (process block 2245) before protection engine 230 delivers the unauthenticated plaintext instruction to target processor 235 for execution. On the other hand, if the integrity values do match, then protection engine 230 delivers the plaintext instruction j to target processor 235 for immediate execution (process block 2250). Loop 2215-2250 continues at process block 2255 moving onto the next instruction and looping back to process block 2215 until the entire program has been executed or a fault occurs (e.g., an instruction fails to authenticate), at which point execution is complete (process block 2260).
The processes explained above are described in terms of computer software and hardware. The techniques described may constitute machine-executable instructions embodied within a machine (e.g., computer) readable storage medium, that when executed by a machine will cause the machine to perform the operations described. Additionally, the processes may be embodied within hardware, such as an application specific integrated circuit (“ASIC”) or the like.
A machine-readable storage medium includes any mechanism that provides (i.e., stores) information in a form accessible by a machine (e.g., a computer, network device, personal digital assistant, manufacturing tool, any device with a set of one or more processors, etc.). For example, a machine-readable storage medium includes recordable/non-recordable media (e.g., read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc.).
The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.
These modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.
This invention was developed with Government support under Contract No. DE-AC04-94AL85000 between Sandia Corporation and the U.S. Department of Energy. The U.S. Government has certain rights in this invention.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4977596 | Maestas et al. | Dec 1990 | A |
| 6560727 | Pierson et al. | May 2003 | B1 |
| 7362859 | Robertson et al. | Apr 2008 | B1 |
| 20100070953 | Velten et al. | Mar 2010 | A1 |
| Entry |
|---|
| Tarman, Thomas D. et al, “On the Use of Trusted Objects to Enforce Isolation Between Processes and Data”, IEEE 0-7803-7436-3/02, 2002, pp. 115-119. |
| Pierson, Lyndon G. et al, “Secure Computing Using Cryptographic Assurance of Execution Correctness”, IEEE 0-7803-8506-3/02, 2004, pp. 239-246. |
| Campbell, Philip L. et al, “Trusted Objects”, IEEE 0-7803-7001-5/01, 2001, pp. 247-248. |
| Pierson, Lyndon G. et al., “Protection of Distributed Internetworked Computers”, IEEE 0-7803-9245-0/05, 2005, 4 pages. |
| Campbell, Philip L. et al, “Principles of Faithful Execution in the Implementation of Trusted Objects”, Sandia Report SAND2003-2328, Jul. 2003, 33 pages, Sandia National Laboratories, Albuquerque, New Mexico. |
| Campbell, Philip L. et al, “Prototyping Faithful Execution in a Java Virtual Machine”, Sandia Report SAND2003-2327, Jul. 2003, 69 pages, Sandia National Laboratories, Albuquerque, New Mexico. |
