Saving and retrieving data based on symmetric key encryption

The present invention relates to data storage and retrieval, and specifically to data storage and retrieval based on symmetric key encryption.

Protecting data on a computer and, as a result, ensuring that data is only disclosed to the right parties has become an important concern for users. The types of data that users want to protect can range from confidential work-related or personal documents, bank account numbers, credit card numbers, social insurance numbers, and more. In addition, it is important for some third parties to protect the data on the user's computer from unauthorized use or access. For example, credit card issuers want their credit card numbers to be protected, and as a result, their numbers are not disclosed to malicious programs or parties that hack computers, and music companies protect their music from copying. Hoping to do, movie studios want to protect their movies from copying.

<p><nplcit num="1"><text>M. Bellare, R. Canetti, and H. Krawczyk, "Keying hash functions for message authentication," in Advances in Cryptology Crypto'96, number 1109 in Lecture Notes in CS, 1996.</text></nplcit></p>

<p> One solution to protecting computer data is to remove general purpose computing devices and use special purpose anti-tamper boxes to distribute, store, and display protected content. However, this solution may not be desirable as it prevents users from expanding their computer (for example, users cannot install additional software components and / or hardware components in such anti-tamper boxes). There is. Therefore, it is beneficial to provide a way to enable general purpose computing devices to protect data.</p>

<p> The present specification discloses the storage and retrieval of data based on symmetric key encryption.</p><p> According to one aspect, the data is received from the calling program. Cryptographic text containing data is generated in such a way that symmetric cryptography can be used so that only one or more target programs can obtain data from the cryptographic text.</p><p> According to another aspect, the bitstring is received from the calling program. Checks the calling program's identifier to determine if the calling program is allowed to access the encrypted data within the encrypted text of the bitstring. Data integrity is also verified and the data is decrypted (sometimes referred to as decryption) using a symmetric key. Data is returned to the calling program only if the calling program is granted access to the data and the integrity of the data is successfully verified.</p>

<figref num="1">It is a figure which shows an exemplary access control model.</figref><figref num="2">It is a figure which shows an exemplary access control environment using four different layers.</figref><figref num="3">It is a flow diagram which shows the exemplary process which carries out a Seal operation.</figref><figref num="4">It is a flow diagram which shows the exemplary process which carries out the UnSeal operation.</figref><figref num="5">It is a flow diagram which shows an exemplary process which carries out a Store operation.</figref><figref num="6">It is a flow diagram which shows the exemplary process which carries out a Seal operation.</figref><figref num="7">It is a flow diagram which shows an exemplary process which carries out a Quote operation.</figref><figref num="8">It is a flow diagram which shows the exemplary process which performs a Verify operation.</figref><figref num="9">It is a flow diagram which shows the exemplary process which carries out PKUnseal operation.</figref><figref num="10">It is a flow diagram which shows the exemplary process which carries out PKSeal operation.</figref><figref num="11">It is a flow diagram which shows the exemplary process which carries out the GenSeal operation.</figref><figref num="12">FIG. 5 illustrates a general purpose computer environment that can be used to perform the techniques described herein.</figref>

Figure 1 shows an exemplary access control model 100. Principal 102 can request access to protected resources. This request is received by the guard 104, which is the component that controls access to the resource 106. The guard 104 inspects the request and decides whether to allow the request based on the access policy of the resource and other information such as the identification of the principal 102 who issued the request. For simplicity, a single principal 102, guard 104, and resource 106 are shown in Figure 1. However, it should be noted that the access control model 100 can include multiple principals 102, multiple guards 104, and / or multiple resources 106.

Principal 102 refers to a component or module that requests access to protected data. This request can be a request to search for protected data (for example, a request to search for a cryptographic key) or a request to perform an operation using protected data (for example, a request to use protected data as a cryptographic key). The request can be a request to encrypt or decrypt specific data using an encryption key). Principal 102 can be implemented as a component or module in hardware, software, firmware, or a combination of hardware, software, and / or firmware.

Guard 104 refers to a component or module that controls access to protected data. Guard 104 may use access policies related to protected data, as well as other information, such as identifying the principal requesting access to the protected content, to allow the principal to access the protected data. Determine if allowed. If the guard 104 determines that the requesting principal is granted access to the protected data, the guard 104 responds to the request in an appropriate manner (eg, the request relates to the protected data). If it is a request, it returns the protected data to the principal, and if the request is a request to encrypt specific data using the protected data, the guard 104 sends the protected data. Use to encrypt specific data and return encrypted text (encrypted data) to the principal). Note that Guard 104 can limit principals based on the nature of the requirement. For example, guard 104 may allow a particular principal to use protected data to sign certain data, but may not allow the protected data to be returned to that particular principal. it can.

The guard 104 can also be characterized as a disclosure guard and / or a serviceguard. Serviceguards perform certain actions with protected data (eg encryption, decryption, digital signatures, etc.) without disclosing protected data (eg encryption keys) when requested by the principal. To do. Disclosure guards, on the other hand, reveal protected data to authorized requesters. Note that a particular guard 104 can be both a disclosure guard and a serviceguard.

Resource 106 can be any type of data for which access is restricted. Examples of resource 106 can include personal information such as encryption keys, bank account numbers, credit card numbers, social insurance numbers, passwords, and the like. Resource 106 can be virtually anything in a computing device. For example, resource 106 can be physical memory (eg RAM or ROM), optical discs, magnetic disks, optical disk drives, magnetic disk drives, video cards, sound cards, smart cards, and so on. As another example, resource 106 could be an operating system abstraction for processes, files, threads, semaphores, and so on.

In the description herein, the access control model 100 will be described primarily with respect to what is implemented in a single computing device. However, please understand that different parts of this model can be implemented on different computing devices. For example, the principal 102 can be on one computing device, and the guard 104 and resource 106 can be on another computing device.

Principals and guards of a computing device, any number n of layers l_nCan be classified into. Figure 2 shows an exemplary access control environment using four different layers. In one embodiment, layer l₁Refers to the hardware layer or security kernel layer, layer l₂Refers to the basic input / output system (BIOS) layer₃Refers to the operating system (OS) layer₄Refers to the application layer.

In the example environment of Figure 2, the lowest layer (layer l)₁) Protects the root resource. Intermediate layer (layer l₂And l₃The program in) then acts as a principal requesting access to the lower layers, and at the same time acts as a guard towards the next higher layer principal. Therefore, the middle layer can add functionality for the principals of the upper layer.

For example, suppose program 120 wants to find root resource 128 protected by guard 126. Program 120 acts as a principal requesting module 122 to access the root resource 128, and module 122 acts as a guard for that resource. Module 122 has a copy of resource 128 (for example, program 120 or layer l).₄In response to a previous request for resources by another program, or when module 122 is initialized and loaded into a computing device (obtained from guard 126), module 122 will have program 120 resource. Check if you are allowed to search for. Module 122 then returns the resource to program 120 if program 120 is allowed to retrieve the resource.

However, if module 122 does not have a copy of resource 128, module 122 acts as a principal requesting module 124 to access the root resource, and module 124 acts as a guard for this resource. Module 124 has a copy of resource 128 (eg program 122 or layer l).₃In response to a previous request for resources by another module, or when module 124 is initialized and loaded into a computing device (obtained from guard 126), module 124 will have program 122 resource. Check if you are allowed to search for. Module 124 then returns the resource to program 122 if program 122 is allowed to retrieve the resource. Module 122 then returns the resource to program 120 if program 120 is allowed to retrieve the resource.

However, if module 124 does not have a copy of resource 128, module 124 acts as a principal requesting guard 126 to access the root resource. Guard 126 checks if module 124 is allowed to search for resources, and returns resources to module 124 if module 124 is allowed to search for resources. Module 124 returns resources to module 122 if module 122 is allowed to search for resources, and module 122 returns resources to program 120 if program 120 is allowed to search for resources.

In the description of the present specification, it is mentioned in a plurality of places that the access control model 100 of FIG. 1 is used to enable the permitted operation of the software. Usually, the resource protected by the authorized operation of software is the encryption key. However, please understand that the allowed behavior of the software is just one example of the use of access control model 100.

Another example of using access control model 100 is authenticating a user to a computer. Most modern computers have access control systems. The user logs on to the computer, and as a result, the computer knows who the user is. After logging on, the user runs a program that normally requires access to system resources (for example, reading a file, writing to an on-screen window, etc.). Usually, the computer's access control system is consulted (for example, "Can user x perform action y on resource z?"). If the answer is no, the program cannot access the resource.

Another example of using access control model 100 is authenticating a user to a remote service. Remote services such as websites (eg online brokers or online banks) can be considered to have access control systems. Resources are people's bank accounts, deposits, and stocks. After the user logs on to the website, the access control system allows the user to have "read" access to the resource "bank account data" (to find the latest bank statement) or the resource "bank account 12345 for $ 1000". Determine if you are allowed to perform the access requested by the user, such as "transfer" access to.

Another example of the use of access control model 100 is the restriction of physical access to a particular building or area. For example, when a user arrives at work in the morning, the user presents his badge and requests an "open" action on the resource "front door." An electronic system (guard) determines whether the user is allowed to enter the building based on the information stored on the badge and unlocks the door accordingly.

A computing device is the authenticated behavior of a program (software) if it is possible to allow the program to gain secure access (from disclosure guard or serviceguard) to at least one cryptographic resource. To enable. In certain embodiments, a computing device that enables authentication and isolation, described below, enables authenticated operation.

It can be said that program C is separated from another program D in two ways: (1) there is memory that can be accessed by program C but not by program D, and (2) program D has This is the case when the inability to start execution of program C (possibly except for the entry point determined by program C) is satisfied. A program is given by its transition rule (executable code) and its initial state (initial value of entry point or instruction pointer IP). The first point guarantees the integrity of program code and state information in program C, as data can be stored in memory inaccessible by program D, even in the presence of hostile behavior by program D. Will be done. This also allows Program C to protect sensitive data (eg, encryption keys) from observations by Program D. The second point ensures that D cannot overturn C's behavior by choosing entry points in a hostile manner.

Further, it can be said that the program C can authenticate the program D when the program C can identify both the transition rule (program code) of the program D and the initial state. The computing device is a single program E for each layer j &lt;i, assuming that i is the layer of program C._jAllows isolation for any program C from all other program D except. This causes program C to request access to the resource through it, a sequence of guards, E.₁, E₂, ..., E_i-1The program is protected from observation and interference by all programs except. Further, for any layer i, the computing device allows a program running in layer i to authenticate at least some programs in layer i + 1. This requirement allows the program to act as a guard against requests from the next layer of principals. These two observations allow a program in any tier to request access to resources from the previous program, protect integrity and resources through isolation, and authenticate requests from principals in the next tier. Gives an inductive argument that it can act as a guard on resources.

Separation can be achieved by using physical memory protection. This technique is referred to as "separation in space" or "spatial separation". For example, the ring memory protection and virtual memory protection found in many modern microprocessors are sufficient to provide spatial isolation. An operating system kernel (tier i) operating in privileged mode can set up a page table for an application (tier i + 1), where all applications are in physical memory and the operating system is the virtual address of that application. Give access only to the parts you choose to map to space. In addition, the kernel limits application privileges to prevent applications from changing memory mappings, ensuring that applications can only start executing kernel code at well-defined entry points (system calls).

Another technique for performing separation between the two layers is to separate their executions in time. This technique is referred to as "separation in time" or "time separation". The first layer i program runs to completion, renders a resource unusable, and then exits. Control is then transferred to the next layer i + 1.

Authentication is done in the subsequent layer (j = i + 1). Program C authenticates the program (transition rule) and initial state of the configuration of j. The program can be authenticated by having Program C inspect the layer j program. That is, program C usually reads the memory containing the layer j program and calculates the cryptographic digest for this memory range. Note that the goal in this regard is not the evaluation of statements made by other principals with respect to the code, but only the confirmation of the identification of the code. Therefore, no certificate is needed in this regard.

