CA2425006C - Saving and retrieving data based on symmetric key encryption - Google Patents

Abstract

In accordance with certain aspects, data is received from a calling program. Ciphertext that includes the data is generated, using a symmetric cipher, in a manner that allows only one or more target programs to be able to obtain the data from the ciphertext. In accordance with other aspects, a bit string is received from a calling program. An identifier of the calling program is checked to determine whether the calling program is allowed to access data encrypted in ciphertext of the bit string. The integrity of the data is also verified, and the data is decrypted using a symmetric key. The data is returned to the calling program only if the calling program is allowed to access the data and if the integrity of the data is successfully verified.

Description

SAVING AND RETRIEVING DATA BASED ON SYMMETRIC KEY ENCRYPTION
A portion of the disclosure of this patent document contains material which 3 is subject to copyright protection. The copyright owner has no objection to the 4 facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but 6 otherwise reserves all copyright rights whatsoever.

9 This invention relates to saving and retrieving data, and particularly to saving and retrieving data based on symmetric key encryption.

13 Protecting data on computers so that the data is only disclosed to 14 appropriate parties has become an important concern for users. The types of data that users want to protect varies greatly, such as work-related or personal 16 confidential documents, bank account numbers, credit card numbers, social 17 security numbers, and so forth. Additionally, it is also important to some third 18 parties to protect the data on the users' computers from improper use or access.
19 For example, credit card issuers want credit card numbers to be protected so that they are not disclosed to malicious programs or parties hacking into the computer, 1 music companies want songs to be protected so they cannot be copied, movie

2 studios want movies to be protected so they cannot be copies, and so forth.

3 One solution to protect data on computers is to do away with general-

4 purpose computing devices and use special-purpose tamper-resistant boxes for delivery, storage, and display of secure content. This solution, however, can be 6 undesirable as it prevents users from expanding their computers (e.g., users cannot a install additional software components and/or hardware components on such s tamper-resistant boxes). Thus, it would be beneficial to provide a way to allow 9 data to be protected on general-purpose computing devices.

i l SUMMARY

12 Saving and retrieving data based on symmetric key encryption is described 13 herein.

14 In accordance with one aspect, data is received from a calling program.
Ciphertext that includes the data is generated, using a symmetric cipher, in a 16 manner that allows only one or more target programs to be able to obtain the data 17 from the ciphertext.

18 In accordance with another aspect, a bit string is received from a calling 19 program. An identifier of the calling program is checked to determine whether the calling program is allowed to access data encrypted in ciphertext of the bit string.
21 The integrity of the data is also verified, and the data is decrypted using a 22 symmetric key. The data is returned to the calling program only if the calling 23 program is allowed to access the data and if the integrity of the data is successfully 24 verified.

According to a broad aspect, there is provided a method, implemented in a computing device, the method comprising: receiving a bit string from a calling program; checking an identifier of the calling program to determine whether the calling program is allowed to access data encrypted in ciphertext of the bit string, the checking comprising: obtaining, from the bit string, identifiers of multiple target programs that are allowed to access the data; checking whether one of the identifiers of the multiple target programs is the same as the identifier of the calling program;
determining that the calling program is allowed to access the data if one of the identifiers of the multiple target programs is the same as the identifier of the calling program; and determining that the calling program is not allowed to access the data if none of the identifiers of the multiple target programs is the same as the identifier of the calling program; verifying the integrity of the data; decrypting the data using a symmetric key; and returning the data to the calling program only if the calling program is allowed to access the data and if the integrity of the data is successfully verified.

According to another broad aspect, there is provided one or more computer storage media having stored thereon a plurality of instructions that, when executed by one or more processors of a computing device, causes the one or more processors to: receive data from a calling program; generate, using a symmetric cipher, ciphertext that includes the data and identifiers of multiple target programs that are allowed to access the data; after the ciphertext is generated, receive a bit string from another calling program; check an identifier of the other calling program to determine whether the other calling program is one of the multiple target programs;
verify the integrity of the data; decrypt the data using a symmetric key; and return the data to the other calling program only if the other calling program is one of the multiple target programs and if the integrity of the data is successfully verified.
According to another broad aspect, there is provided one or more computer storage media having stored thereon a plurality of instructions that, when executed by one or more processors of a computing device, causes the one or more processors to: obtain an identifier of a calling application; generate a bit string 2a including the identifier of the calling application, data to be sealed for the calling application, and identifiers of multiple target applications that are allowed to unseal the data; generate a message authentication code (MAC) value for the bit string;
encrypt the bit string using a symmetric key and a symmetric cipher; and return the MAC value and the encrypted bit string to the calling application.

According to another broad aspect, there is provided one or more computer storage media having stored thereon a plurality of instructions that, when executed by one or more processors of a computing device, causes the one or more processors to: receive, from a calling program, a bit string including ciphertext and a message authentication code (MAC) value; decrypt the ciphertext in the bit string using a symmetric key to generate plaintext data; generate a message authentication code (MAC) value for at least a portion of the plaintext data; check whether the MAC
value in the bit string is equal to the generated MAC value; check whether an identifier of the calling program is included as one of multiple target program identifiers in the plaintext data, the multiple target program identifiers identifying multiple target programs that are allowed to unseal the plaintext data; and return the plaintext data to the calling program only if the MAC value in the bit string is equal to the generated MAC value and if the identifier of the calling program is included as one of the multiple target program identifiers in the plaintext data.

According to another broad aspect, there is provided a device comprising a plurality of hardware means, the plurality of hardware means including:
means for receiving a bit string from a calling program; means for checking an identifier of the calling program to determine whether the calling program is allowed to access data encrypted in ciphertext of the bit string, the means for checking determining that the calling program is allowed to access the data if the identifier of the calling program is included as one of multiple target program identifiers in the ciphertext; means for verifying the integrity of the data; means for decrypting the data using a symmetric key; and means for returning the data to the calling program only if the calling program is allowed to access the data and if the integrity of the data is successfully verified.
2b According to another broad aspect, there is provided one or more computer storage media having stored thereon a plurality of instructions that, when executed by one or more processors of a computing device, causes the one or more processors to:
receive a bit string from a calling program; check an identifier of the calling program to determine whether the calling program is allowed to access data encrypted in ciphertext of the bit string, wherein to check the identifier is to: obtain, from the bit string, identifiers of multiple target programs that are allowed to access the data; check whether one of the identifiers of the multiple target programs is the same as the identifier of the calling program; determine that the calling program is allowed to access the data if one of the identifiers of the multiple target programs is the same as the identifier of the calling program; and determine that the calling program is not allowed to access the data if none of the identifiers of the multiple target programs is the same as the identifier of the calling program; verify the integrity of the data; decrypt the data using a symmetric key; and return the data to the calling program only if the calling program is allowed to access the data and if the integrity of the data is successfully verified.

According to another broad aspect, there is provided a computing device comprising: a processor; and a memory, coupled to the processor, storing a plurality of instructions that when executed by the processor cause the processor to perform acts comprising: receiving a bit string from a calling program; checking an identifier of the calling program to determine whether the calling program is allowed to access data encrypted in ciphertext of the bit string, the checking comprising: obtaining, from the bit string, identifiers of multiple target programs that are allowed to access the data; checking whether one of the identifiers of the multiple target programs is the same as the identifier of the calling program; determining that the calling program is allowed to access the data if one of the identifiers of the multiple target programs is the same as the identifier of the calling program; and determining that the calling program is not allowed to access the data if none of the identifiers of the multiple target programs is the same as the identifier of the calling program; verifying the integrity of the data; decrypting the data using a symmetric key; and returning the data to the calling program only if the calling program is allowed to access the data and if the integrity of the data is successfully verified.
2c According to another broad aspect, there is provided a method, implemented in a computing device, the method comprising: receiving data from a calling program; generating, using a symmetric cipher, ciphertext that includes the data and identifiers of multiple target programs that are allowed to access the data;
after the ciphertext is generated, receiving a bit string from another calling program;
checking an identifier of the other calling program to determine whether the other calling program is one of the multiple target programs; verifying the integrity of the data; decrypting the data using a symmetric key; and returning the data to the other calling program only if the other calling program is one of the multiple target programs and if the integrity of the data is successfully verified.

According to another broad aspect, there is provided a computing device comprising: a processor; and a memory, coupled to the processor, storing a plurality of instructions that when executed by the processor cause the processor to:
receive data from a calling program; generate, using a symmetric cipher, ciphertext that includes the data and identifiers of multiple target programs that are allowed to access the data; after the ciphertext is generated, receive a bit string from another calling program; check an identifier of the other calling program to determine whether the other calling program is one of the multiple target programs; verify the integrity of the data; decrypt the data using a symmetric key; and return the data to the other calling program only if the other calling program is one of the multiple target programs and if the integrity of the data is successfully verified.

According to another broad aspect, there is provided a method, implemented in a computing device, the method comprising: obtaining an identifier of a calling application; generating a bit string including the identifier of the calling application, data to be sealed for the calling application, and identifiers of multiple target applications that are allowed to unseal the data; generating a message authentication code (MAC) value for the bit string; encrypting the bit string using a symmetric key and a symmetric cipher; and returning the MAC value and the encrypted bit string to the calling application.

2d According to another broad aspect, there is provided a computing device comprising: a processor; and a memory, coupled to the processor, storing a plurality of instructions that when executed by the processor cause the processor to:
obtain an identifier of a calling application; generate a bit string including the identifier of the calling application, data to be sealed for the calling application, and identifiers of multiple target applications that are allowed to unseal the data; generate a message authentication code (MAC) value for the bit string; encrypt the bit string using a symmetric key and a symmetric cipher; and return the MAC value and the encrypted bit string to the calling application.

According to another broad aspect, there is provided a method, implemented in a computing device, the method comprising: receiving, from a calling program, a bit string including ciphertext and a message authentication code (MAC) value; decrypting the ciphertext in the bit string using a symmetric key to generate plaintext data; generating a message authentication code (MAC) value for at least a portion of the plaintext data; checking whether the MAC value in the bit string is equal to the generated MAC value; checking whether an identifier of the calling program is included as one of multiple target program identifiers in the plaintext data, the multiple target program identifiers identifying multiple target programs that are allowed to unseal the plaintext data;
and returning the plaintext data to the calling program only if the MAC value in the bit string is equal to the generated MAC value and if the identifier of the calling program is included as one of the multiple target program identifiers in the plaintext data.

According to another broad aspect, there is provided a computing device comprising: a processor; and a memory, coupled to the processor, storing a plurality of instructions that when executed by the processor cause the processor to:
receive, from a calling program, a bit string including ciphertext and a message authentication code (MAC) value; decrypt the ciphertext in the bit string using a symmetric key to generate plaintext data; generate a message authentication code (MAC) value for at least a portion of the plaintext data; check whether the MAC value in the bit string is equal to the generated MAC value; check whether an identifier of the 2e calling program is included as one of multiple target program identifiers in the plaintext data, the multiple target program identifiers identifying multiple target programs that are allowed to unseal the plaintext data; and return the plaintext data to the calling program only if the MAC value in the bit string is equal to the generated MAC value and if the identifier of the calling program is included as one of the multiple target program identifiers in the plaintext data.

According to another broad aspect, there is provided a method, implemented in a computing device, the method comprising: receiving a bit string from a calling program; checking an identifier of the calling program to determine whether the calling program is allowed to access data encrypted in ciphertext of the bit string, the checking determining that the calling program is allowed to access the data if the identifier of the calling program is included as one of multiple target program identifiers in the ciphertext; verifying the integrity of the data;
decrypting the data using a symmetric key; and returning the data to the calling program only if the calling program is allowed to access the data and if the integrity of the data is successfully verified.

According to another broad aspect, there is provided one or more computer storage media having stored thereon a plurality of instructions that, when executed by one or more processors of a computing device, causes the one or more processors to: receive a bit string from a calling program; check an identifier of the calling program to determine whether the calling program is allowed to access data encrypted in ciphertext of the bit string, wherein to check the identifier is to determine that the calling program is allowed to access the data if the identifier of the calling program is included as one of multiple target program identifiers in the cipheirtext;
verify the integrity of the data; decrypt the data using a symmetric key; and return the data to the calling program only if the calling program is allowed to access the data and if the integrity of the data is successfully verified.

2f According to another broad aspect, there is provided a computing device comprising: a processor; and a memory, coupled to the processor, storing a plurality of instructions that when executed by the processor cause the processor to:
receive a bit string from a calling program; check an identifier of the calling program to determine whether the calling program is allowed to access data encrypted in ciphertext of the bit string, wherein to check the identifier is to determine that the calling program is allowed to access the data if the identifier of the calling program is included as one of multiple target program identifiers in the ciphertext;
verify the integrity of the data; decrypt the data using a symmetric key; and return the data to the calling program only if the calling program is allowed to access the data and if the integrity of the data is successfully verified.

2g I BRIEF DESCRIPTION OF THE DRAWINGS

2 The same numbers are used throughout the document to reference like 3 components and/or features.

4 Fig. 1 illustrates an exemplary access control model.

Fig. 2 shows an example access control environment employing four 6 different hierarchical layers.

7 Fig. 3 is a flowchart illustrating an exemplary process for implementing the 8 Seal operation.

9 Fig. 4 is a flowchart illustrating an exemplary process for implementing the io UnSeal operation.

11 Fig. 5 is a flowchart illustrating an exemplary process for implementing the 12 Store operation.

13 Fig. 6 is a flowchart illustrating an exemplary process for implementing the 14 Seal operation.

Fig. 7 is a flowchart illustrating an exemplary process for implementing the 16 Quote operation.

17 Fig. 8 is a flowchart illustrating an exemplary process for implementing the 18 Verify operation.

19 Fig. 9 is a flowchart illustrating an exemplary process for implementing the Seal operation 21 Fig. 10 is a flowchart illustrating an exemplary process for implementing 22 the PKSeaI operation.

23 Fig. 11 is a flowchart illustrating an exemplary process for implementing 24 the GenSeal operation.

lee@lhayes a 509.324.9256 3 Any. Docker No. MSI-13/6US

Fig. 12 illustrates a general computer environment, which can be used to 2 implement the techniques described herein.

Fig. I illustrates an exemplary access control model 100. A principal 102 6 can make a request to access a protected resource. The request is received by a guard 104, which is a component that controls access to a resource 106. Guard 8 104 examines the request and decides whether to grant the request based on an 9 access policy for the resource as well as other information, such as the identity of the principal 102 that issued the request. For ease of explanation, a single 11 principal 102, guard 104, and resource 106 are illustrated in Fig. 1.
However, it 12 should be noted that access control model 100 can include multiple principals 102, 13 multiple guards 104, and/or multiple resources 106.

14 A principal 102 refers to a component or module that requests access to protected data. This request may be a request to retrieve the protected data (e.g., a 16 request for retrieval of a cryptographic key), or a request to perform an 17 operation(s) using the protected data (e.g., the protected data could be a 18 cryptographic key and the request could be a request to encrypt or decrypt 19 particular data using the cryptographic key). The principal 102 can be implemented as a component or module in hardware, software, firmware, or a 21 combination of hardware, software, and/or firmware.

22 A guard 104 refers to a component or module that controls access to the 23 protected data. Guard 104 uses an access policy associated with the protected 24 data, as well as other information (such as the identity of the principal requesting access to the protected content), to determine whether to allow the principal to leeÃhayes pc 5037249256 4 Any. Docket No. MS1-13/6US

i access the protected data. If guard 104 determines that the requesting principal is 2 permitted to access the protected data, then guard 104 responds to the request in an 3 appropriate manner (e.g., if the request is a request for the protected data, then the 4 protected data is returned to the principal; or, if the request is a request for particular data to be encrypted using the protected data, then guard 104 encrypts 6 the particular data using the protected data and returns the ciphertext (the 7 encrypted data) to the principal). It should be noted that guard 104 may restrict s principals based on the nature of the request. For example, guard 104 may allow a 9 particular principal to have particular data signed using the protected data but may not allow the protected data to be returned to the particular principal.

11 A guard 104 can also be characterized as a disclosure guard and/or a service 12 guard. A service guard performs certain operations (e.g., encryption, decryption, 13 digital signing, etc.) with the protected data (e.g., a cryptographic key) at the 14 request of principals without disclosing the protected data. A disclosure guard, on the other hand, reveals the protected data to authorized requestors. It should be 16 noted that a particular guard 104 can be both a disclosure guard and a service 17 guard.

is Resource 106 can be any type of data to which access is to be restricted.
19 Examples of resources 106 include cryptographic keys, bank account numbers, credit card numbers, personal information such as social security numbers, 21 passwords, and so forth. Resource 106 can also be virtually anything else in a 22 computing device. For example, a resource 106 may also be physical memory 23 (e.g., RAM or ROM), optical or magnetic disks or disk drives, video cards, sound 24 cards, smart cards, and so forth. By way of another example, a resource 106 may lee0hayes pk 5w324.e256 5 Arry. Docker No. MSI-1316US

I also be operating system abstractions, such as processes, files, threads, 2 semaphores, and so forth.

3 In the discussion herein, access control model 100 is described 4 predominately with reference to being implemented on a single computing device.
However, it is to be appreciated that different portions of the model can be 6 implemented on different computing devices. For example, a principal 102 may 7 be on one computing device while a guard 104 and resource 106 may be on s another computing device.

