JP2012039390A - Flexible correction of authentication rule - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a computing technology capable of securely correcting one rule element of complicated authentication rules in a reliable environment.SOLUTION: A security LSI with tamper resistance includes a nonvolatile memory, a volatile memory, a monotone counter region, a configuration register storing storage information related to a platform status, and an encryption section. The security LSI also includes an object rule correction ticket issue part that corrects a rule included in an object received from the outside. Only when the received object includes the same encryption hash as a stored encryption hash, the ticket issue part is activated. Therefore, a rule correction is performed by a method for which origin of the correction can be sufficiently checked.

Description

  The Trusted Computing Group (TCG) was created to protect electronic devices such as personal computers and mobile phones while maintaining openness and flexibility. The Trusted Computing Group focuses on standard development, which is an important aspect of the overall security solution. In particular, “TPM Main Part 1 Design Principals, Specification Version 1.”, which is also published as ISO / IEC11889. 2, Revision 103 ", working on a hardware computer chip called Trusted Platform Module (TPM). This trusted platform module is in particular a hardware device that provides secure storage of information by encryption, a series of encryption processes executed in a secure environment, and a series of integrity metrics.

  One feature of this TPM is that many of the commands require authentication. This authentication is defined as the only factor that needs to be kept secret, and a common way to generate this value is to make this value a hash of the password entered by the user.

  Regarding the functionality of the TPM, various improvement proposals have been proposed in a paper “Extending Secure Execution Environments beyond the TPM” by Talha Tariq. In this paper, flexible authentication in conjunction with a smart card is proposed as a method of replacing the single authentication value described above with a cumulative hash value representing multiple authentication rule factors such as user password, TPM status, and third party certification authority. Has been. It is stated that this hash value is generated in the smart card paired with the TPM, and those skilled in the art will, in another form, handle this flexible authentication rule in an enhanced TPM or trusted It will be appreciated that it may be moved into a suitable processing environment. This processing environment is provided by a CPU in the system having a software TPM implemented in a reliable processing area.

  Those skilled in the art will also recognize that these flexible authentication rule factors need to be editable. The key used to sign the authentication data can change. Of course, it is better to change the user password. Dependency on device status may change.

  The existing TPM specification has an API called TPM_ChangeAuth that allows the owner of the key to change its authentication value. However, when flexible authentication is used, a number of problems arise. For example, in TPM_ChangeAuth, it is necessary to prove that you have access authority to the object before changing the authentication value, so if the key of the third-party certification authority is lost or invalidated, access authority to the object will be increased. It cannot be obtained and changes are never allowed. The existing specification does not describe how to avoid the problem when the certification is lost. Furthermore, when TPM_ChangeAuth operates in flexible authentication, the ability to completely change the authentication rule may not be preferable from the TPM owner side. For example, if both the TPM owner and the object owner have an authentication rule factor associated with the object, the flexible authentication value is ambiguous with no evidence of which specific rule factor has changed. Because of the hash value, the object owner will be able to unintentionally or intentionally overwrite the TPM owner's rule factor. The Tariq paper does not describe anything about how to solve these issues.

  US Patent Application Publication No. 2010/115625 by Proudler describes additional TPM enhancements that explain how outsiders can authenticate TPM operations and data migration to other TPMs. However, nothing is described about how the client device changes its own rules and how to change the rules before migrating to another TPM.

  U.S. Pat. No. 5,933,498 to Schneck et al. Seeks to address the challenge of updating authentication rules by providing that the server retains the original rule list and distributes copies to multiple client devices. Client devices can also distribute rules with their own rules added, but how to change their rules, and how to change rules before further delivery to other devices Nothing is stated about whether or not. Further, although each individual rule is independent, it is not described how to handle the case where the completed rule is ambiguous combining all the individual rules.

  US Pat. No. 7,363,650 by Moronici et al. Also updates authentication rules by specifying how to maintain a delta list of policy changes and how to apply the deltas to client devices Is not addressing how client devices change their own rules, or how to change rules before further delivery to other devices. . Again, each individual rule is independent, but it does not describe how to handle the case where the completed rule is ambiguous with all the individual rules combined.

  In the article by Sarmenta et al. “Virtual Monotonic Counters and Count-Limited Objects using a TPM with a Trusted OS”, how information is represented in a Merkle hash tree and how it changes in a trusted environment Then, the problem of updating the cumulative hash value is addressed by defining whether the tree root is transmitted. However, it does not describe how to authenticate a particular leaf change, nor does it teach how to represent data other than the virtual monotonic counter in the tree.

  Also, in a reliable system, it is important to be able to audit the origin of the data. For example, when changing one rule factor in a complex rule represented by an ambiguous value, the change and evidence that only that change has actually been made are required. Therefore, there is a need for a method for safely and reliably updating an ambiguous value representing a flexible authentication rule based on an authenticated change request for one value representing a rule factor in the flexible authentication rule.

  Therefore, the present application proposes a method, system, and computer program product that implements a reliable update that updates one factor that represents an individual rule factor in a synthetic hash that represents a flexible authentication rule.

  Broadly speaking, the present invention relates to the technical field of secure computing.

  In one aspect of the present invention, there is provided a technology that allows one rule factor to be changed safely in a reliable environment from among complicated authentication rules so that it can be reliably proved that a change and only a change has occurred. To do. Thereby, the origin of an authentication rule can be guaranteed.

  Other aspects and advantages of the present invention will become apparent from the following detailed description, taken in conjunction with the drawings, illustrating by way of example the principles of the invention.