The second task of Program C is to identify the initial state of Program D. In general, the problem of determining the initial state of a program at any execution stage is very difficult. Therefore, program C controls the initial state of program D. Realistically, this means that when program C starts executing program D in the initial state σ, program C can only see the initial state σ of program D.

In summary, to authenticate Program D, Program C inspects the memory contents (program and possibly data) that it considers relevant and calculates a cryptographic digest. Program C then transfers execution to a well-defined entry point in Program D.

When the resource is a cryptographic key, the authenticated behavior allows each operating system and application program to have exclusive access to one or more secrets. The separation described above protects each secret from attacks by hostile code. The program authentication described above allows the program to be identified so that each secret is kept only by the program that owns it.

In general, in response to a request from the program (principal 102 in FIG. 1), the guard 104 establishes the identification of the program (ie, the guard 104 authenticates the program). If the program is not the owner of the requested secret (resource 106), guard 104 rejects the request. Otherwise, Guard 104 calculates the secret and, perhaps, a function with more information provided by the program (which can be the secret itself) and returns the result. In the alternative, instead of explicitly accepting or rejecting the request, guard 104 services the request but constrains the caller's identity to the result. This alternative is suitable, for example, when the result returned by the guard does not contain sensitive information (eg, a request to make a digital signature using a secret). The term gating function is used herein to refer to both cases.

In addition, in either case, the guard 104 authenticates the caller (principal 102). Authentication of principal 102 is also referred to herein as function ID (), which returns a digest of the calling program (the program that calls the gating function of guard 104). The digest is the use of one or more of various cryptographic hash functions (also known as one-way hash functions) such as SHA1 (Secure Hash Algorithm 1), MD5 (Message Digest 5), MD2 (Message Digest 2), keyed MAC (keyed MAC). It can be generated in any of a variety of traditional forms, such as the use of a message confirmation code).

Sealed strage is implemented in one class of gating functions described herein. The purpose of shielded storage is to allow a program to store a secret so that only a specific set of programs (defined by the program that stores the secret) can retrieve the secret. In one embodiment, only the program that first saved (sealed) the secret can recover (unseal) the secret. Usually, the lifespan of these secrets exceeds the time of individual execution of the program. Secrets used during a single run of a program can be stored (sealed), and instead, isolation and random number generators are used to allow the program to maintain a single run secret. .. Shielded storage allows programs to remain secret across different executions that may not overlap in time. Layer l_iHowever, with the interface below, the next layer l_{i + 1}Expose shielded storage to (for example, using "Seal" and "UnSeal" and / or PKSeal and PKNseal behaviors).

The description herein regarding shielded storage refers to the encryption keys used to encrypt and decrypt data. These encryption keys are the keys associated with guards that protect access to resources (eg, guard 104 in Figure 1).

As used herein, reference is made to the identifier of a program (for example, the identifier of a program that invokes an action, or the identifier of a target program that is granted access to a resource). As used herein, these identifiers are often referred to as digests. However, please understand that the digest is just one example of a program identifier. Other types of identifiers, which are measurements or other representations of the program and can detect all changes to the program, can be used. If any changes are made to the program (for example, maliciously gaining access to protected data and an opponent modifies one or more instructions in an attempt to use that data). The identifier must reflect the change (for example, the identifier of the program that does not change is different from the identifier of the program that has changed).

The Seal operation receives as input data to be sealed (eg secret). The Seal operation, as an option, receives as input a condition when the secret is revealed (unsealed) and / or a condition for identifying the other party. In one embodiment, this condition is a digest of the target program that is allowed to retrieve (unseal) the data. Instead, programs that are allowed to retrieve (unseal) data can be identified in other ways. For example, a program can be identified by a public key that validates one or more certificates, each of which is associated with one or more programs.

Alternatively, other conditions may be used in addition to or in place of the target program identifier. The condition can include a time constraint on when data can be revealed (unsealed), such as a specific time or day of the week during which the secret can be revealed (unsealed). As another example, the condition can include a password or other data identifier that must be provided to reveal (unseal) the secret, for example, seal the secret only by a program that has knowledge of the password. It can be released.

As another example, the condition can be a well-formed formula (for example, a statement written in first-order logic, a statement written in predicate logic, and so on). The formula is evaluated (for example, by a guard) and the secret is revealed (unsealed) only if the evaluation returns a true indication.

In another example, the condition can be an executable program in a language (eg, Java®, C *, Java® script, VBScript, etc.). The secret is revealed (unsealed) only if the program is executed (for example, by a guard) and the program returns some indication of "true" or "satisfied".

In situations where the condition is a digest of the target program rather than being supplied with a digest of the target program, the Seal action can use the digest of the program that calls the Seal action (this allows the digest of the target program to be used. Implicitly entered). In addition, digests of multiple target programs can be entered into the Seal operation, which allows multiple target programs to reveal (unseal) the data.

In the Seal operation, the input (data and conditions that allow data retrieval (unsealing)) is encrypted along with the calling identifier. The Seal operation returns the input data in encrypted form (as encrypted text). The Seal operation also returns a value that can be used to verify the integrity of the sealed data (for example, a Message Confirmation Code (MAC) value). This returned data allows the saved data to be referenced in subsequent UnSeal operations, as described in detail below.

Table I shows the pseudo code of the Seal operation. In the pseudocode in Table I, ID () refers to the ID () function described above, e refers to the value returned to the caller (eg a string or sequence of bits), and data refers to the data to be sealed. Point to [t₁, ..., t_m] Refers to the digest (or one or more other conditions) of one or more (m) target programs that are allowed to retrieve (unseal) data. Table I d = ID () e = store {data, [t₁, ..., t_m], d) return e

FIG. 3 is a flow chart showing an exemplary process 200 for performing a Seal operation. Process 200 is performed by guard 104 in FIG. 1 and can be performed with hardware, software, firmware, or a combination thereof.

First, the sealed secret is received from the caller (action 202). Either the secret is encrypted so that it can only be retrieved by a specific target program (behavior 204), or instead the secret is only available if one or more specific conditions are met. To be able to search. Returns the encrypted text containing the encrypted secret to the caller (action 206). Additional information, such as the caller's favorite digest and / or the target program's digest, can also be returned to the caller (either as part of the ciphertext or separately from the ciphertext).

In the UnSeal operation, the bit string (for example, encryption key) returned by the Seal operation is received as input when the calling program seals the data currently desired to be searched. In UnSeal operation, the condition to reveal the data is obtained and it is checked whether the condition is satisfied. For example, if the condition includes digests of one or more target programs that are allowed to retrieve (unseal) the data, the UnSeal operation gets these digests and the calling program has one or more. Check if it is one of the target programs of. If the calling program is not one of one or more target programs, the UnSeal operation will fail and the requested data will not be returned to the calling party. However, if the calling program is one of one or more target programs, the UnSeal operation succeeds and the requested data is returned to the calling program. The digest of the program that sealed the data is also returned from the UnSeal operation as an option.

Table II shows the pseudo code of the UnSeal operation. In the pseudo code in Table II, data refers to the requested (previously sealed) data, [t.₁, ..., t_m] Refers to the digest (or one or more other conditions) of one or more (m) target programs that are allowed to retrieve (unseal) data, and e is the input to the UnSeal operation. (Usually the previous output from the Seal operation), where d refers to the digest of the program that sealed the data. Table II (data, [t₁, ..., t_m], d) = retrieve (e) if ID () is in [t₁, ..., t_m] then return (data, d) else fail else fail

FIG. 4 is a flow diagram showing an exemplary process 220 that implements the UnSeal operation. Process 220 is performed by guard 104 in FIG. 1 and can be performed with hardware, software, firmware, or a combination thereof.

First, it receives encrypted text containing the encrypted data that the caller wants to retrieve (action 222). It checks whether the caller is allowed to retrieve the data (action 224) and proceeds based on whether the caller is allowed to retrieve the data (action 226). If the caller is allowed to retrieve the data, the data (decrypted) is returned to the caller (action 228). If the caller is not allowed to retrieve the data, the process fails (action 230) and the data is not returned to the caller.

Shielded storage can be implemented in different ways. In one embodiment, shielded storage is implemented using physically protected non-volatile memory. In this embodiment, the computing device associates different guards with different parts of the protected non-volatile memory so that each guard can access only the part associated with that guard. In this embodiment, the Store and Retrieve operations referenced in the Seal and UnSeal operations are called to force the computing device to store or retrieve the data in protected non-volatile memory associated with the guard, respectively. Is done.

For example, a storage device (such as a hard disk drive) can be used for guarding. Rather than simply executing read and write commands to a storage device unconditionally, the storage device identifies the principal attempting to access that storage device (for example, based on the principal's digest) and is specific. Allow only the principal to access the storage device. Alternatively, different principals can be restricted to access to only certain parts of the storage device (eg, a particular sector or address range).

In another embodiment, shielded storage is performed using cryptography. A description of one exemplary embodiment of shielded storage using cryptography continues.

When implementing shielded storage using cryptography, the resource is the key K, not the physically protected memory. In Store operation, the input is not physically saved. Instead, the Store operation produces a cryptographically protected output c, which is the input to the Store operation in an encrypted and maintainable form. Encryption is the result of applying symmetric encryption to the input. The latter property results from applying a message verification code (MAC) to the input (either before or after encrypting the input).

Table III shows the pseudo code for Store operation. In the pseudo code in Table III, b refers to the bit string input to the Store operation, c refers to the bit string output by the Store operation, K1 refers to the first part of the key K, and K2 refers to the first part of the key K. Refers to the second part of key K. The key K is a symmetric key of the guard that performs the Seal operation and the Store operation. Table III m = MAC_K1(b) c = (m, Encrypt_K2(b)) return c

Therefore, as can be seen from Table III, the value (m) is generated by applying a MAC to the bit string input to the Store operation. The MAC uses the key K part (K1) as the key. Also, the bit string input to the save operation is encrypted using the second part (K2) of the key K. The value generated by applying the MAC to the input bitstring and encrypting the input bitstring is returned to the caller of the Store operation.

Key K is divided into two independent keys K1 and K2 to avoid using the same key for MAC and encryption. This division can be performed in any of various forms. The partition can use different bits of key K or, instead, use one or more identical bits. For example, assuming that key K is 1024 bits, the lower 512 bits can be used as key K1 and the upper 512 bits can be used as key K2, with even-th bits (bits 0, 2, 4, 6, 6). 8, 10, ..., 1022) can be used as key K1 and odd-th (bits 1, 3, 5, 7, 9, 11, ..., 1023) can be used as key K2, lower You can use 650 bits as key K1 and the upper 650 bits as key K2 (some bits will be used for both K1 and K2). Instead, the same key K can be used for both MAC and cryptography.

In the pseudo code shown in Table III, the Store operation is performed by calculating the MAC for the data, encrypting the MAC, and outputting the encrypted MAC. Instead, the Store operation can be performed differently. For example, the Store operation can first encrypt the data, then calculate the MAC for the encrypted text, and output both the encrypted text and the MAC. As another example, the Store operation can calculate the MAC for the data, encrypt both the data and the MAC, and output the encrypted text.

Cryptography performed by Store-operated cryptography can be performed using any of a variety of symmetric cryptographic algorithms. In general, symmetric encryption algorithms use the same key for both encryption and decryption. Examples of such algorithms include triple-DES (Data Encryption Standard), AES (Advanced Encryption Standard), and so on.

Similarly, the MAC can be any of a variety of message confirmation codes (see, eg, Non-Patent Document 1). In the alternative, integrity can be protected by public key digital signature instead of MAC.