9 The principals and guards on a computing device can be categorized into to any number n of hierarchical layers 1, Fig. 2 shows an example access control I1 environment employing four different hierarchical layers. In one implementation, 12 layer 11 refers to a hardware or security kernel layer, layer 12 refers to a basic 13 input/output system (BIOS) layer, layer 13 refers to an operating system (OS) layer, 14 and layer 14 refers to an application layer.

1s In the example environment of Fig. 2, the lowest layer (layer 11) guards a 16 root resource. Programs in the intermediate layers (layers 12 and 13) act as 17 principals that request access from the next lower layer, while at the same time act 18 as guards towards principals in the next higher layer. The intermediate layers can 19 thus add functionality for principals in higher layers.

20 By way of example, assume that a program 120 desires to retrieve a root 21 resource 128 that is guarded by guard 126. Program 120 acts as a principal 22 requesting access to the root resource 128 from module 122, which acts as a guard 23 of the resource. If module 122 has a copy of the resource 128 (e.g., previously 24 obtained from guard 126 in response to a previous request for the resource by 25 program 120 or some other program in layer 14, or when module 122 was Iee0hayes ,x sos 324-92% 6 Arty. Docker No. MSI-1316US

1 initialized and loaded in the computing device), then module 122 checks whether 2 program 120 is allowed to retrieve the resource. Module 122 then returns the 3 resource to program 120 if program 120 is allowed to retrieve the resource.

4 However, if module 122 does not have a copy of the resource 128, then module 122 acts as a principal requesting access to the root resource from module 6 124, which acts as a guard of the resource. If module 124 has a copy of the 7 resource 128 (e.g., previously obtained from guard 126 in response to a previous 8 request for the resource by module 122 or some other module in layer 13, or when 9 module 124 was initialized and loaded in the computing device), then module checks whether module 122 is allowed to retrieve the resource. Module 124 then 11 returns the resource to module 122 if module 122 is allowed to retrieve the 12 resource. Module 122 then returns the resource to program 120 if program 120 is 13 allowed to retrieve the resource.

14 However, if module 124 does not have a copy of the resource 128, then module 124 acts as a principal requesting access to the root resource from guard 16 126. Guard 126 checks whether module 124 is allowed to retrieve the resource, 17 and returns the resource to module 124 if module 124 is allowed to retrieve the 18 resource. Module 124 then returns the resource to module 122 if module 122 is 19 allowed to retrieve the resource, and module 122 returns the resource to program 120 if program 120 is allowed to retrieve the resource.

21 In the discussion herein, multiple references are made to employing access 22 control model 100 of Fig. 1 to allow authenticated operation of software.
23 Typically, the resources being protected in authenticated operation of software are 24 cryptographic keys. However, it is to be appreciated that authenticated operation of software is only one example of the use of access control model 100.

leeOhayes We ws 324.92e6 7 Arty. Docker No. MSI-/316US

1 Another example of the use of access control model 100 is the 2 authentication of a user(s) to a computer. Most modem computers have an access 3 control system. A user logs on to the computer so that the computer knows who 4 the user is. After logging on, the user runs programs that typically need to access s system resources (e.g. read files, write to windows on the screen, etc.).
Typically, 6 the access control system of the computer is consulted (e.g., "can user x perform 7 operation y on resource z?"). If the answer is "no" the program cannot access the 8 resource.

9 Another example of the use of access control model 100 is the authentication of a user(s) to a remote service. Remote services such as web sites 11 (e.g., on-line brokers or banks) can be thought of as having access control systems.
12 The resources are people's bank accounts, their money and their stocks.
After a 13 user logs on to the web site, the access control system will determine if the user is 14 authorized to perform the accesses requested by the user, such as a "read"
access on the resource "bank account data" (to retrieve the latest bank statement), or a 16 "transfer" access on the resource "$1000 in bank account 12345".

17 Yet another example of the use of access control model 100 is restricting 18 physical access to particular buildings or areas. For example, when a user arrives 19 at work in the morning, the user shows his or her badge and requests the "open"
operation on the resource "front door". Some electronic system (a guard) 21 determines, based on information stored on the badge, if the user is allowed to 22 enter the building and unlocks the door accordingly.

23 A computing device enables authenticated operation of a program 24 (software) if it is possible to let the program obtain protected access (from a disclosure guard or from a service guard) to at least one cryptographic resource.

BeeOhayes pc so433a.e2s6 8 Arty. Docker No. MS14316US

i In certain embodiments, a computing device that enables authentication and 2 isolation, as described below, enables authenticated operation.