A better understanding of the present invention can be obtained by considering the following detailed description of the preferred embodiments in conjunction with the following drawings.
FIG. 1 shows a TPM v1.2 mounting system according to the prior art in which a TPM is mounted as a discrete chip. FIG. 2 shows a TPM v1.2 onboard system according to the prior art in which the TPM is implemented in a reliable execution environment presented by the processor. FIG. 3 is a system corresponding to the flexible authentication according to the present invention based on the prior art of FIG. FIG. 4 is a system corresponding to the flexible authentication according to the present invention based on the prior art of FIG. FIG. 5 is an example of a flexible authentication rule according to the present invention. FIG. 6 is an example of an event flow for calculating a flexible authentication rule according to the present invention. FIG. 7 shows a key structure according to the prior art. FIG. 8 shows a key structure corresponding to flexible authentication according to the present invention. FIG. 9 shows a rule factor correction permission ticket according to the present invention. FIG. 10A is an eTPM v1.2 onboard system featuring a smart card reader according to the present invention. FIG. 10B shows a ticket issuing method of the rule factor correction permission unit according to the present invention. FIG. 11 shows another preferred embodiment of the rule factor correction permission unit according to the present invention. FIG. 12 shows a flowchart for issuing a rule correction ticket according to the present invention. FIG. 13 shows an event flow for generating a rule correction ticket from a rule factor correction permission ticket according to the present invention. FIG. 14 shows an event flow for correcting a key using a rule correction ticket according to the present invention.

  Hereinafter, preferred embodiments of the present invention will be described.

  FIG. 1 shows a TPM v1.2 mounting system according to the prior art, in which the TPM is mounted as a discrete chip. The TPM v1.2 onboard system 100 includes a central processing unit CPU 102 and a trusted platform module TPM 104 defined by a Trusted Computing Group. Next, there are general hardware resources 116 such as a RAM, a ROM, and a hard disk, and a basic input / output system BIOS 106 is provided. An operating system 108 exists at the upper level. As an interface to the TPM 104, there is a trusted software stack TSS110 defined by the Trusted Computing Group. On this system, one or more applications 112 aware of the TPM that interact with each other via the TSS 110 that exchanges information with the TPM 104 may be executed. Further, the other application 114 that does not use the TSS 110 may or may not be executed.

  FIG. 2 shows a TPM v1.2 onboard system according to the prior art in which the TPM is implemented in a reliable execution environment presented by the processor. The TPM v1.2 installation system 200 includes a central processing unit CPU 202 corresponding to a reliable execution environment such as ARM TrustZone. Thereby, the CPU can establish two different modes in which the left side is the normal mode and the right side is the secure mode, and the boundary 206 exists between them. Due to this boundary, a process being executed in one mode cannot directly access the process or memory in the other mode. First, secure mode provides a secure hardware resource 208. This hardware resource is, in a preferred form, provided by a SoC (system on chip) solution. Next, there is a secure basic input / output system BIOS 210, and a secure operation system 212 is present above it. In this secure OS, software (SW) TPM 204 protected by the secure OS is executed. Also, other secure applications 214 may or may not be executed. In the preferred form, secure mode disables any debugging features. This means that software running on a secure OS is protected from unauthorized access from outside the device. One or more resources in the secure mode may be dynamically loaded from the resources in the normal mode. These resources are preferably encrypted when stored in normal mode and decrypted when loaded in secure mode.

  The normal mode is similar to the system of FIG. First, there are general hardware resources 116 such as a RAM, a ROM, and a hard disk, and a basic input / output system BIOS 106 is provided. An operating system 108 exists at the upper level. As an interface to the TPM 204, there is a trusted software stack TSS110 defined by the Trusted Computing Group. On this system, one or more applications 112 that are aware of the TPM and interact with each other via the TSS 110 that exchanges information with the TPM 204 may be executed. Further, the other application 114 that does not use the TSS 110 may or may not be executed.

  FIG. 3 is an eTPM, and the leading “e” represents for extended. This eTPM corresponds to the flexible authentication according to the present invention and is based on the prior art of FIG. In the TPM 104, there are a non-volatile RAM, NVRAM 300 for storing data for a long time, a volatile RAM for storing short-term data, a VRAM 302, and a monotonic counter for storing a special counter value that is incremented and never decremented. 304, a PCR 312, a platform configuration register, and a special VRAM storage unit that holds platform configuration information. Next, there is a core TPM function 308 and an added flexible authentication rule evaluation and management function 310 according to the present invention. The flexible authentication rule evaluation and management function includes a method for verifying and evaluating each term of each rule factor, and a result of accumulating all the evaluated terms using the synthetic hash extension unit 320. This method includes a method of combining the rule factors and the intermediate results so far. In a preferred form, the extension unit 320 uses a synthetic hash extension technique described by TCG. In addition, there are two additional support components for the flexible authentication rule evaluation and management function 310. One is a ticket issuing unit 322, which generates a ticket permitting the key to modify the flexible authentication rule for the key. The other is a ticket verification unit 324 that verifies the format and signature of a ticket that permits the change of each flexible authentication rule factor. Finally, there are encryption algorithms SHA-1 314, RSA 316 and HMAC 318. These encryption algorithms are currently only those required by the TPM, but other algorithms such as SHA256, SHA384 and SHA512 or ECC may be used instead without departing from the invention. Those skilled in the art will also recognize that ROM 306 may be reprogrammed by an authorized person using techniques well known in the art.

  FIG. 4 is an eTPM, and the leading “e” represents an extended (for tended). This eTPM corresponds to the flexible authentication according to the present invention and is based on the prior art of FIG. The SW TPM 204 stores a non-volatile RAM for storing data for a long period of time, NVRAM 300, a volatile RAM for storing data for a short period of time, a VRAM 302, and a monotonic counter for storing a special counter value that is incremented and never decremented. There is a counter 304, a PCR 312, a platform configuration register, and a special VRAM storage unit that holds platform configuration information. Next, the code storage area 400 exists, and stores software that realizes the core TPM function 308 and the added flexible authentication rule evaluation and management function 310 according to the present invention. The flexible authentication rule evaluation and management function includes a method for verifying and evaluating each term of each rule factor, and a result of accumulating all the evaluated terms using the synthetic hash extension unit 320. This method includes a method of combining the rule factors and the intermediate results so far. In a preferred form, the extension unit 320 uses a synthetic hash extension technique described by TCG. In addition, there are two additional support components for the flexible authentication rule evaluation and management function 310. One is a ticket issuing unit 322, which generates a ticket permitting the key to modify the flexible authentication rule for the key. The other is a ticket verification unit 324 that verifies the format and signature of a ticket that permits the change of each flexible authentication rule factor. Finally, there are encryption algorithms SHA-1 314, RSA 316 and HMAC 318. These encryption algorithms are currently only those required by the TPM, but other algorithms such as SHA256, SHA384 and SHA512 or ECC may be used instead without departing from the invention. Also, those skilled in the art may realize that the code storage unit 400 may be realized in various ways, such as when placed in the ROM or when loading code from an external storage unit using an appropriate technique. You will understand.

  FIG. 5 is a data display example of the flexible authentication rule according to the present invention. The flexible authentication rule 500 can be viewed as a tree of individual rule factors 504, 508, 512, each individual rule factor having a specific value. The expected PCR state is 0x34 ... 56 506, the expected signed state is 0x56 ... 78 510, and the expected NV RAM is 0x78 ... 9A 514. In a preferred form, the predicted signed state rule factor 508 is generated by a fingerprint reader. In addition to these rule factors, other rule factors such as a prediction ID and a prediction password acquired from the ID card may be added.

  Further, the flexible authentication rule itself has a value of 0x12... 34 502, and this value represents a combination of all individual rule factors. The arrow in the drawing first calculates the rule factor 512 at the bottom and expands it to the initial value of the flexible authentication rule, that is, 0x00... 000, and evaluates the second rule factor 508 so far. And the third rule factor 504 is evaluated and shown to extend within the previous results. The final result is the value 502 of the flexible authentication rule 500. As will be described later with reference to FIG. 8, this final value may be associated with the TPM key to notify the eTPM that the flexible authentication rule needs to be verified before allowing access to the associated key. In a preferred form, these values are calculated using a SHA-1 hash. However, those skilled in the art will recognize that other hash algorithms may be used instead. The rule factor may represent a predicted platform configuration register in the TPM, that is, a predicted PCR value 504, or a signed predicted value 508 from a third party, or a predicted value 512 in NVRAM.

  FIG. 6 shows an example of an event flow for calculating a flexible authentication rule according to the present invention. In order to calculate a rule, three main elements are required. First, there is a TSS 110 that processes a request from an application that evaluates a rule, a flexible authentication rule function 310 in the TPM, and finally a rule hash value storage unit 600 that is placed in the VRAM 302 on the TPM. For simplicity, the command routine from the TSS 110 to the flexible authentication rule function 310 via the TPM interface is not shown. This rule hash is a variable session with respect to the flexible authentication rule session that records the current composite hash in which all verified rule factors are accumulated. Initially, the TSS requests 602 to start a new flexible authentication rule session with the TPMEx_StartRuleSession API. As a result, the rule hash value is initialized 604 to 0x00... 00 606. Next, the first rule factor located at the bottom of the tree of FIG. 5 is executed by calling 608 TMPEx_RuleTestNV API requesting verification that the value of the memory location of NVRAM 300, Cell_1, is less than 10. The flexible authentication rule evaluation unit 310 in the TPM first verifies that the value stored in Cell_1 is actually smaller than 610, and if it is considered smaller than 10, the SHA-1 hash of the argument of the TPMEx_RuleTestNV API is determined. A value representative of the rule factor is formed by determining 612 the value. In this example, the SHA-1 hash has a value of 0x78... 9A, which matches the predicted value described in 514 of FIG. This value is then expanded 612 into the rule hash. The operation of extending a value into a hash is a process described in the TPM specification. According to this, a hash obtained by concatenating the current hash and the value to be extended is calculated, and the result is added to a new hash. Is used to update the hash. For the sake of illustration, the new rule hash after expansion is 0xFE... DC 616.

  Next, the second rule factor, located in the middle of the tree of FIG. 5, is executed by calling 618 TPMEx_RuleTestSign API that requires verification that one particular data has a valid signature attached. The flexible authentication rule evaluator in the TPM first verifies that the data is actually signed correctly 620, and if the data is considered to be correctly signed, the SHA-1 hash value of the argument of the TPMEx_RuleTestSign API is used. By obtaining 622, a value representative of the rule factor is formed. In this example, the SHA-1 hash has a value of 0x56... 78, which matches the predicted value described in 510 of FIG. This value is then extended 624 into the rule hash. To illustrate, the new rule hash after expansion is 0xDC ... BA 626.

  Next, the third rule factor located at the top of the tree of FIG. 5 is executed by calling 628 TMPEx_RuleTestPCR API that requires verification that the current subset of PCR values matches the passed value. The The in-TPM flexible authentication rule evaluator first verifies that the current PCR value is actually equal to the passed value 630, and if it is considered equal, determines the value of the SHA-1 hash of the argument of the TPMEx_RuleTestPCR API. By determining 632, a value representative of the rule factor is formed. In this example, the SHA-1 hash has a value of 0x34... 56, which matches the predicted value described in 506 in FIG. This value is then expanded 634 into the rule hash. To illustrate, the new rule hash after expansion is 0x12... 34 636. When the flexible authentication rule 500 of FIG. 5 is confirmed, it is 0x12. Therefore, an object in which the flexible authentication rule is set to this value may be used immediately in the TPM.

  FIG. 7 shows a key structure according to the prior art described in the TPM specification. There are many fields in the TPM key structure 700. First, 1.1.0.0. There is a version number label ver 702 with a value of, followed by a keyUsage 704 that indicates how the key can be used. KeyFlags 706 indicates control options that can be set for each key, and authUsageData 708 indicates how to use authentication data for the key. algorithmParms 710 is a structure that indicates which encryption algorithms and signature algorithms can be used with this key, and both pcrInfoSize 712 and pcrInfo 714 define a PCR value set that must be present before the key is used. . The pubKey 716 holds the public part of the key. Finally, both encDataSize 718 and encData 720 represent the secret part of the key.

  FIG. 8 shows a key structure corresponding to flexible authentication according to the present invention. The TPM flexible authentication key structure 800 has many fields, most of which are the same as shown in FIG. First, 1.3.0.0. There is a version number label ver 702 having the value of Note that the version number has been incremented each time the key structure is different from that described in the prior art. Next is a keyUsage 704 that indicates how the key can be used. KeyFlags 706 indicates control options that can be set for each key, and authUsageData 708 indicates how to use authentication data for the key. Here, there are an additional flag indicating whether to use faRuleData 802 and another additional flag indicating whether faRuleData 802 can be modified. Next, algorithmParms 710 is a structure that indicates which encryption algorithm and which signature algorithm can be used with this key. Both pcrInfoSize 712 and pcrInfo 714 must have a PCR value set before the key is used. Is defined. faRuleData 802 defines a flexible authentication rule hash that must be present before the key is used. The pubKey 716 holds the public part of the key. Finally, both encDataSize 718 and encData 720 represent the secret part of the key.

  In order to load the TPM flexible authentication key structure 800 into the TPM, a rule hash 600 stored in the TPM must first be generated by executing an event sequence similar to that shown in FIG. Next, the TSS 110 calls the existing TPM_LoadKey2 API with a command from the application 112 that is aware of the TPM. The operation of this command according to the prior art is detailed in the TPM specification. Furthermore, if there is a flag set in authUsageData 708 indicating that faRuleData 802 needs to be checked, the TPM compares faRuleData 802 of the passed key with the value stored in rule hash 600, and if they do not match, The TPM_LoadKey2 API must return an appropriate error code indicating that the key cannot be loaded.

  Above we have detailed how keys with flexible authentication rules are defined and loaded. Next, a method for changing the flexible authentication rule will be described in detail.

  FIG. 9 shows a rule factor correction permission ticket according to the present invention. In order to modify one factor in the flexible authentication rule, it includes an unmodified rule factor, a modified rule factor, a key handle for correction, and an ID indicating the type of rule factor to be changed. The request must be signed by the rule factor correction permission unit to generate the TPM rule factor correction ticket 900. The fields of this structure are as follows: First, the SHA-1 hash represents the old rule factor 902 in the flexible authentication that needs to be replaced. This factor corresponds to 506, 510, or 514 in FIG. Next, another SHA-1 represents a new rule factor 904 in the flexible authentication that will replace the old factor 902. Then, an ID representing the factor type 906 to be replaced, a TPM factor authentication key structure 908 as shown in FIG. 8, an encrypted digest 910 of the field so far, and a signature key 912 that signed the digest, There is. In a preferred form, this signature key has a keyUsage field 704 set to a value of TPM_KEY_FACHANGE indicating that it is a signature key that is allowed to sign such types of tickets. As will be described later, when using a ticket, both the old rule factor 902 and / or the TPM factor authentication key 908 have no restrictions on the old rule factor 902 and / or the TPM factor authentication key 908. NULL may be used.

  FIG. 10A shows an eTPM-equipped system according to the present invention in which the TPM is mounted as a discrete chip and the rule factor correction permission unit is resident on the smart card. The eTPM mounting system 100 includes a central processing unit CPU 102 and a trusted platform module TPM 104 defined by the Trusted Computing Group. Next, there are general hardware resources 116 such as a RAM, a ROM, and a hard disk, and a basic input / output system BIOS 106 is provided. An operating system 108 exists at the upper level. As an interface to the TPM 104, there is a trusted software stack TSS110 defined by the Trusted Computing Group. On this system, one or more applications 112 aware of the TPM that interact with each other via the TSS 110 that exchanges information with the TPM 104 may be executed. Further, the other application 114 that does not use the TSS 110 may or may not be executed. In addition, there is a smart card reader 1004 attached to the system 100 via an interface such as USB or other connection methods known in the art. A smart card 1002 is in the smart card reader 1004, and a rule factor correction permission application 1000 is on the smart card 1002. In a preferred form, the smart card 1002 and the rule factor modification permission application 1000 are compliant with the standards defined in Oracle's Java Card 3.0 specification. A person skilled in the art can trust the reliability of the system 100 as long as the system supports the rule factor correction permission application 1000 through various technologies or on a remote server. It will be understood that it may be implemented in a certain execution environment.

  FIG. 10B shows a ticket issuing method of the rule factor correction permission unit according to the present invention. In order to generate a rule factor correction permission ticket, three elements must be exchanged. First, the TSS 110 makes a request to the rule factor correction permission unit 1000, and the rule factor correction permission unit signs the permission right using the TPM 104. In a preferred embodiment, the rule factor correction permission unit 1000 is placed on a smart card 1002 connected to the system 100. First, the TSS 110 searches 1052 for the key whose rule factor is to be updated and the current value of the rule factor. In the preferred form, there is a list associated with the keys that represents the individual rule factors for each key. In another preferred form, the application 112 aware of the TPM that calls the TSS 110 passes the rule factor calculated in advance as an argument. The TSS then calculates 1054 a new rule factor. This value may be calculated by the TSS itself. Alternatively, in another preferred form, the application 112 aware of the TPM that calls the TSS 110 passes a new rule factor calculated in advance as an argument. Here, when the old rule factor, the new rule factor, the rule factor type, and the target key are prepared, the TSS 110 requests the rule factor correction permission unit to approve the change 1056. First, the rule factor correction permission unit 1000 verifies that the flexible authentication rule can be changed by the passed key by confirming that the keyUsage 704 field is an appropriate value, and the rule factor type is permitted to be changed. 1060 to confirm that it has been done. For example, the local rule factor correction permitting unit may only permit issuing a ticket for changing the NVRAM check factor, but the remote rule factor correcting permitting unit may issue a ticket that can change any factor type. Further confirmation is then performed 1062. In a preferred embodiment, only the signature key may be changed by the local rule factor correction permission unit. If all these checks are successful, the rule factor correction permission unit 1000 loads 1064 the correction permission key into the TPM 104. Note that this loading itself may request a flexible authentication rule to be applied as shown in FIG. If the key is loaded successfully, the rule factor modification permission unit creates 1066 a ticket structure and requests 1068 to generate a signed digest of the structure. The ticket is then returned 1070 to the TSS for further processing.

  FIG. 11 shows another preferred embodiment of the rule factor correction permission unit according to the present invention. Similar to FIG. 10B, three elements need to be exchanged in order to generate a rule factor correction permission ticket. First, the TSS 110 makes a request to the rule factor correction permission unit 1000, and the rule factor correction permission unit signs the permission right using the TPM 104. In a preferred embodiment, the rule factor correction permission unit 1000 is placed on a smart card 1002 connected to the system 100. First, the TSS 110 retrieves 1102 a key for which a rule factor is to be updated and a current parameter and a new parameter of the rule factor that is desired to be changed. In a preferred form, for each key there is a list associated with keys representing individual rule factors. In another preferred form, the application 112 aware of the TPM that calls the TSS 110 passes the rule factor parameter as an argument. Next, the TSS 110 requests the rule factor correction permission unit to approve the change by passing the old rule factor parameter and the new rule factor parameter searched in 1102 1104. In this figure, since the rule factor to be corrected is the rule factor 508 in FIG. 5, the old data, the new data, and the key used for the signature are passed. First, the rule factor correction permission unit 1000 calculates 1106 an old rule factor and a new rule factor based on the passed parameters. Similar to FIG. 10B, the rule factor correction permission unit 1000 next verifies that the flexible authentication rule can be changed by the passed key by confirming that the key Usage 704 field is an appropriate value 1108, and Confirm 1110 that the rule factor type is permitted to be changed. For example, the local rule factor correction permitting unit may only permit issuing a ticket for changing the NVRAM check factor, but the remote rule factor correcting permitting unit may issue a ticket that can change any factor type. Next, further confirmation is performed 1112. Compared to step 1062 of FIG. 10B, the further confirmation 1112 is more detailed because their individual elements are passed rather than the hash values of the old and new rule factors. For example, the old key A may be verified to confirm that it has become invalid, or the new key B may be verified to confirm that it has not been invalidated. Alternatively, message A and message B may be verified to confirm that they are the same and are simply the key being modified. Since the keys A and B are only used by the rule factor correction permission unit 1000 that verifies the signature, in the preferred embodiment, these keys are designated as X. 509 certificate. In other preferred embodiments, these keys are placed in the TPM. If all these checks are successful, the rule factor correction permission unit 1000 loads the modification permission key into the TPM 104 1114. Note that this loading itself may request a flexible authentication rule to be applied as shown in FIG. If the key is loaded successfully, the rule factor modification permitting unit creates 1116 a ticket structure and requests 1118 to generate a signed digest of the structure. The ticket is then returned 1120 to the TSS for further processing.

  FIG. 12 shows a rule correction ticket according to the present invention. In order to authenticate the modification to the completed flexible authentication rule, the TPM must issue a ticket that can clearly state that the TPM rule factor modification ticket 900 is permitted to change the key. The fields in the rule correction ticket structure 1200 are as follows. First, the SHA-1 hash includes the old flexible authentication rule value 1202 that needs to be replaced. This factor corresponds to 502 in FIG. Next, another SHA-1 includes a new flexible authentication rule value 1204 that will replace the old rule value 1202. Then, the TPM factor authentication key structure 1206 as shown in FIG. 8 that has the flexible authentication rule value changed from the value of 1202 to the value of 1204, and finally, the HMAC digest of the field of the structure There is 1208. This HMAC is calculated according to RFC 2104 using an appropriate secret key such as a tpmProof value in TPM_PERMANENT_DATA defined by the TPM.

  FIG. 13 shows an event flow for generating a rule correction ticket from a rule factor correction permission ticket according to the present invention. In order to verify the rules, three main elements are required. First, a TSS 110 that processes a request from an application that verifies a rule, then a flexible authentication (FA) rule function 310 in the TPM, and finally a pair value storage unit of a rule hash placed in the VRAM 302 on the TPM There is 1300. This event sequence is similar to that for calculating the flexible authentication rule as shown in FIG. However, when this ticket is generated instead of one rule hash 600, a rule hash pair 1300 is required to calculate both an old rule hash and a new rule hash. First, the TPMEx_StartRuleVerificationSession API is called 1302 and both rule hashes are initialized to a value 1306 of 0x00. Next, the arrangement of rule factors as shown in FIG. 5 is applied. In FIG. 6, each rule factor is verified before being expanded into the hash, but the key point here is that the rule factor is not verified. The TPMEx_RuleVerifyNV API is called 1308, and without examining the specified NVRAM location, the flexible authentication (FA) rule evaluator 310 forms a value representative of the rule factor by obtaining 1310 the value of the SHA-1 hash of the argument of the TPMEx_RuleVerifyNV API. To do. In this example, the SHA-1 hash has a value of 0x78... 9A, which matches the predicted value described in 514 of FIG. This value is then extended 1312 to both rule hash pairs. The operation of extending a value into a hash is a process described in the TPM specification. According to this, a hash obtained by concatenating the current hash and the value to be extended is calculated, and the result is added to a new hash. Is used to update the hash. To illustrate, the new rule hash pair after expansion is 0xFE... DC 616.

  Next, the second rule factor located in the middle of the tree of FIG. 5 is executed by calling 1316 the TPMEx_RuleVerifySign API. Since this is the rule factor that issued the rule factor correction permission ticket according to FIG. 10A, this ticket is also passed to the flexible authentication (FA) rule evaluation unit 310. This evaluator first verifies that the rule factor modification permission ticket is correctly signed and that the factorID indicates the current rule factor type 1318, and sets the value of the SHA-1 hash of the argument. Seeking 1320. This SHA-1 hash has a value of 0x56... 78 in this example, and matches the predicted value described in 510 of FIG. Next, the calculated hash is compared 1322 with the hash stored in the oldFactor field of the rule factor correction permission ticket. If they are equal, the ticket is a valid ticket to modify this term, so the oldFactor 902 and newFactor 904 of this ticket are each expanded 1324 to each field in the rule hash pair. To illustrate, the new rule hash pair after expansion is 0xDC ... BA (old value) and 0xCD ... BA (new value) 1326. If the old factor value 902 of the rule factor correction permission ticket is NULL, the verification of the old value in 1322 is omitted, and if the factor ID 906 is NULL, the verification of the ID in 1318 is omitted.

  Next, the third rule factor located at the top of the tree in FIG. 5 is to call TMPEx_RuleVerifyPCR API 1328, and without examining the specified PCR, the flexible authentication (FA) rule evaluator 310 determines the argument of the TPMEx_RuleVerifyPCR API. A value representative of the rule factor is formed by determining the value of the SHA-1 hash. In this example, the SHA-1 hash has a value of 0x34... 56, which matches the predicted value described in 506 in FIG. This value is then expanded 1332 into the rule hash pair. For the sake of illustration, the expanded rule hash pair is an old hash value of 0x12... 34 and a new hash value 1334 of 0x21.

  At this point, since the old flexible authentication rule value and the new flexible authentication rule value have been calculated, for the first time, the client TSS uses the TPMEx_RequestRuleModificationTicket API and generates a key for creating a ticket and a rule factor correction permission ticket. Passing can request 1336 to create a rule correction ticket. If the faRuleData field 802 of the passed key is equal to the old value of the rule hash pair 1300, the rule factor correction permission ticket is correctly signed, and 1338 if the key field 908 of the rule factor correction permission ticket is equal to the passed key. The rule correction ticket is issued 1340 and the ticket is returned to the TSS 110.

  FIG. 14 shows an event flow for correcting a key using a rule correction ticket according to the present invention. In order to perform the correction, two main elements are required. First, there is a TSS 110 that handles requests from applications that modify keys, and a flexible authentication (FA) rule function 310 in the TPM that handles the actual changes to the structure. Since the keys in the TPM are encrypted by their parent key, it is necessary to first establish an OSAP session using the parent key 1400 and obtain the authority to decrypt the data of the target child key. . When a session is established according to the prior art implemented in the TPM core 308, it is possible to make actual changes to the data. The TSS makes a request 1402 to change the flexible authentication by passing the target key, the OSAP session handle, and the rule correction ticket generated as shown in FIG. First, the flexible authentication (FA) rule evaluator verifies 1404 the OSAP session as described in the prior art. Then, the format 1406 of the key structure and the signature 1408 of the rule correction ticket are verified, and the match between the key field 1206 of the rule correction ticket and the passed key 800 is compared for each byte, and oldFARule 1204 is the key's faRuleData 802. Verify that the rule modification ticket is valid 1410 for the passed key. If these two match, the private key data stored in encData 720 is decrypted with the parent key 1410, and the resulting structure is verified, and this structure is described in the prior art. As such, it is guaranteed to be a valid TPM_STORE_ASYMKEY or TPM_MIGRATE_ASYMKEY. The faRuleData 802 in the passed key is set 1414 in the newFARule field 1204 of the rule correction ticket 1208. Then, the hash value stored in the pubDataDigest of the decrypted encData 720 is recalculated to reflect the change in the flexible authentication rule. Finally, encData 720 is re-encrypted with the parent key 1418 and a successful operation is returned 1420 to the caller.

  One skilled in the art may combine the technique of FIG. 14 with the technique described in the TPM specification for key movements that allow the key to change key policies each time the key is moved. You will understand.

  Although the present invention has been described based on the above embodiments, the present invention is obviously not limited to such embodiments. The following cases are also included in the present invention.

  (1) Each of the above devices is specifically a computer system including a microprocessor, a ROM, a RAM, a hard disk unit, a display unit, a keyboard, a mouse, and the like. A computer program is stored in the RAM or the hard disk unit. Each device achieves its functions by the microprocessor operating according to the computer program. Here, the computer program is configured by combining a plurality of instruction codes indicating instructions for the computer.

  (2) A part or all of the constituent elements constituting each of the above-described devices may be configured by one system LSI (Large Scale Integration). The system LSI is an ultra-multifunctional LSI manufactured by integrating a plurality of components on a single chip, and specifically, a computer system including a microprocessor, ROM, RAM, and the like. . A computer program is stored in the RAM. The system LSI achieves its functions by the microprocessor operating according to the computer program.

  Furthermore, each unit of the components that make up each device may be made as a separate individual chip or as a single chip including some or all.

  Furthermore, although an LSI is described here, a designated IC, LSI, super LSI, or ultra LSI may be used depending on the degree of integration.

  Furthermore, the means for circuit integration is not limited to LSI, and a dedicated circuit or a general-purpose processor can also be used. It is also possible to use a programmable field program gate array (FPGA) after the LSI has been manufactured, and a reconfigurable processor that can reconfigure circuit cell connections and settings within the LSI. It is.

  Furthermore, if integrated circuit technology that replaces LSI emerges through advances in semiconductor technology or other derived technology, the technology can of course be used to achieve component integration. Application of biotechnology is expected.

  (3) Part or all of the constituent elements constituting each of the above devices may be configured from an IC card that can be attached to and detached from each device or a single module. The IC card or module is a computer system that includes a microprocessor, ROM, RAM, and the like. The IC card or the module may be included in the above super multifunctional LSI. The IC card or the module achieves its functions by the microprocessor operating according to the computer program. This IC card or this module may have tamper resistance.

  (4) The present invention may be a computer program that implements the method described above by a computer, or may be a digital signal such as a computer program.

  The present invention also relates to a computer-readable recording medium capable of reading a computer program or a digital signal, such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray Disc), It may be recorded in a semiconductor memory or the like. Further, it may be a digital signal recorded on these recording media.

  In the present invention, a computer program or a digital signal may be transmitted via an electric communication line, a wireless or wired communication line, a network represented by the Internet, a data broadcast, or the like.

  The present invention may also be a computer system including a microprocessor and a memory, the memory storing the computer program, and the microprocessor operating according to the computer program.

  Further, the program or digital signal may be recorded on a recording medium and transferred, or the program or digital signal may be transferred via a network or the like and executed by another independent computer system.

  (5) Those skilled in the art will readily appreciate that there can be many variations of the described embodiments that do not depart in principle from the teachings and advantages inherent in the present invention. Further, any combination of the above modifications and embodiments is included within the scope of the present invention.