FIG. 5 is a flow chart showing an exemplary process 250 that implements the Store operation. Process 250 is performed by guard 104 in FIG. 1 and can be performed with hardware, software, firmware, or a combination thereof.

First, it receives the saved data (action 252). Apply symmetric encryption to the data (action 254) and apply a message confirmation code (MAC) to the data (action 256). The encrypted data generated in action 254 and the MAC value generated in action 256 are returned to the caller (action 258).

The Retrieve operation receives a bitstring containing the MAC value and encrypted text as input. Cryptanalyze the encrypted text to generate plaintext and generate the MAC value for that plaintext. If the MAC value generated for the plaintext is the same as the MAC value received as part of the input bitstring, the plaintext is returned to the caller. However, if the MAC value generated for the plaintext is not the same as the MAC value received as part of the input bitstring, the Retrieve operation will fail and the plaintext will not be returned to the caller. It should be understood that the particular form in which the Retrieve operation is performed to obtain the MAC and ciphertext from the input bitstring depends on the form in which the Store operation is performed.

The pseudo code for the Retrieve operation is shown in Table IV. In the pseudo code in Table IV, c refers to the bitstring input to the Retrieve operation, b refers to the bitstring output by the Retrieve operation, and m refers to the MAC value portion of the bitstring input to the Retrieve operation. , D refers to the encrypted text portion of the bitstring entered in the Retrieve operation, K1 refers to the first part of key K, and K2 refers to the second part of key K. The K1 and K2 keys are the same parts of the key K as described above for Store operation. Table IV Let (m, d) = c b = Decrypt_K2(d)) if m = MAC_K1(b) then return b else fail else fail

Therefore, as can be seen from Table IV, the value (b) is generated by decrypting the bit string input to the Retrieve operation. A MAC value is then generated for value (b). If the MAC value generated by the Retrieve operation is the same as the MAC value received as part of the bitstring entered in the Retrieve operation, then value (b) is returned to the caller of the Retrieve operation, otherwise In this case, the Retrieve operation fails.

The pseudocode in Table IV is based on an embodiment of a Store operation that calculates the MAC for the data, encrypts the data, and outputs the MAC and the encrypted text together (which acts as the input bitstring for the Retrieve operation). If the Store operation is performed to first encrypt the data, calculate the MAC for the encrypted text, and then output both the encrypted text and the MAC, the Retrieve operation will calculate the MAC for the encrypted text and calculate it. It is performed to compare with the MAC value received as part of the input bitstring, decrypt the encrypted text if the MAC values match, and return the decrypted data. If the Store operation is performed to calculate the MAC for the data and encrypt both the data and the MAC, the Retrieve operation decrypts the input bitstring and calculates the MAC for the data in the input bitstring. Then, the calculated MAC is compared with the MAC value of the decrypted string, and data is returned when the MAC values match.

Similar to the above description of Store operation, any of the various decryption algorithms can be used for Retrieve operation. However, the decryption algorithm must correspond to the encryption algorithm in order to be able to decrypt the encrypted data. Similarly, any of the various message confirmation codes can be used as a MAC, but the message confirmation code must be the same as the message confirmation code used by the Store operation.

FIG. 6 is a flow chart showing an exemplary process 270 that performs the Seal operation. Process 270 is performed by guard 104 in FIG. 1 and can be performed with hardware, software, firmware, or a combination thereof.

First, it receives the encrypted text and MAC value (behavior 272). Decrypts the encrypted text to generate plaintext data (operation 274). A message confirmation code (MAC) is applied to the plaintext data to generate a MAC value (operation 276) and check if the MAC value generated in operation 276 is equal to the MAC value received in operation 272 (operation 278). ). The process then proceeds based on whether the generated MAC value is equal to the received MAC value (operation 280). If the generated MAC value is equal to the received MAC value, the plaintext data is returned to the caller (action 282). However, if the generated MAC value is not equal to the received MAC value, the process fails (action 284) and the plaintext data is not returned to the caller.

Therefore, cryptographic techniques for shielded storage can detect all destruction of value c (output of Store operation), and value b (input to Store operation) by encryption to encrypt key K2 (value b). It is virtually guaranteed that you will not be able to search unless you have access to the key used).

Another class of gating functionality involves remote authentication. The purpose of remote authentication is to allow a program to authenticate even without a strong physical bond to the authentication function (eg using a server or smart card). In this situation, authentication is cryptographically based. That is, both entities proceed via the cryptographic authentication protocol. This includes an authenticated configuration with access to the secret, which is protocol dependent but is usually a private or symmetric key. In addition, computing devices can tie the use of this authentication secret to the identification of the configuration (eg, processor and / or software) that requires its use. Therefore, the authentication function can establish the identification of the computing device and the software running on it.

Two actions, the Quote action and the PKNseal action, are the respective gating features of public key signing and private key cryptography. The guard performing these gating functions can access the signing key Ks and the decryption key Kd. Both the signing key Ks and the decryption key Kd are also referred to as the private key of the public / private key pair. This public / private key pair is a guard key pair that performs Quote and PKNseal operations.

The Quote action returns a public key signature for the input to the Quote action and / or a combination of conditions that identify the other party (eg, concatenation) when the secret can be revealed. Similar to the Seal and UnSeal behaviors described above, revealing secrets can be tied to any of a variety of conditions. In one embodiment, the condition is an identifier (eg, digest) of the calling program.

Unique to the signature is the assertion that the action is performed at the request of the identified calling program. The Quote operation works with the Verify operation, and the Verify operation is usually performed on a device other than the device on which the Quote operation is performed (for example, on a remote server device, on a smart card, etc.). The Verify operation performs public key signature verification, retrieves and evaluates the calling program's identifier (and / or other conditions that reveal the secret).

The pseudo code for the Quote operation is shown in Table V. In the pseudo code in Table V, ID () refers to the ID () function described above, a represents the data entered into the Quote operation, and Ks points to the signing key. Table V d = ID () return sn = Signature_Ks(d, a)

Therefore, as can be seen from Table V, in the Quote operation, the digest of the calling program is obtained and the input value a is received. The Quote operation generates a digital signature (sn) that uses the signature key Ks for the input value a and the digest of the calling program. The input value a can be generated by the calling program and instead be a value received from another component or device (for example, from a device performing a Verify operation). Digital signatures are generated using public key cryptography.

FIG. 7 is a flow chart showing an exemplary process 300 that implements the Quote operation. Process 300 is performed by guard 104 in FIG. 1 and can be performed with hardware, software, firmware, or a combination thereof.

First, the input data is received from the caller (operation 302). Obtain the caller's identifier (and / or one or more other conditions for retrieving the input data) (action 304), and the input data and the caller's identifier (and / or one or more other conditions). Generate a digital signature for the combination of (operation 306). It then returns the generated digital signature to the caller (action 308).

In the Verify operation, public key signature verification is executed, the identifier of the calling program is searched, and evaluated. The Verify operation normally receives the digital signature generated by the Quote operation from a device other than the device on which the Verify operation is performed (for example, a remote server device, smart card, etc.). In the Verify operation, the digest of the program that called the Quote operation (for example, application program, operating system, firmware program, etc.) is extracted from the received digital signature, and the digest is evaluated to determine the progress method.

The pseudo code for the Verify operation is shown in Table VI. In the pseudo code in Table VI, d refers to the digest of the program that called the Quote operation, a refers to the value entered for the Quote operation, and Sn refers to the digital signature received as input by the Verify operation. Table VI (d, a) = Extract_Kv(Sn) Evaluate (d)

Therefore, as you can see from Table VI, the Verify operation takes a digital signature and uses the verification key Kv (the public key of the public / private key pair containing the signing key Ks) to extract the digest d and the value a from the signature. To do. The Verify program can then evaluate the digest d of the program that called the Quote action. The form of evaluating digest d can be changed. For example, the evaluation can include comparing Digest d to a list of "approved" or "trusted" application programs.

FIG. 8 is a flow chart showing an exemplary process 320 that performs the Verify operation. Process 320 is performed by guard 104 in FIG. 1 and can be performed with hardware, software, firmware, or a combination thereof.

First, it receives a digital signature (operation 322). Extract both the caller's identifier (and / or one or more other conditions for finding the input value) that quoted the input value (using the Quote action) and the input value itself from the digital signature (action 324). ). Evaluate the caller's identifier (and / or one or more other conditions) to determine how to proceed with respect to the input value (action 326).

PKUnseal behavior is a version of public key cryptography that is gated against the identity of the caller (eg, a digest of the calling program) or one or more other conditions in its place. The result of the public key decryption of the input c to the PKUnseal operation is interpreted as a pair (d, s), where s is a secret and d can reveal s to it (eg, s). , A digest of the calling program). If the caller of PKUnseal is not d, PK Unseal operation fails. The input c to the PKUnseal operation is generated by a second operation PKSeal that can be performed on a device other than the device on which the PKNseal operation is performed (eg, remote server device, smart card, etc.). The PKSeal operation performs paired (d, s) public key cryptography. PKUnseal and PKSeal operations can also be used to perform shielded storage.

The pseudo code for PKUnseal operation is shown in Table VII. In the pseudocode in Table VII, ID () refers to the ID () function described above, c refers to the input to the PKNseal operation, and [d1, ..., d._m] Refers to a digest of one or more calling programs (or instead one or more other conditions) that can reveal s to it, and s refers to protected data. Kd refers to the decryption key (the private key of the public / private key pair associated with the guard performing the PKNseal operation). Table VII ([d1, ..., d_m], s) = Decrypt_Kd(c) if ID () is in [d1, ..., d_m] then return s else fail else fail

Therefore, as can be seen from Table VII, in the PKNseal operation, the public key decryption and the decryption key Kd are used to decrypt the input value c. The decrypted input value is a digest of one or more calling programs that are allowed to reveal protected data s to it [d1, ..., d._m] (Or if instead it is allowed to reveal protected data s and / or one or more conditions that identify the other party). The PKUnseal operation also generates a digest of the calling program. The digest of the calling program is the digest [d1, ..., d_m], The protected data s is returned to the calling program. However, the digest of the calling program is digest [d1, ..., d_m], The protected data s is not returned to the calling program.

FIG. 9 is a flow diagram illustrating an exemplary process 340 for performing a PKNseal operation. Process 340 is performed by guard 104 in FIG. 1 and can be performed with hardware, software, firmware, or a combination thereof.

First, it receives encrypted text containing the encrypted data that the caller wants to retrieve (action 342). It checks whether the caller is allowed to search the data (action 344) and proceeds based on whether the caller is allowed to search the data (action 346). If the caller is allowed to retrieve the data, it returns the data (which was decrypted using public key cryptography) to the caller (action 348). If the caller is not allowed to retrieve the data, the process fails (action 350) and the data is not returned to the caller.

PKSeal behavior is a version of public key cryptography that is gated based on the identity of the caller (eg, a digest of the caller program or one or more other programs). The PKSeal operation performs paired (d, s) public key cryptography, where s is secret and d can reveal s to it in one or more configurations (eg, for example). Identifies the digest of the calling program).

The pseudo code for PKSeal operation is shown in Table VIII. In the pseudo code in Table VIII, c refers to the output of the PKSeal operation, [d1, ..., d._m] Refers to the digest of one or more calling programs that can reveal s to it, s refers to the protected data, and Ke refers to the encryption key. Table VIII c = Encrypt_Ke([d1, ..., d_m], s) return c

Therefore, as can be seen from Table VIII, in PKSeal operation, as input, protected data s, and a digest of one or more programs that can reveal protected data s to it [d1, ... , D_m] Is received. Vs. [d1, ..., d_m], S is encrypted using public key cryptography based on the encryption key Ke. The encryption key Ke is a guard public key intended to be able to decrypt encrypted text. Returns the cryptographic text resulting from public key cryptography to the calling program.