3 A program C can be referred to as being isolated from another program D if 4 two points are satisfied: (1) there is memory that can be accessed by program C
but not by program D, and (2) program D cannot initiate execution of program C
6 (except, possibly, at an entry point(s) determined by program Q. A program is 7 given by its transition rules (executable code) and by its initial state (entry point(s) 8 or initial value of the instruction pointer IP). The first point guarantees integrity of 9 the program code and the state information of program C, even in the presence of adversarial behavior by program D, since data can be stored in the memory that 1 i cannot be accessed by program D. This point also allows program C to protect 12 confidential data (e.g., cryptographic keys) from observation by program D.
The 13 second point guarantees that D cannot subvert the behavior of C by choosing the 14 entry point adversarially.

Additionally, it can be said that a program C can authenticate a program D
16 if program C is able to identify both the transition rules (program code) and the 17 initial state of program D. The computing device enables isolation for any 18 program C from any other program D, with the exception of a single program 19 for each layer j < i, where i is the layer of program C. This protects programs from observation and interference by any program, except for the sequence E1, E2, 21 . . . ,Ei_, of guards through which program C requests access to its resources.
22 Furthermore, for any layer i, the computing device enables a program executing in 23 layer i to authenticate at least some programs in layer i + 1. This requirement 24 allows a program to act as a guard for requests from ;principals in the next layer.
These two observations give rise to an inductive argument that programs in any leeIhayes pe 509-32a-9256 9 Atty. Docket No. MSI-1316US

1 layer can act as guards for resources by requesting access to a resource from their 2 predecessor, protecting their integrity and the resource through isolation and 3 authenticating requests from principals in the next layer.

4 Isolation can be implemented by using physical memory protections. This approach is referred to as "isolation in space" or "space isolation". For example, 6 the ring and virtual memory, protections found in many modern microprocessors 7 are sufficient to implement isolation in space. An operating system kernel (layer i) s running in privileged mode can set up page tables for applications (layer i + 1), 9 such that any application can only access those parts of physical memory that the io operating system kernel chooses to map into the application's virtual address 11 space. Furthermore, the kernel restricts applications' privileges so that they cannot 12 change the memory mapping, and ensures that applications can initiate execution 13 of kernel code only at a well defined entry point(s) (system calls).

14 Another approach to implementing isolation between two layers is to separate their execution in time. This approach is referred to as "isolation in time"
16 or "time isolation". A program in a first layer i executes to completion, makes 17 certain resources unavailable, and then terminates. Subsequently, control is 18 transferred to the next layer i+l.

19 Authentication occurs between subsequent layers (j - i + 1). Program C
authenticates the program (transition rules) and the initial state of the 21 configuration of j. The program can be authenticated by letting program C
inspect 22 the program in layer j. That is, typically program C reads the memory, which 23 contains the program for layer j, and computes a cryptographic digest over this 24 memory range. It should be noted that the goal at this point is only to ascertain the leeohayes ak 509.324.9256 10 Atty. Docket No. MSI-1316US

i identity of the code, not to evaluate statements made by other principals about the 2 code. Thus, certificates are not necessary at this point..

3 The second task for program C is to identify the initial state of program D.
4 In general, the problem of determining the initial state of a program at an arbitrary s execution stage is very difficult. Thus, program C controls the initial state of 6 program D. In practical terms, this means that program C can only ascertain the 7 initial state a of program D if program C initiates the execution of program D at or.

8 In summary, in order to authenticate program D, program C inspects the 9 memory contents it deems relevant (program and, possibly, data) and computes a io cryptographic digest. After that, program C transfers execution to a well-defined entry point of program D.

12 In situations where the resources are cryptographic keys, authenticated 13 operation allows each operating system and application program to have exclusive 14 access to one or more secrets. The isolation discussed above protects each secret is from attacks by adversarial code. The authentication of programs discussed above 16 allows programs to be identified, such that each secret is disclosed only to the 17 program that owns it.

18 Generally, given a request from a program (a principal 102 of Fig. 1), a 19 guard 104 establishes the identity of the program (that is, guard 104 authenticates 20 the program). If the program is not the owner of the requested secret (a resource 21 106), then guard 104 rejects the request. Otherwise, guard 104 computes some 22 function of the secret (which may be the secret itself) and, possibly, further 23 information provided by the program and returns the result. Alternatively, rather 24 than explicitly accepting or rejecting requests, guard 104 may service the request 25 but bind the identity of the caller into the result. This alternate approach is !ee L hayes dk 509324.9256 11 Any. Docker No. MSI-1316US

I appropriate, for example, if the result returned by the guard does not contain 2 confidential information (e.g., requests to use a secret to produce a digital 3 signature). The term gating functions is used herein to refer to both of these cases.
4 Additionally, in either case, guard 104 authenticates the caller (principal 102). Authenticating a principal 102 is also referred to herein by a function IDO, 6 which returns a digest of the calling program (the program calling a gating 7 function of guard 104). The digest can be generated in any of a wide variety of 8 conventional manners, such as using any one or more of a variety of cryptographic 9 hash functions (also referred to as one-way hash functions), such as SHA1 (Secure to Hash Algorithm 1), MD5 (Message Digest 5), MDR? (Message Digest 2), etc.;
I i using a keyed MAC (Message Authentication Code); and so forth.

12 One class of gating functions described herein implement sealed storage.
13 The purpose of sealed storage is to allow programs to store secrets, such that only 14 a particular set of one or more programs (defined by the program that stores the is secret) can retrieve the secrets. In one implementation, only the program that 16 originally saves (seals) the secret can recover (unseal) the secret.
Typically, the 17 life time of these secrets will exceed the time of individual executions of the 18 program. Secrets used during a single execution of a program can be saved 19 (sealed), or alternatively isolation and a random number generator also allow a 20 program to maintain secrets during a single execution. Sealed storage also allows 21 a program to maintain secrets across different executions, which may not overlap 22 in time. A layer 1; exposes sealed storage to the next layer 1; 1 by means of the 23 following interface (e.g., using the "Seal" and "UnSeal" operations and/or PKSeal 24 and PKUnseal operations).

IeeOhayes Pk 509.324.92S6 12 Airy. Docket No. MSI-13!6US

1 The discussions herein regarding sealed storage refer to cryptographic keys 2 being used to encrypt and decrypt data. These cryptographic keys are the keys 3 associated with the guard that is guarding access to the resource (e.g., guard 104 of 4 Fig. 1).

The discussions herein also refer to identifiers of programs (e.g., an 6 identifier of the program calling or invoking an operation, or an identifier of a 7 target program that is allowed to access a resource). These identifiers are often 8 referred to herein as digests. However, it is to be appreciated that digests are only 9 one example of identifiers of programs. Other types of identifiers that are a measure or other representation of the program and that allow any changes to the 11 program to be detected can be used. If any changes are made to the program (e.g., 12 one or more instructions being changed by an adversary in an attempt to 13 maliciously gain access to and make use of the protected data) then the identifier 14 of the program should reflect that change (e.g., the identifier for the unchanged is program will be different than the identifier for the changed program).

16 The Seal operation receives, as an input, data (e.g., a secret) to be sealed.
17 The Seal operation also optionally receives, as an input, a condition that identifies 18 when and/or to whom the secret may be revealed (unsealed). In one 19 implementation, this condition is a digest of a target program that is allowed to retrieve (unseal) the data. Alternatively, programs that are to be allowed to 21 retrieve (unseal) the data can be identified in other manners. For example, the 22 programs may be identified by a public key that verifies one or more certificates, 23 with each certificate being associated with one or more of the programs.

24 Alternatively, other conditions may be used in addition to, or in place of, an identifier of a target program. For example, the condition may include particular Iee0hayes dk eos324v2ee 13 Arty. Docker No. MSI-1316US

1 time constraints for when the data can be revealed (unsealed), such as particular 2 times of the day or days of the week during which the secret can be revealed 3 (unsealed). By way of another example, the condition may include an identifier of 4 a password or other data that must be provided in order for the secret to be revealed (unsealed) - e.g., the secret can only be unsealed by programs having 6 knowledge of the password.

By way of yet another example, the condition can be a logical formula (e.g., 8 any statement written in first order logic, any statement written in predicate logic, 9 etc.). The logical formula is evaluated (e.g., by the guard) and the secret is to revealed (unsealed) only if the evaluation returns an indication of true.

11 In still another example, the condition can be an executable program in 12 some language (e.g., Java, C*, Javascript, VBScript, etc.). The program is 13 executed (e.g., by the guard) and the secret is revealed (unsealed) only if the 14 program returns some indication of "true" or "satisfied".

is In situations where the condition is the digest of the target program, rather 16 than being supplied with the digest of the target program, the Seal operation may 17 use the digest of the program that invokes the Seal operation (thereby implicitly 18 inputting the digest of the target program). Additionally, digests of multiple target 1g programs can be input to the Seal operation, thereby allowing multiple target 20 programs to retrieve (unseal) the data.

21 The Seal operation encrypts its inputs (the data and the condition(s) 22 allowing retrieval (unsealing) of the data) together with an identifier of the caller.
23 The Seal operation returns the input data in an encrypted form (as ciphertext). The 24 Seal operation also returns a value (e.g., a message authentication code (MAC) 25 value) that can be used to verify the integrity of the sealed data. This returned data lee4ghayes n~ 5e9.32 .92s6 14 Airy. Docker No. MSI-7316US

1 allows the stored data to be referenced in subsequent UnSeal operations, as 2 discussed in more detail below.

3 Pseudo code for the Seal operation is illustrated in Table 1. In the pseudo 4 code of Table I, IDO refers to the IDO function discussed above, e refers to the s value (e.g., a string or sequence of bits) that is returned to the caller, data refers to 6 the data to be sealed, and [t1i ..., t,, ] refers to the digests of one or more (rn) target 7 program(s) that are allowed to retrieve (unseal) the data (or alternatively one or 8 more other conditions).

9 Table I
d =ID() 11 e = store (data, [t1, ..., tm], d) return e 13 Fig. 3 is a flowchart illustrating an exemplary process 200 for 14 implementing the Seal operation. Process 200 is performed by a guard 104 of Fig.
1, and may be implemented in hardware, software, firmware, or a combination thereof.
17 Initially, a secret to be sealed is received from the caller (act 202). The 18 secret is encrypted so that the secret can only be retrieved by a particular target 19 program(s) (act 204), or alternatively so that the secret can only be retrieved if one or more particular conditions are satisfied. Ciphertext including the encrypted 21 secret is then returned to the caller (act 206). Additional information may also be 21 returned to the caller (as part of the ciphertext or separate from the ciphertext), 23 such as a digest of the caller and/or digest(s) of the target program(s).

Iee0hayes ax 50a32e=9256 15 Arrv. Docker No. MSI-1316US

I The UnSeal operation receives, as an input, a bit string that was returned by 2 the Seal operation when sealing data (e.g., a cryptographic key) that the calling 3 program now desires to retrieve. The UnSeal operation obtains the condition(s) 4 for revealing the data and checks whether those conditions are satisfied.
For s example, if the condition(s) included digest(s) of the one or more target 6 program(s) that are allowed to retrieve (unseal) the data, then the UnSeal operation 7 obtains those digest(s) and checks whether the calling program is one of the one or 8 more target program(s). If the calling program is not one of the one or more target 9 program(s) then the UnSeal operation fails and the requested data is not returned to the caller. However, if the calling program is one of the one or more target I I program(s), then the UnSeal operation succeeds and the requested data is returned 12 to the calling program. The digest of the program that sealed the data is also 13 optionally returned by the UnSeal operation.

14 Pseudo code for the UnSeal operation is illustrated in Table II. In the Is pseudo code of Table II, data refers to the data that is being requested (and that 16 has been previously sealed), [t,, ..., tõ,] refers to the digests of one or more (m) 17 target program(s) that are allowed to retrieve (unseal) the data (or alternatively one 18 or more other conditions), e refers to the input to the UnSeal operation (typically 19 previously output by a Seal operation), and d refers to the digest of the program that sealed the data.

21 Table II
22 (data, [t1, ..., t,,,], d) = retrieve(e) 23 if ID{ is in [t,, ..., tõ,] then return (data, d) else fail.

lee0hayes ax S2-92S6 16 Any. Docket No. MS1-7316US

CA 02425006 2003-04-09' Fig. 4 is a flowchart illustrating an exemplary process 220 for 2 implementing the UnSeal operation. Process 220 is performed by a guard 104 of 3 Fig. 1, and may be implemented in hardware, software, firmware, or a 4 combination thereof.

s Initially, ciphertext with encrypted data that the caller desires to retrieve is 6 received (act 222). A check is made as to whether the caller is allowed to retrieve 7 the data (act 224), and processing proceeds based on whether the caller is allowed 8 to retrieve the data (act 226). If the caller is allowed to retrieve the data, then the 9 data (decrypted) is returned to the caller (act 228). If the caller is not allowed to to retrieve the data, then the process fails (act 230) and the data is not returned to the 11 caller.

12 Sealed storage can be implemented in different manners. In one 13 implementation, sealed storage is implemented using physically protected non-14 volatile memory. In this implementation, the computing device associates 15 different guards with different portions of the protected non-volatile memory and 16 allows each guard to access only those portions which are associated with that 17 guard. In this implementation, the Store and Retrieve operations referenced in the is Seal and UnSeal operations are invoked to have the computing device store and 19 retrieve, respectively, the data in the protected non-volatile memory associated 20 with the guard.

21 By way of example, a storage device (such as a hard disk drive) can 22 implement a guard. Rather than simply executing read and write commands to the 23 storage device unconditionally, the storage device identifies the principal 24 attempting to access the storage device (e.g., based on a digest of the principal) 25 and allows only a particular principal(s) to access the storage device.

leeQhayes dk 5o432<-9256 1 / Am. Docker No. MSI-1316US

I Alternatively, different principals may be restricted to accessing only particular 2 portions of the storage device (e.g., particular sectors or address ranges).

3 In another implementation, sealed storage is implemented using 4 cryptography. A description of one exemplary implementation of sealed storage using cryptography follows.

6 When using cryptography to implement sealed storage, the resource is a 7 key K rather than physically protected memory. The Store operation does not s physically store its inputs. Rather, the Store operation produces a 9 cryptographically protected output c, which is the inputs of the Store operation in an encrypted and integrity protected form. The encryption is a result of applying a II symmetric cipher to the input(s). The latter property results from applying a 12 message authentication code (MAC) to the input(s) (either before or after the 13 input(s) is encrypted).

14 Pseudo code for the Store operation is illustrated in Table III. In the pseudo Is code of Table III, b refers to the bit string input to the Store operation, c refers to 16 the bit string output by the Store operation, KI refers to a first part of the key K, 17 and K2 refers to a second part of the key K. The key K is a symmetric key of the ,8 guard implementing the Seal and Store operations.

19 Table III
m = MACKI(b) 21 c = (m, EncryptK2(b)) return c 23 Thus, as can be seen in Table III, a value (m) is generated by applying a 24 MAC to the bit string input to the Store operation. The MAC is keyed to a portion lee63bhayes ck s 32a-9M 18 Atty. Docket No. MSl-1316US

1 (KI) of the key K. The bit string input to the store operation is also encrypted 2 using a second portion (K2) of the key K. The values generated by applying the 3 MAC to the input bit string and by encrypting the input bit string are then returned 4 to the caller of the Store operation.

The key K is partitioned into two independent keys KI and K2 in order to 6 avoid using the same key for the MAC and the cipher. This partitioning can be 7 performed in any of a variety of manners. The partitions may use different bits of g the key K or alternatively may use one or more of the same bits. For example, 9 assuming that the key K is 1024 bits, then the low 512 bits may be used as key KI
1o and the high 512 bits may be used as key K2, the even. numbered bits (bits 0, 2, 4, 11 6, 8, 10, ..., 1022) maybe used as key KI and the odd numbered bits (bits 1, 3, 5, 12 7, 9, 11, ..., 1023) may be used as key K2, the low 650 bits may be used as key 13 KI and the high 650 bits may be used as key K2 (resulting in some bits being used 14 for both KI and K2), and so forth. Alternatively, the same key K may be used for both the MAC and the cipher.

16 The pseudo code illustrated in Table III implements the Store operation by 17 computing a MAC over the data, encrypting the data, and outputting both the 18 MAC and the ciphertext. Alternatively, the Store operation may be implemented 19 in different manners. For example, the Store operation may encrypt the data first, then compute a MAC over the ciphertext and output both the ciphertext and the 21 MAC. By way of another example, the Store operation may compute a MAC over 22 the data, then encrypt both the data and the MAC, and output the ciphertext.

23 The encryption performed by the cipher of the Store operation can be 24 performed using any of a variety of symmetric encryption algorithms.
Generally, symmetric encryption algorithms use the same key for both encryption and lee@hayes pk 509324.9256 19 Airy. Docker No. MSI-1316US

1 decryption. Examples of such algorithms include triple-DES (Data Encryption 2 Standard), AES (Advanced Encryption Standard), and so forth.

3 Similarly, the MAC can be any of a variety of message authentication a codes, such as the MAC described in M. Bellare, R. Canetti, and H. Krawczyk, s "Keying hash functions for message authentication," in Advances in Cryptology -6 Crypto'96, number 1109 in Lecture Notes in CS, 1996. Alternatively, integrity 7 can be protected by means of a public key digital signature in place of a MAC.

8 Fig. 5 is a flowchart illustrating an exemplary process 250 for 9 implementing the Store operation. Process 250 is performed by a guard 104 of Fig. 1, and may be implemented in hardware, software, firmware, or a 11 combination thereof.

12 Initially, data to be stored is received (act 252). A symmetric cipher is 13 applied to the data (act 254) and a message authentication code (MAC) is applied 14 to the data (act 256). The encrypted data generated in act 254 and the MAC
value is generated in act 256 are then returned to the caller (act 258).

16 The Retrieve operation receives an input bit string that includes a MAC
17 value and ciphertext. The ciphertext is decrypted to generate plaintext and a MAC
is value is generated for the plaintext. If the MAC value generated for the plaintext 19 is the same as the MAC value received as part of the input bit string, then the plaintext is returned to the caller. However, if the MAC value generated for the 21 plaintext is not the same as the MAC value received as part of the input bit string, 22 then the Retrieve operation fails and the plaintext is not returned to the caller. It is 23 to be appreciated that the specific manner in which the Retrieve operation is 24 implemented to obtain the MAC and the ciphertext from the input bit string is dependent on the manner in which the Store operation is implemented lee ?hayes & 50e324~ZH 20 Arty. Docker No. MSI-1316US

1 Pseudo code for the Retrieve operation is illustrated in Table IV. In the 2 pseudo code of Table IV, c refers to the bit string input to the Retrieve operation, b 3 refers to the bit string output by the Retrieve operation, m refers to the MAC value 4 portion of the bit string input to the Retrieve operation, d refers to the ciphertext portion of the bit string input to the Retrieve operation, KI refers to a first part of 6 the key K, and K2 refers to a second part of the key K. The KI and K2 keys are 7 the same portions of the key K as discussed above with. respect to the Store 8 operation.

9 Table IV

Let(m,d)=c --~
1 b =DecryptK2(d)) if m = MACKI(b) then return b 12 else fail 13 Thus, as can be seen in Table IV, a value (b) is generated by decrypting the 14 bit string input to the Retrieve operation. A MAC value is then generated for the value (b). If the MAC value generated by the Retrieve operation is the same as the 16 MAC value that is received as part of the bit string input to the Retrieve operation 17 then the value (b) is returned to the caller of the Retrieve operation, otherwise the 18 Retrieve operation fails.

19 The pseudo code of Table IV is based on the implementation of the Store operation where the MAC is computed over the data, the data is encrypted, and the 21 MAC and ciphertext together are output (and serve as the input bit string to the Retrieve operation). If the Store operation were implemented to encrypt the data 22 23 first, then compute a MAC over the ciphertext and output both the ciphertext and 24 the MAC, then the Retrieve operation would be implemented to compute the MAC of the ciphertext and compare it to the MAC value received as part of the lee Ohayes ck 69432x9256 21 Arry. Docker No. MSI.7316US

1 input bit string, then decrypt the ciphertext and return the decrypted data if the 2 MAC values match. If the Store operation were implemented to compute a MAC
3 over the data then encrypt both the data and the MAC, then the Retrieve operation a would be implemented to decrypt the input bit string, then compute a MAC
over the data in the input bit string and compare the computed MAC to a MAC value in 6 the decrypted string, and return the data if the MAC values match.

7 Analogous to the discussion above regarding the Store operation, any of a 8 variety of decryption algorithms can be used by the Retrieve operation.
However, 9 the decryption algorithm should correspond to the encryption algorithm so that the to encrypted data can be decrypted. Similarly, any of a variety of message 11 authentication codes can be used as the MAC, but he message authentication code 12 used should be the same as the message authentication code used by the Store 13 operation.

14 Fig. 6 is a flowchart illustrating an exemplary process 270 for implementing the Seal operation. Process 270 is performed by a guard 104 of Fig.
16 1, and may be implemented in hardware, software, firmware, or a combination 17 thereof.

1R Initially, a ciphertext and MAC value are received (act 272). The 19 ciphertext is decrypted to generate plaintext data (act 274). A message authentication code (MAC) is applied to the plaintext data to generate a MAC
21 value (act 276) and a check is made as to whether the MAC value generated in act 22 276 is equal to the MAC value received in act 272 (act 278). Processing then 23 proceeds based on whether the generated MAC value is equal to the received 24 MAC value (act 280). If the generated MAC value is equal to the received MAC
value, then the plaintext data is returned to the caller (act 282). However, if the lee&hayes pk ws32a=92sc 22 Arty. Docker No. MSI-1316US

1 generated MAC value is not equal to the received MAC value, then the process 2 fails (act 284) and the plaintext data is not returned to the caller.

Thus, the cryptography approach to sealed storage substantially guarantees 4 that any corruption of the value c (the output of the Store operation) can be s detected, and that the value b (the input to the Store operation) cannot be retrieved 6 without access to the key K2 (the key used by the cipher to encrypt the value b).

7 Another class of gating functions implement remote authentication. The s purpose of remote authentication is to allow programs to be authenticated even in 9 the absence of a strong physical coupling to the authenticator (e.g., using servers io or smart cards). In this situation, authentication is based on cryptography. That is, 11 I both entities go through a cryptographic authentication protocol. This involves the 12 authenticated configuration having access to a secret, which, depending on the 13 protocol, is typically a private key or a symmetric key. Additionally, the 14 computing device can tie the use of these authentication secrets to the identity of is the configuration (e.g., the processor and/or software) that requests their use.
16 Thus, the authenticator can establish the identity of the computing device, as well 17 as the software executing on it.

18 Two operations, the Quote operation and the PKUnseal operation, are the 19 respective gating functions for public key signing and public key decryption. The 20 guard implementing these gating functions has access to a signing key Ks and a 21 decryption key Kd. Both the signing key Ks and the decryption key Kd are also 22 referred to as the private key of a public/private key pair. This public/private key 23 pair is a key pair of the guard implementing the Quote and PKUnseal operations.

24 The Quote operation returns a public key signature over a combination of 25 (e.g., the concatenation of) the input to the Quote operation and a condition that lee0hayes We 509.32.=92% 23 Atty. Docker No. MSI-1316US

1 identifies when and/or to whom the secret may be revealed. Analogous to the Seal 2 and UnSeal operations discussed above, revealing of the secret can be tied to any 3 of a variety of conditions. In one implementation, the condition is an identifier of 4 (e.g., digest of) the calling program.

Inherent in the signature is the assertion that the operation was performed at 6 the request of the identified calling program. The Quote operation works in 7 conjunction with a Verify operation, which typically executes on a device other 8 than the device on which the Quote operation executes (e.g., on a remote server 9 device, on a smart card, etc.). The Verify operation performs a public key signature verification and retrieves and evaluates the identifier of the calling 1 program (and/or other conditions for revealing the secret).

12 Pseudo code for the Quote operation is illustrated in Table V. In the 13 pseudo code of Table V, IDO refers to the IDO function discussed above, a refers 14 to the data input to the Quote operation, and Ks refers to a signing key.

is Table V
16 d =IDO
17 return sn=Si natureK,(d, a) 18 {
19 Thus, as can be seen in Table V, the Quote operation obtains a digest of the calling program and receives an input value a. The Quote operation generates a 21 digital signature (sn) of the input value a and the digest of the calling program 22 using the signing key Ks. The input value a can be generated by the calling 23 program, or alternatively may be a value that is received from another component 24 or device (e.g., from the device that will be performing the Verify operation). The digital signature is generated using public key cryptography.

leeehayes ~ soa3241256 24 Arty. Docker No. MSI-1316US

I Fig. 7 is a flowchart illustrating an exemplary process 300 for 2 implementing the Quote operation. Process 300 is performed by a guard 104 of 3 Fig. 1, and may be implemented in hardware, software, firmware, or a 4 combination thereof.

Initially, input data is received from a caller (act 302). An identifier of the 6 caller (an/or one or more other conditions for retrieving the input data) is obtained 7 (act 304) and a digital signature over the combination of the input data and the 8 identifier (and/or one or more other conditions) of the caller is generated (act 306).
9 The generated digital signature is then returned to the caller (act 308).

The Verify operation performs a public key signature verification and I I retrieves and evaluates the identifier of the calling program. The Verify operation 12 receives a digital signature that was generated by a Quote operation, typically 13 from a device other than the device on which the Verify operation executes (e.g., 14 on a remote server device, on a smart card, etc.). The Verify operation extracts the Is digest of the program (e.g., an application program, operating system, firmware 16 program, etc.) that called the Quote operation from the received digital signature, 17 and evaluates that digest to determine how to proceed.

18 Pseudo code for the Verify operation is illustrated in Table VI. In the 19 pseudo code of Table VI, d refers to the digest of the program that called the Quote operation, a refers to the value that was input to the Quote operation, and Sn 21 refers to the digital signature received by the Verify operation as an input.

Iee 2shayes we 50432d=9256 25 Any. Docket No. MSI-1316US

Table VI
2 (d,a)=Extractxv(Snn) 3 Evaluate(d) Thus, as can be seen in Table VI, the Verify operation receives a digital signature and, using verification key K=v (which is the public key of the s 6 public/private key pair that includes the signing key Ks) extracts the digest d and the value a from the signature. The Verify program can then evaluate the digest d 8 of the program that called the Quote operation. The manner in which the digest d 9 is evaluated can vary. For example, the evaluation may involve comparing the digest d to a list of "approved" or "trusted" application programs.

11 Fig. 8 is a flowchart illustrating an exemplary process 320 for 12 implementing the Verify operation. Process 320 is performed by a guard 104 of 13 Fig. 1, and may be implemented in hardware, software, firmware, or a combination thereof.

Initially, a digital signature is received (act 322). Both the identifier of the is 16 caller (and/or one or more other conditions for retrieving the input value) that I7 quoted an input value (using the Quote operation) and the input value itself are 18 extracted from the digital signature (act 324). The identifier of the caller (and/or 19 the one or more other extracted conditions) is then evaluated to determine how to proceed with the input value (act 326).

21 The PKUnseal operation is a version of public key decryption, which is gated on the identity of the caller (e.g., the digest of the calling program), or 22 23 alternatively one or more other conditions. The result of the public key decryption 24 of the input c to the PKUnseal operation is interpreted as a pair (d, s), where s is a secret and d identifies a configuration (e.g., digest of a calling program) to which s Iee0hayes pc 509.334.9256 26 Any. Docket No. MS1-1316US

I may be revealed. If the caller of PKUnseal is not d then the PKUnseal operation 2 fails. The input c to the PKUnseal operation is generated by a second operation 3 PKSeal, which can be executed on a device other than the device on which the 4 PKUnseal operation executes (e.g., on a remote server device, on a smart card, etc.). The PKSeal operation performs a public key encryption of a pair (d, s).
The 6 PKUnseal and PKSeal operations can also be used to implement sealed storage.

7 Pseudo code for the PKUnseal operation is illustrated in Table VII. In the s pseudo code of Table VII, ID() refers to the ID() function discussed above, c refers 9 to the input to the PKUnseai operation, [d], ..., d,,] refers to the digest(s) of the one or more calling programs to which s can be revealed (or alternatively one or 11 more other conditions), s refers to the protected data, and Kd refers to a decryption 12 key (a private key of a public/private key pair associated with the guard that is 13 implementing the PKUnseal operation).

14 Table VII
([d], ..., d j, s) = DecryptKd(c) 16 if IDO is in [d], ..., d,J then return s else fail 17 Thus, as can be seen in Table VII, the PKUnseal operation decrypts the 18 input value a using public key decryption and the decryption key Kd. The 19 decrypted input value includes the digest(s) [d], ..., dõ=J of one or more calling programs to which the protected data s is allowed to be revealed (or alternatively 21 one or more other conditions identifying when and/or to whom the protected data s 22 is allowed to be revealed). The PKUnseal operation also generates a digest of the 23 calling program. If the digest of the calling program is equal to one of the digests 24 [d], ..., d], then the protected data s is returned to the calling program.
However, leef3hayes p k 5 -324.9256 27 Airy. Docket No. MSI-1316US

1 if the digest of the calling program is not equal to one of the digests [d], ..., dõ 1J, 2 then the protected data s is not returned to the calling program.

3 Fig. 9 is a flowchart illustrating an exemplary process 340 for 4 implementing the PKUnseal operation. Process 340 is performed by a guard 104 of Fig. 1, and may be implemented in hardware., software, firmware, or a 6 combination thereof.

7 Initially, ciphertext with encrypted data that the caller desires to retrieve is s received (act 342). A check is made as to whether the caller is allowed to retrieve 9 the data (act 344), and processing proceeds based on whether the caller is allowed to retrieve the data (act 346). If the caller is allowed to retrieve the data, then the 11 data (decrypted using public key decryption) is returned to the caller (act 348). If 12 the caller is not allowed to retrieve the data, then the process fails (act 350) and the 13 data is not returned to the caller.

14 The PKSeal operation is a version of public key encryption, which is gated on the identity of the caller (e.g., the digest of the calling program or one or more 16 other programs). The PKSeal operation performs a public key encryption of a pair 17 (d, s), where s is a secret and d identifies one or more configurations (e.g., digests 18 of a calling program) to which s may be revealed.

19 Pseudo code for the PKSeal operation is illustrated in Table VIII. In the pseudo code of Table VIII, c refers to the output of the PKSeal operation, [d], ..., 21 dõ ,J refers to the digest(s) of the one or more calling programs to which s can be 22 revealed, s refers to the protected data, and Ke refers to an encryption key.