Claims (15)

An information processing apparatus including a tamper-resistant security LSI,
The LSI is
A non-volatile memory area for storing data that needs to be available even after the LSI is rebooted;
A volatile memory area for storing data necessary only during one boot cycle of the LSI;
A monotonic counter area for storing a plurality of non-volatile counters that can only be incremented;
A platform configuration register (PCR) area that stores accumulated information about the platform state;
An encryption unit that generates a plurality of encryption keys, encrypts the data, decrypts the data, generates a plurality of encryption signatures, and verifies the plurality of encryption signatures;
An external interface for transmitting information to the outside of the LSI and receiving information from the outside of the LSI;
A first storage area in the volatile memory area for storing a first cryptographic hash;
A second storage area in the volatile memory area for storing a second cryptographic hash;
Received, including the representative value of the object received via the external interface, the first cryptographic hash, the second cryptographic hash, and the cryptographic digest of the representative value and the two cryptographic hashes An object rule correction ticket issuing unit for issuing an object rule correction ticket for correcting a rule included in the object;
An object rule modification ticket issuance control unit that enables the ticket issuing unit only when the received object includes an encryption hash equal to the first encryption hash stored in the first storage area; An information processing apparatus comprising: The LSI further comprises:
A cryptographic hash expansion unit that expands the first storage area with a first value and expands the second storage area with a second value;
A rule factor is applied by requesting the cryptographic hash extension unit to extend a value representative of data received via the external interface into the first storage area and the second storage area. A rule factor application section;
A first value representative of data received via the external interface is expanded in the first storage area, and a second value described in the rule factor correction ticket received via the external interface A second rule factor application unit that applies two rule factors by requesting the cryptographic hash expansion unit to expand the data into the second storage area,
The rule factor correction ticket includes a second value for replacement that extends in the second storage area, and an encryption digest of data in the rule factor correction ticket.
The information processing apparatus according to claim 1. The rule factor correction ticket further includes:
Including the predicted first value;
The second rule factor application unit further confirms that the predicted first value matches the first value representing data received via the external interface;
The information processing apparatus according to claim 2, wherein if they do not match, a request is not made to the cryptographic hash expansion unit to expand the first value. The rule factor correction ticket further includes:
Including a predicted representative value of the object,
The second rule factor application unit further confirms that the predicted representative value of the object matches the representative value of the object received via the external interface,
The information processing apparatus according to claim 2, wherein if they do not match, a request is not made to the cryptographic hash expansion unit to expand the first value. The rule factor correction ticket further includes:
Including the predicted rule factor type,
The second rule factor application unit further confirms that the predicted rule factor type matches the rule factor type received via the external interface;
The information processing apparatus according to claim 2, wherein if they do not match, a request is not made to the cryptographic hash expansion unit to expand the first value. An information processing apparatus including a CPU having a tamper-resistant secure application execution environment,
The secure application execution environment is:
A secure operating system that provides services to applications in the secure application execution environment;
A non-volatile memory area for storing data that needs to be available even after the CPU is rebooted;
A volatile memory area for storing data necessary only during one boot cycle of the CPU;
A monotonic counter area for storing a plurality of non-volatile counters that can only be incremented;
A platform configuration register (PCR) area that stores accumulated information about the platform state;
An encryption unit that generates a plurality of encryption keys, encrypts the data, decrypts the data, generates a plurality of encryption signatures, and verifies the plurality of encryption signatures;
An external interface for transmitting information outside the secure application execution environment and receiving information from outside the secure application execution environment;
A first storage area in the volatile memory area for storing a first cryptographic hash;
A second storage area in the volatile memory area for storing a second cryptographic hash;
Received, including the representative value of the object received via the external interface, the first cryptographic hash, the second cryptographic hash, and the cryptographic digest of the representative value and the two cryptographic hashes An object rule correction ticket issuing unit for issuing an object rule correction ticket for correcting a rule included in the object;
An object rule modification ticket issuance control unit that enables the ticket issuing unit only when the received object includes an encryption hash equal to the first encryption hash stored in the first storage area; An information processing apparatus comprising: The secure application execution environment further includes:
A cryptographic hash expansion unit that expands the first storage area with a first value and expands the second storage area with a second value;
A rule factor is applied by requesting the cryptographic hash extension unit to extend a value representative of data received via the external interface into the first storage area and the second storage area. A rule factor application section;
A first value representative of data received via the external interface is expanded in the first storage area, and a second value described in the rule factor correction ticket received via the external interface A second rule factor application unit that applies two rule factors by requesting the cryptographic hash expansion unit to expand the data into the second storage area,
The information processing apparatus according to claim 6, wherein the rule factor correction ticket includes a replacement second value that is expanded in the second storage area, and an encryption digest of data in the rule factor correction ticket. The rule factor correction ticket further includes:
Including the predicted first value;
The second rule factor application unit further confirms that the predicted first value matches the first value representing data received via the external interface;
The information processing apparatus according to claim 7, wherein if they do not match, a request is not made to the cryptographic hash expansion unit to expand the first value. The rule factor correction ticket further includes:
Including a predicted representative value of the object,
The second rule factor application unit further confirms that the predicted representative value of the object matches the representative value of the object received via the external interface,
The information processing apparatus according to claim 7, wherein if they do not match, a request is not made to the cryptographic hash expansion unit to expand the first value. The rule factor correction ticket further includes:
Including the predicted rule factor type,
The second rule factor application unit further confirms that the predicted rule factor type matches the rule factor type received via the external interface;
The information processing apparatus according to claim 7, wherein if they do not match, a request is not made to the cryptographic hash expansion unit to expand the first value. An object rule correction ticket issuing method,
Providing a first cryptographic hash representing the current object rule value;
Providing a second cryptographic hash representing the new object rule value;
Provide an object containing object rule values,
Provide rule factor types,
Verifying that the object rule value is equal to the first cryptographic hash value; and
If these values are equal, an object rule correction ticket issuance method for generating an object rule correction ticket by generating an encryption digest of the representative value of the object, the first encryption hash, and the second encryption hash . The method further comprises:
Provide a data set that represents the rule factors,
Providing a rule factor correction ticket that includes a cryptographic hash value for replacement and an encrypted digest of the data in the rule factor correction ticket;
Verifying that the encryption digest associated with the rule factor correction ticket is correct;
12. If the verification is successful, a value representative of the data set representing a rule factor is expanded in the first cryptographic hash, and a replacement cryptographic hash is expanded in the second cryptographic hash. The method described. The method further comprises:
The rule factor correction ticket further includes a predicted first value;
Further verifying that the predicted first value matches a value representative of a data set representing a rule factor;
The method according to claim 12, wherein if they do not match, the extension into the first cryptographic hash and the extension into the second cryptographic hash are not performed. The method further comprises:
The rule factor correction ticket further includes a predicted representative value of the object;
Further verifying that the predicted representative value of the object matches the representative value of the object;
The method according to claim 12, wherein if they do not match, the extension into the first cryptographic hash and the extension into the second cryptographic hash are not performed. The method further comprises:
The rule factor correction ticket further includes a predicted rule factor type;
Further verifying that the predicted rule factor type matches the rule factor type;
The method according to claim 12, wherein if they do not match, the extension into the first cryptographic hash and the extension into the second cryptographic hash are not performed.

Images