FIG. 10 is a flow diagram illustrating an exemplary process 360 that implements the PK Zeal operation. Process 360 is performed by guard 104 in FIG. 1 and can be performed with hardware, software, firmware, or a combination thereof.

First, the secret to be sealed is received from the caller (action 362). Either the secret is encrypted using public key cryptography so that only certain target programs can retrieve the secret (behavior 364), or instead, one or more other conditions are met. Make it possible to search for secrets only in cases. Returns the encrypted text containing the encrypted secret to the caller (action 366). Additional information, such as the caller's digest and / or the target program's digest, can also be returned to the caller (as part of the ciphertext or separately from the ciphertext).

The Quote and PKNseal actions are intended to be used with public key authentication protocols. Most public key authentication protocols can be easily adapted by replacing all calls to public key cryptography, public key cryptography, signing, and signature verification with PKNseal, PKSeal, Quote, and Verify, respectively. it can.

In some situations it is important to be able to obtain random numbers (for example, as the basis for cryptographic key generation). Random numbers can be obtained in a variety of different forms. In one embodiment, the source of random numbers is a cryptographically strong random number generator implemented in the hardware of the computing device.

One of the alternatives to the Seal operation described above is the GenSeal operation, which combines the Seal operation with the random number generation operation. GenSeal behavior must be able to retrieve secrets as input Digest of target program [t1, ..., t_m] (And / or other conditions that must be met in order to retrieve the secret). In the GenSeal operation, a random number is generated, the newly generated random number is sealed, and as a result, the newly generated random number is subjected to the target digest [t1, ..., t._m] (And / or other conditions that are satisfied) so that only the calling program with one of them can be searched.

The pseudo code for GenSeal operation is shown in Table IX. In the pseudocode in Table IX, ID () points to the ID () function described above, c points to the output of the GenSeal operation, s points to the newly generated random number, and [t1, .. ., t_m], But one or more target programs that must be allowed to look up the value s (one of which can optionally be a program that calls GenSeal behavior) or one instead Or refers to several other conditions, where GenRandom () refers to a function that generates random numbers. Table IX d = ID () s = GenRandom () c = store (s, [t1, ..., t_m], d) return c

FIG. 11 is a flow diagram illustrating an exemplary process 380 that implements the GenSeal operation. Process 380 is performed by guard 104 in FIG. 1 and can be performed with hardware, software, firmware, or a combination thereof.

First, it receives input from the caller that identifies the target program that must be able to retrieve the secret or one or other condition that must be satisfied to retrieve the secret instead (action 382). Generate a secret (behavior 384) and encrypt the secret so that only the identified target program can retrieve the secret (behavior 386), or one or other condition is satisfied instead. Make it possible to search for secrets only in cases. Returns the encrypted text containing the encrypted secret to the caller (action 388). Additional information, such as the caller's digest and / or the target program's digest, can also be returned to the caller (as part of the ciphertext or separately from the ciphertext).

The services provided by the Disclosure Guard can be used for general purpose sealing services. For example, returning to Figures 1 and 2, layer n-1 identifies layer n during initialization (eg, after a compute device reset or boot, or at the beginning of program execution). A single key is opened in n. Layer n caches this key and uses it to encrypt additional secrets. The next time this platform is booted with the same configuration, the disclosure guard will supply the same root key (eg, via UnSeal or PKNseal) and all previously encrypted secrets will be revealed by layer n. You can search.

In some embodiments, when the next layer is initialized (for example, after resetting or booting a computing device, or at the beginning of program execution), to that next layer, by a lower layer 1 One or more secrets will be disclosed. After this gated disclosure, the lower layers are no longer used (until the next boot or reset). This usage model is also referred to as a disclosure guard model. By using the disclosure guard model, access to lower layers is reduced.

The gating features described herein can be used with serviceguards and disclosure guards implemented using time and spatial separations. Under four service model embodiments for authentication behavior: (1) Serviceguard-Spatial Separation, (2) Disclosure Guard-Spatial Separation, (3) Disclosure Guard-Time Separation, and (4) Serviceguard-Time Separation. explain. In the description of these service models, it is assumed that the subordinate guards have disclosed one or more keys to the guards of the layer being considered. The form of obtaining these keys depends on the model of guarding and separation of the underlying layers. Different layers of the same computing device can use different ones of these service models.

(1) Serviceguard-Spatial isolation: The guard measures and stores the identity of the requesting program when it is initialized. The guard implements a protection system that uses a processor service (eg, a CPU or other security processor or security coprocessor), and a system call interface that exposes authenticated behavior primitive behavior.

(2) Disclosure Guard-Spatial Separation: The guard gets a service request at initialization in the form of a crypto blob. The blob can be stored in memory or instead obtained from an external storage device. The guard measures the identification of the program it initializes and discloses the key to the program according to the gating function described above. Before passing control to the next layer, the guard establishes mode-protection for itself and its secret resources.

(3) Disclosure Guard-Time Separation: The guard gets a service request at initialization in the form of a crypto blob (group of bits). The blob can be stored in memory or instead obtained from an external storage device. The guard measures the identification of the program it initializes and discloses the key to the program according to the gating function described above. Before passing control to the next layer, the guard removes (or otherwise makes it inaccessible) the key used to perform the gating function.

(4) Serviceguard-Time Separation: In the Serviceguard-Time Separation model, the computing device safely saves the program state across security resets. This model is similar to model (1) (Serviceguard-Spatial Separation), but before passing control to the next layer, Serviceguard removes its secret (prevents it from functioning until the next reboot). .. The next layer runs normally until it needs to request service from the guard. When needed, the next layer stores the request parameters in a place in memory that can withstand the reset and performs the reset. When the device reboots, Serviceguard gets its secret, sees the request, executes it (using the key), destroys the key and related information, and gives the result and control of the calculation: Pass it to the layer (the layer that first requested the service).

In some embodiments, the security kernel must expose primitives (behavior) Seal, Unseal, GetRandom (to get random numbers), and PKNseal (or Quote) if the computing device supports spatial isolation. Must be. Disclosure guards or service guards can be enforced in the security kernel. On the other hand, if the platform supports time separation, the security kernel must provide disclosure guards and implement primitives (behavior) Unseal, GenSeal, and PKNseal (or Quote).

It should also be noted that the functionality of Quote and PKNseal can be built on the Seal and Unseal primitives or the Unseal and GenSeal primitives. For example, the manufacturer implements Quote or PKNseal, l₁Acts as a host for higher-level software (eg operating systems) based on GenSeal and Unseal implemented in₂You can build a program. The manufacturer can generate the keys required by the service layer, seal them, and ship them with the device or CPU (or make them available online).

An exemplary description of a series of hardware embodiments that allows the platform to support authenticated operation is continued. Similar to the upper layer of the system, the lower layer (l in Figure 2)₁The characteristics of) are (a) secret key resources, (b) privileged codes that can access these keys, and (c) controlled initialization of the tier.

The authenticated behavior provides a strong bond between the program and the private key. In the upper layers, the guards in the lower layers guarantee this binding. At the lower tier, there is no underlying software guard that can grate access to platform secrets. Therefore, l₁L to the program₁Another mechanism is used to support key association. One way to achieve this bond is l₁Make the software a platform microcode or firmware that cannot be changed after manufacturing, l₁In software, l₁To give unrestricted access to the key. This platform microcode or firmware can be called a security kernel, l₁The key is called a platform key. The platform is designed to pass control only to a given security kernel. This hardware behavior can also be described as a simple resource guard that discloses the platform key to a predefined security kernel.

The platform key and security kernel firmware are either part of the processor or instead run on one or more other components of the computing device (for example, a security processor or coprocessor that can also perform cryptographic operations). be able to. Platform keys and security kernel firmware can be implemented on a single component or instead on multiple components of a computing device.

With authenticated behavior, the program is started in a controlled initial state. At the higher level, you can trust the software running at the lower level to start execution at the correct entry point. But l₁Now the hardware performs this function. Normally, at power-on or after a reset, the current processor begins execution by following a deterministic sequence. For example, in the simplest case, the processor fetches and executes code from an architecturally defined memory location. l₁By ensuring that the security kernel is the code that runs at startup (as part of a deterministic sequence), the program can be started in a controlled initial state.

In addition, other platform states must not be able to disrupt the execution of the security kernel. A robust and reliable debug state must be made clear to the processor by reset and power on. When used in this example, the platform state change used to start or call the security kernel is referred to as a security reset.

In addition, device manufacturers can use Seal and Unseal l₁The platform key generation or installation used by the implementation must be deployed. If the device must be recognized as part of a PKI (Public Key Infrastructure), the manufacturer must also prove the platform's public key. This is l₁It can be a platform key used directly by, or it can be a key used by a higher layer instead.

Key generation and certification can be the responsibility of the CPU manufacturer or, instead, the responsibility of a third party, such as an OEM, who assembles the CPU into the device. Instead, this responsibility can be shared by multiple such parties.

If a security kernel is running, it can protect itself from code running at higher layers using the isolation mechanism described above. Separation in space usually includes privileged mode support, and separation in time usually includes secrets hidden from the upper layers.

Most current processors do not require additional platform support to support spatial isolation. That is, the existing privileged mode or level is sufficient (as long as the hardware resources that allow access to the platform key can be protected from the upper layers).

To support time separation, use hardware assistance to allow the security kernel to hide the platform key before passing control to the upper layers. One form of providing platform key security in the time-separated model is to use a stateful guard circuit called a reset latch. A reset latch is a hardware circuit that opens after a reset or power-on, but has the property that any software can programmatically close this latch at any time. Once closed, the latch remains closed until the next reset or power-on. Platforms that implement time-separated security kernels must gate platform key access based on the state of the reset latch, and the security kernel must close this latch before passing control to the upper layers. .. As explained above, the security kernel must also take additional steps, such as clearing memory and registers, before passing control, which are the same as those used in the upper layers.

If the platform uses spatial isolation, the security kernel uses privileged mode to protect itself and its platform key from programs hosted by the security kernel (for example, the operating system). In addition, the security kernel establishes a system invocation interface for invoking authentication actions.

If a platform uses spatial isolation, the platform must also include storage that remains until after a security reset to pass parameters to service routines. To call the service, the operating system prepares a command and parameter block in a memory location known to the security kernel and performs a security reset. If the OS wants to continue execution after a service call (rather than a simple restart), the OS and security kernel are extra to ensure that this can be done in a reliable and secure manner. Must be processed.

The authenticated behavior described herein is secure in a variety of settings, including protection of personal data from viruses, protection of sensitive server data from network attacks, network management, copy protection, reliable distributed computing, and more. Can be used for. Authenticated behavior allows different programs that can run on the same computer without a particular trust relationship to store their cryptographic resources independently of the processing of other software.

Part of the description below refers to the SSP (Secure Service Processor). In one embodiment, the SSP is a processor (for use within the computing device) that provides basic cryptographic services to the computing device (eg, the Gating feature described herein by the SSP). For example, layer l in Figure 2.₁) Is supported). An SSP can utilize a cryptographic key and usually has one or more cryptographic keys that are unique (or expected to be unique) to the SSP. The SSP can be part of the device's CPU, or it can be one or more other processors instead. For example, the SSP can be another chip or integrated circuit (IC) in a computing device.

In a different embodiment, the SSP is a properly isolated software program that exposes the same functionality as in the previous embodiment to the caller. This SSP embodiment has access (directly or indirectly) to the encryption key. There are multiple embodiments of options for providing such access. For example, the SSP can call a lower layer serviceguard or disclosure guard. Alternatively, the SSP can have exclusive access to the persistent memory (eg, hard disk, flash memory, ROM, etc.) that contains the required encryption key.