leeOhayes ck 5c9.324.9 s6 28 Atty. Docket No. MSI-1316US

1 Table VIII
2 c=EnCryptKe(1 deb, ..., dm1 , s) 3 return c Thus, as can be seen in Table VIII, the PKSeal operation receives as an input the protected data s and digests [d], ..., d,J of one or more programs to 6 which the protected data s can be revealed. The pair [d], ..., d, J, s is then encrypted using public key cryptography based on the encryption key Ke. The encryption key Ke is the public key of the guard that is intended to be able to s 9 decrypt the ciphertext. The ciphertext resulting from the public key encryption is then returned to the calling program.
to it Fig. 10 is a flowchart illustrating an exemplary process 360 for 12 implementing the PKSea1 operation. Process 360 is performed by a guard 104 of 13 Fig. 1, and may be implemented in hardware, software, firmware, or a combination thereof.

Initially, a secret to be sealed is received from the caller (act 362). The is 16 secret is encrypted using public key encryption so that the secret can only be 17 retrieved by a particular target program(s) (act 364), or alternatively only if one or 18 more other conditions are satisfied. Ciphertext including the encrypted secret is 19 then returned to the caller (act 366). Additional information may also be returned to the caller (as part of the ciphertext or separate from the ciphertext), such as a 21 digest of the caller and/or digest(s) of the target program(s).

The Quote and PKUnseal operations are intended to be used in connection 22 23 with public key authentication protocols. Most public key authentication protocols can be straightforwardly adapted by replacing any call to public key lee Ohayes o so9=3N=9256 29 Atty. Docket Na. MSI-1316US

i decryption, public key encryption, signing, and signature verification by a call to 2 PKUnseal, PKSeaI, Quote, Verify, respectively.

3 In some situations, it is important to be able to obtain a random number 4 (e.g., as a basis for generating cryptographic keys). Random numbers can be obtained in a variety of different manners. In one implementation, the source of 6 random numbers is a cryptographically strong random number generator 7 implemented in the hardware of the computing device.

8 One alternative to the Seal operation discussed above is a GenSeal 9 operation that combines the Seal operation with a generate random number l0 operation. The GenSeal operation receives as input the digests [t], ..., tõj of target 11 program(s) that should be able to retrieve the secret (and/or other conditions that 12 must be satisfied in order for the secret to be retrieved). The GenSeal operation 13 generates a random number and seals the newly generated random number so that 14 it can be retrieved only by calling programs having one of the target digest(s) [t], ..., tõj (and/or the other conditions satisfied).

16 Pseudo code for the GenSeal operation is illustrated in Table IX. In the 17 pseudo code of Table IX, ID() refers to the ID() function discussed above, c refers 18 to the output of the GenSeal operation, s refers to the newly generated random 19 number, [t], ..., t,nJ refer to one or more target program(s) that should be permitted to retrieve the value s (one of which may optionally be the program calling the 21 GenSeal operation) or alternatively one or more other conditions, and 22 GenRandom() refers to a function that generates a random number.

lee@hayes,. so4324=e2sc 30 Airy. Docker;Vo.MS/-1316US

1 Table IX
2 d =ID() s =GenRandom() 3 c = store (s, [t], ..., tõ fI , d) 4 return c 6 Fig. 11 is a flowchart illustrating an exemplary process 380 for 7 implementing the GenSeal operation. Process 380 is performed by a guard 104 of 8 Fig. 1, and may be implemented in hardware, software, firmware, or a 9 combination thereof.

Initially, an input is received from a caller that identifies a target program(s) 11 that should be able to retrieve a secret (act 3 82), or alternatively one or more other 12 conditions that are to be satisfied in order for the secret to be retrieved. A secret is 13 then generated (act 384), and the secret is encrypted so that the secret can only be 14 retrieved by the identified target program(s) (act 386), or alternatively so that the secret can be retrieved only if the one or more other conditions are satisfied.
16 Ciphertext including the encrypted secret is then returned to the caller (act 388).
17 Additional information may also be returned to the caller (as part of the ciphertext 18 or separate from the ciphertext), such as a digest of the caller and/or digest(s) of 19 the target program(s).

The services provided by a disclosure guard can be used for general-21 purpose sealing services. For example, referring back to Figs. 1 and 2, layer n-1 22 reveals a single key to layer n based on the identity of layer n on initialization 23 (e.g., after reset or booting of the computing device, or upon beginning execution 24 of a program). Layer n caches this key and uses it to encrypt additional secrets.
The next time the platform is booted into the same configuration, the disclosure iee0hayes n~ 509 324.9258 31 Arty. Dacket No. WSJ-1376US

1 guard provides the same root-key (e.g., through UnSeal or PKUnseal), and all the 2 secrets previously encrypted can be retrieved by layer n.

3 In certain embodiments, a lower layer discloses one or more secrets to the 4 next layer when that next layer is initialized (e.g., after reset or booting of the computing device, or upon beginning execution of a program). Following this 6 gated disclosure, the lower layer is no longer used (until the next boot or reset).
7 This use-model is also referred to as the disclosure guard model. By employing 8 the disclosure guard model, accesses to the lower layer are reduced.

9 The gating functions discussed herein can be used with service guards and 1o disclosure guards implemented using time isolation and space isolation.
Four 11 service model implementations for authenticated operation are discussed below:
12 (1) service guard - space isolation; (2) disclosure guard -- space isolation; (3) 13 disclosure guard - time isolation; (4) service guard - time isolation. In the 14 discussion of these service models, assume that a lower-level guard has disclosed one or more keys to the guard at the layer being considered. The manner in which 16 these keys are obtained depends on the guard and isolation model of the layer 17 beneath. Different layers on the same computing device can use different ones of 18 these service models.

19 (1) Service guard - space isolation: The guard measures and saves the identity of the requesting program when it is initialized. The guard implements a 21 protection system using processor services (e.g., of a CPU or some other security 22 processor or co-processor), and a system-call interface exposing the authenticated 23 operation primitive operations.

24 (2) Disclosure guard - space isolation: The guard obtains service requests on initialization in the form of cryptographic blobs. The blobs could be stored in lee0hayes et 504324-9256 32 Arty. Docker No. MSIJ316US

I memory, or alternatively obtained from external storage devices. The guard 2 measures the identity of programs that it initializes, and discloses keys to 3 programs according to the gating functions described above. Before relinquishing 4 control to the next layer, the guard establishes mode--protection for itself and its secret resources.

6 (3) Disclosure guard - time isolation: The guard obtains service requests 7 on initialization in the form of cryptographic blobs (groups of bits). The blobs s could be stored in memory, or alternatively obtained from external storage 9 devices. The guard measures the identity of programs that it initializes, and Io discloses keys to programs according to the gating functions described above.
i I Before passing control to these programs, the guard deletes (or otherwise makes 12 inaccessible) the keys used to implement the gating functions.

13 (4) Service guard - time isolation: In the service guard - time isolation 14 model, the computing device securely preserves program state across the security Is reset. This model is similar to model (1) (service guard - space isolation), 16 however, before passing control to the next layer, the service guard deletes its I7 secret (rendering it non-functional until the next reboot). The next layer will now Is execute normally, until it needs to request a service from the guard. At that point, 19 it stores the parameters of the request somewhere in memory where they will 20 survive a reset and performs a reset. As the device reboots, the service guard 21 obtains its secret, sees the request, executes it (using its key), destroys the key and 22 any related information, and passes the result of the computation and control to the 23 next layer (the layer that had originally requested the service).

24 In certain embodiments, if a computing device supports space isolation, 25 then the security kernel should expose the primitives (operations) Seal, Unseal, leet?hayes Gk 5o9-324-92% 33 Any. Docker ,.o. MSI-1316US

1 GetRandom (to obtain a random number), and PKUnseal (or Quote). The security 2 kernel can implement a disclosure guard or a service guard. On the other hand, if 3 the platform supports time isolation, then the security kernel should provide a 4 disclosure guard, and should implement the primitives (operations) Unseal, GenSeal, and PKUnseal (or Quote).

6 It should also be noted that Quote and PKUnseal functionality can be built -, on the Seal and Unseal or Unseal and GenSeal primitives. For example, 8 manufacturers can build an 12 program(s) that implements Quote or PKUnseal and 9 acts as a host for higher-level software (e.g., operating systems) upon GenSeal and to Unseal implemented in 11. The manufacturer can generate and Seal the keys needed by the service layer and ship them with the device or CPU (or make them 12 available online).

13 An exemplary description of a family of hardware implementations that 14 will enable platforms to support authenticated operation follows. As with higher layers in the system, the characteristics of the lowest layer (11 of Fig. 2) are: (a) 16 secret key resources, (b) privileged code that has access to these keys, and (c) 17 controlled initialization of the layer.

18 Authenticated operation provides a strong binding between programs and 19 secret keys. At higher layers, guards in lower layers guarantee this binding. At the lowest layer, there is no underlying software guard that can gate access to the 21 platform secrets. Thus, another mechanism is used to support the association of 22 the 11 keys to the 11 program. One way of accomplishing this binding is having 11 23 software be platform microcode or firmware that is not changeable following 24 manufacture, and give the 11 software unrestricted access to the 11 keys.
This platform microcode or firmware can then be referred to as the security kernel, and leeOhayes p 509.324.9266 34 Atry. Docket No. MSI-1316US

1 the l1 keys referred to as the platform keys. The platform is designed to only pass 2 control to a predetermined security kernel. The hardware behavior can also be 3 explained as a simple resource guard that discloses the platform keys to the 4 predefined security kernel.

The platform keys and the security kernel firmware can be part of the 6 processor or alternatively implemented in one or more other components in the 7 computing device (e.g., a security processor or coprocessor, which may also s perform cryptographic operations). The platform keys and the security kernel 9 firmware can be implemented in a single component, or alternatively implemented to in multiple components of the computing device.

11 With authenticated operation, programs are started in a controlled initial 12 state. At higher levels, the software running at lower levels can be entrusted to 13 start execution at the correct entry point. At 11, however, hardware performs this 14 function. Typically, on power-up or following reset, current processors begin execution by following some deterministic sequence. For example, in the simplest 16 case the processor starts fetching and executing code from an architecturally-17 defined memory location. For 11, programs can be started in a controlled initial 18 state by the hardware ensuring that the security kernel is the code that executes on i9 startup (as part of the deterministic sequence).

Additionally, no other platform state should be able to subvert execution of 21 the security kernel. Reset and power-up provide a robust and a well-debugged 22 state-clear for the processor. As used in this example, the platform state change 23 that is used to start or invoke the security kernel is referred to as a security reset.

24 Furthermore, a device manufacturer should arrange for the generation or installation of the platform keys used by the 11 implementation of Seal and Unseal.

leeOhayes o --- 32+=9266 35 Atty. Docker No. MSI-1316US

1 If the device is to be recognized as part of a PKI (Public Key Infrastructure), the 2 manufacturer should also certify a public key for the platform. This can be a 3 platform key used directly by 11, or alternatively a key used by a higher layer.

4 Key generation and certification can be the responsibility of the CPU
manufacturer or alternatively some other party, such as the OEM that assembles 6 the CPU into a device. Alternatively, the responsibility can be shared by multiple 7 such parties.

8 Once the security kernel is executing it can use the isolation mechanisms 9 described above to protect itself from code executing at higher layers.
Isolation in space will typically involve privilege mode support, and isolation in time will i l typically involve secrets being hidden from upper layers.

12 No additional platform support is needed to support space isolation on most 13 current processors - an existing privilege mode or level will suffice (as long as the 14 hardware resource that allows access to the platform key can be protected from higher layers).

16 To support time isolation, hardware assistance is used to allow the security 17 kernel to conceal the platform key before passing control to higher layers.
One 18 way to provide platform key security in the time isolation model is to employ a 19 stateful guard circuit that is referred to as a reset latch. A reset latch is a hardware circuit that has the property that it is open following reset or power-up, but any 21 software at any time can programmatically close the latch. Once closed, the latch 22 remains closed until the next reset or power-up. A platform that implements a 23 time-isolated security kernel should gate platform key access on the state of a reset 24 latch, and the security kernel should close the latch before passing control to higher layers. As mentioned above, the security kernel should also take additional leeL%hayes p c 5O9-32a92S6 36 Atry. Docket N'o. MSI-1316US

1 actions such as clearing memory and registers before passing control, but these 2 action are the same as those used at higher levels.

3 If the platform employs space isolation then the security kernel uses 4 privilege modes to protect itself and its platform keys from programs (e.g., s operating systems) that it hosts. Furthermore, the security kernel establishes a 6 system call interface for invocation of the authentication operations.

7 If the platform employs space isolation, then the platform should also 8 contain storage that survives a security reset to pass parameters to service routines.
9 To invoke a service, an operating system prepares a command and parameter to block in a memory location known to the security kernel and performs a security 1 i reset. If the OS wishes to continue execution following the service call (as 12 opposed to a simple restart) then it and the security kernel should take extra 13 measures to ensure that this can be done reliably and safely.

14 The authenticated operation discussed herein can be used for security in a 15 variety of settings, such as protecting personal data from viruses, protecting 16 confidential server data from network attacks, network administration, copy 17 protection, trustworthy distributed computing, and so forth. The authenticated 18 operation allows different programs, which can execute on the same computer 19 without being in a particular trust relationship, to preserve their cryptographic 20 resources irrespective of the actions of other software.

21 Some of the discussions below make reference to an SSP (Secure Service 22 i Processor). In one embodiment, an SSP is a processor (for use in a computing 23 device) that provides basic cryptographic services to a computing device (e.g., the 24 SSP supports the gating functions described herein (e.g., as layer 11 of Fig. 2)).
25 The SSP can make use of cryptographic keys, and typically has one or more leeGhayes Pk so¾32unss 37 Arty. Docker No. MS1.1316US

1 cryptographic keys that are unique (or expected to be unique) to that SSP.
The 2 SSP can be part of the CPU(s) of the device, or alternatively one or more other 3 processors. For example, the SSP may be a separate chip or integrated circuit (IC) 4 in a computing device.

In a different embodiment, an SSP is an appropriately isolated software 6 program that exposes the same functionality to its callers as the previous 7 embodiment does. The SSP embodiment has access (directly or indirectly) to 8 cryptographic keys. A number of implementation options exist for providing such 9 access. For example, the SSP may call service or disclosure guards in lower layers. Or the SSP may have exclusive access to some part of persistent memory 11 (e.g. hard disk, flash memory, ROM, etc.) that contains the required cryptographic 12 key(s).

13 In summary, an SSP is defined by the functionality it exposes to principals 14 in a higher layer. An SSP is a guard (as described above) with access (direct or indirect) to cryptographic keys. The SSP uses these keys to provide cryptographic 16 services to its callers. The following sections will describe exemplary 17 functionality an SSP exposes.

18, 19 Example Operations The following is a discussion of example implementations of sealed storage 21 operations and of remote authentication operations. This section illustrates 22 example implementations of the Seal, UnSeal, Quote, and PKUnseal operations 23 discussed above.

leef2+hayes Pk 5O9-32492s6 38 Arty. Docker No. MSI-1316US

The following definitions are used in this section:
2 Name Type Description DIGEST BYTE[20] 160-bit value. Commonly the output of a SHA-1 hash operation.
4 SECRET BYTE[32] 256 bit value. Commonly a secret to be sealed or pksealed.
ordinal INTEGER The ordinal component of each input and output structure identifies the operation to 6 which it belongs and whether it is an input 7 or an output structure.
KM 256-bit key Key for HMAC operations.
8 Ks 256-bit key AES key for Seal and UnSeal.
Ku 2048 bits * 3 RSA key pair for PKUnse4al 9 2048 bits * 3 RSA key pair for Quote.
R 128 bits Random number 12 Additionally, access policies are referred to in this section and the Bound 13 Key Operations section below. The access policy describes when the particular 14 operations are functional (that is, when they will work). The user of a computing device is able to selectively switch off certain functions. For example, the 16 computing device (e.g., a SSP that implements the Seal operation) includes a 17 register called FeatureEnable. One of the bits in the register is called MainEnable.
18 If the user sets MainEnable to false then none of the functions in these sections 19 will work any more. The access policy description included with each function describes under which FeatureEnable settings the function will work.

Seal Definition SSP STATUS Seal( [in] SECRET S, 24 [in] DIGEST Target [23, [in] UINT32 MaxLen, [out] UINT32* ActualLen, lee 2.hayes pqk sos aza=ezss 39 Atry. Docket No. MS1-1316US

[out] BYTE* SealedBlob 1 ~
2 Parameters Seal-Input SEQUENCE
3 ordinal INTEGER, secret Secret, target DigestPair }

Seal-Output SEQUENCE 1 ordinal INTEGER, status INTEGER, 6 sealed-blob OCTET STRING }

Return Values SSP_SUCCESS

8 Comments 9 The Seal operation forms an encrypted blob (group of bits) that can to only be decrypted by the corresponding Unseal operation if the following 11 evaluate true:

12 Is the encoding correct?
13 = Is the MAC correct?

14 Is the currently running SK/SL (Security Kernel or Secure Loader) the one named as the Target during the Seal operation?

16 Seal adds internal randomness so that the output of the Seal 17 operation on the same input produces different results. This ensures that 18 Seal cannot be used as a hardware device identifier. Seal also includes an 19 identifier of the program calling the Seal operation (e.g., a digest of the calling program saved in a PCR register of the SSP, also referred to herein 21 as the PCR value) when the seal was performed to provide integrity 22 information to the unsealer.

Iee0hayes pc 50r32.a25e 40 Atty. Docket No. MS/-1316US

1 Access Policy 2 Allowed = FeatureEnable.MainEnable &
3 (FeatureEnable.UseSymmKey==A11 4 FeatureEnable.UseSymmKey==AuthSL

& SLKnown & AuthPCR[CurrentSL].UseSymrKey ) 6 Actions 7 The Seal operation implements the following actions:
8 1. Generate a 128-bit random number R

9 2. Let DO be the current value of the PCR[O], D 1 = PCR[ 1 ]
3. DIGEST M = HMAC[KM](R II S target II DO D1) 11 4. C = AES[Ks](R II S 11 Target II DO D1 II M) 12 5. Return SSP_SUCCESS with SealedBlob set to C

14 Unseal Definition SSP_STATUS Unseal( 16 [in] BYTE* SealedBlob, [in] UINT32 SealedBlobLen, 17 [out] SECRET S, [out] DIGEST Source Parameters 19 Unseal-Input SEQUENCE {
ordinal INTEGER, sealed-blob OCTET STRING }
21 Unseal-Output SEQUENCE {
ordinal INTEGER, status INTEGER, secret Secret, source Digest }

24 Return Values SSP SUCCESS
SSP_UNSEAL_ERROR

lee$2 hayes ac _"_ 3 .9 Ss 41 Arry. Docket No. MSJ=1316US

1 Comments 2 The Unseal operation internally decrypts a blob generated by the 3 Seal operation and checks the following conditions:

4 Is the encoding correct?

. Is the current value of the PCR the one named as the Target during 6 the Seal operation?

7 If all checks succeed, then the secret and the sealer's PCR is 8 returned; otherwise an UNSEAL-ERROR is returned.

9 Access Policy Allowed = FeatureEnable.MainEnable &
11 (FeatureEnable.UseSymmKey=AllI
12 FeatureEnable.UseSymmKey==AuthSL

13 & SLKnown & AuthPCR[CurrentSL].UseSymmKey ) 14 Actions The Unseal operation implements the following actions:
16 1. M = AES-1 [Ks](SealedBlob).

17 2. Interpret M as (BITS[128] R II SECRET Si II DIGEST
18 TargetO II DIGEST Targetl II DIGEST SealerO 11 DIGEST Sealerl II
19 DIGEST N).

3. DIGEST D = PIMAC[KM](R Ii Si II TargetO II Targetl 21 SealerO II Sealerl).

22 4. If(TargetO 1= PC-R[O] II Targetl != PCR[1]) return 23 SSP UNSEAL ERROR with S, Source set to :zero.

IeePy hayes w= w4324.92% 42 Airy. Docket No. MS1.1316U5 1 5. If D!=N return SSP_UNSEAL_ERROR with S, Source set to 2 zero.

3 6. Else return SSP_SUCCESS with S set to Si and Source set to 4 {SealerO, Sealerl}.

6 Quote 7 Definition SSP_STATUS Quote( 8 [in] BITSTRING d-ext, [out] PKSignature SigBlob Parameters Quote-Input {
ordinal INTEGER, 11 d-ext Digest }
12 Quote-output {
ordinal INTEGER, 13 status INTEGER, sig-blob PKSignature }

14 Return Values SSP SUCCESS
SSP CRYPTO ERROR

16 Comments 17 The Quote operation instructs the SSP to sign the concatenation of 18 the externally supplied D-EXT and the internal PCR value.

19 Access Policy Allowed = FeatureEnable.MainEnable &
21 (FeatureEnable.UsePrivKey==All 22 FeatureEnable.UsePrivKey==AuthSL

23 & SLKnown & AuthPCR[CurrentSL].UsePrivKey ) 24 Actions The Quote operation implements the following actions:

lee2hayes Pk 50s324-9256 43 Atty. Docket No. MSI-1316US

1 1. The SSP forms a message M consisting of the concatenation 2 of the identifier for message type QuoteMessage, D-EXT and the contents 3 of the PCR register, under DER (Distinguished Encoding Rules) encoding:
4 SEQUENCE {
message-type PKMessageType, d-ext Digest, 6 pcr DigestPair }

8 2. The SSP then uses KQ, PRIV to generate a signed message 9 over M according to the default implementation of RSASSA-PSS-SIGN as specified in PKCS #1 V2.1. If the function returns an error then return 11 SSP_CRYPTO_ERROR with SigBlob set to 0.

12 3. The SSP returns SSP SUCCESS and the signature value just 13 calculated together with signatureAlgorithm = rSASSA-PSS-Default-14 Identifier in SigBlob.

16 PKUnseal 1? Definition SSP_STATUS PK_Unseal( 18 [in] PKCiphertext SealedBlob, [out] SECRET Secret Parameters PkUnseal-Input ordinal INTEGER, 21 pk-sealed-blob PKCiphertext }
22 Pkunseal-output 1 ordinal INTEGER, 23 status INTEGER, secret Secret }
24 Return Values SSP_ SUCCESS
S SP CRYPTO ERROR

leef2 hayes Gk Soa324=92So 44 Arty. Docker No. MSI-1316US

SSP_BAD_DATA_ERROR

Comments The PKUnseal operation takes an encrypted blob of length 416 bits, and of a particular format. The blob is decrypted, and if the decryption and decoding is successful, the 416-bit message is interpreted as the concatenation of a secret value and the PCR value that is permitted to receive the decrypted value.

If the current PCR value is equal to that specified in the encrypted blob, the secret is revealed; otherwise an error is returned.

Access Policy Allowed = FeatureEnable.MainEnable &.

(FeatureEnable.UsePrivKey==All FeatureEnable.UsePrivKey==AuthSL

& SLKnown & AuthPCR[CurrentSL].UsePrivKey ) Actions The PKUnseal operation implements the following actions:

1. The SSP tests if the AlgorithmIdentifier in pk-sealed-blob is sspV 1 BoundKey.
18 i 9 ,~ 1 2. The SSP internally decrypts SeaiedBlob according to the default implementation of RSAES-OAEP-DECRYPT as specified in PKCS
#I V2.1, obtaining a plaintext message M.

3. If the output of the decoding operation i.s "decoding error"
return SSP BAD DATA ERROR with Secret set to zero.

4. Otherwise, the recovered message M should be of the following form under DER encoding:

lee@hayes ck 50}324.9256 45 Atty. Docker No. MS1-1316US

SEQUENCE {
message-type PKMessageType, secret Secret, 2 target Digest }

4 Furthermore, Secret should consist of 256 bits (= 32 octets) and target should consist of 160 bits (= 20 octets). The message type should be 6 sspVlPKSealedMessage. If any of these conditions is not met, return 7 SSP_BAD_DATA_ERROR with Secret set to zero, otherwise:

8 1. If target != PCR return SSP_BAD_DATA_ERROR with 9 Secret set to zero.

2. If target == PCR return SSP_SUCCESS with Secret set to 11 secret.

13 Bound Key Operations 14 Additionally, a set of bound key functions or operations allow is cryptographic keys to be created and certified locally (e.g., by the SSP), and also 16 allow cryptographic keys to be communicated from trustworthy remote parties 17 (e.g., communicated to the SSP).

18 Bound key functionality is characterized as follows:

19 1. A service guard (e.g. SSP) at some system layer accesses a bound key directly. Each bound key has an associated condition(s) that 21 determines which guard(s) may access the bound key. The condition(s) is expressed implicitly. That is, the bound key is 11 23 encrypted, such that only one or some set of guards have the keys 24 to decrypt it.

iee&hayes oua 504324.925fi 46 Atry. Docket No. MSI-1316US

1 2. A service guard with access to a bound. key exposes functions that 2 require the use of the bound key (e.g. signing, MAC, encryption, 3 decryption) to principals in a higher layer. Each bound key may 4 have an associated usage condition(s), in which case the guard will only service requests that satisfy the associated condition(s).

6 3. Bound keys are contained in cryptographically protected data 7 structures (also referred to herein bound key blobs). Bound key 8 blobs are self protecting and can be stored outside trusted 9 environments.

Bound keys have the following benefits:

11 Each principal can be allowed to have its own bound key.
12 Furthermore, each principal can be allowed to have arbitrarily 13 many bound keys. This allows for more fine grained policy 14 settings and improves privacy in certain applications. Thus, guards need not be restricted to having only one or a few keys that are used 16 to service requests from all principals.

17 = The bound key is not disclosed outside the authorized service 18 guard(s). Thus, a compromise of a principal (e.g. due to a 19 programming error) will not lead to a compromise of any bound key. In one embodiment, the service guard (SSP) is implemented 21 in hardware. In this case, bound keys cannot be compromised due 22 to malicious or incorrect software.

Iee0hayes Pk S 32x9256 47 Arty. Docket No. MSI-7316US

1 The bound key functions provide protection for cryptographic keys. Bound 2 keys can be generated by remote parties or they can be created locally through the 3 GenBoundKey command.

4 Bound keys that are generated locally may emit a "quote" certificate that can be used to provide remote parties with evidence of the type of the public key, 6 the type of key generated, the state of the machine during generation, and the 7 (optional) condition (e.g. digests) to which the key is bound.

8 Bound keys include one or more of the following elements:

9 The key usage (e.g., BoundSign, BoundQuote, BoundPkUnseal, BoundPkDecrypt, BoundMAC, BoundEncrypt, or BoundDecrypt). This element is optional. If included, this element restricts the bound key to 12 being used only with the identified function type.

13 A condition element (as described above) that specifies under which 14 conditions the bound key can be used (also referred to as bound key usage condition(s)). For example, the condition(s) may be represented 16 in the form of one or more digests of programs. In this case, the bound 17 key must only be used by or on behalf of programs whose digest is 18 specified. Other examples of conditions include time constraints, 19 logical formulas, and executable programs, as described above. This element is optional. If the element is omitted, some default condition 21 applies. For example, the default condition may not restrict access to 22 the bound key (vacuous condition).

23 The cryptographic key (the bound key) or some data that allows the key 24 to be computed.

lee0hayes ck scs az<.sass 48 Atty. Docket No. INS1-1316US

1 One or more conditions (as described above) under which the bound key 2 usage condition can be changed. Such changing is also referred to as 3 bound key migration, and the condition(s) a migration condition(s).
4 This element is optional. If the element is omitted, some default condition applies. For example, the default conditions may be "always 6 false", such that the digests (if present) cannot be changed.

7 One or more conditions, under which the set of service guards that can 3 directly access the bound key can be changed. Such changing is also 9 referred to as bound key exportation, and the condition(s) an export condition(s). This element is optional.

it 12 Cryptographic Protection of Bound Keys 13 Bound keys have the same cryptographic requirements as the sealed storage 14 and attestation functions described above (Seal, UnSeal, PKUnseal). In particular, locally generated bound keys could be protected by any of the cryptographic 16 implementations of the Store and Retrieve functions described above. In each 17 case, the confidentiality of the bound key itself is protected and the integrity of the 18 overall data structure is protected in order to ensure that the different conditions 19 that govern the usage of the bound key have not been corrupted. As described earlier, this can be achieved by various combinations of symmetric ciphers or 21 public key encryption algorithms with MACS or digital signatures. In one 22 embodiment, the bound key data structure is public key encrypted.

lee0hayes Pk sos 32 25 49 Am. Docker No. MS1-1316US

2 In certain embodiments, bound keys can be used in one or more of the 3 following functions:

4 BoundSign . BoundQuote 6 a BoundPkDecrypt 7 BoundPkUnseal 8 o BoundMAC

9 BoundEncrypt BoundDecrypt i GenBoundKey 12 BoundKeyMigrate 13 BoundKeyExport 14 In each of these functions, the bound key blob (the group of bits in the data structure) and the data to be operated on by the key contained within the bound 16 key blob are provided as parameters to the bound-key functions. If the key usage 17 element is included in the bound key blob, then the SSP ensures that the bound 18 key is used for the correct purpose (for example, a key that was created with type ig "BoundQuoteKey" can only be used in a BoundQuote operation).

In some implementations, the bound key is a private key of a public/private 21 key pair. In such implementations, the bound key 'blob can contain the private 22 key, or alternatively some data that allows the key to be computed. For example, a 23 private key fragment may be contained in the bound key blob, and this fragment, 24 in conjunction with the corresponding public key, can be used to reconstruct the private key of the public/private key pair.

lee0hayes Pk --- a2a=92% 50 Atty. Docket No. MS1-7316US

I The BoundSign operation receives a data input that is to be signed using the 2 bound key, and also receives a bound key blob. The SSP recovers the private 3 signing key from the bound key blob and then generates a digitally signed 4 message over the data input using the recovered signing key. The SSP then outputs the digitally signed message. If the bound key blob is corrupted or the 6 bound key usage condition(s), if any, are not satisfied, then the SSP does not 2 perform the operation. The data input can thus be digitally signed using the s recovered private key without the private key being revealed by the SSP.

9 The BoundQuote operation receives as an input data to be signed and a bound key blob. The SSP recovers the private key from the bound key blob and I then uses the recovered signing key to generate a signature over the data input to 12 the operation and the current PCR value (e.g., an identifier, such as a digest, of the 13 program invoking the BoundQuote operation) as in the Quote operation described 14 above. The SSP then outputs the digitally signed message. If the bound key blob is corrupted or the bound key usage condition(s), if any, are not satisfied, then the 16 SSP does not perform the operation. In one implementation, the BoundQuote 17 operation is similar to the BoundSign operation, but differs in that the current PCR
18 value is used in the BoundQuote operation.

19 The BoundPkDecrypt operation receives as an input ciphertext and a bound key blob. The SSP recovers the private key from the bound key blob and then 21 uses the recovered private bound key to decrypt the input ciphertext. The 22 decrypted data is then output by the BoundPkDecrypt operation. If the bound key 23 blob is corrupted or the bound key usage condition(s), if any, are not satisfied, 24 then the SSP does not perform the operation.