In summary, an SSP is defined by the functionality it exposes to higher-level principals. An SSP is a guard (described above) that has access to a cryptographic key (direct or indirect). The SSP uses these keys to provide cryptographic services to the caller. The following sections describe exemplary functionality exposed by the SSP.

Illustrative behavior The following is an exemplary embodiment of the shielded storage operation and a description of the remote authentication operation. This section describes embodiments of the Seal operation, UnSeal operation, Quote operation, and PKNseal operation example described above.

This section uses the following definitions.

<tables num="1"><img file="JP4808279B2_D0001.tif" /></tables>

In addition, access policies are mentioned in this section and in the section on bound key actions below. The access policy describes when a particular action works (ie, it works). Users of computing devices can selectively turn off certain features. For example, a computing device (eg, an SSP that performs a Seal operation) contains a register called FeatureEnable. One of the bits in this register is called MainEnable. If the user sets MainEnable to false, none of the features in this section will work. The description of the access policy included in each function describes under which FeatureEnable setting the function operates.

Seal Definition SSP_STATUS Seal ( [in] SECRET S, [in] DIGEST Target [2], [in] UINT32 MaxLen, [out] UINT32 * ActualLen, [out] BYTE * SealedBlob

Parameters Seal-Input :: = SEQUENCE { ordinal INTEGER, secret Secret, target Digest Pair} Seal-Output :: = SEQUENCE { ordinal INTEGER, status INTEGER, sealed-blob OCTET STRING}

Return value SSP_SUCCESS

comment The Seal operation forms an encrypted blob (group of bits) that can only be decrypted by the corresponding Unseal operation if the following evaluations are true. Is the coding correct? Is the MAC correct? -Whether the currently operating SK / SL (security kernel or secure loader) is the one whose name was specified as the target during Seal operation.

Seal adds internal randomness so that the output of a Seal operation for the same input produces different results. This ensures that Seal cannot be used as a hardware device identifier. The Seal is stored in the SSP's PCR register, which is the identifier of the program that called the Seal operation (for example, also referred to herein as the PCR value) when the seal was performed to provide integrity information to the item to be opened. The called digest of the called program) is also included.

Access policy Allowed = FeatureEnable.MainEnable &amp; (FeatureEnable.UseSymmKey == All | FeatureEnable.UseSymmKey == AuthSL &amp; SLKnown &amp; AuthPCR [CurrentSL] .UseSymmKey)

processing In the Seal operation, the following processing is performed. 1. Generate a 128-bit random number R 2. Make D0 the current value of PCR [0] and set D1 = PCR [1] 3. Digest M = HMAC [K_M] (RTheSThe targetTheD0TheD1) 4.C = AES [K_S] (R The S The Target The D0 The D1 The M) 5. Set SealedBlob to C and return SSP_SUCCESS

Unseal Definition SSP_STATUS Unseal ( [in] BYTE * SealedBlob, [in] UINT32 SealedBlobLen, [out] SECRET S, [out] DIGEST Source )

Parameters Unseal-Input :: = SEQUENCE { ordinal INTEGER, sealed-blob OCTET STRING} Unseal-Output :: = SEQUENCE { ordinal INTEGER, status INTEGER, secret Secret, source Digest}

Return value SSP_SUCCESS SSP_UNSEAL_ERROR

comment In the Unseal operation, the blob generated by the Seal operation is internally decrypted and the following conditions are inspected. Is the coding correct? -Is the current value of PCR the one named as the target during Seal operation?

If all tests are successful, it returns the PCR of the secret and the sealed object, otherwise it returns UNSEAL_ERROR.

Access policy Allowed = FeatureEnable.MainEnable &amp; (FeatureEnable.UseSymmKey == All | FeatureEnable.UseSymmKey == AuthSL &amp; SLKnown &amp; AuthPCR [CurrentSL] .UseSymmKey)

processing In the Unseal operation, the following processing is performed. 1. M = AES-1 [K_S] (Sealed Blob). 2. Interpret M as (BITS [128] R The SECRET S1 The DIGEST Target 0 The DIGEST Target 1 The DIGEST Sealer 0 The DIGEST Sealer 1 The DIGEST N). 3. Digest D = HMAC [K_M] (R The S1 The Target 0 The Target 1 The Sealer 0 The Sealer 1). 4. In the case of (Target0! = PCR [0] The Target1! = PCR [1]), set 0 to S and Source and return SSP_UNSEAL_ERROR. 5. When D! = N, set S and Source to 0 and return SSP_UNSEAL_ERROR. 6. Otherwise, set S to S1 and Source to {Sealer0, Sealer1} and return SSP_SUCCESS.

Quote Definition SSP_STATUS Quote ( [in] BITSTRING d-ext, [out] PKSignature SigBlob )

Parameters Quote-Input :: = { ordinal INTEGER, d-ext Digest} Quote-output :: = { ordinal INTEGER, status INTEGER, sig-blob PKSignature}

Return value SSP_SUCCESS SSP_CRYPTO_ERROR

comment The Quote operation instructs the SSP to sign the concatenation of externally supplied D-EXT and internal PCR values.

Access policy Allowed = FeatureEnable.MainEnable &amp; (FeatureEnable.UsePrivKey == All | FeatureEnable.UsePrivKey == AuthSL &amp; SLKnown &amp; AuthPCR [CurrentSL] .UsePrivKey)

processing In the Quote operation, the following processing is performed. 1. The SSP forms a message M consisting of the identifier D-EXT of the message type QuoteMessage and the concatenation of the contents of the PCR register under DER (Distinguished Encoding Rules) encoding. SEQUENCE { message-typePKMessageType, d-ext Digest, pcr Digest Pair }

2.SSP is K_Q, PRIV is used to generate a signed message for M according to the default implementation of RSASSA-PSS-SIGN specified in PKCS # 1 V2.1. If this function returns an error, set SigBlob to 0 and return SSP_CRYPTO_ERROR.

3. SSP returns SSP_SUCCESS and the newly calculated signature value with SigBlob's signatureAlgorithm = rSASSA-PSS-Default-Identifier.

PKUnseal Definition SSP_STATUS PK_Unseal ( [in] PKCiphertext SealedBlob, [out] SECRET Secret )

Parameters PkUnseal-Input :: = { ordinal INTEGER, pk-sealed-blob PKCiphertext} PkUnseal-output :: = { ordinal INTEGER, status INTEGER, secret Secret}

Return value SSP_SUCCESS SSP_CRYPTO_ERROR SSP_BAD_DATA_ERROR

comment The PKUnseal operation takes an encrypted blob in a specific format with a length of 416 bits. The blob is decrypted, and if the decryption and decryption is successful, the 416-bit message is interpreted as a concatenation of the secret value and the PCR value that is allowed to receive the decrypted value.

If the current PCR value is equal to the one specified in the encrypted blob, it reveals the secret, otherwise it returns an error.

Access policy Allowed = FeatureEnable.MainEnable &amp; (FeatureEnable.UsePrivKey == All | FeatureEnable.UsePrivKey == AuthSL &amp; SLKnown &amp; AuthPCR [CurrentSL] .UsePrivKey)

processing In the PKUnseal operation, the following processing is performed. 1. SSP tests if the AlgorithmIdentifier for pk-sealed-blob is sspV1BoundKey.

2. SSP internally decrypts SealedBlob according to the default implementation of RSAES-OAEP-DECRYPT specified in PKCS # 1 V2.1 to obtain plaintext message M.

3. If the output of the decryption operation is a "decryption error", set Secret to 0 and return SSP_BAD_DATA_ERROR.

4. Otherwise, the recovered message M must have the form: SEQUENCE { message-type PKMessageType, secret Secret, target Digest}

In addition, the Secret must consist of 256 bits (= 32 octets) and the target must consist of 160 bits (= 20 octets). The message type must be sspV1PKSealedMessage. If any of these conditions are not met, Secret is set to 0 and SSP_BAD_DATA_ERROR is returned. If not 1. If target! = PCR, set Secret to 0 and return SSP_BAD_DATA_ERROR. 2. If target == PCR, set Secret to Secret and return SSP_SUCCESS.

Binding key operation In addition, binding key functions or pairs of binding key actions allow you to create and prove cryptographic keys locally (for example, by SSP) and to communicate cryptographic keys from trusted remote parties. (For example, communicate with the SSP).

The binding key functionality has the following characteristics. 1. A system tier serviceguard (eg SSP) has direct access to the binding key. Each binding key has an associated condition that determines which guard can access the binding key. The condition is implicitly expressed. That is, the binding key is encrypted so that only one or a set of guards has the key to decrypt the binding key.

2. The serviceguard with access to the binding key exposes features that require the use of the binding key to higher-level principals (eg signing, MAC, encryption, decryption). Each binding key can have associated terms of use, in which case the guard will only serve requests that satisfy the relevant terms.

3. The binding key is contained in a cryptographically protected data structure (also referred to herein as a binding key blob). Binding key blobs are self-protecting and can be stored outside of a trusted environment.

The binding key has the following advantages. Each principal can be allowed to have its own binding key. In addition, each principal can be allowed to have any number of binding keys. This allows for finer granularity policy settings and improves privacy in certain applications. Therefore, the guard need not be restricted to having only one or a few keys used to service requests from all principals.

-The binding key will not be disclosed outside of the authorized serviceguard. Therefore, jeopardizing the principal (eg, due to a programming error) does not jeopardize all binding keys. In one embodiment, a serviceguard (SSP) is implemented in hardware. In this case, the binding key cannot be compromised by malicious or malicious software.

The binding key feature provides encryption key protection. The binding key can be generated by a remote party or created locally via the GenBoundKey command.

A locally created binding key provides evidence of the type of public key, the type of key generated, the state of the machine being generated, and the (optional) condition (even a digest) to which the key is bound to it. Can issue a "citation" certificate that can be used to give to.

The binding key contains one or more of the following elements: -Key usage (eg BoundSign, BoundQuote, BoundPkUnseal, BoundPkDecrypt, BoundMAC, BoundEncrypt, or BoundDecrypt). This element is optional. If included, this element limits the binding key to use only in the identified functional type.

-Condition element (explained above) that specifies under what conditions this binding key can be used (also called binding key usage condition). For example, a condition can be expressed in the form of a digest of one or more programs. In this case, the binding key must only be used by or on behalf of the program for which the digest is specified. Other elements of the condition include time constraints, logical expressions, and executable programs, as explained above. This element is optional. If this element is omitted, certain default conditions apply. For example, the default condition may not restrict access to the binding key (empty condition).

A cryptographic key (binding key) or other data that allows the key to be calculated.

-One or more conditions under which the binding key usage conditions can be changed (explained above). Such changes are also referred to as binding key porting, and such conditions are referred to as porting conditions. This element is optional. If this element is omitted, certain default conditions apply. For example, the default condition can be "always false" so that the digest (if any) cannot be changed.

· Under that, one or more conditions that allow you to change the set of serviceguards that have direct access to the binding key. Such changes are also referred to as binding key exports, and such conditions are referred to as export conditions. This element is optional.

Cryptographic protection of binding keys The binding key has the same cryptographic requirements as the shielded storage and proof functions (Seal, Unseal, PKNseal) described above. Specifically, the locally generated binding key can be protected by any of the cryptographic embodiments of the Store and Retrieve functions described above. In any case, the authenticity of the binding key itself is protected and the integrity of the overall data structure is protected to ensure that the different conditions governing the usage of the binding key are not destroyed. To. As described earlier, this can be achieved by various combinations of symmetric or public key cryptography and MAC or digital certification. In one embodiment, the binding key data structure is encrypted with a public key.

function In certain embodiments, the binding key can be used in one or more of the functions below. BoundSign BoundQuote BoundPkDecrypt BoundPkUnseal BoundMAC BoundEncrypt Bound Decrypt GenBoundKey BoundKeyMigrate BoundKeyExport

For each of these functions, the binding key blob (a group of bits in the data structure) and the data manipulated by the keys contained in the binding key blob are provided as parameters to the binding key function. When a key usage element is included in a binding key blob, the SSP guarantees that the binding key will be used for the correct purpose (for example, a key created using the type "BoundQuoteKey" will have BoundQuote behavior. Can only be used in).

In some embodiments, the binding key is the private key of the public / private key pair. In such an embodiment, the binding key blob can contain a private key and instead can contain some data that allows the key to be calculated. For example, a private key fragment can be included in a binding key blob, which can be used with the corresponding public key to reconstruct the private key of a public / private key pair.

The BoundSign operation receives data input signed using the binding key and also receives the binding key blob. The SSP recovers the private signing key from the binding key blob and uses the recovered signing key to generate a digitally signed message for the data entry. The SSP then outputs a digitally signed message. If the binding key blob is corrupted or has binding key usage conditions that are not met, the SSP will not perform any action. Therefore, the recovered private key can be used to digitally sign the data entry without the SSP revealing the private key.

The BoundQuote operation takes the signed data and the binding key blob as input. The SSP recovers the private key from the binding key blob and then uses the recovered signing key to enter the data and current PCR values (eg, for example) in this operation, similar to the Quote operation described above. Generates a signature for the digest (identifier, etc.) of the program that called the BoundQuote operation. The SSP then outputs a digitally signed message. If the binding key blob is corrupted or has binding key usage conditions that are not met, the SSP will not perform any action. In one embodiment, the BoundQuote operation is similar to the BoundSign operation, except that the BoundQuote operation uses the current PCR value.

The BoundPkDecrypt operation takes the encrypted text and the binding key blob as input. The SSP recovers the private key from the binding key blob and uses the recovered secret binding key to decrypt the input ciphertext. After that, the decrypted data is output by the BoundPkDecrypt operation. If the binding key blob is corrupted or there is a binding key usage condition that is not met, the SSP will not perform any action.

The BoundPkUnseal operation takes the encrypted text and the binding key blob as input. The SSP recovers the private key from the binding key blob and uses it to decrypt the input ciphertext, similar to the PKNseal operation described above. The decrypted data is output by the BoundPk Unseal operation. If the binding key blob is corrupted or there is a binding key usage condition that is not met, the SSP will not perform any action.

In BoundMAC operation, the binding key is used to receive the data input for which the MAC is calculated, and the binding key blob is also received. If the binding key blob is corrupted or there is a binding key usage condition that is not met, the SSP will not perform any action. Otherwise, the SSP recovers the binding key from the binding key blob and uses the recovered binding key to generate a message confirmation code (MAC) for data entry. The SSP outputs the calculated MAC. Therefore, the SSP can use the recovered binding key to calculate the MAC of the data entry without revealing the binding key.

The BoundEncrypt operation receives data input that is encrypted using the binding key, and also receives the binding key blob. If the binding key blob is corrupted or there is a binding key usage condition that is not met, the SSP will not perform any action. Otherwise, the SSP recovers the binding key from the binding key blob and uses the recovered binding key to encrypt the data input. The SSP outputs the calculated ciphertext. Therefore, the SSP can use the recovered binding key to encrypt the data input without revealing the binding key.

The BoundDecrypt operation receives data input that is decrypted using the binding key, and also receives the binding key blob. If the binding key blob is corrupted or there is a binding key usage condition that is not met, the SSP will not perform any action. If not, the SSP recovers the binding key from the binding key blob and uses the recovered binding key to decrypt the data input. The SSP outputs the calculated plaintext. Therefore, the SSP can use the recovered binding key to decrypt the data input without revealing the binding key.

The GenBoundKey operation causes the SSP to create a new binding key. The new binding key is an encryption key, and a new binding key blob containing the newly generated key is generated. Please understand that the binding key blob does not always contain the entire key. For example, if the newly generated key is a public / private key pair, it may be sufficient to include only the private key in the binding key blob.

The new binding key blob is bound to one or more guards, and this guard is usually the SSP performing the action (for example, the new binding key blob similar to the Store function described above). By cryptographically protecting the new binding key blob in some other way, so that only that SSP can find it). The GenBoundKey operation can also have parameters that determine various aspects of the new binding key blob, and the data describing these parameters will be added to the newly generated private key in a way that protects some integrity. (For example, the data is part of a new binding key blob). Examples of this data include porting conditions, binding key usage conditions, etc., as described above. Then a new binding key blob is output by GenBoundKey.