{eeL4hayes Pk 50s 324.9256 5 1 Atry. Docket No. MSI-1316US

1 The BoundPkUnseal operation receives as an input ciphertext and a bound 2 key blob. The SSP recovers the private key from the bound key blob and then 3 uses the private key to decrypt the input ciphertext as in the PKUnseal operation 4 described above. The decrypted data is then output by the BoundPkUnseal operation. If the bound key blob is corrupted or the bound key usage condition(s), 6 if any, are not satisfied, then the SSP does not perform the operation.

7 The BoundMAC operation receives a data input, over which the MAC is to s be computed using the bound key, and also receives a bound key blob. If the 9 bound key blob is corrupted or the bound key usage condition(s), if any, are not satisfied, then the SSP does not perform the operation. Otherwise, the SSP
11 recovers the bound key from the bound key blob and then generates a message 12 authentication code (MAC) over the data input using the recovered bound key.
13 The SSP then outputs the computed MAC. Thus, a MAC for the data input can be 14 computed using the recovered bound key without the bound key being revealed by is the SSP.

16 The BoundEncrypt operation receives a data input, which is to be encrypted 17 using the bound key, and also receives a bound key blob. If the bound key blob is 18 corrupted or the bound key usage condition(s), if any, are not satisfied, then the 19 SSP does not perform the operation. Otherwise, the SSP recovers the bound key from the bound key blob and then encrypts the data input using the recovered 21 bound key. The SSP then outputs the computed ciphertext. Thus, the data input 22 can be encrypted using the recovered bound key without the bound key being 23 revealed by the SSP.

24 The BoundDecrypt operation receives a data input, which is to be decrypted using the bound key, and also receives a bound key blob. If the bound key blob is tee2hayes Pk ws.324azss 52 Atty. Docker No. MS1.1316US

1 corrupted or the bound key usage condition(s), if any,, are not satisfied, then the 2 SSP does not perform the operation. Otherwise, the SSP recovers the bound key 3 from the bound key blob and then decrypts the data input using the recovered 4 bound key. The SSP then outputs the computed plaintext. Thus, the data input s can be decrypted using the recovered bound key without the bound key being 6 revealed by the SSP.

7 The GenBoundKey operation causes the SSP to create a new bound key.
8 The new bound key is a cryptographic key, and a new bound key blob is generated 9 that includes the newly generated key. It is to be appreciated that the bound key to blob does not always have to include the entire key. For example, if the newly generated key is a public/private key pair, it may be sufficient to include the 12 private key in the bound key blob.

13 The new bound key blob is bound to one or more guards - typically the 14 SSP that is executing the operation (e.g., by cryptographically protecting the new 15 bound key blob analogous to the Store function described above, or otherwise 16 securing the new bound key blob so that it can be retrieved only by the SSP). The 17 GenBoundKey operation may also have parameters that determine various aspects 18 of the new bound key blob and data describing these parameters are attached to the 19 newly generated private key in some integrity protected way (e.g., the data is made 20 part of the new bound key blob). Examples of this data, as discussed above, 21 include the migration condition, the bound key usage condition, and so forth. The 22 new bound key blob is then output by the GenBoundKe_y operation.

23 In general, a bound key may be any kind of cryptographic key, including a 24 symmetric key or a public-private key pair. The exact key type depends on the 25 bound key operation(s) in which it is to be used. For example, a bound key to be leeehayes pc Sa 3N-92s6 53 Any. Docker.No. MS1-1316US

1 used in BoundMAC would typically be a symmetric key, whereas a bound key to 2 be used in BoundSign would typically be a public/private signature key pair.
The 3 key type may be specified as a parameter to GenBoundKey.

4 The BoundKeyMigrate operation allows the usage condition of a bound key to be changed. The SSP verifies that one or more migration conditions are 6 satisfied. Any of a variety of conditions may be used with the BoundKeyMigrate 7 operation (e.g., any condition, analogous to those discussed above with reference s to the Seal and UnSeal operations, that identifies when and/or to whom the data 9 can be migrated). If the verification is not successfully made, then the operation fails. If the verifications is successfully made, then the guard produces a new 11 bound key blob, in which the bound key usage condition has been changed as 12 requested.

13 The BoundKeyExport operation instructs the SSP to change the set of 14 guards (SSPs) that can directly access the bound key. The SSP verifies that one or more conditions are satisfied. Any of a variety of conditions may be used with the 16 BoundKeyExport operation (e.g., any condition, analogous to those discussed 17 above with reference to the Seal and UnSeal operations, that identifies when 18 and/or to whom the data can be exported). If the verification is not successfully 19 made, then the operation fails. If the verification is successfully made, then the SSP changes the cryptographic protection on the bound key blob as requested.
In 21 one embodiment, the SSP encrypts the bound key data structure with one or more 22 new keys.

23 An example of a class of conditions that the creator (whether local or 24 remote) of a bound key can specify is that the bound key may only be used on behalf of principals whose program digests have a particular value(s). In this case, leef-'Ahayes oK so-324.92s6 54 Auy. Docket No. MS1-1316US

1 the bound key operations check the requesting principal's digest after internal 2 retrieval of the bound key blob, and fail without performing additional 3 computation if the digest is not as specified in the bound key blob.

4 A bound key blob is typically tied or bound to a particular SSP by means of a cryptographic operation that requires a unique key of the particular SSP to 6 succeed. Examples of such operations are MAC, digital signatures, encryption, 7 and combined encryption and integrity verification functions.

s 9 Example Bound Key Operations In one implementation, migration is authorized by way of a local migration l i certificate or an export certificate issued by the authorizing entity. The local-12 migration certificate is a default of RSASSA-PSS-SIGN operation over the 13 following data structure:

14 Bound-migration-info SEQUENCE {
source-bound-blob-digest Digest, dest-PCR DigestPair }

17 Local SSP-migration is requested using the 13 oundKeyMigrate operation.
18 To authorize local-migration, the SSP is provided with a Bound-migration-info 19 structure referring to this bound key, and a properly formed certificate over this structure provided by the authorized entity. If the migration authorization is 21 acceptable, the SSP rebinds the key for the new PCR., with all other key attributes 22 remaining unchanged (e.g., if the key was not originally bound to a PCR.
value, it 23 will not be when rebound). The source-bound-blob-digest is the digest of the 24 encrypted external form of the bound key.

leef',Ahayes pk 5cn 32+=9256 55 Arty. Docket No. MS1-1316US

1 I Remote-migration is achieved through the BourldKeyExport function with, 2 for example, a Bound-export-info structure signed by the authorizing entity:

3 Bound-export-info SEQUENCE {
source-bound-blob-digest Digest, 4 dest-pubkey RSAPublicKey dest-PCR DigestPair }
The authorizing entity is in complete control of the device or software module to which the key is re-bound when a key is marked exportable.

The bound key operations use a PKCiphertext, which is a sequence of type Bound-key-blob encrypted with the platform public encryption key as follows:

Bound-key-blob SEQUENCE {
message-type PKMessageType, key-type Bound-key-type, 11 bound-to-PCR BOOL, bound-to DigestPair, migrateable Bool, 12 migrate-auth Digest, exportable Bool, 13 export-auth Digest, pub-key-digest Digest, 14 bound-key PKCompressedPrivateKey }
16 where:
Bound-key-type INTEGER {
BoundSignKey, 17 BoundQuoteKey BoundDecryptKey, 18 BoundPkUnsealKey }

The bound-to-PCR member is a flag that indicates whether the bound-to 21 Digest field must match the current PCR value in order for the bound key to be 22 used. {migrateable, migrate-auth} indicates whether the key is migrateable, and if 23 so under the control of what authority (if migrateable is false, then the migrate-24 auth value is unimportant). {exportable, export-auth} indicates whether the key is exportable, and if so under the control of what authority (if exportable is false, IeOOhayes,x 504324.92% 56 Airy. Docket No. MS1.1316US

1 then the export-auth value is unimportant). Pub-key-digest is the digest of the 2 corresponding public key to provide a strong binding between the 3 PKCompressedPrivateKey and the public key that is needed to recover the private 4 key.

In one implementation, if a bound key is created locally with the 6 GenBoundKey function, the SSP creates a signature over a data structure detailing the public properties of the key that was just generated, and the configuration of 8 the system during bound key export.

9 Bound-key-pub-info SEQUENCE {
message-type PKMessageType, // sspVlBoundKeyGenMessage sig-nonce Digest, key-type Bound-key-type, 11 bound-to-PCR BOOL, bound-to DigestPair, 12 migrateable Bool, migrate-auth Digest, 13 exportable Bool, export-auth Digest, creator-PCR DigestPair 14 bound-pub-key Digest }

16 In this data structure, key-type, bound-to-PCR, bound-to, migrateable, 17 migrate-auth, exportable, and export-auth are the bound key characteristics of the 18 newly generated key. Creator-PCR is the PCR that was active when the key was 19 exported, and bound-pub-key is the digest of the newly created public key.
sig-nonce is the digest-sized value passed in when bound-key generation was 21 requested.

72 Exemplary definitions of the BoundSign, BoundQuote, BoundPkDecrypt, 23 BoundPkUnseal, GenBoundKey, BoundKeyMigrate, and BoundKeyExport 24 operations are as follows.

lee0hayes we 5o4uz -qz% 57 Airy. Docker No. MSI.1316L'S

1 BoundSign 2 Definition SSP_STATUS BoundSign( 3 [in] PKCiphertext BoundKeyBlob, [in] RSAPublicKey PubPartOfBoundKey, 4 [in] BITSTRING DataToBeSigned [out] PKSignature sig-blob }
Parameters 6 BoundSign-Input ordinal INTEGER, 7 bound-key BoundKeyBlob, bound-pub-key RSAPublicKey, 8 data-to-be-signed OCTET STRING }
BoundSign-output {
9 ordinal INTEGER, status INTEGER, sig-blob PKSignature }
11 Return Values SSP SUCCESS
12 SSP_CRYPTO_ERROR
SSP_BAD_DATA_ERROR
SSP UNSEAL ERROR

Comments The BoundSign operation takes PKciphertext of type sspVlBoundKey containing a BoundKeyBlob of type BoundSignKey and the corresponding public key. If either of these conditions is not met, or if the sequence fails to decode, then the operation fails with SSP CRYPTO ERROR.

If Bound-to-PCR is set, the SSP checks that the current PCR value is as specified in the Bound-key-blob sequence. If it is not, the SSP returns SSP CRYPTO ERROR.

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

leeQhayes 509.32<-8256 58 Am. Docker No. MSI-1316US

1 Access Policy 2 Allowed = FeatureEnable.MainEnable &
3 (FeatureEnable.UsePrivKey==All1 4 FeatureEnable.UsePrivKey==AuthSL

& SLKnown & AuthPCR[CurrentSL].UsePrivKey ) 6 Actions 7 The BoundSign operation implements the following actions:

8 1. The SSP tests if the Algorithmldentifier in pk-sealed-blob is 9 sspV 1 BoundKey.

2. The SSP internally decrypts SealedBlob according to the 11 default implementation of RSAES-OAEP-DECRYPT as specified in PKCS
12 # 1 V2.1, obtaining a plaintext message M.

13 3. If the output of the decoding operation is "decoding error"
14 return SSP CRYPTO ERROR with Secret set to zero.

4. Otherwise, the recovered message M should be a DER

16 encoding of the form Bound-key-blob, with type BoundSignKey. If not, 17 the SSP should emit SSP CRYPTO E OR.

18 5. If bound-to-PCR is TRUE, then the bound-to should be 19 compared to the current PCR value. If the value is not the same, the SSP
should output SSP_CRYPTO_ERROR.

21 6. The SSP then recovers the bound private key using the 22 associated public key provided. If this fails, the SSP returns 23 SSP_CRYPTO_ERROR. If it succeeds, the SSP uses the recovered private 24 key bound-key to generate a signed message over the input message DataToBeSigned according to the default implementation of RSASSA-lee0hayes Pk 50932.9256 59 Any. Docker No. MSI.1316US

PSS-SIGN as specified in PKCS #1 V2.1 If the function returns an error, 2 then return SSP_CRYPTO_ERROR with SigBlob set to 0.

3 7. Return SSP SUCCESS

6 BoundQuote 7 Definition SSP_STATUS BoundQuote( 8 [in] PKCiphertext BoundKeyBlob, [in] DIGEST DataToBeSigned 9 [out] PKSignature sig-blob Parameters BoundQuote-Input {
11 ordinal INTEGER, bound-key BoundKeyBlob, 12 bound-pub-key RSAPublicKey, data-to-be-quoted Digest }

BoundQuote-output ordinal INTEGER, 14 status INTEGER, sig-blob PKSignature }
Return Values 16 SSP_SUCCESS
SSP_CRYPTO_ERROR
SSP_BAD_DATA_ERROR
SSP UNSEAL ERROR

is Comments 19 The BoundQuote operation takes PKciphertext of type sspVlBoundKey containing a BoundKeyBlob of type BoundQuoteKey. If 21 either of these conditions is not met, or if the sequence fails to decode, then 22 the operation fails with SSP_CRVPTO_ERROR.

leee4hayesyk sos.32ae2ec 60 Arty. Docker No. MS/-1316US

1 If Bound-to-PCR is set, the SSP checks that the current PCR value is 2 as specified in the Bound-key-blob sequence. If it is not, the SSP returns 3 SSP CRYPTO ERROR.

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

6 Access Policy Allowed = FeatureEnable.MainEnable &
8 (F eatureEnable.UsePrivKey==All 1 9 FeatureEnable.UsePrivKey==AuthSL

& SLKnown & AuthPCR[CurrentSL].UsePrivKey ) 11 Actions 12 The BoundQuote operation implements the following actions:

13 1. The SSP tests if the Algorithmldentifier in pk-sealed-blob is 14 sspV l BoundKey.

2. The SSP internally decrypts SealedBlob according to the 16 default implementation of RSAES-OAEP-DECRYPT as specified in PKCS
1~ #1 V2.1, obtaining a plaintext message M.

18 3. If the output of the decoding operation is "decoding error"
19 return SSP CRYPTO ERROR with Secret set to zero.

4. Otherwise, the recovered message M should be a DER

21 encoding of the form Bound-key-blob, with type BoundQuoteKey. If not 22 the SSP should emit SSP CRYPTO ERROR.

23 5. If bound-to-PCR is true, then the bound-to should be 24 compared to the current PCR value. If the value is not the same, the SSP
should output SSP_CRYPTO_ERROR.

lee0hayes we 5094124.9256 61 Atly. Docker iVo. MSI-1316US

1 6. The SSP then uses the recovered private key fragment and the 2 public key to reconstruct the private key. The private key can be 3 reconstructed as follows. In general, RSA keys are made of a number N =
4 p * q (N is the product of two prime numbers p and q.), and two exponents e (encryption exponent) and d (decryption exponent). N and e form the 6 public key; d is the private key. In general, d is as long as N (e.g. 2048 7 bits). If the factorization of N is known (i.e., if p and q are known) then the s private key d can be readily determined. Note that p and q are only half as 9 long as N. So, rather than storing d as the private key, we store p. Then, given the public key N,e and p, the value q = Nip can be computed, and 11 then the value d determined given p and q.

12 The private key is then used to generate a signature message over the 13 input message DataToBeSigned and the current PCR value according to the 14 specification in the Quote operation defined above. If the function returns an error then return SSP_CRYPTO_ERROR with SigBlob set to 0.
16 7. Return SSP_SUCCESS

19 BoundPkDecrypt Definition SSP_STATUS BoundPkDecrypt( 21 [in] PKCiphertext BoundKeyBlob, [in] RSAPublicKey BoundPubKey, 22 [in] PKCiphertext DataToBeDecrypted, [out] Secret decryptedData Parameters 24 BoundPkDecrypt-Input {
ordinal INTEGER, bound-key BoundKeyBlob, lee(bhayes ax so .t o.sose 62 Any. Docket No. MS1-1316US

bound-pub-key RSAPublicKey, 1 pk-sealed-blob PKCiphertext }
2 BoundPkDecrypt-output ordinal INTEGER, status INTEGER, 3 d-blob Secret }
4 Return Values SSP_SUCCESS
SSP UNSEAL ERROR
SSPCRYPTOERROR
6 SSP_BAD_DATA_ERROR

Comments The BoundPkDecrypt operation takes PKciphertext of type 9 sspV 1 BoundKey containing a BoundKeyBlob of type BoundDecryptKey.
If either of these conditions is not met, or if the sequence fails to decode, 11 then the operation fails with SSP_CRYP T O_ER.ROR.

If Bound-to-PCR is set, the SSP checks that the current PCR value is 13 as specified in the Bound-key-blob sequence. If it is not, the SSP returns SSP CRYPTO ERROR.

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

17 Access Policy Allowed = FeatureEnable.MainEnable &
18 19 (FeatureEnable.UsePrivKey==All 1 FeatureEnable.UsePrivKey==AuthSL

21 & SLKnown & AuthPCR[CurrentSL].UsePrivKey ) Actions The BoundPkDecrypt operation implements the following actions:

24 1. The SSP tests if the Algorithmldentifier in pk-sealed-blob is sspV l BoundKey.

lee(?lhayes pk w9.32ae26 63 Airv. Docker,vo. MSI-1316US

1 2. The SSP internally decrypts SealedBlob according to the 2 default implementation of RSAES-OAEP-DECRYPT as specified in PKCS
3 #1 V2.1, obtaining a plaintext message M.

4 3. If the output of the decoding operation is "decoding error,"
return SSP_CRYPT _ERROR with Secret set to zero.

6 4. Otherwise, the recovered message M should be a DER

7 encoding of the form Bound-key-blob, with type BoundDecryptKey. If not, 8 the SSP should emit SSP_CRYPTO_ERROR.

9 5. If bound-to-PCR is true, then the bound-to should be compared to the current PCR value, if the value is not the same, the SSP
I1 should output SSP_CRYPTO_ERROR.

12 6. The SSP recovers the private key using the provided public 13 key. The private key can be recovered as discussed above in the 14 BoundQuote operation. It then uses the recovered private bound-key to decrypt the pk-sealed-blob using the default implementation of RSAES-16 OAEP-DECRYPT as specified in PKCS #1 V2..1, obtaining a plaintext 17 message M.

18 7. The SSP sets d-blob to M.
19 8. Return SSP_SUCCESS.

22 BoundPkUnseal 23 Definition SSP_STATUS BoundPKUnseal( 24 [in] PKCiphertext BoundKeyBlob, [in] RSAPublicKey BoundPubKey, [in] PKCiphertext DataToBeUnsealed [out] Secret decryptedData iee0hayes pr 569.324.9256 64 Any. Docket No. MS1-1316US

Parameters 2 BoundPKUnseal-Input {
ordinal INTEGER, 3 bound-key BoundKeyBlob, bound-pub-key RSAPublicKey, pk-sealed-blob PKCiphertext }

BoundPKUnseal-output {
ordinal INTEGER, status INTEGER, 6 d-blob Secret }

Return Values SSP-SUCCESS
SSP_UNSEAL_ERROR

S SP BAD DATA ERROR

Comments The BoundPkUnseal operation takes PKciphertext of type sspV1BoundKey containing a BoundKeyBlob of type BoundPKUnsealKey.

If either of these conditions is not met, or if the sequence fails to decode, then the operation fails with SSP_CRYPTO_ERROR.

If Bound-to-PCR is set, the SSP checks that the current PCR value is as specified in the Bound-key-blob sequence. If it is not, the SSP returns SSP CRYPT ERROR.

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

Access Policy Allowed = FeatureEnable.MainEnable &

(FeatureEnable.UsePrivKey==All FeatureEnable.UsePrivKey==AuthSL

& SLKnown & AuthPCR[CurrentSL].UsePrivKey ) lee(?hayes pk 5U9.324l25& 65 Arrv. Docker No. MSI-1316US

1 Actions 2 The BoundPkUnseal operation must implement the following steps:
3 1. The SSP tests if the Algorithmldentifier in pk-sealed-blob is 4 sspV 1 BoundKey.

2. The SSP internally decrypts SealedBlob according to the 6 default implementation of RSAES-OAEP-DECRYPT as specified in PKCS
7 #1 V2.1, obtaining a plaintext message M.

8 3. If the output of the decoding operation is "decoding error,"
9 return SSP CRYPTO ERROR with Secret set to zero.

4. Otherwise, the recovered message M should be a DER

11 encoding of the form Bound-key-blob, with type BoundDecryptKey. If not, 12 the SSP should emit SSP CRYPTO ERROR.

13 5. If bound-to-PCR is true, then the bound-to should be 14 compared to the current PCR value. If the value is not the same, the SSP
should output SSP_CRYPTO_ERROR.

16 6. The SSP recreates the private key using the bound key blob.
1' The private key can be recovered as discussed above in the BoundQuote 18 operation. It then uses the recovered private bound-key to unseal the pk-19 sealed-blob using the steps described in the PK,_Unseal command.

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

22 S. Otherwise, the SSP sets d-blob to M.

23 9. Return SSP SUCCESS.

leeahayes,x 50432.9256 66 Atty. Docker No. M51-13)6US

1 GenBoundKey 2 Definition SSP_STATUS GenBoundKey( 3 [in] BoundKeyType KeyType, [in] BOOL BoundToPcr, 4 [in] DIGEST BoundTo[2], [in] BOOL migrateable, [in] DIGEST migrationAuthority, [in] BOOL exportable, [in] DIGEST exportAuthority, 6 [in] DIGEST SigNonce, [out] BoundKey bound-key, 7 [out] PKPublickey newPubKey, [out] PKSignature boundKeyQuoteBlob }

Parameters 9 GenBoundKey-Input {
ordinal INTEGER, key-type Bound-key-type, bound-to-pcr BOOL, 11 bound-to DigestPair, migrateable BOOL, migrate-auth Digest, 12 exportable BOOL, export-auth Digest, 13 sig-nonce Digest }

GenBoundKey-output {
ordinal INTEGER, status INTEGER, bound-blob PKCiphertext, 16 bound-pub RSAPublicKey, sig-blob PKSignature }

Return Values 18 SSP_SUCCESS
SS P BAD DATA ERROR

Comments The GenBoundKey operation causes the SSP to generate a new zl bound-key blob containing the newly generated private key. The bound-key blob is encrypted with the SSP's own public key.

leeà hayes F& 509.321=92S6 67 At. Docket No. MSI-1316US

1 GenBoundKey also outputs the public key of the newly generated 2 key-pair, a quote-signature that indicates that the SSP generated the key, its 3 characteristics, and the PCR value when the key was generated.

4 The caller of GenBoundKey also indicates the type of bound-key to be created: whether it is for signing, quoting, unsealing with 6 BoundPkUnseal, or decrypting with BoundPi<Decrypt. The caller also 7 specifies whether the bound-key should be bound to a PCR, and if so, the 8 PCR value to which it is bound.

9 Access Policy Allowed = FeatureEnable.MainEnable &
11 (FeatureEnable.UsePrivKey= All1 12 FeatureEnable.UsePrivKey==AuthSL

13 & SLKnown & AuthPCR[CurrentSL].UsePrivKey ) 14 Actions The GenBoundKey operation implements the following actions:

16 1. The SSP generates a new public private RSA key-pair. The 17 SSP can optionally generate key-pairs when the SSP is otherwise idle, and 18 store a small cache of keys in non-volatile memory for immediate retrieval.
19 2. The SSP internally generates a bound-key structure containing the newly generate private key and the bound-key type and other 21 parameters provided by the caller.

22 3. The SSP encrypts the bound-key blob with the platform 23 public encryption key.

leeGhayes p o 509-32d=9256 68 Arty. Docket No. MSI-1316US

4. The SSP generates a signed blob of a bound-key-pub-info 2 containing the properties of the newly created key, the PCR values at the 3 time of key creation and the supplied nonce.

4 5. The SSP outputs the encrypted bound-key blob, the newly generated public key, and the quoted key blob.

6 6. Return SSP_SUCCESS.

9 BoundKeyMigrate Definition SSP_STATUS BourdKeyMigrate( 11 [in] PKCiphertext BoundKeyBlob, [in] RSAPublicKey PubPartOfBoundKey, 12 [in] BOUND MIGRATION NFO MigrationInfo, [in] RSA SIG SigOnMigrationlnfo Parameters 14 GenBoundKey-Input {
ordinal INTEGER, migration-info Bound-migration-info, migration-pubkey RSAPublicKey, 16 migration-auth PKSignature }

17 GenBoundKey-output {
ordinal INTEGER, 18 status INTEGER, re-bound-blob PKCiphertext, 19 }

Return Values SSP_SUCCESS
SSP BAD DATA ERROR

Comments The BoundKeyMigrate operation instructs the SSP to re-bind a key to a different PCR value in a controlled manner. The original key-creator, local or remote, names the migration-authorization entity. Only bound keys lee?hayes ,x 509.324.9256 69 Atty. Docker Vo. USI-1316US

1 marked migrateable can be migrated, and these will only be migrated if the 2 SSP is provided with an appropriated signed Boundmigration-info 3 structure. Appropriately signed means signed with the public key whose 4 digest is contained within the bound key blob. The other bound key attributes are not changed.

7 Access Policy 8 Allowed = FeatureEnable.MainEnable &
9 (FeatureEnable.UsePrivKey==All I

FeatureEnable.UsePrivKey-AuthSL

11 & SLKnown & AuthPCR[CurrentSL].UsePrivKey ) 12 Actions 13 The BoundKeyMigrate operation implements the following actions:
14 1. The SSP internally decrypts the bound-key structure and interprets it as a Bound-key-blob. If the decoding fails, the SSP returns 16 SSP CRYPTO ERROR.

17 2. The SSP validates that Bound-export-info refers to the same 18 key, that the signature is properly formed, and that the digest of the public 19 key of the signer is as named in the `migrateable' field of the Bound-key-blob.

21 3. The SSP checks that the key is migrateable. If not, the SSP
22 returns SSP CRYPO ERROR

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

Iee ahayes ek SOA32a=9256 70 Atm. Docket No. MSI-1116US

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

3 6. The SSP re-encrypts the bound-key-blob, and exports the re-4 encrypted structure.

6. Return SSP_SUCCESS.

8 BoundKeyExport 9 Definition SSP_STATUS BoundKeyExport( [in] PKCiphertext BoundKeyBlob, [in] RSAPublicKey PubpartOfBoundKey, 11 (in] BOUND EXPORT NFO Exportlnfo, [in] RSA_SIG SigOnExportlnfolnfo, [out] PKCipherText ReBoundBlob 13 Parameters BoundKeyExport-Input {
14 ordinal INTEGER, bound-key PKCipherText, bound-pub-key RSAPublicKey, export-info Bound-export-info, export-auth PKSignature, 17 GenBoundKey-output {
ordinal INTEGER, 18 status INTEGER, re-bound-blob PKCiphertext, 19 }
Return Values SSP_SUCCESS
S SP BAD DATA ERROR

Comments The BoundKeyExport operation instructs the SSP to export the private part of a bound key to a remote entity in a format consistent with bound keys on the source device in a controlled manner. The original key-lee?hayes Pk 5 32492% 71 Any. Docker No. MS/-1316US

1 creator, local or remote, names the export-authorization entity. Only bound 2 keys marked exportable can be exported, and these will only be exported if 3 the SSP is provided with an appropriated signed Bound-export-info 4 structure. Appropriately signed means signed with the public key whose digest is contained within the original bound key blob. BoundKeyExport 6 allows appropriately authorized callers to specify the public key and PCR
7 value of the target entity to which the key should be rebound. There is no 8 specific requirement that the external entity be an SSP, but the newly bound 9 blob follows bound-key conventions to allow remote SSPs to consume exported bound keys directly.

12 Access Policy 13 Allowed = FeatureEnable.MainEnable &.
14 (FeatureEnable.UsePrivKey-All 1 FeatureEnable.UsePrivKey==AuthSL

16 & SLKnown & AuthPCR[CurrentSL].U sePrivKey ) 17 Actions 18 The BoundKeyExport operation implements the following actions:
19 1. The SSP internally decrypts the bound-key structure and interprets it as a Bound-key-blob. If the decoding fails, the SSP returns 21 SSP_CRYPTO_ERROR.

22 2. The SSP validates that Bound-export-info refers to the same 23 key, that the signature is properly formed, and that the digest of the public 24 key of the signer is as named in the 'export' field of the Bound-key-blob.

lee@haye5 dk 50v 324.925e 72 Arty. Docket No. MSi=1316US

1 3. The SSP checks that the key is exportable. If not, the SSP
2 returns SSP CRYPO ERROR.

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

5. The SSP internally generates a new bound-key-blob structure

6 containing the parameters from the original bound-key-blob structure and

7 the new PCR value supplied in Bound-export-info. All other parameters

8 remain the same.

9 6. The SSP encrypts the new bound-key blob with the public encryption key supplied in Bound-export-info.

11 ?. The newly bound key is exported.
12 8. Return SSP SUCCESS.

14 General Computer Environment Fig. 12 illustrates a general computer environment 400, which can be used 16 to implement the techniques described herein. The computer environment 400 is 17 only one example of a computing environment and is not intended to suggest any 18 limitation as to the scope of use or functionality of the computer and network 19 architectures. Neither should the computer environment 400 be interpreted as having any dependency or requirement relating to any one or combination of 21 components illustrated in the exemplary computer environment 400.

22 Computer environment 400 includes a general-purpose computing device in 23 the form of a computer 402. Computer 402 can be used, for example, to 24 implement principal 102 and guard 104 of Fig. 1, or the layers of Fig. 2.
The components of computer 402 can include, but are not limited to, one or more leeGhayes pc 509.324.9298 73 Arty. Docke, No. MSI-1316US

1 processors or processing units 404 (optionally including one or more security 2 processors or coprocessors (such as an SSP) and/or one or more cryptographic 3 processors or coprocessors), a system memory 406, and a system bus 408 that 4 couples various system components including the processor 404 to the system memory 406.

6 The system bus 408 represents one or more of any of several types of bus 7 structures, including a memory bus or memory controller, a peripheral bus, an 8 accelerated graphics port, and a processor or local bus using any of a variety of 9 bus architectures. By way of example, such architectures can include an Industry to Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an i, Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) 12 local bus, and a Peripheral Component Interconnects (PCI) bus also known as a 13 Mezzanine bus.

14 Computer 402 typically includes a variety of computer readable media.
Such media can be any available media that is accessible by computer 402 and 16 includes both volatile and non-volatile media, removable and non-removable 17 media.

18 The system memory 406 includes computer readable media in the form of 19 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 21 (BIOS) 414, containing the basic routines that help to transfer information 22 between elements within computer 402, such as during start-up, is stored in ROM
23 412. RAM 410 typically contains data and/or program modules that are 24 immediately accessible to and/or presently operated on by the processing unit 404.

lee2lhayes c c 509.32492 74 Atty. Docket No. MSI-I316US

1 Computer 402 may also include other removable/non-removable, 2 volatile/non-volatile computer storage media. By way of example, Fig. 12 3 illustrates a hard disk drive 416 for reading from and writing to a non-removable, 4 non-volatile magnetic media (not shown), a magnetic disk drive 418 for reading from and writing to a removable, non-volatile magnetic disk 420 (e.g., a "floppy 6 disk"), and an optical disk drive 422 for reading from and/or writing to a 7 removable, non-volatile optical disk 424 such as a CD-ROM, DVD-ROM, or other s optical media. The hard disk drive 416, magnetic disk drive 418, and optical disk 9 drive 422 are each connected to the system bus 408 by one or more data media io interfaces 426. Alternatively, the hard disk drive 416, magnetic disk drive 418, 11 and optical disk drive 422 can be connected to the system bus 408 by one or more 12 interfaces (not shown).

13 The disk drives and their associated computer-readable media provide non-14 volatile storage of computer readable instructions, data structures, program modules, and other data for computer 402. Although the example illustrates a hard 16 disk 416, a removable magnetic disk 420, and a removable optical disk 424, it is to 17 be appreciated that other types of computer readable media which can store data 18 that is accessible by a computer, such as magnetic cassettes or other magnetic 19 storage devices, flash memory cards, CD-ROM, digital versatile disks (DVD) or other optical storage, random access memories (RAM), read only memories 21 (ROM), electrically erasable programmable read-only memory (EEPROM), and 22 the like, can also be utilized to implement the exemplary computing system and 23 environment.

24 Any number of program modules can be stored on the hard disk 416, magnetic disk 420, optical disk 424, ROM 412, and/or RAM 410, including by lee0hayes pk se9-3zm9256 75 At. Docket No. MS)-1316US

1 way of example, an operating system 426, one or more application programs 428, 2 other program modules 430, and program data 432. Each of such operating 3 system 426, one or more application programs 428, other program modules 430, 4 and program data 432 (or some combination thereof) may implement all or part of the resident components that support the distributed file system.

6 A user can enter commands and information into computer 402 via input 7 devices such as a keyboard 434 and a pointing device 436 (e.g., a "mouse").
s Other input devices 438 (not shown specifically) may include a microphone, 9 joystick, game pad, satellite dish, serial port, scanner, and/or the like.
These and other input devices are connected to the processing unit 404 via input/output 11 interfaces 440 that are coupled to the system bus 408, but may be connected by 12 other interface and bus structures, such as a parallel port, game port, or a universal 13 serial bus (USB).

14 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 16 monitor 442, other output peripheral devices can include components such as 17 speakers (not shown) and a printer 446 which can be connected to computer 18 via the input/output interfaces 440.

19 Computer 402 can operate in a networked environment using logical connections to one or more remote computers, such as a remote computing device 21 448. By way of example, the remote computing device 448 can be a personal 22 computer, portable computer, a server, a router, a network computer, a peer device 23 or other common network node, and the like. The remote computing device 448 is 24 illustrated as a portable computer that can include many or all of the elements and features described herein relative to computer 402.

lee0hayes ac 509324.9256 76 Atty. Docker No. MSI-1316US

Logical connections between computer 402 and the remote computer 448 2 are depicted as a local area network (LAN) 450 and a general wide area network 3 (WAN) 452. Such networking environments are commonplace in offices, 4 enterprise-wide computer networks, intranets, and the Internet.

When implemented in a LAN networking environment, the computer 402 is 6 connected to a local network 450 via a network interface or adapter 454.
When 7 implemented in a WAFT networking environment, the computer 402 typically 8 includes a modem 456 or other means for establishing communications over the 9 wide network 452. The modem 456, which can be internal or external to computer 402, can be connected to the system bus 408 via the input/output interfaces 440 or 11 other appropriate mechanisms. It is to be appreciated that the illustrated network 12 connections are exemplary and that other means of establishing communication 13 link(s) between the computers 402 and 448 can be employed.

14 In a networked environment, such as that illustrated with computing environment 400, program modules depicted relative to the computer 402, or 16 portions thereof, may be stored in a remote memory storage device. By way of 17 example, remote application programs 458 reside on a memory device of remote 18 computer 448. For purposes of illustration, application programs and other 19 executable program components such as the operating system are illustrated herein as discrete blocks, although it is recognized that such programs and components 21 reside at various times in different storage components of the computing device 22 402, and are executed by the data processor(s) of the computer.

23 Various modules and techniques may be described herein in the general 24 context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include leeiDhayes ox 50s324-s256 77 Arry. Docker No. MS1-1316US

1 routines, programs, objects, components, data structures, etc. that perform 2 particular tasks or implement particular abstract data types. Typically, the 3 functionality of the program modules may be combined or distributed as desired in 4 various embodiments.

An implementation of these modules and techniques may be stored on or 6 transmitted across some form of computer readable media. Computer readable media can be any available media that can be accessed by a computer. By way of 8 example, and not limitation, computer readable media may comprise "computer 9 storage media" and "communications media."

"Computer storage media" includes volatile and non-volatile, removable 11 and non-removable media implemented in any method or technology for storage 12 of information such as computer readable instructions, data structures, program 13 modules, or other data. Computer storage media includes, but is not limited to, 14 RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic 16 tape, magnetic disk storage or other magnetic storage devices, or any other 17 medium which can be used to store the desired information and which can be 18 accessed by a computer.

19 "Communication media" typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data 21 signal, such as carrier wave or other transport mechanism. Communication media 22 also includes any information delivery media. The term "modulated data signal"
23 means a signal that has one or more of its characteristics set or changed in such a 24 manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or feeQhayes Ck 999.32<=92% 78 Arty. Docker No. MSI-1316US

I direct-wired connection, and wireless media such as acoustic, RF, infrared, and 2 other wireless media. Combinations of any of the above are also included within 3 the scope of computer readable media.

4 Although the description above uses language that is specific to structural features and/or methodological acts, it is to be understood that the invention 6 defined in the appended claims is not limited to the specific features or acts 7 described. Rather, the specific features and acts are disclosed as exemplary forms s of implementing the invention.

I i lee@hayes yk soe-324.92% 79 Atty. Docket No. MSI-1316US

Claims (70)

CLAIMS:

1. A method, implemented in a computing device, the method comprising:

receiving a bit string from a calling program;

checking an identifier of the calling program to determine whether the calling program is allowed to access data encrypted in ciphertext of the bit string, the checking comprising:

obtaining, from the bit string, identifiers of multiple target programs that are allowed to access the data;

checking whether one of the identifiers of the multiple target programs is the same as the identifier of the calling program;

determining that the calling program is allowed to access the data if one of the identifiers of the multiple target programs is the same as the identifier of the calling program; and determining that the calling program is not allowed to access the data if none of the identifiers of the multiple target programs is the same as the identifier of the calling program;

verifying the integrity of the data;

decrypting the data using a symmetric key; and returning the data to the calling program only if the calling program is allowed to access the data and if the integrity of the data is successfully verified.

2. A method as recited in claim 1, wherein the data comprises a cryptographic key.

3. A method as recited in claim 1, further comprising:

returning, to the calling program, an identifier of a program that previously sealed the data.

4. A method as recited in claim 3, wherein the identifier of the program that previously sealed the data comprises a digest value generated by applying a cryptographic hash function to the program that previously sealed the data.

5. A method as recited in claim 1, wherein the identifier of the calling program comprises a digest value generated by applying a cryptographic hash function to the target program.

6. A method as recited in claim 1, wherein receiving the bit string comprises receiving the bit string as part of an UnSeal operation.

7. A method as recited in claim 1, wherein the bit string comprises a combination of the ciphertext and a message authentication code (MAC) value for the ciphertext.

8. A method as recited in claim 1, wherein the bit string comprises a combination of the ciphertext and a message authentication code (MAC) value for the data.

9. A method as recited in claim 1, wherein the bit string comprises a ciphertext generated from a combination of the data and a message authentication code (MAC) value for the data.

10. A method as recited in claim 1, wherein the verifying comprises:
obtaining the data by decrypting the ciphertext;

generating a message authentication code (MAC) value for the obtained data;

comparing the generated MAC value to a MAC value received as part of the bit string; and successfully verifying the integrity of the data only if the generated MAC
value is equal to the MAC value received as part of the bit string.

11. A method as recited in claim 10, wherein the generating the MAC value comprises generating the MAC value using a first part of the symmetric key, and wherein the decrypting the data comprises decrypting the data using a second part of the symmetric key.

12. One or more computer storage media having stored thereon a plurality of instructions that, when executed by one or more processors of a computing device, causes the one or more processors to:

receive data from a calling program;

generate, using a symmetric cipher, ciphertext that includes the data and identifiers of multiple target programs that are allowed to access the data;

after the ciphertext is generated, receive a bit string from another calling program;

check an identifier of the other calling program to determine whether the other calling program is one of the multiple target programs;

verify the integrity of the data;

decrypt the data using a symmetric key; and return the data to the other calling program only if the other calling program is one of the multiple target programs and if the integrity of the data is successfully verified.

13. One or more computer storage media as recited in claim 12, wherein the calling program and the other calling program are the same program.

14. One or more computer storage media as recited in claim 12, wherein to verify the integrity of the data is to verify the integrity using one part of the symmetric key and wherein to decrypt the data is to decrypt the data using another part of the symmetric key.

15. One or more computer storage media having stored thereon a plurality of instructions that, when executed by one or more processors of a computing device, causes the one or more processors to:

obtain an identifier of a calling application;

generate a bit string including the identifier of the calling application, data to be sealed for the calling application, and identifiers of multiple target applications that are allowed to unseal the data;

generate a message authentication code (MAC) value for the bit string;
encrypt the bit string using a symmetric key and a symmetric; cipher; and return the MAC value and the encrypted bit string to the calling application.

16. One or more computer storage media as recited in claim 15, wherein the instructions that when executed by the one or more processors cause the one or more processors to obtain the identifier of the calling application comprise instructions that when executed by the one or more processors cause the one or more processors to generate a digest of the calling application using a cryptographic hash function.

17. One or more computer storage media as recited in claim 15, wherein the instructions when executed by the one or more processors further cause the one or more processors to receive, from the calling application, the data.

18. One or more computer storage media as recited in claim 15, wherein the instructions when executed by the one or more processors further cause the one or more processors to generate a random value to be used as the data.

19. One or more computer storage media as recited in claim 15, wherein the symmetric key includes a first part and a second part that are independent of one another, wherein to generate the MAC value is to generate the MAC value with the first part of the symmetric key, and wherein to encrypt the bit string is to encrypt the bit string with the second part of the symmetric key.

20. One or more computer storage media having stored thereon a plurality of instructions that, when executed by one or more processors of a computing device, causes the one or more processors to:

receive, from a calling program, a bit string including ciphertext and a message authentication code (MAC) value;

decrypt the ciphertext in the bit string using a symmetric key to generate plaintext data;

generate a message authentication code (MAC) value for at least a portion of the plaintext data;

check whether the MAC value in the bit string is equal to the generated MAC value;

check whether an identifier of the calling program is included as one of multiple target program identifiers in the plaintext data, the multiple target program identifiers identifying multiple target programs that are allowed to unseal the plaintext data; and return the plaintext data to the calling program only if the MAC value in the bit string is equal to the generated MAC value and if the identifier of the calling program is included as one of the multiple target program identifiers in the plaintext data.

21. One or more computer storage media as recited in claim 20, wherein the identifier of the calling program comprises a digest of the calling program generated using a cryptographic hash function.

22. One or more computer storage media as recited in claim 20, wherein to generate the MAC value is to generate the MAC value using a first part of the symmetric key, and wherein to decrypt the ciphertext in the bit string is to decrypt the ciphertext in the bit string using a second part of the symmetric key.

23. A device comprising a plurality of hardware means, the plurality of hardware means including:

means for receiving a bit string from a calling program;

means for checking an identifier of the calling program to determine whether the calling program is allowed to access data encrypted in ciphertext of the bit string, the means for checking determining that the calling program is allowed to access the data if the identifier of the calling program is included as one of multiple target program identifiers in the ciphertext;

means for verifying the integrity of the data;

means for decrypting the data using a symmetric key; and means for returning the data to the calling program only if the calling program is allowed to access the data and if the integrity of the data is successfully verified.

24. One or more computer storage media having stored thereon a plurality of instructions that, when executed by one or more processors of a computing device, causes the one or more processors to:

receive a bit string from a calling program;

check an identifier of the calling program to determine whether the calling program is allowed to access data encrypted in ciphertext of the bit string, wherein to check the identifier is to:

obtain, from the bit string, identifiers of multiple target programs that are allowed to access the data;

check whether one of the identifiers of the multiple target programs is the same as the identifier of the calling program;

determine that the calling program is allowed to access the data if one of the identifiers of the multiple target programs is the same as the identifier of the calling program; and determine that the calling program is not allowed to access the data if none of the identifiers of the multiple target programs is the same as the identifier of the calling program;

verify the integrity of the data;

decrypt the data using a symmetric key; and return the data to the calling program only if the calling program is allowed to access the data and if the integrity of the data is successfully verified.

25. One or more computer storage media as recited in claim 24, wherein the data comprises a cryptographic key.

26. One or more computer storage media as recited in claim 24, wherein the plurality of instructions when executed by the one or more processors further causes the one or more processors to:

return, to the calling program, an identifier of a program that previously sealed the data.

27. One or more computer storage media as recited in claim 26, wherein the identifier of the program that previously sealed the data comprises a digest value generated by applying a cryptographic hash function to the program that previously sealed the data.

28. One or more computer storage media as recited in claim 24, wherein the identifier of the calling program comprises a digest value generated by applying a cryptographic hash function to the target program.

29. One or more computer storage media as recited in claim 24, wherein to receive the bit string is to receive the bit string as part of an UnSeal operation.

30. One or more computer storage media as recited in claim 24, wherein the bit string comprises a combination of the ciphertext and a message authentication code (MAC) value for the ciphertext.

31. One or more computer storage media as recited in claim 24, wherein the bit string comprises a combination of the ciphertext and a message authentication code (MAC) value for the data.

32. One or more computer storage media as recited in claim 24, wherein the bit string comprises a ciphertext generated from a combination of the data and a message authentication code (MAC) value for the data.

33. One or more computer storage media as recited in claim 24, wherein to verify the integrity of the data is to:

obtain the data by decrypting the ciphertext;

generate a message authentication code (MAC) value for the obtained data;

compare the generated MAC value to a MAC value received as part of the bit string; and successfully verify the integrity of the data only if the generated MAC
value is equal to the MAC value received as part of the bit string.

34. One or more computer storage media as recited in claim 33, wherein to generate the MAC value is to generate the MAC value using a first part of the symmetric key, and wherein to decrypt the data is to decrypt the data using a second part of the symmetric key.

35. A computing device comprising:
a processor; and a memory, coupled to the processor, storing a plurality of instructions that when executed by the processor cause the processor to perform acts comprising:
receiving a bit string from a calling program;

checking an identifier of the calling program to determine whether the calling program is allowed to access data encrypted in ciphertext of the bit string, the checking comprising:

obtaining, from the bit string, identifiers of multiple target programs that are allowed to access the data;

checking whether one of the identifiers of the multiple target programs is the same as the identifier of the calling program;

determining that the calling program is allowed to access the data if one of the identifiers of the multiple target programs is the same as the identifier of the calling program; and determining that the calling program is not allowed to access the data if none of the identifiers of the multiple target programs is the same as the identifier of the calling program;

verifying the integrity of the data;

decrypting the data using a symmetric key; and returning the data to the calling program only if the calling program is allowed to access the data and if the integrity of the data is successfully verified.

36. A computing device as recited in claim 35, wherein the data comprises a cryptographic key.

37. A computing device as recited in claim 35, wherein the plurality of instructions when executed by the processor further cause the processor to perform acts comprising:

returning, to the calling program, an identifier of a program that previously sealed the data.

38. A computing device as recited in claim 37, wherein the identifier of the program that previously sealed the data comprises a digest value generated by applying a cryptographic hash function to the program that previously sealed the data.

39. A computing device as recited in claim 35, wherein the identifier of the calling program comprises a digest value generated by applying a cryptographic hash function to the target program.

40. A computing device as recited in claim 35, wherein receiving the bit string comprises receiving the bit string as part of an UnSeal operation.

41. A computing device as recited in claim 35, wherein the bit string comprises a combination of the ciphertext and a message authentication code (MAC) value for the ciphertext.

42. A computing device as recited in claim 35, wherein the bit string comprises a combination of the ciphertext and a message authentication code (MAC) value for the data.

43. A computing device as recited in claim 35, wherein the bit string comprises a ciphertext generated from a combination of the data and a message authentication code (MAC) value for the data.

44. A computing device as recited in claim 35, wherein the verifying comprises:

obtaining the data by decrypting the ciphertext;

generating a message authentication code (MAC) value for the obtained data;

comparing the generated MAC value to a MAC value received as part of the bit string; and successfully verifying the integrity of the data only if the generated MAC
value is equal to the MAC value received as part of the bit string.

45. A computing device as recited in claim 44, wherein the generating the MAC value comprises generating the MAC value using a first part of the symmetric key, and wherein the decrypting the data comprises decrypting the data using a second part of the symmetric key.

46. A method, implemented in a computing device, the method comprising:
receiving data from a calling program;

generating, using a symmetric cipher, ciphertext that includes the data and identifiers of multiple target programs that are allowed to access the data;

after the ciphertext is generated, receiving a bit string from another calling program;

checking an identifier of the other calling program to determine whether the other calling program is one of the multiple target programs;

verifying the integrity of the data;

decrypting the data using a symmetric key; and returning the data to the other calling program only if the other calling program is one of the multiple target programs and if the integrity of the data is successfully verified.

47. A method as recited in claim 46, wherein the calling program and the other calling program are the same program.

48. A method as recited in claim 46, wherein verifying the integrity of the data comprises verifying the integrity using one part of the symmetric key and wherein decrypting the data comprises decrypting the data using another, part of the symmetric key.

49. A computing device comprising:
a processor; and a memory, coupled to the processor, storing a plurality of instructions that when executed by the processor cause the processor to:

receive data from a calling program;

generate, using a symmetric cipher, ciphertext that includes the data and identifiers of multiple target programs that are allowed to access the data;

after the ciphertext is generated, receive a bit string from another calling program;

check an identifier of the other calling program to determine whether the other calling program is one of the multiple target programs;

verify the integrity of the data, decrypt the data using a symmetric key; and return the data to the other calling program only if the other calling program is one of the multiple target programs and if the integrity of the data is successfully verified.

50. A computing device as recited in claim 49, wherein the calling program and the other calling program are the same program.

51. A computing device as recited in claim 49, wherein to verify the integrity of the data is to verify the integrity using one part of the symmetric key and wherein to decrypt the data is to decrypt the data using another part of the symmetric key.

52. A method, implemented in a computing device, the method comprising:
obtaining an identifier of a calling application;

generating a bit string including the identifier of the calling application, data to be sealed for the calling application, and identifiers of multiple target applications that are allowed to unseal the data;

generating a message authentication code (MAC) value for the bit string;
encrypting the bit string using a symmetric key and a symmetric cipher;
and returning the MAC value and the encrypted bit string to the calling application.

53. A method as recited in claim 52, wherein obtaining the identifier of the calling application comprises generating a digest of the calling application using a cryptographic hash function.

54. A method as recited in claim 52, further comprising receiving, from the calling application, the data.

55. A method as recited in claim 52, further comprising generating a random value to be used as the data.

56. A method as recited in claim 52, wherein the symmetric key includes a first part and a second part that are independent of one another, wherein generating the MAC value comprises generating the MAC value with the first part of the symmetric key, and wherein encrypting the bit string comprises encrypting the bit string with the second part of the symmetric key.

57. A computing device comprising:
a processor; and a memory, coupled to the processor, storing a plurality of instructions that when executed by the processor cause the processor to:

obtain an identifier of a calling application;

generate a bit string including the identifier of the calling application, data to be sealed for the calling application, and identifiers of multiple target applications that are allowed to unseal the data;

generate a message authentication code (MAC) value for the bit string;
encrypt the bit string using a symmetric key and a symmetric cipher;
and return the MAC value and the encrypted bit string to the calling application.

58. A computing device as recited in claim 57, wherein the instructions that when executed by the processor cause the processor to obtain the identifier of the calling application comprise instructions that when executed by the processor cause the processor to generate a digest of the calling application using a cryptographic hash function.

59. A computing device as recited in claim 57, wherein the instructions when executed by the processor further cause the processor to receive, from the calling application, the data.

60. A computing device as recited in claim 57, wherein the instructions when executed by the processor further cause the processor to generate a random value to be used as the data.

61. A computing device as recited in claim 57, wherein the symmetric key includes a first part and a second part that are independent of one another, wherein to generate the MAC value is to generate the MAC value with the first part of the symmetric key, and wherein to encrypt the bit string is to encrypt the bit string with the second part of the symmetric key.

62. A method, implemented in a computing device, the method comprising:
receiving, from a calling program, a bit string including ciphertext and a message authentication code (MAC) value;

decrypting the ciphertext in the bit string using a symmetric key to generate plaintext data;

generating a message authentication code (MAC) value for at least a portion of the plaintext data;

checking whether the MAC value in the bit string is equal to the generated MAC value;

checking whether an identifier of the calling program is included as one of multiple target program identifiers in the plaintext data, the multiple target program identifiers identifying multiple target programs that are allowed to unseal the plaintext data; and returning the plaintext data to the calling program only if the MAC value in the bit string is equal to the generated MAC value and if the identifier of the calling program is included as one of the multiple target program identifiers in the plaintext data.

63. A method as recited in claim 62, wherein the identifier of the calling program comprises a digest of the calling program generated using a cryptographic hash function.

64. A method as recited in claim 62, wherein the generating the MAC value comprises generating the MAC value using a first part of the symmetric key, and wherein decrypting the ciphertext in the bit string comprises decrypting the ciphertext in the bit string using a second part of the symmetric key.

65. A computing device comprising:
a processor; and a memory, coupled to the processor, storing a plurality of instructions that when executed by the processor cause the processor to:

receive, from a calling program, a bit string including ciphertext and a message authentication code (MAC) value;

decrypt the ciphertext in the bit string using a symmetric kell to generate plaintext data;

generate a message authentication code (MAC) value for at least a portion of the plaintext data;

check whether the MAC value in the bit string is equal to the generated MAC value;

check whether an identifier of the calling program is included as one of multiple target program identifiers in the plaintext data, the multiple target program identifiers identifying multiple target programs that are allowed to unseal the plaintext data; and return the plaintext data to the calling program only if the MAC value in the bit string is equal to the generated MAC value and if the identifier of the calling program is included as one of the multiple target program identifiers in the plaintext data.

66. A computing device as recited in claim 65, wherein the identifier of the calling program comprises a digest of the calling program generated using a cryptographic hash function.

67. A computing device as recited in claim 65, wherein to generate the MAC value is to generate the MAC value using a first part of the symmetric key, and wherein to decrypt the ciphertext in the bit string is to decrypt the ciphertext in the bit string using a second part of the symmetric key.

68. A method, implemented in a computing device, the method comprising:
receiving a bit string from a calling program;

checking an identifier of the calling program to determine whether the calling program is allowed to access data encrypted in ciphertext of the bit string, the checking determining that the calling program is allowed to access the data if the identifier of the calling program is included as one of multiple target program identifiers in the ciphertext;

verifying the integrity of the data;

decrypting the data using a symmetric key; and returning the data to the calling program only if the calling program is allowed to access the data and if the integrity of the data is successfully verified.

69. One or more computer storage media having stored thereon a plurality of instructions that, when executed by one or more processors of a computing device, causes the one or more processors to:

receive a bit string from a calling program;

check an identifier of the calling program to determine whether the calling program is allowed to access data encrypted in ciphertext of the bit string, wherein to check the identifier is to determine that the calling program is allowed to access the data if the identifier of the calling program is included as one of multiple target program identifiers in the ciphertext;

verify the integrity of the data;

decrypt the data using a symmetric key; and return the data to the calling program only if the calling program is allowed to access the data and if the integrity of the data is successfully verified.

70. A computing device comprising:

a processor; and a memory, coupled to the processor, storing a plurality of instructions that when executed by the processor cause the processor to:

receive a bit string from a calling program;

check an identifier of the calling program to determine whether the calling program is allowed to access data encrypted in ciphertext of the bit string, wherein to check the identifier is to determine that the calling program is allowed to access the data if the identifier of the calling program is included as one of multiple target program identifiers in the ciphertext;

verify the integrity of the data;

decrypt the data using a symmetric key; and return the data to the calling program only if the calling program is allowed to access the data and if the integrity of the data is successfully verified.