In general, the binding key can be any type of cryptographic key, including a symmetric key or a public key private key pair. The exact key type depends on the binding key action in which it is used. For example, the binding key used for BoundMAC is usually a symmetric key, while the binding key used for BoundSign is usually a public / private signing key pair. The key type can be specified as a parameter to GenBoundKey.

BoundKeyMigrate allows you to change the conditions for using bound keys. The SSP verifies that one or more transplant conditions are met. Any of the various conditions can be used with the BoundKeyMigrate operation (for example, any condition that allows data to be ported and / or identifies the other party, similar to the conditions described above for Seal and UnSeal operations). If the verification is not successful, the operation will fail. If the validation is successful, the guard creates a new binding key blob, and within that binding key blob, the binding key usage conditions have been changed as required.

The BoundKeyExport operation tells the SSP to change the set of guards (SSPs) that have direct access to the binding key. The SSP verifies that one or more conditions are met. Any of the various conditions can be used with the BoundKeyExport operation (for example, if data can be exported and / or all conditions that identify the other party, similar to the conditions described above for Seal and UnSeal operations). If the verification is not successful, the operation will fail. If the validation is successful, the SSP modifies the cryptographic protection against the binding key blob as requested. In one embodiment, the SSP encrypts the bound key data structure with one or more new keys.

An example of a conditional class that can be specified by the creator of the binding key (local or remote) is that the binding key can only be used in place of a principal with a program digest that has a particular value. In this case, the binding key action checks the requesting principal's digest after an internal search of the binding key blob, and does not perform any additional calculations if the digest is not the one specified by the binding key blob. In addition, the binding key operation fails.

A binding key blob is usually tied to, or bound to, a particular SSP by a cryptographic operation that requires a unique key for that particular SSP to succeed. Examples of such behavior are MAC functions, digital signature functions, cryptographic functions, and combinations of cryptographic and integrity verification functions.

Example of binding key operation In one embodiment, porting is permitted by a local porting certificate or an export certificate issued by a permitting entity. The local port certificate is the default for RSASSA-PSS-SIGN operation for the following data structures. Bound-migration-info :: = SEQUENCE { source-bound-blob-digest Digest, dest-PCR Digest Pair }

Local SSP porting is required using the BoundKeyMigrate operation. To allow local porting, the SSP is provided with a Bound-migration-info structure that references this binding key, and a well-formed certificate for this structure provided by the authorized entity. If portability is acceptable, the SSP rebindings the key for a new PCR, leaving all other key attributes unchanged (for example, if the key was not originally bound to the PCR value). Is not bound even in the case of rebinding). A source-bound-blob-digest is an encrypted external digest of a binding key.

Remote porting is accomplished via the BoundKcyExport function, for example, using the Bound-export-info structure below, signed by a permitting entity. Bound export-info :: = SEQUENCE { source-bound-blob-digest Digest, dest-pubkey RSAPublicKey dest-PCR Digest Pair }

The permitting entity has full control over the device or software module to which the key is rebound if the key is marked as exportable.

PKCiphertext is used in the binding key operation, and this PKCiphertext is a sequence of the following type Bound-key-blob encrypted using the platform public encryption key. Bound-key-blob :: = SEQUENCE { message-type PKMessageType, key-type Bound-key-type, bound-to-PCR BOOL, bound-to Digest Pair, migrateable Bool, migrate-auth Digest, exportable Bool, export-auth Digest, pub-key-digest Digest, bound-key PKCompressedPrivateKey} here Bound-key-type :: = INTEGER { BoundSignKey, BoundQuoteKey BoundDecryptKey, BoundPkUnsealKey}

The bound-to-PCR element is a flag that indicates whether the bound-to digest field must match the current PCR value in order to use the bound key. {migrateable, migrate-auth} indicates whether the key is portable and, if so, which permissions it is under control (if migrateable is false, the migrate-auth value is important) Not). {exportable, export-auth} indicates whether the key is exportable and, if so, which permissions it is under control (if exportable is false, the export-auth value is important). Not). The pub-key-digest is a digest of the corresponding public key to provide a strong bond between the PKCompressedPrivateKey and the public key needed to recover the private key.

In one embodiment, when a binding key is created locally using the GenBoundKey function, the SSP is for a data structure detailing the public properties of the newly generated key, and for the configuration of the system during the binding key export. Create a signature. Bound-key-pub-info :: = SEQUENCE { message-type PKMessageType, // sspV1BoundKeyGenMessage sig-nonce Digest, key-type Bound-key-type, bound-to-PCR BOOL, bound-to Digest Pair, migrateable Bool, migrate-auth Digest, exportable Bool, export-auth Digest, creator-PCR Digest Pair bound-pub-key Digest}

Within this data structure, key-type, bound-to-PCR, bound-to, migrateable, migrate-auth, exportable, and export-auth are the binding key properties of newly generated keys. The creator-PCR is the PCR that was active when the key was exported, and the bound-pub-key is the digest of the newly created public key. sig-nonce is the digest size value passed when binding key generation was requested.

Illustrative definitions of BoundSign, BoundQuote, BoundPkDecrypt, BoundPkUnseal, GenBoundKey, BoundKeyMigrate, and BoundKeyExport behaviors are shown below.

BoundSign Definition SSP_STATUS BoundSign ( [in] PKCiphertext BoundKeyBlob, [in] RSAPublicKey PubPartOfBoundKey, [in] BITSTRING DataToBeSigned [out] PKSignature sig-blob )

Parameters BoundSign-Input :: = { ordinal INTEGER, bound-key BoundKeyBlob, bound-pub-key RSAPublicKey, data-to-be-signed OCTET STRING} BoundSign-output :: = { ordinal INTEGER, status INTEGER, sig-blob PKSignature}

Return value SSP_SUCCESS SSP_CRYPTO_ERROR SSP_BAD_DATA_ERROR SSP_UNSEAL_ERROR

comment The BoundSign operation takes the PKciphertext of type sspV1BoundKey containing the BoundKeyBlob of type BoundSignKey and the corresponding public key. If either of these conditions is not met, or if the sequence cannot be decrypted, the operation fails and SSP_CRYPTO_ERROR is returned.

If bound-to-PCR is set, the SSP checks that the current PCR value is specified in the Bound-key-blob sequence. Otherwise, SSP returns SSP_CRYPTO_ERROR.

Finally, the SSP signs the input message with the decrypted private key.

Access policy Allowed = FeatureEnable.MainEnable &amp; (FeatureEnable.UsePrivKey == All | FeatureEnable.UsePrivKey == AuthSL &amp; SLKnown &amp; AuthPCR [CurrentSL] .UsePrivKey)

processing In the BoundSign operation, the following processing is performed. 1. SSP tests if the AlgorithmIdentifier for pk-sealed-blob is sspV1BoundKey.

2. SSP internally decrypts SealedBlob according to the default implementation of RSAES-OAEP-DECRYPT specified in PKCS # 1 V2.1 to obtain plaintext message M.

3. If the output of the decryption operation is a "decryption error", set Secret to 0 and return SSP_CRYPTO_ERROR.

4. Otherwise, the recovered message M must be Bound-key-blob format DER-encoded of type BoundSignKey. Otherwise, the SSP must issue SSP_CRYPTO_ERROR.

5. If the bound-to-PCR is TRUE, the bound-to must be compared to the current PCR value. If these values are not the same, the SSP must output SSP_CRYPTO_ERROR.

6. The SSP recovers the bound private key using the associated public key provided. If this fails, the SSP returns SSP_CRYPTO_ERROR. On success, the SSP uses the recovered private key binding key to send a signed message to the input message DataToBeSigned according to the default implementation of RSASSA-PSS-SIGN specified in PKCS # 1 V2.1. Generate. If this function returns an error, set SigBlob to 0 and return SSP_CRYPTO_ERROR.

7. Returns SSP_SUCCESS.

BoundQuote Definition SSP_STATUS BoundQuote ( [in] PKCiphertext BoundKeyBlob, [in] DIGEST DataToBeSigned [out] PKSignature sig-blob )

Parameters BoundQuote-Input :: = { ordinal INTEGER, bound-key BoundKeyBlob, bound-pub-key RSAPublicKey, data-to-be-quoted Digest} BoundQuote-output :: = { ordinal INTEGER, status INTEGER, sig-blob PKSignature}

Return value SSP_SUCCESS SSP_CRYPTO_ERROR SSP_BAD_DATA_ERROR SSP_UNSEAL_ERROR

comment In BoundQuote operation, PKcipher text of type sspV1BoundKey including BoundKeyBlob of type BoundQuoteKey is taken. If either of these conditions is not met, or if the sequence cannot be decrypted, the operation fails and SSP_CRYPTO_ERROR is returned.

If bound-to-PCR is set, the SSP checks that the current PCR value is specified in the Bound-key-blob sequence. Otherwise, SSP returns SSP_CRYPTO_ERROR.

Finally, the SSP quotes the input message with the decrypted private key.

Access policy Allowed = FeatureEnable.MainEnable &amp; (FeatureEnable.UsePrivKey == All | FeatureEnable.UsePrivKey == AuthSL &amp; SLKnown &amp; AuthPCR [CurrentSL] .UsePrivKey)

processing In the BoundQuote operation, the following processing is performed. 1. SSP tests if the AlgorithmIdentifier for pk-sealed-blob is sspV1BoundKey.

2. SSP internally decrypts SealedBlob according to the default implementation of RSAES-OAEP-DECRYPT specified in PKCS # 1 V2.1 to obtain plaintext message M.

3. If the output of the decryption operation is a "decryption error", set Secret to 0 and return SSP_CRYPTO_ERROR.

4. Otherwise, the recovered message M must be Bound-key-blob format DER-encoded of type BoundQuoteKey. Otherwise, the SSP must issue SSP_CRYPTO_ERROR.

5. If the bound-to-PCR is true, the bound-to must be compared to the current PCR value. If these values are not the same, the SSP must output SSP_CRYPTO_ERROR.

6. The SSP then reconstructs the private key using the recovered private key fragment and public key. The private key can be reconstructed as follows. In general, an RSA key consists of the number N = p × q (N is the product of two prime numbers p and q) and two exponents e (encryption exponent) and d (cryptanalysis exponent). N and e form the public key and d is the private key. In general, d is as long as N (for example, 2048 bits). If the factorization of N is known (ie, p and q are known), then the private key d can be easily determined. Note that p and q are only half the length of N. Therefore, instead of storing d as a private key, p is stored in the present invention. Therefore, given the public keys N, e, and p, the value q = N / p can be calculated, and then the value d can be determined from p and q.

This private key is then used to generate the input message DataToBeSigned and a signing message for the current PCR value, as specified in the Quote behavior defined above. If this function returns an error, set SigBlob to 0 and return SSP_CRYPTO_ERROR.

7. Returns SSP_SUCCESS.

BoundPkDecrypt Definition SSP_STATUS BoundPkDecrypt ( [in] PKCiphertext BoundKeyBlob, [in] RSAPublicKey BoundPubKey, [in] PKCiphertext DataToBeDecrypted, [out] Secret decryptedData )

Parameters BoundPkDecrypt-Input :: = { ordinal INTEGER, bound-key BoundKeyBlob, bound-pub-key RSAPublicKey, pk-sealed-blob PKCiphertext} BoundPkDecrypt-output :: = { ordinal INTEGER, status INTEGER, d-blob Secret}

Return value SSP_SUCCESS SSP_UNSEAL_ERROR SSP_CRYPTO_ERROR SSP_BAD_DATA_ERROR

comment In BoundPkDecrypt operation, PKciphertext of type sspV1BoundKey including BoundKeyBlob of type BoundDecryptKey is taken. If either of these conditions is not met, or if the sequence cannot be decrypted, the operation fails and SSP_CRYPTO_ERROR is returned.

If bound-to-PCR is set, the SSP checks that the current PCR value is specified in the Bound-key-blob sequence. Otherwise, SSP returns SSP_CRYPTO_ERROR.

Finally, the SSP decrypts the input message with the private key decrypted from the bound blob.

Access policy Allowed = FeatureEnable.MainEnable &amp; (FeatureEnable.UsePrivKey == All | FeatureEnable.UsePrivKey == AuthSL &amp; SLKnown &amp; AuthPCR [CurrentSL] .UsePrivKey)

processing In the BoundPkDecrypt operation, the following processing is performed. 1. SSP tests if the AlgorithmIdentifier for pk-sealed-blob is sspV1BoundKey.

2. SSP internally decrypts SealedBlob according to the default implementation of RSAES-OAEP-DECRYPT specified in PKCS # 1 V2.1 to obtain plaintext message M.

3. If the output of the decryption operation is a "decryption error", set Secret to 0 and return SSP_CRYPTO_ERROR.

4. Otherwise, the recovered message M must be Bound-key-blob format DER-encoded of type BoundDecryptKey. Otherwise, the SSP must issue SSP_CRYPTO_ERROR.

5. If the bound-to-PCR is true, the bound-to must be compared to the current PCR values, and if these values are not the same, the SSP must output SSP_CRYPTO_ERROR. ..

6. The SSP recovers the private key using the public key provided. The private key can be recovered as described above for BoundQuote behavior. Then, using the recovered secret binding key, decrypt pk-sealed-blob using the default implementation of RSAES-OAEP-DECRYPT specified in PKCS # 1 V2.1 to get the plaintext message M. To do.

7. SSP sets d-blob to M.

8. Returns SSP_SUCCESS.

BoundPkUnseal Definition SSP_STATUS BoundPKUnseal ( [in] PKCiphertext BoundKeyBlob, [in] RSAPublicKey BoundPubKey, [in] PKCiphertext DataToBeUnsealed [out] Secret decryptedData )

Parameters BoundPKUnseal-Input :: = { ordinal INTEGER, bound-key BoundKeyBlob, bound-pub-key RSAPublicKey, pk-sealed-blob PKCiphertext} BoundPKUnseal-output :: = { ordinal INTEGER, status INTEGER, d-blob Secret}

Return value SSP_SUCCESS SSP_UNSEAL_ERROR SSP_CRYPTO_ERROR SSP_BAD_DATA_ERROR

comment In BoundPkUnseal operation, PKcipher text of type sspV1BoundKey including BoundKeyBlob of type BoundPKUnsealKey is taken. If either of these conditions is not met, or if the sequence cannot be decrypted, the operation fails and SSP_CRYPTO_ERROR is returned.

If bound-to-PCR is set, the SSP checks that the current PCR value is specified in the Bound-key-blob sequence. Otherwise, SSP returns SSP_CRYPTO_ERROR.

Finally, the SSP uses PK_Unseal with the private key decrypted from the bound blob to unseal the input message.

Access policy Allowed = FeatureEnable.MainEnable &amp; (FeatureEnable.UsePrivKey == All | FeatureEnable.UsePrivKey == AuthSL &amp; SLKnown &amp; AuthPCR [CurrentSL] .UsePrivKey)

processing In the BoundPkUnseal operation, the following steps are performed. 1. SSP tests if the AlgorithmIdentifier for pk-sealed-blob is sspV1BoundKey.

2. SSP internally decrypts SealedBlob according to the default implementation of RSAES-OAEP-DECRYPT specified in PKCS # 1 V2.1 to obtain plaintext message M.

3. If the output of the decryption operation is a "decryption error", set Secret to 0 and return SSP_CRYPTO_ERROR.

4. Otherwise, the recovered message M must be Bound-key-blob format DER-encoded of type BoundDecryptKey. Otherwise, the SSP must issue SSP_CRYPTO_ERROR.

5. If the bound-to-PCR is true, the bound-to must be compared to the current PCR value. If these values are not the same, the SSP must output SSP_CRYPTO_ERROR.

6. The SSP recreates the private key using the binding key blob. The private key can be recovered as described above for BoundQuote behavior. Then use the recovered secret binding key and unseal the pk-sealed-blob using the steps described in the PK_Unseal command.

7. If the PCR named in the unsealed blob does not match the current PCR, the SSP returns SSP_CRYPTO_ERROR.

8. If not, the SSP sets d-blob to M.

9. Returns SSP_SUCCESS.

GenBoundKey Definition SSP_STATUS GenBoundKey ( [in] BoundKeyType KeyType, [in] BOOL BoundToPcr, [in] DIGEST BoundTo [2], [in] BOOL migrateable, [in] DIGEST migration Authority, [in] BOOL exportable, [in] DIGEST export Authority, [in] DIGEST Sig Nonce, [out] BoundKey bound-key, [out] PKPublickey newPubKey, [out] PKSignature boundKeyQuoteBlob )

Parameters GenBoundKey-Input :: = { ordinal INTEGER, key-type Bound-key-type, bound-to-pcr BOOL, bound-to Digest Pair, migrateable BOOL, migrate-auth Digest, exportable BOOL, export-auth Digest, sig-nonce Digest } GenBoundKey-output :: = { ordinal INTEGER, status INTEGER, bound-blob PK Ciphertext, bound-pub RSAPublicKey, sig-blob PKSignature}

Return value SSP_SUCCESS SSP_BAD_DATA_ERROR

comment The GenBoundKey operation causes the SSP to generate a new bound-key blob containing the newly generated private key. The bound-key blob is encrypted using the public key of the SSP itself.

GenBoundKey also outputs the public key of the newly generated key pair, the citation signature indicating that the SSP generated the key, its characteristics, and the PCR value when the key was generated.

The caller of GenBoundKey also indicates the type of binding key created, that is, whether it is used for signing, quoting, unsealing with BoundPkUnseal, or decrypting with BoundPkDecrypt. The caller also specifies whether the binding key must be bound to the PCR and, if so, the PCR value to which it is bound.

Access policy Allowed = FeatureEnable.MainEnable &amp; (FeatureEnable.UsePrivKey == All | FeatureEnable.UsePrivKey == AuthSL &amp; SLKnown &amp; AuthPCR [CurrentSL] .UsePrivKey)

processing In the GenBoundKey operation, the following processing is performed. 1. The SSP generates a new public secret RSA key pair. The SSP can optionally generate a key pair if the SSP is idle and store it in a small cache of keys in non-volatile memory for immediate retrieval.

2. The SSP internally generates a newly generated private key and a binding key structure containing the type of binding key supplied by the caller and other parameters.

3. The SSP encrypts the binding key blob using the platform public encryption key.

4. The SSP will generate a Bound-key-pub-info signed blob containing the properties of the newly created key, the PCR value at the time of key creation, and the provided nonce.

5. The SSP outputs the encrypted binding key blob, the newly generated public key, and the quoted key blob.

6. Returns SSP_SUCCESS.

BoundKeyMigrate Definition SSP_STATUS BoundKeyMigrate ( [in] PKCiphertext BoundKeyBlob, [in] RSAPublicKey PubPartOfBoundKey, [in] BOUND_MIGRATION_INFO MigrationInfo, [in] RSA_SIG SigOnMigrationInfo )

Parameters GenBoundKey-Input :: = { ordinal INTEGER, migration-info Bound-migration-info, migration-pubkey RSAPublicKey, migration-auth PK Signature } GenBoundKey-output :: = { ordinal INTEGER, status INTEGER, re-bound-blob PKCiphertext, }

Return value SSP_SUCCESS SSP_BAD_DATA_ERROR

comment The BoundKeyMigrate operation instructs the SSP to rebind the key to a different PCR value in a controlled manner. The original local or remote key creator specifies the name of the portable entity. Only binding keys marked as portable can be ported, and these binding keys will only be ported if a properly signed Bound-migration-info structure is supplied to the SSP. Properly signed means a signature using the public key that contains the digest of the binding key blob. Other binding key attributes are unchanged.

Access policy Allowed = FeatureEnable.MainEnable &amp; (FeatureEnable.UsePrivKey == All | FeatureEnable.UsePrivKey == AuthSL &amp; SLKnown &amp; AuthPCR [CurrentSL] .UsePrivKey)

processing In the BoundKeyMigrate operation, the following processing is performed. 1. The SSP internally decrypts the bound-key structure and interprets it as a Bound-key-blob. If the decryption fails, the SSP returns SSP_CRYPTO_ERROR.

2. The SSP refers to the same key in Bound-export-info, the signature is formed correctly, and the digest of the signer's public key is named in the "migrateable" field of the Bound-key-blob. Verify that is specified.

3. The SSP checks that the key is portable. Otherwise, SSP returns SSP_CRYPO_ERROR.

4. If the key is bound to PCR, the SSP checks that the current PCR is named in the key blob.

5. The SSP replaces the PCR value with the one named in the dest-PCR field of Bound-migration-info.

6. The SSP re-encrypts the binding key blob and exports the re-encrypted structure.

7. Returns SSP_SUCCESS.

BoundKeyExport Definition SSP_STATUS BoundKeyExport ( [in] PKCiphertext BoundKeyBlob, [in] RSAPublicKey PubPartOfBoundKey, [in] BOUND_EXPORT_INFO ExportInfo, [in] RSA_SIG SigOnExportInfoInfo, [out] PKCipherText ReBoundBlob )

Parameters BoundKeyExport-Input :: = { ordinal INTEGER, bound-key PKCipherText, bound-pub-key RSAPublicKey, export-info Bound-export-info, export-auth PKSignature, } GenBoundKey-output :: = { ordinal INTEGER, status INTEGER, re-bound-blob PKCiphertext, }

Return value SSP_SUCCESS SSP_BAD_DATA_ERROR

comment The BoundKeyExport operation instructs the SSP to export the secret part of the binding key to the remote entity in a controlled manner and consistently with the binding key of the source device. The original local or remote key creator specifies the name of the export-permitted entity. Only binding keys marked as exportable can be exported, and these binding keys are only exported if a properly signed Bound-export-info structure is supplied to the SSP. Properly signed means a signature using the public key that contains the digest of the original binding key blob. BoundKeyExport allows a properly authorized caller to specify the public key and PCR value of the target entity for which the key must be rebound to it. There is no special requirement that the external entity be an SSP, but newly bound blobs follow binding key conventions to allow remote SSPs to directly consume the exported binding key.

Access policy Allowed = FeatureEnable.MainEnable &amp; (FeatureEnable.UsePrivKey == All | FeatureEnable.UsePrivKey == AuthSL &amp; SLKnown &amp; AuthPCR [CurrentSL] .UsePrivKey)

processing In the BoundKeyExport operation, the following processing is performed. 1. The SSP internally decrypts the bound-key structure and interprets it as a Bound-key-blob. If the decryption fails, the SSP returns SSP_CRYPTO_ERROR.

2. The SSP refers to the same key in Bound-export-info, the signature is formed correctly, and the digest of the signer's public key is named in the "exportable" field of the Bound-key-blob. Verify that is specified.

3. The SSP checks that the key is exportable. Otherwise, SSP returns SSP_CRYPO_ERROR.

4. If the key is bound to PCR, the SSP checks that the current PCR is named in the key blob.

5. The SSP internally creates a new Bound-key-blob structure containing the parameters of the original Bound-key-blob structure and the new PCR values supplied by Bound-export-info. All other parameters remain the same.

6. The SSP encrypts the new Bound-key-blob with the public encryption key provided by Bound-export-info.

7. Export the newly bound key.

8. Returns SSP_SUCCESS.

General computer environment FIG. 12 shows a general purpose computer environment 400 that can be used to perform the techniques described herein. The computer environment 400 is just one example of a computing environment and is not intended to imply limits on the scope or functionality of the use of computer and network architectures. Also, the computer environment 400 shall not be construed as having a dependency or requirement for any one or combination of the components shown in the exemplary computer environment 400.

The computer environment 400 includes a general purpose computing device in the form of a computer 402. Computer 402 can be used, for example, to implement the Principal 102 and Guard 104 of FIG. 1 or the layer of FIG. The components of computer 402 include one or more processors or processing units 404 (optionally one or more security processors or security coprocessors (such as SSP)) and / or one or more cryptographic processors or coprocessors. It can include, but is not limited to, a system bus 408 that combines various system components, including a processor), system memory 406, and processor 404 into system memory 406.

System bus 408 is one of several types of bus architectures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor buses or local buses that use any of the various bus architectures. Represents multiple. For example, such architectures include Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnects, also known as mezzanine buses. (PCI) bus can be included.

Computer 402 typically includes a variety of computer-readable media. Such media can be any usable medium accessible by computer 402, including both volatile and non-volatile media, removable and non-removable media. Is done.

System memory 406 includes computer-readable media in the form of volatile memory such as random access memory (RAM) 410 and / or non-volatile memory such as read-only memory (ROM) 412. A basic input / output system (BIOS) 414 containing basic routines that help transfer information between elements in computer 402, such as during boot, is stored in ROM 412. RAM410 typically contains data and / or program modules that are immediately accessible from processor 404 and / or are currently manipulated by processor 404.

Computer 402 can also include other removable / non-removable, volatile / non-volatile computer storage media. For example, Figure 12 shows the magnetics that read from and write to a non-removable non-volatile magnetic medium (not shown), a hard disk drive 416, read from and write to it from a removable non-volatile magnetic disk 420 (eg, a "floppy® disk"). A disk drive 418 and an optical disk drive 422 that reads from and / or writes to a removable non-volatile optical disk 424 such as a CD-ROM, DVD-ROM, or other optical medium are shown. The hard disk drive 416, magnetic disk drive 418, and optical disk drive 422 are each connected to system bus 408 by one or more data medium interfaces 426. Instead, hard disk drive 416, magnetic disk drive 418, and optical disk drive 422 can be connected to system bus 408 through one or more interfaces (not shown).

The disk drive and associated computer readable media provide non-volatile storage of computer readable instructions, data structures, program modules, and other data on the computer 402. This example shows a hard disk 416, a removable magnetic disk 420, and a removable optical disk 424, but a magnetic cassette or other magnetic storage device, a flash memory card, a CD-ROM, a digital versatile disk (DVD). Or other types of computer-accessible data, such as other optical storage, random access memory (RAM), read-only memory (ROM), electroerasable programmable read-only memory (EEPROM), and the like. It should be appreciated that computer-readable media can also be used to implement exemplary computing systems and environments.

Any number of program modules, including, for example, operating system 426, one or more application programs 428, other program modules 430, and program data 432, hard disk 416, magnetic disk 420, optical disk 424, ROM 412, and / or It can be saved in RAM410. All or one of the resident components that support a distributed file system by each (or some combination of) such operating system 426, one or more application programs 428, other program modules 430, and program data 432. Can carry out the department.

The user can enter commands and information into computer 402 through input devices such as keyboard 434 and pointing device 436 (eg, "mouse"). Other input devices 438 (not specifically shown) can include microphones, joysticks, gamepads, satellite dishes, serial ports, scanners, and / or similar. These and other input devices are connected to the processing unit 404 via an I / O interface 440 that is coupled to the system bus 408, but with other interfaces such as a parallel port, game port, or universal serial bus (USB). It can also be connected by a bus structure.

A monitor 442 or other type of display device can also be connected to the system bus 408 via an interface such as a video adapter 444. In addition to the monitor 442, other output peripherals can include components that can be connected to the computer 402 via the I / O interface 440, such as speakers (not shown) and printer 446.

Computer 402 can operate in a networked environment using a logical connection to one or more remote computers, such as remote computing device 448. For example, the remote computing device 448 can be a personal computer, a portable computer, a server, a router, a network computer, a peer device or other common network node, and the like. The remote computing device 448 is illustrated as a portable computer that can include many or all of the elements and features described herein with respect to the computer 402.

The logical connection between computer 402 and remote computer 448 is illustrated as a local area network (LAN) 450 and a general wide area network (WAN) 452. Such networking environments are commonplace in offices, company-wide computer networks, intranets, and the Internet.

When implemented in a LAN networking environment, computer 402 is connected to local network 450 via a network interface or network adapter 454. When implemented in a WAN networking environment, the computer 402 typically includes a modem 456 or other means for establishing communication over the wide area network 452. Modem 456 can be internal or external to computer 402, but can be connected to system bus 408 via input / output interface 440 or other suitable mechanism. Please understand that the network connection shown is exemplary and that other means of establishing a communication link between computers 402 and 448 can be used.

In a networked environment, such as the one shown with the computing environment 400, the program module shown for computer 402 or a portion thereof can be stored in a remote memory storage device. As an example, the remote application program 458 resides in the storage device of the remote computer 448. For illustration purposes, application programs and other executable program components such as the operating system are shown as separate blocks in this figure, but such programs and components are at various times on the compute device 402. It should be understood that it resides in different storage components and is executed by the computer's data processor.

Various modules and techniques can be described herein in the general context of computer executable instructions executed by one or more computers or other devices, such as program modules. Program modules generally include routines, programs, objects, components, data structures, etc. that perform specific tasks or perform specific abstract data types. Generally, the functionality of a program module can be combined or distributed as desired in various embodiments.

Embodiments of these modules and techniques can be stored on or transmitted through some form of computer-readable medium. The computer-readable medium can be any usable medium accessible by the computer. As an example, rather than a limitation, computer-readable media can include "computer storage media" and "communication media."

A "computer storage medium" is a volatile and non-volatile, removable and removable device that is practiced by any method or technique for storing information such as computer-readable instructions, data structures, program modules, or other data. Includes non-removable media. Computer-readable media include RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROMs, digital versatile disks (DVDs) or other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices or others. Includes, but is not limited to, magnetic storage devices, or other media that can be used to store desired information and can be accessed by a computer.

A "communication medium" typically implements computer-readable instructions, data structures, program modules, or other data within a modulated data signal, such as a carrier wave or other transport mechanism. The communication medium also includes an information delivery medium. The term "modulated data signal" means a signal whose characteristics are set or changed in the form of encoding information within the signal. By way of example, but not by limitation, communication media include wired media such as wired networks or direct wiring connections and radio media such as acoustic, RF, infrared, and other radio media. Any combination of the above is also included in the scope of computer readable media.

Although the above description used a language specific to structural features and / or methodological behaviors, it should be understood that the invention defined in the claims is not limited to the particular features or behaviors described. Instead, certain features and behaviors are disclosed as exemplary embodiments of the practice of the invention.

An exemplary process for performing a 200 Seal operation 220 Illustrative process of performing UnSeal operation An exemplary process of performing a 250 Store operation An exemplary process of performing a 270 Seal operation 300 Quote An exemplary process for performing a quote operation 320 An exemplary process for performing a Verify operation Illustrative process of performing 340 PK Unseal operation An exemplary process for performing a 360 PK Seal operation An exemplary process that performs the 380 GenSeal operation