TCG TPM Main Part 1 Design Principles Specification Version 1.2 Revision 94 29 March 2006 Contact: tpmwg@trustedcomputinggroup.org TCG Published Copyright TCG 2003 - 2006 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 ii Revision 94 29 March 2006 TCG Published Copyright 2003-2006 Trusted Computing Group, Incorporated. Disclaimer THIS SPECIFICATION IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Without limitation, TCG disclaims all liability, including liability for infringement of any proprietary rights, relating to use of information in this specification and to the implementation of this specification, and TCG disclaims all liability for cost of procurement of substitute goods or services, lost profits, loss of use, loss of data or any incidental, consequential, direct, indirect, or special damages, whether under contract, tort, warranty or otherwise, arising in any way out of use or reliance upon this specification or any information herein. No license, express or implied, by estoppel or otherwise, to any TCG or TCG member intellectual property rights is granted herein. Except that a license is hereby granted by TCG to copy and reproduce this specification for internal use only. Contact the Trusted Computing Group at www.trustedcomputinggroup.org for information on specification licensing through membership agreements. Any marks and brands contained herein are the property of their respective owners. TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 iii TCG Published Acknowledgement TCG wishes to thank all those who contributed to this specification. This version builds on the work published in version 1.1 and those who helped on that version have helped on this version. A special thank you goes to the members of the TPM workgroup who had early access to this version and made invaluable contributions, corrections and support. David Grawrock TPM Workgroup chair Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 iv Revision 94 29 March 2006 TCG Published Change History Version Date Description Rev 50 Jun 2003 Started 30 Jun 2003 by David Grawrock First cut at the design principles Rev 52 Jul 2003 Started 15 Jul 2003 by David Grawrock Moved Rev 58 Aug 2003 Started 27 Aug 2003 by David Grawrock All emails through 28 August 2003 New delegation from Graeme merged Rev 62 Oct 2003 Approved by WG, TC and Board as public release of 1.2 Rev 63 Oct 2003 Started 2 Oct 2003 by David Grawrock Kerry email 7 Oct "Various items in rev62" kerry email 10 Oct "Other issues in rev 62" Changes to audit generation Rev 64 Oct 2003 Started 12 Oct 2003 by David Grawrock Removed PCRWRITE usage in the NV write commands Added locality to transport_out log Disable readpubek now set in takeownership. DisableReadpubek now deprecated, as the functionality is moot. Oshrats email regarding DSAP/OSAP sessions and the invalidation of them on delegation changes Changes for CMK commands. Oshrats email with minor 63 comments Rev 65 Nov 2003 Action in NV_DefineSpace to ignore the Booleans in the input structure (Kerry email of 10/30 Transport changes from markus 11/6 email Set rules for encryption of parameters for OIAP,OSAP and DSAP Rewrote section on debug PCR to specify that the platform spec must indicate which register is the debug PCR Orlando FtF decisions CMK changes from Graeme Rev 66 Nov 2003 Comment that OSAP tied to owner delegation needs to be treated internally in the TPM as a DSAP session Minor edits from Monty Added new GetCapability as requested by PC Specific WG Added new DP section that shows mandatory and optional Oshrat email of 11/27 Change PCR attributes to use loc ality selection instead of an array of BOOĽs Removed transport sessions as something to invalidate when a resource type is flushed. Oshrat email of 12/3 added checks for NV_Locked in the NV commands Additional emails from the WG for minor editing fixes Rev 67 Dec 2003 Made locality_modifier always a 1 size Changed NV index values to add the reserved bit. Also noticed that the previous NV index values were 10 bytes not 8. Edited them to correct size. Audit changes to ensure audit listed as optional and the previous commands properly deleted Added new OSAP authorization encryption. Changes made with new entity types, new section in DP (bottom of doc) and all command rewritten to check for the new encryption Rev 68 Jan 2004 Added new section to identify allchanges made for FIPS. Made some FIPS changes on creating and loading of keys Added change that OSAP encryption IV creation always uses both odd and even nonces Added SEALX ordinal and changes to TPM_STORED_DATA12 and seal/unseal to support this Rev 69 Feb 2004 Fixup on stored_data12. TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 v TCG Published Removed magic4 from the GPIO Added in section 34 of DP further discussion of versioning and getcap DP todo section cleaned up Changed store_privkey in migrate_asymkey Moved text for getcapabilities ­ hopefully it is easier to read and follow through on now. Rev 70 Mar 2004 Rewrite structure doc on PCR selection usage. New getcap to answer questions regarding TPM support for pcr selection size Rev 71 Mar 2004 Change terms from authorization data to AuthData. Rev 72 Mar 2004 Zimmermann's changes for DAA Added TPM_Quote2, this includes new structure and ordinal Updated key usage table to include the 1.2 commands Added security properties section that links the main spec to the conformance WG guidelines (in section 1) Rev 73 Apr 2004 Changed CMK_MigrateKey to use TPM_KEY12 and removed two input parameters Allowed TPM_Getcapability and TPM_GetTestResult to execute prior to TPM_Startup when in failure mode Rev 74 May 2004 Minor editing to reflect comments on web site. Locked spec and submitted for IP review Rev 76 Aug 2004 All comments from the WG Included new SetValue command and all of the indexes to make that work Rev 77 Aug 2004 All comments from the WG Rev 78 Oct 2004 Comments from WG. Added new getcaps to report andquery current TPM version Rev 82 Jan 2005 All changes from emails and minutes (I think). Rev 84 Feb 2005 Final changes for 1.2 level 2 Rev 88 Aug 2005 Eratta level 2 release candidate Rev 91 Sept. 2005 Update toFigure 9 (b) in section 9.2by TasneemBrutch Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 vi Revision 94 29 March 2006 TCG Published TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 vii TCG Published Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 viii Revision 94 29 March 2006 TCG Published Table of Contents 1. Scope and Audience...............................................................................................................................1 1.1 Key words ...................................................................................................................................1 1.2 Statement Type ...........................................................................................................................1 2. Description.............................................................................................................................................2 2.1 TODO (notes to keep the editor on track) ......................................................................................2 2.2 Questions....................................................................................................................................2 2.2.1 Delegation Questions ............................................................................................................6 2.2.2 NV Questions......................................................................................................................10 3. Protection ............................................................................................................................................12 3.1 Introduction ...............................................................................................................................12 3.2 Threat .......................................................................................................................................13 3.3 Protection of functions ................................................................................................................13 3.4 Protection of information ............................................................................................................13 3.5 Side effects ...............................................................................................................................14 3.6 Exceptions and clarifications.......................................................................................................14 4. TPM Architecture..................................................................................................................................16 4.1 Interoperability...........................................................................................................................16 4.2 Components..............................................................................................................................16 4.2.1 Input and Output .................................................................................................................17 4.2.2 Cryptographic Co-Processor ................................................................................................17 4.2.2.1 RSA Engine.......................................................................................................................18 4.2.2.2 Signature Operations ..........................................................................................................18 4.2.2.3 Symmetric Encryption Engine .............................................................................................18 4.2.2.4 Using Keys ........................................................................................................................19 4.2.3 Key Generation...................................................................................................................19 4.2.3.1 Asymmetric ­ RSA .............................................................................................................20 4.2.3.2 Nonce Creation..................................................................................................................20 4.2.4 HMAC Engine.....................................................................................................................20 4.2.5 Random Number Generator .................................................................................................21 4.2.5.1 Entropy Source and Collector..............................................................................................22 4.2.5.2 State Register....................................................................................................................22 4.2.5.3 Mixing Function ..................................................................................................................23 4.2.5.4 RNG Reset ........................................................................................................................23 4.2.6 SHA-1 Engine.....................................................................................................................23 4.2.7 Power Detection..................................................................................................................24 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 ix TCG Published 4.2.8 Opt-In.................................................................................................................................24 4.2.9 Execution Engine ................................................................................................................25 4.2.10 Non-Volatile Memory ...........................................................................................................26 4.3 Data Integrity Register (DIR).......................................................................................................26 4.4 Platform Configuration Register (PCR)........................................................................................26 5. Endorsement Key Creation ...................................................................................................................29 5.1 Controlling Access to PRIVEK ....................................................................................................29 5.2 Controlling Access to PUBEK.....................................................................................................30 6. Attestation Identity Keys........................................................................................................................31 7. TPM Ownership ...................................................................................................................................32 7.1 Platform Ownership and Root of Trust for Storage .......................................................................32 8. Authentication and Authorization Data ...................................................................................................33 8.1 Dictionary Attack Considerations ................................................................................................34 9. TPM Operation .....................................................................................................................................36 9.1 TPM Initialization & Operation State Flow ....................................................................................37 9.1.1 Initialization.........................................................................................................................37 9.2 Self-Test Modes ........................................................................................................................39 9.2.1 Operational Self-Test...........................................................................................................41 9.3 Startup ......................................................................................................................................45 9.4 Operational Mode ......................................................................................................................45 9.4.1 Enabling a TPM ..................................................................................................................47 9.4.2 Activating a TPM .................................................................................................................48 9.4.3 Taking TPM Ownership .......................................................................................................49 9.4.3.1 Enabling Ownership ...........................................................................................................50 9.4.4 Transitioning Between Operational States.............................................................................51 9.5 Clearing the TPM.......................................................................................................................51 10. Physical Presence................................................................................................................................53 11. Root of Trust for Reporting (RTR)..........................................................................................................55 11.1 Platform Identity.........................................................................................................................55 11.2 RTR to Platform Binding.............................................................................................................56 11.3 Platform Identity and Privacy Considerations ...............................................................................56 11.4 Attestation Identity Keys.............................................................................................................56 11.4.1 AIK Creation .......................................................................................................................57 11.4.2 AIK Storage ........................................................................................................................58 12. Root of Trust for Storage (RTS).............................................................................................................59 12.1 Loading and Unloading Blobs .....................................................................................................59 13. Transport Sessions and Authorization Protocols .....................................................................................60 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 x Revision 94 29 March 2006 TCG Published 13.1 Authorization Session Setup.......................................................................................................62 13.2 Parameter Declarations for OIAP and OSAP Examples ................................................................63 13.2.1 Object-Independent Authorization Protocol (OIAP) ................................................................65 13.3 Object-Specific Authorization Protocol (OSAP)............................................................................67 13.4 Authorization Session Handles ...................................................................................................71 13.5 Authorization-Data Insertion Protocol (ADIP)...............................................................................72 13.6 AuthData Change Protocol (ADCP).............................................................................................75 13.7 Asymmetric Authorization Change Protocol (AACP).....................................................................76 14. FIPS 140 Physical Protection ................................................................................................................77 14.1 TPM Profile for FIPS Certification................................................................................................77 15. Maintenance ........................................................................................................................................78 15.1 Field Upgrade............................................................................................................................79 16. Proof of Locality ...................................................................................................................................81 17. Monotonic Counter ...............................................................................................................................82 18. Transport Protection .............................................................................................................................85 18.1 Transport encryption and authorization........................................................................................87 18.1.1 MGF1 parameters ...............................................................................................................89 18.1.2 HMAC calculation................................................................................................................89 18.1.3 Transport log creation..........................................................................................................90 18.1.4 Additional Encryption Mechanisms .......................................................................................90 18.2 Transport Error Handling............................................................................................................90 18.3 Exclusive Transport Sessions .....................................................................................................91 18.4 Transport Audit Handling............................................................................................................92 18.4.1 Auditing of wrapped commands ...........................................................................................92 19. Audit Commands ..................................................................................................................................94 19.1 Audit Monotonic Counter............................................................................................................96 20. Design Section on Time Stamping.........................................................................................................97 20.1 Tick Components.......................................................................................................................97 20.2 Basic Tick Stamp.......................................................................................................................98 20.3 Associating a TCV with UTC.......................................................................................................98 20.4 Additional Comments and Questions ........................................................................................ 100 21. Context Management ......................................................................................................................... 103 22. Eviction.............................................................................................................................................. 105 23. Session pool ...................................................................................................................................... 106 24. Initialization Operations ....................................................................................................................... 107 25. HMAC digest rules.............................................................................................................................. 109 26. Generic authorization session termination rules .................................................................................... 110 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 xi TCG Published 27. PCR Grand Unification Theory ............................................................................................................ 111 27.1 Validate Key for use................................................................................................................. 114 28. Non Volatile Storage ........................................................................................................................... 116 28.1 NV storage design principles .................................................................................................... 117 28.1.1 NV Storage use models ..................................................................................................... 117 28.2 Use of NV storage during manufacturing ................................................................................... 119 29. Delegation Model ............................................................................................................................... 120 29.1 Table Requirements................................................................................................................. 120 29.2 How this works ........................................................................................................................ 121 29.3 Family Table............................................................................................................................ 123 29.4 Delegate Table ........................................................................................................................ 124 29.5 Delegation Administration Control ............................................................................................. 125 29.5.1 Control in Phase 1............................................................................................................. 126 29.5.2 Control in Phase 2............................................................................................................. 127 29.5.3 Control in Phase 3............................................................................................................. 127 29.6 Family Verification ................................................................................................................... 127 29.7 Use of commands for different states of TPM ............................................................................ 129 29.8 Delegation Authorization Values ............................................................................................... 129 29.8.1 Using the authorization value ............................................................................................. 130 29.9 DSAP description .................................................................................................................... 130 30. Physical Presence.............................................................................................................................. 134 30.1 Use of Physical Presence......................................................................................................... 134 31. TPM Internal Asymmetric Encryption ................................................................................................... 136 31.1.1 TPM_ES_RSAESOAEP_SHA1_MGF1............................................................................... 136 31.1.2 TPM_ES_RSAESPKCSV15............................................................................................... 137 31.1.3 TPM_ES_SYM_CNT......................................................................................................... 137 31.1.4 TPM_ES_SYM_OFB ......................................................................................................... 137 31.2 TPM Internal Digital Signatures ................................................................................................ 138 31.2.1 TPM_SS_RSASSAPKCS1v15_SHA1................................................................................. 138 31.2.2 TPM_SS_RSASSAPKCS1v15_DER.................................................................................. 138 31.2.3 TPM_SS_RSASSAPKCS1v15_INFO ................................................................................. 138 31.2.4 Use of Signature Schemes ................................................................................................ 138 32. Key Usage Table ................................................................................................................................ 140 33. Direct Anonymous Attestation ............................................................................................................. 142 33.1 TPM_DAA_JOIN ..................................................................................................................... 142 33.2 TPM_DAA_Sign ...................................................................................................................... 144 33.3 DAA Command summary ......................................................................................................... 144 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 xii Revision 94 29 March 2006 TCG Published 33.3.1 TPM setup ........................................................................................................................ 145 33.3.2 JOIN................................................................................................................................. 145 33.3.3 SIGN................................................................................................................................ 149 34. General Purpose IO............................................................................................................................ 152 35. Redirection......................................................................................................................................... 153 36. Structure Versioning ........................................................................................................................... 154 37. Certified Migration Key Type ............................................................................................................... 156 37.1 Certified Migration Requirements.............................................................................................. 156 37.2 Key Creation ........................................................................................................................... 157 37.3 Migrate CMK to a MA............................................................................................................... 157 37.4 Migrate CMK to a MSA............................................................................................................. 158 38. Revoke Trust...................................................................................................................................... 159 39. Mandatory and Optional Functional Blocks........................................................................................... 161 40. Optional Authentication Encryption ...................................................................................................... 164 41. 1.1a and 1.2 Differences ..................................................................................................................... 166 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 1 TCG Published 1. Scope and Audience1 The TPCA main specification is an industry specification that enables trust in computing2 platforms in general. The main specification is broken into parts to make the role of each3 document clear. A version of the specification (like 1.2) requires all parts to be a complete4 specification.5 A TPM designer MUST be aware that for a complete definition of all requirements necessary6 to build a TPM, the designer MUST use the appropriate platform specific specification for all7 TPM requirements.8 1.1 Key words9 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD,"10 "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in the chapters 2-1011 normative statements are to be interpreted as described in [RFC-2119].12 1.2 Statement Type13 Please note a very important distinction between different sections of text throughout this14 document. You will encounter two distinctive kinds of text: informative comment and15 normative statements. Because most of the text in this specification will be of the kind16 normative statements, the authors have informally defined it as the default and, as such,17 have specifically called out text of the kind informative comment They have done this by18 flagging the beginning and end of each informative comment and highlighting its text in19 gray. This means that unless text is specifically marked as of the kind informative20 comment, you can consider it of the kind normative statements.21 For example:22 Start of informative comment23 This is the first paragraph of 1­n paragraphs containing text of the kind informative24 comment ...25 This is the second paragraph of text of the kind informative comment ...26 This is the nth paragraph of text of the kind informative comment ...27 To understand the TCG specification the user must read the specification. (This use of28 MUST does not require any action).29 End of informative comment30 This is the first paragraph of one or more paragraphs (and/or sections) containing the text31 of the kind normative statements ...32 To understand the TCG specification the user MUST read the specification. (This use of33 MUST indicates a keyword usage and requires an action).34 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 2 Revision 94 29 March 2006 TCG Published 2. Description35 The design principles give the basic concepts of the TPM and generic information relative to36 TPM functionality.37 A TPM designer MUST review and implement the information in the TPM Main specification38 (parts 1-4) and review the platform specific document for the intended platform. The39 platform specific document will contain normative statements that affect the design and40 implementation of a TPM.41 A TPM designer MUST review and implement the requirements, including testing and42 evaluation, as set by the TCG Conformance Workgroup. The TPM MUST comply with the43 requirements and pass any evaluations set by the Conformance Workgroup. The TPM MAY44 undergo more stringent testing and evaluation.45 The question section keeps track of questions throughout the development of the46 specification and hence can have information that is no longer current or moot. The47 purpose of the questions is to track the history of various decisions in the specification to48 allow those following behind to gain some insight into the committees thinking on various49 points.50 2.1 TODO (notes to keep the editor on track)51 52 2.2 Questions53 How to version the flag structures?54 I suggest that we simply put the version into the structure and pass it back in the55 structure. Add the version information into the persistent and volatile flag structures.56 When using the encryption transport failures are easy to see. Also the watcher on the line57 can tell where the error occurred. If the failure occurs at the transport level the response58 is an error (small packet) and it is in the clear. If the error occurs during execution of the59 command then the response is a small encrypted packet. Should we expand the packet60 size or simply let this go through?61 Not an issue.62 Do we restrict the loading of a counter to once per TPM_Startup(Clear)?63 Yes once a counter is set it must remain the same until the next successful startup.64 Does the time stamp work as a change on the tag or as a wrapped command like the65 transport protection.66 While possibly easier at the HW level the tag mechanism seems to be harder at the SW67 level as to what commands are sent to the TPM. The issue of how the SW presents68 the TS session to the SW writer is not an issue. This is due to the fact that however69 the session is presented to the SW writer the writer must take into account which70 commands are being time stamped and how to manage the log etc. So accepting a71 mechanism that is easy for the HW developer and having the SW manage the72 interface is a sufficient direction.73 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 3 TCG Published When returning time information do we return the entire time structure or just the time74 and have the caller obtain all the information with a GetCap call?75 All time returns will use the entire structure with all the details.76 Do we want to return a real clock value or a value with some additional bits (like a77 monotonic value with a time value)?78 Add a count value into the time structure.79 Do we need NTP or is SNTP sufficient?80 The TPM will not run the time protocol itself. What the TPM will do is accept a value81 from outside software and a hash of the protocols that produced the value. This82 allows the platform to use whatever they want to set the value from secure time to83 the local PC clock.84 Can an owner destroy a TPM by issuing repeated CreateCounter commands?85 A TPM may place a throttle on this command to avoid burn issues. It MUST not be86 possible to burn out the TPM counter under normal operating conditions. The87 CreateCounter command is limited to only once per successful88 TPM_Startup(ST_CLEAR).89 This answer is now somewhat moot as the command to createcounter is now owner90 authorized. This allows the owner to decide when to authorize the counter creation.91 As there are only 4 counters available it is not an issue with having the owner92 continue to authorize counters.93 What happens to a transport session (log etc.) on an S3?94 Should these be the same as the authorization sessions? The saving of a transport95 session across S3 is not a security concern but is a memory concern. The TPM MUST96 clear the transport session on TPM_Startup(CLEAR) and MAY clear the session on97 TPM_Startup(any).98 While you can't increment or create a new counter after startup can you read a counter99 other than the active one?100 You may read other counters101 When we audit a command that is not authorized should we hash the parameters and102 provide that as part of the audit event, currently they are set to null.103 We should hash parameters of non-authorized commands104 There is a fundamental problem with the encryption of commands in the transport and105 auditing. If we cover a command we have no way to audit, if we show the command then106 it isn't protected. Can we expose the command (ordinal) and not the parameters?107 If the owner has requested that a function be audited then the execute transport return108 will include sufficient information to produce the audit entry.109 How to set the time in the audit structure and tell the log what is going on.110 The time in the audit structure is set to nulls except when audit occurs as part of a111 transport session. In that case the audit command is set from the time value in the112 TPM.113 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 4 Revision 94 29 March 2006 TCG Published Is there a limit to the number of locality modifiers?114 Yes, the TPM need only support a maximum of 4 modifiers. The definition of the115 modifiers is always a platform specific issue.116 How do we evict various resources?117 There are numerous eviction routines in the current spec. We will deprecate the various118 types and move to TPM_Flushxxx for all resource types.119 Can you flush a saved context?120 Yes, you must be able to invalidate saved contexts. This would be done by making sure121 that the TPM could not load any saved context.122 What is the value of maintaining the clock value when the time is not incrementing? Can123 this be due to the fact that the time is now known to be at least after the indicated time?124 Moot point now as we don't keep the clock value at125 Should we change the current structures and add the tag?126 TODO127 Can we have a bank of bits (change bit locality) for each of the 4 levels of locality?128 Now129 How do we find out what sessions are active? Do we care?130 I would say yes we care and we should use the same mechanism that we do for the keys.131 A GetCap that will return the handles.132 Can we limit the transport sessions to only one?133 No, we should have as a minimum 2 sessions. One gets into deadlocks and such so the134 minimum should be 2.135 Does the TPM need to keep the audit structure or can it simply keep a hash?136 The TPM just keeps the audit digest and no other information.137 What happens to an OSAP session if the key associated with it is taken off chip with a138 "SaveContext"? What happens if the key saveContext occurs after an OSAP auth context139 that is already off chip? How do you later connect the key to the auth session (without140 having to store all sorts of things on chip)? Are we really honestly convinced that we've141 thought of all the possible ramifications of saving and restoring auth sessions? And is it142 really true that all the things we say about a saved auth session do/should apply to a143 saved key (which is to say is there really a single loadContext command and a single144 context structure)?145 Saved context a reliable indication of the linkage between the OSAP and the key. When146 saving save auth then key, on load key then auth. Auth session checks for the key147 and if not found fails.148 Why is addNonce an output of 16.5 loadContext?149 If iťs wrong, iťs a little late to find out now - why not have it as an input and have the150 TPM return an error if the encrypted addNonce doesn't match the input? The thought151 was that the nonce area might not be a nonce but was information that the caller152 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 5 TCG Published could put in. If they use it as a nonce fine, but they could also use it as a label or153 sequence number or ... any value the caller wanted154 Is there a memory endurance problem with contextNonceSession?155 contextNonceSession does not have to be saved across S3 states so there is no156 endurance problem.157 Is there a memory endurance problem with contextNonceKey?158 contextNonceKey only changes on TPM_Startup(ST_Clear) so iťs endurance is the same159 as a PCR.160 The debate continues about restoring a resource's handle during TPM_LoadContext.161 Debate ends by having the load context be informed of what the loaders opinion is about162 the handle. The requestor can indicate that it wishes the same handle and if the TPM163 can perform that task it does, if it cannot then the load fails.164 Interesting attack is now available with the new audit close flag on get audit signed. Anyone165 with access to a signing key can close the audit log. The only requirement on the166 command is that the key be authorized. While there is no loss of information (as the167 attacker can always destroy the external log) does the closing of a log make things look168 different. This does enable a burn out attack. The ability to closeAudit enables a new169 DenialOfService attack.170 Resolution: The TPM Owner owns the audit process, so the TPM Owner should have171 exclusive control over closeAudit. Hence the signing key used to closeAudit must be172 an AIK. Note that the owner can choose to give this AIK's AuthData value to the OS,173 so that the OS can automatically close an audit session during platform power down.174 But such operations are outside this specification.175 Should we keep the E function in the tick counter?176 From Graeme, I would prefer to see these calculations deleted. The calculation starts177 with one assertion and derives a contradictory assertion. Generally, there seems little178 value in trying to derive an equality relationship when nothing is known about the179 path to and from the Time Authority.180 What is the difference between DIR_Quote and DirReadSigned?181 Appears to be none so DIR_Quote deleted182 The tickRate parameter associates tick with seconds and has no way to indicate that the183 rate is greater than one second. Is this OK?184 Do we need to allow for tick rates that are slower than once per second. We report in185 nanoseconds.186 The TPM MUST support a minimum of 2 authorization sessions. Where do we put this187 requirement in the spec?188 Can we find a use for the DIR and BIT areas for locality 0?189 They have no protections so in many ways they are just extra. We leave this as it is as190 locality 0 may mean something else on a platform other than a PC.191 How do we send back the transport log information on each execute transport?192 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 6 Revision 94 29 March 2006 TCG Published It is 64 byes in length and would make things very difficult to include on every193 command. Change wrappedaudit to be input params, add output parms and the194 caller has all information necessary to create the structure to add into the digest.195 The transport log structure is a single structure used both for input and output with the196 only difference being the setting of ticks to 0 on input and a real value on output, do we197 need two structures.198 I believe that a single structure is fine199 For TPM_Startup(ST_Clear) I added that all keys would be flushed. Is this right?200 Yes201 Why have 2 auths for release transport signed? It is an easy attack to simply kill the202 session.203 The reason is that an attacker can close the session and get a signature of the session204 log. We are currently not sure of the level of this attack but by having the creator of205 the session authorize the signing of the log it is completely avoided.206 19.3 Action 3 (startup/state) doesn't reference the situation where there is no saved state.207 My presumption is that you can still run startup/clear, but maybe you have to do a208 hardware reset?209 DWG I don't think so. This could be an attack and a way to get the wrong PCR values210 into the system. The BIOS is taking one path and may not set PCR values. Hence the211 response is to go into failed selftest mode.212 What happens to a transport session if a command clears the TPM like revokeTrust213 This is fine. The transport session is not complete but the session protected the214 information till the command that changed the TPM. It is impossible to get a log from215 the session or to sign the session but that is what the caller wanted.216 2.2.1 Delegation Questions217 Is loading the table by untrusted process ok? Does this cause a problem when the new table218 is loaded and permissions change?219 Yes, the fill table can be done by any process. A TPM Owner wishing to validate the table220 can perform the operations necessary to gain assurance of the table entries.221 Are the permissions for a table row sensitive?222 Currently we believe not but there are some attack models that knowing the permissions223 makes the start of the attack easier. It does not make the success of the attack any224 easier. Example if I know that a single process is the only process in the table that225 has the CreateAIK capability then the attacker only attempts to break into the single226 process and not all others.227 What software is in use to modify the table?228 The table can be updated by any software or process given the capability to manage the229 table. Three likely sources of the software would be a BIOS process, an applet of a230 trusted process and a standalone self-booting (from CD-ROM) management231 application.232 Who holds the TPM Owner password?233 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 7 TCG Published There is no change to the holding of the TPM Owner token. The permissions do allow the234 creation of an application that sets the TPM Owner token to a random value and235 then seals the value to the application.236 How are these changes created such that there is minimal change to the current TPM?237 This works by using the current authorization process and only making changes in the238 authorization and not for each and every command.239 What about S3 and other events?240 Permissions, once granted, are non-volatile.241 The permission bit to changeOwnerAuth (bit 11) gives rise to the functionality that the SW242 that has this bit can control the TPM completely. This includes removing control from243 the TPM Owner as the TPM Owner value will now be a random value only known to SW.244 There are use models where this is good and bad, do we want this functionality?245 Pros and cons of physical enable table when TPM Owner is present ­ Pro physically present246 user can make SW play fair. Con ­ physically present user can override the desires of a247 TPM Owner.248 Do we need to reset TPM_PERMISSION_KEY at some time?249 We know that the key is NOT reset on TPM_ClearOwner.250 What is the meaning of using permission table in an OIAP and OSAP mode?251 Delegate table can be used in either OIAP or OSAP mode.252 Can you grant permissions without assigning the permissions to a specific process?253 Yes, do a SetRow with a PCR_SELECTION of null and the permissions are available to254 any process.255 Do we need a ClearTableOwner?256 I would assert that we do not need this command. The TPM Owner can perform SetRow257 with NULLS four times and creates the exact same thing. Not having this command258 lowers the number of ordinals the TPM is required to support.259 There are some issues with the currently defined behavior of familyID and the260 verificationCount.261 Talked to David for 30 mins. We decided that maxFamilyID is set to zero at262 manufacture, and incremented for every FamTable_SetRow263 It is the responsibility of DelTable_SetRow to set the appropriate familyID264 DelTable_SetRow fails if the provided familyID is not active and present somewhere in265 the FamTable266 FillTable works differently. It effectively resets the family table (invalidating all active267 rows) and sets up as many rows as are needed based on the number of families268 specified in FillTable269 This still needs a bit of work. Presumably the caller of FillTable uses a "fake" familyID,270 and this is changed to the actual familyID when the fill happens271 There are some issues with the verificationCount.272 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 8 Revision 94 29 March 2006 TCG Published Uber-issue. If none of the rows in the table are allowed to create other rows and export273 them, then the "sign" of the table is meaningful274 If one of the rows is allowed to create and export new rows, is there any real meaning to275 "the current set of exported rows?" (i.e. SW can just up and make new rows).276 Should section 4.4, TPM_DelTable_ClearTable), section 4.5 (TPM_DelTable_SetEnable), and277 section 4.7 (TPM_DelTable_Set_Admin) all say "there must be UNAMBIGUOUS evidence278 of the presence of physical access..." Is this okay?279 Answer: No, group agreed to change UNAMBIGUOUS to BEST EFFORT in all three280 sections.281 Is FamilyID a sensitive value?282 If so, why? Agreement: FamilyID is not a sensitive value.283 Should TPM_TakeOwnership be included in permissions bits (see bit 12 in section 3.1)?284 Enables a better administrative monitor and may enable user to take ownership easier.285 Agreement leave it in and change informative comments to reflect the reasons.286 [From the TPM_DelTable_SetRow command informative comments]: Note that there are two287 types of rights: family rights (you can either edit your family's rows or grab new rows)288 and administrative rights.289 This is really just an editor's note, not a question to be resolved.290 [From the TPM_DelTable_ExportRow command informational comments]:291 Does not effect content of exported row left behind in the table;292 Valid for all rows in the table;293 Does not need to be OwnerAuth'd;294 Family Rights are that family can only export a row from rows 0-3 if row belongs to the295 family, but rows 4 and upwards can be exported by any Trusted Process, without any296 family checking being done. This is really just an editor's note, not a question to be297 resolved.298 When a Family Table row is set, the verificationCount is set to 1, make sure that is299 consistently used in all other command actions.300 Done.301 SetEnable and SetEnableOwner enable and disable all rows in a table, not just the rows302 belong to the family of the process that used the SetEnable and/or SetEnableOwner303 commands. This is also true for SetAdmin and SetAdminOwner. Can anybody come up304 with a use scenario where that causes any problems?305 In command actions where the TPM must walk the delegation table looking for a306 configuration that matches the command input parameters (PCRinfo and/or307 authValues) and there are rows in the table with duplicate values, what does the TPM308 do? Is there any reason not to use the rule "the TPM starts walking the table starting309 with the first row and use the first row it finds with matching values"?310 Answer to this question may mean change to pseudo code in section 2.3, Using the311 AuthData Value, which currently shows the TPM walking the delegation table,312 starting with the first row, and using the first row it finds with matching values.313 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 9 TCG Published What familyID value signals a family table row that is not in use/contains invalid values?314 To get consistency in all the command Actions that use this, that FamilyID value has315 been edited in all places to be NULL, instead of 0. Yes, FamilyID value of NULL316 signals a family table row that is not in use or contains invalid values.317 From section 2.4, Delegate Table Fill and Enablement: "The changing of a TPM Owner does318 not automatically clear the delegate table. Changing a TPM Owner does disable all319 current delegations, including exported rows, and requires the new TPM Owner to re-320 enable the delegations in the table. The table entry values like trusted process321 identification and delegations to that process are not effected by a change in owner. THE322 AUTHDATA VALUES DO NOT SURVIVE THE OWNERSHIP CHANGE." Question: If this is323 true, no delegations work after a change of owner. How does the new owner set new324 AuthData values?325 The simple way of handling this is to get AdminMonitor to own backing up delegations at326 first owner install and then be run by new owner, and AdminMonitor uses FillTable,327 to handle "Owner migration." Or, for another use option, is for second owner to pick-328 up PCR-IĎs and delegations bits from previous owner ­ what is the most straight-329 forward way to do this?330 In section 3.1 (Delegate Definitions bit map table), several commands that do not require331 owner authorization are in the table and can be delegated: TPM_SetTempDeactivated (bit332 15), TPM_ReadPubek (bit 7), and TPM_LoadManuMaintPub (bit 3), Why?333 In section 3.3 it is stated, "The Family ID resets to NULL on each change of TPM Owner."334 This invalidates all delegations. Is this what we want?335 You don't have to blow away FamilyID to blow away the blobs, because key is gone. So336 this is not required ­ can eliminate these actions.337 In section 3.12, why is TPM_DELEGATE_LABEL included in the table?338 In section 4.2 (TPM_DelTable_FillTable), is it okay to delete requirement that delegate table339 be empty? Also, in Action 14, now that we have both persistent and volatile tableAdmin340 flags, should this command set volatile tableAdmin flag to FALSE upon completion?341 The delegate table does not need to be empty to use the TPM_DelTable_FillTable342 command, Also, a paragraph has been added to Informative comment for343 TPM_DelTable_FillTable that points out usefulness of immediately following344 TPM_DelTable_FillTable with TPM_Delegate_TempSetAdmin, to stop table345 administration in the current boot cycle.346 In section 4.15 (TPM_FamTable_IncrementCount), why does this command require347 TPMOwner authorization, as currently documented in section 4.15?348 IncrementCount is gated by tableAdmin, which seems sufficient, and use of ownerauth349 makes it difficult to automatically verify a table using a CDROM.350 In section 4.3 (TPM_DelTable_FillTableOwner), in the Action 3d, use OTP[80] = MFG(x1) in351 place of oneTimePad[n] = SHA1(x1 || seed[n]))?,352 yes.353 In section 4.9 (TPM_DelTable_SetRow), is invalidateRow input parameter really needed?354 It is only used in action 5. Couldn't action 5 simply read "Set N1 -> familyID = NULL"?355 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 10 Revision 94 29 March 2006 TCG Published There is no easy way to generate a blob that can be used to delegate migration authority for356 a user key.357 This is because the TPM does not store the migration authority on the chip as the358 migration command involves an encrypted key, not a loaded one. One could invent a359 `CreateMigrationDelegationBlob' that took the encrypted key as input and generated360 the encrypted delegation blob as output, but it would not be pretty. Sorry Dave .361 If a delegate row in NV memory (nominally 4 rows) is to refer to a user key (instead of owner362 auth), then it needs to include a hash of the public key. It could be that the NV table is363 restricted to owner auth delegations, this would save 80 bytes of NV store and also364 simplify the LoadBlob command.365 Maybe would simplify other things. I would definitely NOT permit user keys in the table366 to be run with the legacy OSAP and OIAP ordinals.367 A few more GetCapability values are also required, the usual constants that we discussed368 and also the two readTable caps.369 TBD Verify that Delegate Table Management commands (see section 2.8) cover all the370 functionality of obsolete or updated commands.371 Redefine bits 16 and above in Delegation Definitions table (section 3.1). In particular, can372 new command set (with TPM_FAMILY_OPERATION options as defined in section 3.20) be373 delegated individually and appropriately. Also, how many user key authorized374 commands will be delegated?375 Is new TPM_FAMILY_FLAGS field of family table (defined in section 3.5) sensitive data?376 DSAP informative comment needs to be completed (section 4.1). In particular, does the377 statement "The DSAP command works like OSAP except it takes an encrypted blob ­ an378 encrypted delegate table row -- as input" sufficient? Or do some particular differences379 between DSAP and OSAP have to be pointed out in this informative comment??380 The TPM_Delegate_LoadBlob[Owner] commands cannot be used to load key delegation blobs381 into the TPM. Is another ordinal required to do that?382 Is it okay for TPM_Delegate_LoadBlob[Owner] commands to ignore enable/disable383 use/admin flags in family table rows?384 Is it wise to delegate TPM_DelTable_ConvertBlob command (defined in section 4.11)? Does385 current definition of this command support section 2.7 scenarios?386 Is there a privacy problem with DelTable_ReadRow since the contents may not be identical387 from TPM to TPM?388 Are DSAP sessions being pooled with the other sessions? if so, can one save \load them by389 context functions? if not, then there should be a restriction in saveContext.390 DSAP are "normal" authorization sessions and would save/load with OIAP and OSAP391 sessions392 2.2.2 NV Questions393 You would set this by using a new ordinal that is unauthorized and only turns the flag on to394 lock everything. Yet another ordinal? Do we need it? Is this an important functionality395 for the uses we see?396 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 11 TCG Published Yes this allows us to have "close" to writeonce functionality. What the functionality397 would be is that the RTM would assure that the proper information is present in the398 TPM and then "lock" the area. One could create this functionality by having the RTM399 change the authorization each time but then you would need to eat more NV store so400 save the sealed AuthData value. I think that is easier to have an ordinal than eat the401 NV space and require a much more complex programming model.402 Is it OK to have an element partially written?403 Given that we have chunks there has to be a mechanism to allow partial writes.404 If an element is partially written, how does a caller know that more needs to be written?405 I would say the use model that provides the ability to write ­ read, in a loop is just not406 supported. Get it all written and then do the read.407 Usage of the lock bit: as you wrote, the RTM would assure that the proper information is408 present in the TPM and then "lock" the area. so why in action #4 we should also check409 bWritten when the lock bit is set? should be as action #3b of TPM_NV_DefineSpace, if410 lock is set - return error411 [Grawrock, David] Not quite, the use model I was trying to create was the one where the412 TPM was locked and the user was attempting to add a new area. If the locked bit413 doesn't allow for writing once to a new area, one must reboot to perform the write414 and also tell the RTM what the value to write must be. So this allows the creator of415 an area to write it once and then it flows with the locked bit.416 Can you delete a NV value with only physical presence?417 [Grawrock, David] You can't delete with physical presence, you must use owner418 authorization. This I think is a reasonable restriction to avoid burn problems.419 Why is there no check on the writes for a TPM Owner?420 The check for an owner occurred during the TPM_NV_DefineSpace. It is imperative that421 the TPM_NV_DefineSpace set in place the appropriate restrictions to limit the422 potential for attacks on the NV storage area.423 Description of maxNVBufSize is confusing to me. Why is this value related to the input size?424 And since there is no longer any 'written' bits, why is there a maximum area size at all?425 [Grawrock, David] This is a fixed size and set by the TPM manufacturer. I would see426 values like the input buffer, transport sessions etc all coming up with the max size427 the TPM can handle. This does NOT indicate what is available on the TPM right now.428 The TPM could have 4k of space but max size would be 782 and would always report429 that number. If the available space fell to 20 bytes this value would still be 782.430 If the storage area is an opaque area to the TPM (as described), then how does the TPM431 know what PCR registers have been used to seal a blob?432 The VALUES of the area are opaque, the attributes to control access are not. So if the433 attributes indicate that PCR restrictions are in place the TPM keeps those PCR values434 as part of the index attributes. This in reality seals the value as there is no need for435 tpmProof since the value never leaves the TPM.436 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 12 Revision 94 29 March 2006 TCG Published 3. Protection437 3.1 Introduction438 Start of informative comment439 The Protection Profile in the Conformance part of the specification defines the threats that440 are resisted by a platform. This section, "Protection," describes the properties of selected441 capabilities and selected data locations within a TPM that has a Protection Profile and has442 not been modified by physical means.443 This section introduces the concept of protected capabilities and the concept of shielded444 locations for data. The ordinal set defined in part II and III is the set of protected445 capabilities. The data structures in part II define the shielded locations.446 * A protected capability is one whose correct operation is necessary in order for the447 operation of the TCG Subsystem to be trusted.448 * A shielded location is an area where data is protected against interference and prying,449 independent of its form.450 This specification uses the concept of protected capabilities so as to distinguish platform451 capabilities that must be trustworthy. Trust in the TPM depends critically on the protected452 capabilities. Platform capabilities that are not protected capabilities must (of course) work453 properly if the TCG Subsystem is to function properly.454 This specification uses the concept of shielded locations, rather than the concept of455 "shielded data." While the concept of shielded data is intuitive, it is extraordinarily difficult456 to define because of the imprecise meaning of the word "data." For example, consider data457 that is produced in a safe location and then moved into ordinary storage. It is the same data458 in both locations, but in one it is shielded data and in the other it is not. Also, data may not459 always exist in the same form. For example, it may exist as vulnerable plaintext, but also460 may sometimes be transformed into a logically protected form. This data continues to exist,461 but doesn't always need to be shielded data - the vulnerable form needs to be shielded data,462 but the logically protected form does not. If a specific form of data requires protection463 against interference or prying, it is therefore necessary to say "if the data-D exists, it must464 exist only in a shielded location." A more concise expression is "the data-D must be extant465 only in a shielded location."466 Hence, if trust in the TCG Subsystem depends critically on access to certain data, that data467 should be extant only in a shielded location and accessible only to protected capabilities.468 When not in use, such data could be erased after conversion (using a protected capability)469 into another data structure. Unless the other data structure was defined as one that must470 be held in a shielded location, it need not be held in a shielded location.471 End of informative comment472 1. The data structures described in part II of the TPM specifications MUST NOT be473 instantiated in a TPM, except as data in TPM-shielded-locations.474 2. The ordinal set defined in part II and III of the TPM specifications MUST NOT be475 instantiated in a TPM, except as TPM-protected-capabilities.476 3. Functions MUST NOT be instantiated in a TPM as TPM-protected-capabilities if they do477 not appear in the ordinal set defined in part II and III of the TPM specifications.478 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 13 TCG Published 3.2 Threat479 Start of informative comment480 This section, "Threat," defines the scope of the threats that must be considered when481 considering whether a platform facilitates subversion of capabilities and data in a platform.482 The design and implementation of a platform determines the extent to which the platform483 facilitates subversion of capabilities and data within that platform. It is necessary to define484 the attacks that must be resisted by TPM-shielded locations and TPM-protected capabilities485 in that platform.486 The TCG specifications define all attacks that are resisted by the TPM. These attacks must487 be considered when determining whether the integrity of TPM-protected capabilities and488 data in TPM-shielded locations can be damaged. These attacks must be considered when489 determining whether there is a backdoor method of obtaining access to TPM-protected490 capabilities and data in TPM-shielded locations. These attacks must be considered when491 determining whether TPM-protected capabilities have undesirable side effects.492 End of informative comment493 1. For the purposes of the "Protection" section of the specification, the threats that MUST494 be considered when determining whether the TPM facilitates subversion of TPM-495 protected-capabilities or data in TPM-shielded-locations SHALL include496 a. The methods inherent in physical attacks that fail if the TPM complies with the497 "physical protection" requirements specified by TCG498 b. All methods that require execution of instructions in a computing engine in the499 platform500 3.3 Protection of functions501 Start of informative comment502 A TPM-protected-capability must be used to modify TPM-protected capabilities. Other503 methods must not be allowed to modify TPM-protected capabilities. Otherwise, the integrity504 of TPM-protected capabilities is unknown.505 End of informative comment506 1. A TPM SHALL NOT facilitate the alteration of TPM-protected-capabilities, except by TPM-507 protected capabilities.508 3.4 Protection of information509 Start of informative comment510 TPM-protected capabilities must provide the only means from outside the TPM to access511 information represented by data in TPM-shielded-locations. Otherwise, a rogue can reveal512 data in TPM-shielded-locations, or create a derivative of data from TPM-shielded-locations513 (in a way that maintains some or all of the information content of the data) and reveal the514 derivative.515 End of informative comment516 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 14 Revision 94 29 March 2006 TCG Published 1. A TPM SHALL NOT export data that is dependent upon data structures described in part517 II of the TPM specifications, other than via a TPM-Protected-Capability.518 3.5 Side effects519 Start of informative comment520 An implementation of a TPM-protected capability must not disclose the contents of TPM-521 shielded locations. The only exceptions are when such disclosure is inherent in the522 definition of the capability or in the methods used by the capability. For example, a523 capability might be designed specifically to reveal hidden data or might use cryptography524 and hence always be vulnerable to cryptanalysis. In such cases, some disclosure or risk of525 disclosure is inherent and cannot be avoided. Other forms of disclosure (by side effects, for526 example) must always be avoided.527 End of informative comment528 1. The implementation of a TPM-protected-capability in a TPM SHALL NOT facilitate the529 disclosure or the exposure of information represented by data in TPM-shielded­530 locations, except by means unavoidably inherent in the TPM definition.531 3.6 Exceptions and clarifications532 Start of informative comment533 These exceptions to the blanket statements in the generic "protection" requirements (above)534 are fully compatible with the intended effect of those statements. These exceptions affect535 TCG-data that is available as plain-text outside the TPM and TCG-data that can be used536 without violating security or privacy. These exceptions are valuable because they approve537 use of TPM resources by vendor-specific commands in particular circumstances.538 These clarifications to the blanket statements of the generic "protection" requirements539 (above) do not materially change the effect of those statements, but serve to approve specific540 legitimate interpretations of the requirements.541 End of informative comment542 1. A Shielded Location is a place (memory, register, etc.) where data is protected against543 interference and exposure, independent of its form544 2. A TPM-Protected-Capability is an operation defined in and restricted to those identified545 in part II and III of the TPM specifications.546 3. A vendor specific command or capability MAY use the standard TCG owner/operator547 authorization mechanism548 4. A vendor specific command or capability MAY utilize a TPM_PUBKEY structure stored on549 the TPM so long as the usage of that TPM_PUBKEY structure is authorized using the550 standard TCG authorization mechanism.551 5. A vendor specific command or capability MAY use a sequence of standard TCG552 commands. The command MUST propagate the locality used for the call to the used553 TCG commands or capabilities, or set locality to 0.554 6. A vendor specific command or capability that takes advantage of exceptions and555 clarifications to the "protection" requirements MUST be defined as part of the security556 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 15 TCG Published target of the TPM. Such a vendor specific command or capability MUST be evaluated to557 meet the Platform Specific TPM and System Security Targets.558 7. If a TPM employs vendor-specific cipher-text that is protected against subversion to the559 same or greater extent as internal TPM-resources stored outside the TPM with TCG-560 defined methods, that vendor-specific cipher-text does not necessarily require protection561 from physical attack. If a TPM location stores only vendor-specific cipher-text that does562 not require protection from physical attack, that location can be ignored when563 determining whether the TPM complies with the "physical protection" requirements564 specified by TCG.565 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 16 Revision 94 29 March 2006 TCG Published 4. TPM Architecture566 4.1 Interoperability567 Start of informative comment568 The TPM must support a minimum set of algorithms and operations to meet TCG569 specifications.570 Algorithms571 RSA, SHA-1, HMAC572 The algorithms and protocols are the minimum that the TPM must support. Additional573 algorithms and protocols may be available to the TPM. All algorithms and protocols574 available in the TPM must be included in the TPM and platform credential.575 The reason to specify these algorithms is two fold. The first is to know and understand the576 security properties of selected algorithms; identify appropriate key sizes and ensure577 appropriate use in protocols. The second reason is to define a base level of algorithms for578 interoperability.579 End of informative comment580 4.2 Components581 Start of informative comment582 The following is a block diagram Figure 4:a shows the major components of a TPM.583 584 Figure 4:a - TPM Component Architecture585 End of informative comment586 Key Generation I/O C2 Cryptographic Co-Processor C0 C1 Opt-In Power Detection RNG Communication Bus C7 C6 C4 HMAC Engine SHA-1 Engine Execution Engine Volatile Memory Non-Volatile Memory C3 C8 C5 C10 C9 Rev 0.3 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 17 TCG Published 4.2.1 Input and Output587 Start of informative comment588 The I/O component, Figure 4:a C0, manages information flow over the communications589 bus. It performs protocol encoding/decoding suitable for communication over external and590 internal buses. It routes messages to appropriate components. The I/O component enforces591 access policies associated with the Opt-In component as well as other TPM functions592 requiring access control.593 The main specification does not require a specific I/O bus. Issues around a particular I/O594 bus are the purview of a platform specific specification.595 End of informative comment596 1. The number of incoming operand parameter bytes must exactly match the597 requirements of the command ordinal. If the command contains more or fewer bytes598 than required, the TPM MUST return TPM_BAD_PARAMETER.599 4.2.2 Cryptographic Co-Processor600 Start of informative comment601 The cryptographic co-processor, Figure 4:a C1, implements cryptographic operations within602 the TPM. The TPM employs conventional cryptographic operations in conventional ways.603 Those operations include the following:604 Asymmetric key generation (RSA)605 Asymmetric encryption/decryption (RSA)606 Hashing (SHA-1)607 Random number generation (RNG)608 The TPM uses these capabilities to perform generation of random data, generation of609 asymmetric keys, signing and confidentiality of stored data.610 The TPM may symmetric encryption for internal TPM use but does not expose any611 symmetric algorithm functions to general users of the TPM.612 The TPM may implement additional asymmetric algorithms. TPM devices that implement613 different algorithms may have different algorithms perform the signing and wrapping.614 End of informative comment615 1. The TPM MAY implement other asymmetric algorithms such as DSA or elliptic curve.616 a. These algorithms may be in use for wrapping, signatures and other operations. There617 is no guarantee that these keys can migrate to other TPM devices or that other TPM618 devices will accept signatures from these additional algorithms.619 2. All Storage keys MUST be of strength equivalent to a 2048 bits RSA key or greater. The620 TPM SHALL NOT load a Storage key whose strength less than that of a 2048 bits RSA621 key.622 3. All AIK MUST be of strength equivalent to a 2048 bits RSA key, or greater.623 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 18 Revision 94 29 March 2006 TCG Published 4.2.2.1 RSA Engine624 Start of informative comment625 The RSA asymmetric algorithm is used for digital signatures and for encryption.626 For RSA keys the PKCS #1 standard provides the implementation details for digital627 signature, encryption and data formats.628 There is no requirement concerning how the RSA algorithm is to be implemented. TPM629 manufacturers may use Chinese Remainder Theorem (CRT) implementations or any other630 method. Designers should review P1363 for guidance on RSA implementations.631 End of informative comment632 1. The TPM MUST support RSA.633 2. The TPM MUST use the RSA algorithm for encryption and digital signatures.634 3. The TPM MUST support key sizes of 512, 768, 1024, and 2048 bits. The TPM MAY635 support other key sizes.636 a. The minimum RECOMMENDED key size is 2048 bits.637 4. The RSA public exponent MUST be e, where e = 216+1.638 5. TPM devices that use CRT as the RSA implementation MUST provide protection and639 detection of failures during the CRT process to avoid attacks on the private key.640 4.2.2.2 Signature Operations641 Start of informative comment642 The TPM performs signatures on both internal items and on requested external blobs. The643 rules for signatures apply to both operations.644 End of informative comment645 1. The TPM MUST use the RSA algorithm for signature operations where signed data is646 verified by entities other than the TPM that performed the sign operation.647 2. The TPM MAY use other asymmetric algorithms for signatures; however, there is no648 requirement that other TPM devices either accept or verify those signatures.649 3. The TPM MUST use P1363 for the format and design of the signature output.650 4.2.2.3 Symmetric Encryption Engine651 Start of informative comment652 The TPM uses symmetric encryption to encrypt authentication information, provide653 confidentiality in transport sessions and provide internal encryption of blobs stored off of654 the TPM.655 For authentication and transport sessions, the mandatory mechanism is a Vernam one-656 time-pad with XOR. The mechanism to generate the one-time-pad is MGF1 and the nonces657 from the session protocol. When encrypting authorization data, the authorization data and658 the nonces are the same size, 20 bytes, so a direct XOR is possible.659 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 19 TCG Published For transport sessions the size of data is larger than the nonces so there needs to be a660 mechanism to expand the entropy to the size of the data. The mechanism to expand the661 entropy is the MGF1 function from PKCS#1. This function provides a known mechanism662 that does not lower the entropy of the nonces.663 AES may be supported as an alternate symmetric key encryption algorithm.664 Internal protection of information can use any symmetric algorithm that the TPM designer665 feels provides the proper level of protection.666 The TPM does not expose any of the symmetric operations for general message encryption.667 End of informative comment668 4.2.2.4 Using Keys669 Start of Informative comments:670 Keys can be symmetric or asymmetric.671 As the TPM does not have an exposed symmetric algorithm, the TPM is only a generator,672 storage device and protector of symmetric keys. Generation of the symmetric key would use673 the TPM RNG. Storage and protection would be provided by the BIND and SEAL capabilities674 of the TPM. If the caller wants to ensure that the release of a symmetric key is not exposed675 after UNBIND/UNSEAL on delivery to the caller, the caller should use a transport session676 with confidentiality set.677 For asymmetric algorithms, the TPM generates and operates on RSA keys. The keys can be678 held only by the TPM or in conjunction with the caller of the TPM. If the private portion of a679 key is in use outside of the TPM it is the responsibility of the caller and user of that key to680 ensure the protections of the key.681 The TPM has provisions to indicate if a key is held exclusively for the TPM or can be shared682 with entities off of the TPM.683 End of informative comments.684 1. A secret key is a key that is a private asymmetric key or a symmetric key.685 2. Data SHOULD NOT be used as a secret key by a TCG protected capability unless that686 data has been extant only in a shielded location.687 3. A key generated by a TCG protected capability SHALL NOT be used as a secret key688 unless that key has been extant only in a shielded location.689 4. A secret key obtained by a TCG protected capability from a Protected Storage blob690 SHALL be extant only in a shielded location.691 4.2.3 Key Generation692 Start of informative comment693 The Key Generation component, Figure 4:a C2, creates RSA key pairs and symmetric keys.694 TCG places no minimum requirements on key generation times for asymmetric or695 symmetric keys.696 End of informative comment697 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 20 Revision 94 29 March 2006 TCG Published 4.2.3.1 Asymmetric ­ RSA698 The TPM MUST generate asymmetric key pairs. The generate function is a protected699 capability and the private key is held in a shielded location. The implementation of the700 generate function MUST be in accordance with P1363.701 The prime-number testing for the RSA algorithm MUST use the definitions of P1363. If702 additional asymmetric algorithms are available, they MUST use the definitions from P1363703 for the underlying basis of the asymmetric key (for example, elliptic curve fitting).704 4.2.3.2 Nonce Creation705 The creation of all nonce values MUST use the next n bits from the TPM RNG.706 4.2.4 HMAC Engine707 Start of informative comment708 The HMAC engine, Figure 4:a C3, provides two pieces of information to the TPM: proof of709 knowledge of the AuthData and proof that the request arriving is authorized and has no710 modifications made to the command in transit.711 The HMAC definition is for the HMAC calculation only. It does not specify the order or712 mechanism that transports the data from caller to actual TPM.713 The creation of the HMAC is order dependent. Each command has specific items that are714 portions of the HMAC calculation. The actual calculation starts with the definition from715 RFC 2104.716 RFC 2104 requires the selection of two parameters to properly define the HMAC in use.717 These values are the key length and the block size. This specification will use a key length718 of 20 bytes and a block size of 64 bytes. These values are known in the RFC as K for the key719 length and B as the block size.720 The basic construct is721 H(K XOR opad, H(K XOR ipad, text))722 where723 H = the SHA1 hash operation724 K = the key or the AuthData725 XOR = the xor operation726 opad = the byte 0x5C repeated B times727 B = the block length728 ipad = the byte 0x36 repeated B times729 text = the message information and any parameters from the command730 End of informative comment731 The TPM MUST support the calculation of an HMAC according to RFC 2104.732 The size of the key (K in RFC 2104) MUST be 20 bytes. The block size (B in RFC 2104)733 MUST be 64 bytes.734 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 21 TCG Published The order of the parameters is critical to the TPM's ability to recreate the HMAC. Not all of735 the fields are sent on the wire for each command for instance only one of the nonce values736 travels on the wire. Each command interface definition indicates what parameters are737 involved in the HMAC calculation.738 4.2.5 Random Number Generator739 Start of informative comment740 The Random Number Generator (RNG) component, Figure 6:a C4 is the source of741 randomness in the TPM. The TPM uses these random values for nonces, key generation,742 and randomness in signatures.743 The RNG consists of a state-machine that accepts and mixes unpredictable data and a post-744 processor that has a one-way function (e.g. SHA-1). The idea behind the design is that a745 TPM can be good source of randomness without having to require a genuine source of746 hardware entropy.747 The state-machine can have a non-volatile state initialized with unpredictable random data748 during TPM manufacturing before delivery of the TPM to the customers. The state-machine749 can accept, at any time, further (unpredictable) data, or entropy, to salt the random750 number. Such data comes from hardware or software sources ­ for example; from thermal751 noise, or by monitoring random keyboard strokes or mouse movements. The RNG requires a752 reseeding after each reset of the TPM. A true hardware source of entropy is likely to supply753 entropy at a higher baud rate than a software source.754 When adding entropy to the state-machine the process must ensure that after the addition,755 no outside source can gain any visibility into the new state of the state-machine. Neither756 the Owner of the TPM, nor the manufacturer of the TPM can deduce the state of the state-757 machine after shipment of the TPM. The RNG post-processor condenses the output of the758 state-machine into data that has sufficient and uniform entropy. The one-way function759 should use more bits of input data than it produces as output.760 Our definition of the RNG allows implementation of a Pseudo Random Number Generator761 (PRNG) algorithm. However, on devices where a hardware source of entropy is available, a762 PRNG need not be implemented. This specification refers to both RNG and PRNG763 implementations as the RNG mechanism. There is no need to distinguish between the two764 at the TCG specification level.765 The TPM should be able to provide 32 bytes of randomness on each call. Larger requests766 may fail with not enough randomness being available.767 End of informative comment768 1. The RNG for the TPM will consist of the following components:769 a. Entropy source and collector770 b. State register771 c. Mixing function772 2. The RNG capability is a TPM-protected capability with no access control.773 3. The RNG output may or may not be shielded data. When the data is for internal use by774 the TPM (e.g., asymmetric key generation) the data MUST be held in a shielded location.775 When the data is for use by the TSS or another external caller, the data is not shielded.776 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 22 Revision 94 29 March 2006 TCG Published 4.2.5.1 Entropy Source and Collector777 Start of informative comment778 The entropy source is the process or processes that provide entropy. These types of sources779 could include noise, clock variations, air movement, and other types of events.780 The entropy collector is the process that collects the entropy, removes bias, and smoothes781 the output. The collector differs from the mixing function in that the collector may have782 special code to handle any bias or skewing of the raw entropy data. For instance, if the783 entropy source has a bias of creating 60 percent 1s and only 40 percent 0s, then the784 collector design takes that bias into account before sending the information to the state785 register.786 End of informative comment787 1. The entropy source MUST provide entropy to the state register in a manner that provides788 entropy that is not visible to an outside process.789 a. For compliance purposes, the entropy source MAY be outside of the TPM; however,790 attention MUST be paid to the reporting mechanism.791 2. The entropy source MUST provide the information only to the state register.792 a. The entropy source may provide information that has a bias, so the entropy collector793 must remove the bias before updating the state register. The bias removal could use794 the mixing function or a function specifically designed to handle the bias of the795 entropy source.796 b. The entropy source can be a single device (such as hardware noise) or a combination797 of events (such as disk timings). It is the responsibility of the entropy collector to798 update the state register whenever the collector has additional entropy.799 4.2.5.2 State Register800 Start of informative comment801 The state register implementation may use two registers: a non-volatile register rngState802 and a volatile register. The TPM loads the volatile register from the non-volatile register on803 startup. Each subsequent change to the state register from either the entropy source or the804 mixing function affects the volatile state register. The TPM saves the current value of the805 volatile state register to the non-volatile register on TPM power-down. The TPM may update806 the non-volatile register at any other time. The reasons for using two registers are:807 To handle an implementation in which the non-volatile register is in a flash device;808 To avoid overuse of the flash, as the number of writes to a flash device are limited.809 End of informative comment810 1. The state register is in a TPM shielded-location.811 a. The state register MUST be non-volatile.812 b. The update function to the state register is a TPM protected-capability.813 c. The primary input to the update function SHOULD be the entropy collector.814 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 23 TCG Published 2. If the current value of the state register is unknown, calls made to the update function815 with known data MUST NOT result in the state register ending up in a state that an816 attacker could know.817 a. This requirement implies that the addition of known data MUST NOT result in a818 decrease in the entropy of the state register.819 3. The TPM MUST NOT export the state register.820 4.2.5.3 Mixing Function821 Start of informative comment822 The mixing function takes the state register and produces output. The mixing function is a823 TPM protected-capability. The mixing function takes the value from a state register and824 creates the RNG output. If the entropy source has a bias, then the collector takes that bias825 into account before sending the information to the state register.826 End of informative comment827 1. Each use of the mixing function MUST affect the state register.828 a. This requirement is to affect the volatile register and does not need to affect the non-829 volatile state register.830 4.2.5.4 RNG Reset831 Start of informative comment832 The resetting of the RNG occurs at least in response to a loss of power to the device.833 These tests prove only that the RNG is still operating properly; they do not prove how much834 entropy is in the state register. This is why the self-test checks only after the load of835 previous state and may occur before the addition of more entropy.836 End of informative comment837 1. The RNG MUST NOT output any bits after a system reset until the following occurs:838 a. The entropy collector performs an update on the state register. This does not include839 the adding of the previous state but requires at least one bit of entropy.840 b. The mixing function performs a self-test. This self-test MUST occur after the loading841 of the previous state. It MAY occur before the entropy collector performs the first842 update.843 4.2.6 SHA-1 Engine844 Start of informative comment845 The SHA-1, Figure 4:a C5, hash capability is primarily used by the TPM, as it is a trusted846 implementation of a hash algorithm. The hash interfaces are exposed outside the TPM to847 support Measurement taking during platform boot phases and to allow environments that848 have limited capabilities access to a hash functions. The TPM is not a cryptographic849 accelerator. TCG does not specify minimum throughput requirements for TPM hash850 services.851 End of informative comment852 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 24 Revision 94 29 March 2006 TCG Published 1. The TPM MUST implement the SHA-1 hash algorithm as defined by FIPS-180-1.853 2. The output of SHA-1 is 160 bits and all areas that expect a hash value are REQUIRED854 to support the full 160 bits.855 3. The only commands that SHALL be presented to the TPM in-between a TPM_SHA1Start856 command and a TPM_SHA1Complete command SHALL be a variable number (possibly857 0) of TPM_SHA1Update commands.858 a. The TPM_SHA1Update commands can occur in a transport session.859 4. Throughout all parts of the specification the characters x1 || x2 imply the860 concatenation of x1 and x2861 4.2.7 Power Detection862 Start of informative comment863 The power detection component, Figure 4:a C6, manages the TPM power states in864 conjunction with platform power states. TCG requires that the TPM be notified of all power865 state changes.866 Power detection also supports physical presence assertions. The TPM may restrict867 command-execution during periods when the operation of the platform is physically868 constrained. In a PC, operational constraints occur during the power-on self-test (POST)869 and require Operator input via the keyboard. The TPM might allow access to certain870 commands while in a constrained execution mode or boot state. At some critical point in the871 POST process, the TPM may be notified of state changes that affect TPM command872 processing modes.873 End of informative comment874 4.2.8 Opt-In875 Start of informative comment876 The Opt-In component, Figure 4:a C7, provides mechanisms and protections to allow the877 TPM to be turned on/off, enabled/disabled, activated/deactivated.. The Opt-In component878 maintains the state of persistent and volatile flags and enforces the semantics associated879 with these flags.880 The setting of flags requires either authorization by the TPM Owner or the assertion of881 physical presence at the platform. The platform's manufacturer determines the techniques882 used to represent physical-presence. The guiding principle is that no remote entity should883 be able to change TPM status without either knowledge of the TPM Owner or the Operator is884 physically present at the platform. Physical presence may be asserted during a period when885 platform operation is constrained such as power-up.886 Non-Volatile Flags:887 PhysicalPresenceLifetimeLock888 PhysicalPresenceHWEnable889 PhysicalPresenceCMDEnable890 Volatile Flags:891 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 25 TCG Published PhysicalPresenceV892 The following truth table explains the conditions in which the PhysicalPresenceV flag may893 be altered:894 Persistent / Volatile P P P V Control Flags PhysicalPresenceLifetimeLock PhysicalPresenceHWEnable PhysicalPresenceCMDEnable PhysicalPresenceV - F F - F T T No access to PhysicalPresenceV flag. - - T F Access to PhysicalPresenceV flag through TCS_PhysicalPresence command enabled. - T - - Access to PhysicalPresenceV flag through hardware signal enabled. Volatile Access Semantics to Physical Presence Flag - T T F Access to PhysicalPresenceV flag through hardware signal or TCS_PhysicalPresence command enabled. T F F T F T T Access to PhysicalPresenceV flag permanently disabled. T F T F Exclusive access to PhysicalPresenceV flag through TCS_PhysicalPresence command permanently enabled. T T F - Exclusive access to PhysicalPresenceV flag through hardware signal permanently enabled. Persistent Access Semantics to Physical Presence Flag T T T F Access to PhysicalPresenceV flag through hardware signal or TCS_PhysicalPresence command permanently enabled. Table 4:a - Physical Presence Semantics895 TCG also recognizes the concept of unambiguous physical presence. Conceptually, the use896 of dedicated electrical hardware providing a trusted path to the Operator has higher897 precedence than the physicalPresenceV flag value. Unambiguous physical presence may be898 used to override physicalPresenceV flag value under conditions specified by platform899 specific design considerations.900 Additional details relating to physical presence can be found in sections on Volatile and901 Non-volatile memory.902 End of informative comment903 4.2.9 Execution Engine904 Start of informative comment905 The execution engine, Figure 4:a C8, runs program code to execute the TPM commands906 received from the I/O port. The execution engine is a vital component in ensuring that907 operations are properly segregated and shield locations are protected.908 End of informative comment909 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 26 Revision 94 29 March 2006 TCG Published 4.2.10 Non-Volatile Memory910 Start of informative comment911 Non-volatile memory component, Figure 4:a C9, is used to store persistent identity and912 state associated with the TPM. The NV area has set items (like the EK) and also is available913 for allocation and use by entities authorized by the TPM Owner.914 The TPM designer should consider the use model of the TPM and if the use of NV storage is915 a concern. NV storage does have a limited life and using the NV storage in a high volume916 use model may prematurely wear out the TPM.917 End of informative comment918 4.3 Data Integrity Register (DIR)919 Start of informative comment920 The DIR were a version 1.1 function. They provided a place to store information using the921 TPM NV storage.922 In 1.2 the DIR are deprecated and the use of the DIR should move to the general purpose923 NV storage area.924 The TPM must still support the functionality of the DIR register in the NV storage area.925 End of informative comment926 1. A TPM MUST provide one Data Integrity Register (DIR)927 a. The TPM DIR commands are deprecated in 1.2928 b. The TPM MUST reserve the space for one DIR in the NV storage area929 c. The TPM MAY have more than 1 DIR.930 2. The DIR MUST be 160-bit values and MUST be held in TPM shielded-locations.931 3. The DIR MUST be non-volatile (values are maintained during the power-off state).932 a. A TPM implementation need not provide the same number of DIRs as PCRs.933 4.4 Platform Configuration Register (PCR)934 Start of informative comment935 A Platform Configuration Register (PCR) is a 160-bit storage location for discrete integrity936 measurements. There are a minimum of 16 PCR registers. All PCR registers are shielded-937 locations and are inside of the TPM. The decision of whether a PCR contains a standard938 measurement or if the PCR is available for general use is deferred to the platform specific939 specification.940 A large number of integrity metrics may be measured in a platform, and a particular941 integrity metric may change with time and a new value may need to be stored. It is difficult942 to authenticate the source of measurement of integrity metrics, and as a result a new value943 of an integrity metric cannot be permitted to simply overwrite an existing value. (A rogue944 could erase an existing value that indicates subversion and replace it with a benign value.)945 Thus, if values of integrity metrics are individually stored, and updates of integrity metrics946 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 27 TCG Published must be individually stored, it is difficult to place an upper bound on the size of memory947 that is required to store integrity metrics.948 The PCR is designed to hold an unlimited number of measurements in the register. It does949 this by using a cryptographic hash and hashing all updates to a PCR. The pseudo code for950 this is:951 PCRi New = HASH ( PCRi Old value || value to add)952 There are two salient properties of cryptographic hash that relate to PCR construction.953 Ordering ­ meaning updates to PCRs are not commutative. For example, measuring (A then954 B) is not the same as measuring (B then A).955 The other hash property is one-way-ness. This property means it should be computationally956 infeasible for an attacker to determine the input message given a PCR value. Furthermore,957 subsequent updates to a PCR cannot be determined without knowledge of the previous PCR958 values or all previous input messages provided to a PCR register since the last reset.959 End of informative comment960 1. The PCR MUST be a 160-bit field that holds a cumulatively updated hash value961 2. The PCR MUST have a status field associated with it962 3. The PCR MUST be in the RTS and should be in volatile storage963 4. The PCR MUST allow for an unlimited number of measurements to be stored in the PCR964 5. The PCR MUST preserve the ordering of measurements presented to it965 6. A PCR MUST be set to the default value as specified by the PCRReset attribute966 7. A TPM implementation MUST provide 16 or more independent PCRs. These PCRs are967 identified by index and MUST be numbered from 0 (that is, PCR0 through PCR15 are968 required for TCG compliance). Vendors MAY implement more registers for general-969 purpose use. Extra registers MUST be numbered contiguously from 16 up to max ­ 1,970 where max is the maximum offered by the TPM.971 8. The TCG-protected capabilities that expose and modify the PCRs use a 32-bit index,972 indicating the maximum usable PCR index. However, TCG reserves register indices 230973 and higher for later versions of the specification. A TPM implementation MUST NOT974 provide registers with indices greater than or equal to 230. In this specification, the975 following terminology is used (although this internal format is not mandated).976 9. The PSS MUST define at least define one measurement that the RTM MUST make and977 the PCR where the measurement is stored.978 10.A TCG measurement agent MAY discard a duplicate event instead of incorporating it in a979 PCR, provided that:980 11.A relevant TCG platform specification explicitly permits duplicates of this type of event to981 be discarded982 12.The PCR already incorporates at least one event of this type983 13.An event of this type previously incorporated into the PCR included a statement that984 duplicate such events may be discarded. This option could be used where frequent985 recording of sleep states will adversely affect the lifetime of a TPM, for example.986 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 28 Revision 94 29 March 2006 TCG Published 14.PCRs and the protected capabilities that operate upon them MAY NOT be used until987 power-on self-test (TPM POST) has completed. If TPM POST fails, the TPM_Extend988 operation will fail; and, of greater importance, the TPM_Quote operation and TPM_Seal989 operations that respectively report and examine the PCR contents MUST fail. At the990 successful completion of TPM POST, all PCRs MUST be set to their default value (either991 0x00...00 or 0xFF...FF). Additionally, the UINT32 flags MUST be set to zero.992 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 29 TCG Published 5. Endorsement Key Creation993 Start of informative comment994 The TPM contains a 2048-bit RSA key pair called the endorsement key (EK). The public995 portion of the key is the PUBEK and the private portion the PRIVEK. Due to the nature of996 this key pair, both the PUBEK and the PRIVEK have privacy and security concerns.997 The TPM has the EK generated before the end customer receives the platform. The entity998 that causes EK generation is also the entity that will create a credential attesting to the999 validity of the TPM and the EK.1000 The TPM can generate the EK internally using the TPM_CreateEndorsementKey or by using1001 an outside key generator. The EK needs to indicate the genealogy of the EK generation.1002 Subsequent attempts to either generate an EK or insert an EK must fail.1003 If the data structure TPM_ENDORSEMENT_CREDENTIAL is stored on a platform after an1004 Owner has taken ownership of that platform, it SHALL exist only in storage to which access1005 is controlled and is available to authorized entities.1006 End of informative comment1007 1. The EK MUST be a 2048-bit RSA key1008 a. The public portion of the key is the PUBEK1009 b. The private portion of the key is the PRIVEK1010 c. The PRIVEK SHALL exist only in a TPM-shielded location.1011 2. Access to the PRIVEK and PUBEK MUST only be via TPM protected capabilities1012 a. The protected capabilities MUST require TPM Owner authentication or operator1013 physical presence1014 3. The generation of the EK may use a process external to the TPM and1015 TPM_CreateEndorsementKeyPair1016 a. The external generation MUST result in an EK that has the same properties as an1017 internally generated EK1018 b. The external generation process MUST protect the EK from exposure during the1019 generation and insertion of the EK1020 c. After insertion of the EK the TPM state MUST be the same as the result of the1021 TPM_CreateEndorsementKeyPair execution1022 d. The process MUST guarantee correct generation, cryptographic strength,1023 uniqueness, privacy, and installation into a genuine TPM, of the EK1024 e. The entity that signs the EK credential MUST be satisfied that the generation process1025 properly generated the EK and inserted it into the TPM1026 f. The process MUST be defined in the target of evaluation (TOE) of the security target1027 in use to evaluate the TPM1028 5.1 Controlling Access to PRIVEK1029 Start of informative comment1030 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 30 Revision 94 29 March 2006 TCG Published Exposure of the PRIVEK is a security concern.1031 The TPM must ensure that the PRIVEK is not exposed outside of the TPM1032 End of informative comment1033 1. The PRIVEK MUST never be out of the control of a TPM shielded location1034 5.2 Controlling Access to PUBEK1035 Start of informative comment1036 There are no security concerns with exposure or use of the PUBEK.1037 Privacy guidelines suggest that PUBEK could be considered personally identifiable1038 information (PII) if it were associated in some way with personal information (PI) or1039 associated with other PII, but PUBEK alone cannot be considered PII. Arbitrary random1040 numbers do not represent a threat to privacy unless further associated with PI or PII. The1041 PUBEK is an arbitrary random number that may be associated with aggregate platform1042 information, but not personally identifiable information.1043 An EK may become associated with personally identifiable information when an alias1044 platform identifier (AIK) is also associated with PI. The attestation service could include1045 personal information in the AIK credential, thereby making the AIK-PUBEK association PII ­1046 but not before.1047 The association of PUBEK with AIK therefore is important to protect via privacy guidelines.1048 The owner/user of the TPM should be able to control whether PUBEK is disclosed along1049 with AIK. The owner/user should be notified of personal information that might be added to1050 an AIK credential, which could result in AIK being considered PII. The owner/user should1051 be able to evaluate the mechanisms used by an attestation entity to protect PUBEK-AIK1052 associations before disclosure occurs. No other entity should be privy to owner/user1053 authorized disclosure besides the intended attestation entity.1054 Several commands may be used to negotiate the conditions of PUBEK-AIK disclosure.1055 TPM_MakeIdentity discloses PUBEK-AIK in the context of requesting an AIK credential.1056 TPM_ActivateIdentity ensures the owner/user has not been spoofed by an interloper. These1057 interfaces allow the owner/user to choose whether disclosure is acceptable and control the1058 circumstances under which disclosure takes place. They do not allow the owner/user the1059 ability to retain control of PUBEK-AIK subsequent to disclosure except by traditional means1060 of trusting the attestation entity to abide by an acceptable privacy policy. The owner/user is1061 able to associate the accepted privacy policy with the disclosure operation (e.g.1062 TPM_MakeIdentity).1063 A persistent flag called readPubek can be set to TRUE to permit reading of PUBEK via1064 TPM_ReadPubek. Reporting the PUBEK value is not considered privacy sensitive because it1065 cannot be associated with any of the AIK keys managed by the TPM without using TPM1066 protected-capabilities.. Keys are encrypted with a nonce when flushed from TPM shielded-1067 locations, Cryptanalysis of flushed keys will not reveal an association of EK to any AIK...1068 The command that manipulates the readPubek flag is TPM_DisablePubekRead.1069 End of informative comment1070 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 31 TCG Published 6. Attestation Identity Keys1071 Start of informative comment1072 The Attestation Identity Key (AIK) is an alias to the Endorsement Key (EK). The AIK is a1073 2048-bit RSA key. Generation of an AIK can occur anytime after establishment of the TPM1074 Owner. The TPM can generate a virtually unlimited number of AIK.1075 The TPM Owner controls all aspects of the generation and activation of an AIK. The TPM1076 Owner controls any data associated with the AIK. The AIK credential may contain1077 application specific information.1078 An AIK is a signature key and it signs information generated internally by the TPM. The1079 data would include PCR, other keys and TPM status information. The AIK is a substitute for1080 the EK, which cannot perform signatures for security reasons and cannot perform1081 signatures due to privacy concerns.1082 AIK creation involves three TPM commands.1083 The TPM_MakeIdentity command causes the TPM to generate the AIK key pair. The1084 command also discloses the EK-AIK binding to the service that will issue the AIK credential.1085 The TPM_ActivateIdentity command unwraps a session key that allows for the decryption of1086 the AIK credential. The session key was encrypted using the PUBEK and requires the1087 PRIVEK to perform the decryption.1088 The TPM_RecoverIdentity allows for a subsequent recovery of the session key by again1089 performing the decryption using the PRIVEK.1090 Use of the AIK credential is outside of the control of the TPM.1091 The user of an AIK must prove knowledge of the 160-bit AIK authentication value to use the1092 AIK.1093 End of informative comment1094 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 32 Revision 94 29 March 2006 TCG Published 7. TPM Ownership1095 Start of informative comment1096 Taking ownership of a TPM is the process of inserting a shared secret into a TPM shielded-1097 location. Any entity that knows the shared secret is a TPM Owner. Proof of ownership1098 occurs when an entity, in response to a challenge, proves knowledge of the shared secret.1099 Certain operations in the TPM require authentication from a TPM Owner.1100 Certain operations also allow the human, with physical possession of the platform, to assert1101 TPM Ownership rights. When asserting TPM Ownership, using physical presence, the1102 operations must not expose any secrets protected by the TPM.1103 The platform owner controls insertion of the shared secret into the TPM. The platform1104 owner sets the NV persistent flag ownershipEnabled that allows the execution of the1105 TPM_TakeOwnership command. The TPM_SetOwnerInstall, the command that controls the1106 value ownershipEnabled, requires the assertion of physical presence.1107 Attempting to execute TPM_TakeOwnership fails when a TPM already has an owner. To1108 remove an owner when the current TPM Owner is unable to remove themselves, the human1109 that is in possession of the platform asserts physical presence and executes1110 TPM_ForceClear which removes the shared secret.1111 The insertion protocol that supplies the shared secret has the following requirements:1112 confidentiality, integrity, remoteness and verifiability.1113 To provide confidentiality the proposed TPM Owner encrypts the shared secret using the1114 PUBEK. This requires the PRIVEK to decrypt the value. As the PRIVEK is only available in1115 the TPM the encrypted shared secret is only available to the intended TPM.1116 The integrity of the process occurs by the TPM providing proof of the value of the shared1117 secret inserted into the TPM.1118 By using the confidentiality and integrity, the protocol is useable by TPM Owners that are1119 remote to the platform.1120 The new TPM Owner validates the insertion of the shared secret by using integrity response.1121 End of informative comment1122 The TPM MUST ship with no Owner installed. The TPM MUST use the ownership-control1123 protocol (OIAP or OSAP)1124 7.1 Platform Ownership and Root of Trust for Storage1125 Start of informative comment1126 The semantics of platform ownership are tied to the Root-of-trust-for-storage (RTS). The1127 TPM_TakeOwnership command creates a new Storage Root Key (SRK) and new tpmProof1128 value whenever a new owner is established. It follows that objects owned by a previous1129 owner will not be inherited by the new owner. Objects that should be inherited must be1130 transferred by deliberate data migration actions.1131 End of informative comment1132 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 33 TCG Published 8. Authentication and Authorization Data1133 Start of informative comment1134 Using security vernacular the terms below apply to the TPM for this discussion:1135 Authentication: The process of providing proof of claimed ownership of an object or a1136 subjecťs claimed identity.1137 Authorization: Granting a subject appropriate access to an object.1138 Each TPM object that does not allow "public" access contains a 160-bit shared secret. This1139 shared secret is enveloped within the object itself. The TPM grants use of TPM objects based1140 on the presentation of the matching 160-bits using protocols designed to provide protection1141 of the shared secret. This shared secret is called the AuthData.1142 Neither the TPM, nor its objects (such as keys), contain access controls for its objects (the1143 exception to this is what is provided by the delegation mechanism). If an subject presents1144 the AuthData, that subject is granted full use of the object based on the objecťs1145 capabilities, not a set of rights or permissions of the subject. This apparent overloading of1146 the concepts of authentication and authorization has caused some confusion. This is1147 caused by having two similarly rooted but distinct perspectives.1148 From the perspective of the TPM looking out, this AuthData is its sole mechanism for1149 authenticating the owner of its objects, thus from its perspective it is authentication data.1150 However, from the application's perspective this data is typically the result of other1151 functions that might perform authentications or authorizations of subjects using higher1152 level mechanisms such as OS login, file system access, etc. Here, AuthData is a result of1153 these functions so in this usage, it authorizes access to the TPM's objects. From this1154 perspective, i.e., the application looking in on the TPM and its objects, the AuthData is1155 authorization data. For this reason, and thanks to a common root within the English1156 language, the term for this data is chosen to be AuthData and is to be interpreted or1157 expanded as either authentication data or authorization data depending on context and1158 perspective.1159 The term AuthData refers to the 160-bit value used to either prove ownership of, or1160 authorization to use, an object. This is also called the objecťs shared secret. The term1161 authorization will be used when referring the combined action of verifying the AuthData and1162 allowing access to the object or function. The term authorization session applies to a state1163 where the AuthData has been authentication and a session handle established that is1164 associated with that authentication.1165 A wide-range of objects use AuthData. It is used to establish platform ownership, key use1166 restrictions, object migration and to apply access control to opaque objects protected by the1167 TPM.1168 AuthData is a 160-bit shared-secret plus high-entropy random number. The assumption is1169 the shared-secret and random number are mixed using SHA-1 digesting, but no specific1170 function for generating AuthData is specified by TCG.1171 TCG command processing sessions (e.g. OSAP, ADIP) may use AuthData as an initialization1172 vector when creating a one-time pad. Session encryption is used to encrypt portions of1173 command messages exchanged between TPM and a caller.1174 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 34 Revision 94 29 March 2006 TCG Published The TPM stores AuthData with TPM controlled-objects and in shielded-locations. AuthData1175 is never in the clear, when managed by the TPM except in shielded-locations. Only TPM1176 protected-capabilities may access AuthData (contained in the TPM). AuthData objects may1177 not be used for any other purpose besides authentication and authorization of TPM1178 operations on controlled-objects.1179 Outside the TPM, a reference monitor of some kind is responsible for protecting AuthData.1180 AuthData should be regarded as a controlled data item (CDI) in the context of the security1181 model governing the reference monitor. TCG expects this entity to preserve the interests of1182 the platform Owner.1183 There is no requirement that instances of AuthData be unique.1184 End of informative comment1185 The TPM MUST reserve 160 bits for the AuthData. The TPM treats the AuthData as a blob.1186 The TPM MUST keep AuthData in a shielded-location.1187 The TPM MUST enforce that the only usage in the TPM of the AuthData is to perform1188 authorizations.1189 8.1 Dictionary Attack Considerations1190 Start of informative comment1191 The decision to provide protections against dictionary attacks is due to the inability of the1192 TPM to guarantee that an authorization value has high entropy. While the creation and1193 authorization protocols could change to support the assurance of high entropy values, the1194 changes would be drastic and would totally invalidate any 1.x TPM version.1195 Version 1.1 explicitly avoided any requirements for dictionary attack mitigation.1196 Version 1.2 adds the requirement that the TPM vendor provide some assistance against1197 dictionary attacks. The internal mechanism is vendor specific. The TPM designer should1198 review the requirements for dictionary attack mitigation in the Common Criteria.1199 The 1.2 specification does not provide any functions to turn on the dictionary attack1200 prevention. The specification does provide a way to reset from the TPM response to an1201 attack.1202 By way of example, the following is a way to implement the dictionary attack mitigation.1203 The TPM keeps a count of failed authorization attempts. The vendor allows the TPM Owner1204 to set a threshold of failed authorizations. When the count exceeds the threshold, the TPM1205 locks up and does not respond to any requests for a time out period. The time out period1206 doubles each time the count exceeds the threshold. If the TPM resets during a time out1207 period, the time out period starts over after TPM_Init, or TPM_Startup. To reset the count1208 and the time out period the TPM Owner executes TPM_ResetLockValue. If the authorization1209 for TPM_ResetLockValue fails, the TPM must lock up for the entire time out period and no1210 additional attempts at unlocking will be successful. Executing TPM_ResetLockValue when1211 outside of a time out period still results in the resetting of the count and time out period.1212 End of informative comment1213 The TPM SHALL incorporate mechanism(s) that will provide some protection against1214 exhaustive or dictionary attacks on the authorization values stored within the TPM.1215 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 35 TCG Published This version of the TPM specification does NOT specify the particular strategy to be used.1216 Some examples might include locking out the TPM after a certain number of failures,1217 forcing a reboot under some combination of failures, or requiring specific actions on the1218 part of some actors after an attack has been detected. The mechanisms to manage these1219 strategies are vendor specific at this time.1220 If the TPM in response to the attacks locks up for some time period or requires a special1221 operation to restart, the TPM MUST prevent any authorized TPM command and MAY1222 prevent any TPM from executing until the mitigation mechanism completes. The TPM1223 Owner can reset the mechanism using the TPM_ResetLockValue command.1224 TPM_ResetLockValue MUST be allowed to run exactly once while the TPM is locked up.1225 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 36 Revision 94 29 March 2006 TCG Published 9. TPM Operation1226 Start of informative comment1227 Through the course of TPM operation, it may enter several operational modes that include1228 power-up, self-test, administrative modes and full operation. This section describes TPM1229 operational states and state transition criteria. Where applicable, the TPM commands used1230 to facilitate state transition or function are included in diagrams and descriptions.1231 The TPM keeps the information relative to the TPM operational state in a combination of1232 persistent and volatile flags. For ease of reading the persistent flags are prefixed by pFlags1233 and the volatile flags prefixed by vFlags.1234 The following state diagram describes TPM operational states at a high level. Subsequent1235 state diagrams drill-down to finer detail that describes fundamental operations, protections1236 on operations and the transitions between them.1237 The state diagrams use the following notation:1238 CompositeState - Signifies a state.1239 - Transitions between states are represented as a single headed arrows.1240 - Circular transitions indicate operations that don't result in a transition to another1241 state.1242 - Decision boxes split state flow based on a logical test. Decision conditions are called1243 Guards and are identified by bracketed text..1244 < [text] > Bracketed text indicates transitions that are gated. Text within the brackets1245 describes the pre-condition that must be met before state transition may occur.1246 < /name > Transitions may list the events that trigger state transition. The forward slash1247 demarcates event names.1248 - The starting point for reading state diagrams.1249 - The ending point for state diagrams. Perpetual state systems may not have an ending1250 indicator.1251 - The collection bar consolidates multiple identical transition events into a single1252 transition arrow.1253 - The distribution bar splits transitions to flow into multiple states.1254 H - The history indicator means state values are remembered across context switches or1255 power-cycles.1256 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 37 TCG Published End of informative comment1257 9.1 TPM Initialization & Operation State Flow1258 Start of informative comment1259 1260 Figure 9:a - TPM Operational States1261 End of informative comment1262 9.1.1 Initialization1263 Start of informative comment1264 TPM_Init transitions the TPM from a power-off state to one where the TPM begins an1265 initialization process. TPM_Init could be the result of power being applied to the platform or1266 a hard reset.1267 TPM_Init sets an internal flag to indicate that the TPM is undergoing initialization. The TPM1268 must complete initialization before it is operational. The completion of initialization requires1269 the receipt of the TPM_Startup command.1270 The TPM is not fully operational until all of the self-tests are complete. Successful1271 completion of the self-tests allows the TPM to enter fully operational mode.1272 Fully operational does not imply that all functions of the TPM are available. The TPM needs1273 to have a TPM Owner and be enabled for all functions to be available.1274 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 38 Revision 94 29 March 2006 TCG Published The TPM transitions out of the operational mode by having power removed from the system.1275 Prior to the exiting operational mode, the TPM prepares for the transition by executing the1276 TPM_SaveState command. There is no requirement that TPM_SaveState execute before the1277 transition to power-off mode occurs.1278 End of informative comment1279 1. After TPM_Init and until receipt of TPM_Startup the TPM MUST return1280 TPM_INVALID_POSTINIT for all commands. Prior to receipt of TPM_Startup the TPM1281 MAY enter shutdown or failure mode.1282 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 39 TCG Published 9.2 Self-Test Modes1283 Start of informative comment1284 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 40 Revision 94 29 March 2006 TCG Published 1285 Figure 9:b - Self-Test States1286 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 41 TCG Published After initialization the TPM performs a limited self-test. This test provides the assurance1287 that a selected subset of TPM commands will perform properly. The limited nature of the1288 self-test allows the TPM to be functional in as short of time as possible. The commands1289 enabled by this self-test are:1290 TPM_SHA1xxx ­ Enabling the SHA-1 commands allows the TPM to assist the platform1291 startup code. The startup code may execute in an extremely constrained memory1292 environment and having the TPM resources available to perform hash functions can allow1293 the measurement of code at an early time. While the hash is available, there are no speed1294 requirements on the I/O bus to the TPM or on the TPM itself so use of this functionality1295 may not meet platform startup requirements.1296 TPM_Extend ­ Enabling the extend, and by reference the PCR, allows the startup code to1297 perform measurements. Extending could use the SHA-1 TPM commands or perform the1298 hash using the main processor.1299 TPM_Startup ­ This command must be available as it is the transition command from the1300 initial environment to the limited operational state.1301 TPM_ContinueSelfTest ­ This command causes the TPM to complete the self-tests on all1302 other TPM functions. If TPM receives a command, and the self-test for that command has1303 not been completed, the TPM may implicitly perform the actions of the1304 TPM_ContinueSelfTest command.1305 TPM_SelfTestFull ­ A TPM MAY allow this command after initialization, but typically1306 TPM_ContinueSelfTest would be used to avoid repeating the limited self tests.1307 TPM_GetCapability ­ A subset of capabilities can be read in the limited operation state.1308 The complete self-test ensures that all TPM functionality is available and functioning1309 properly.1310 End of informative comment1311 1. At startup, a TPM MUST self-test all internal functions that are necessary to do1312 TPM_SHA1Start, TPM_SHA1Update, TPM_SHA1Complete, TPM_SHA1CompleteExtend,1313 TPM_Extend, TPM_Startup, TPM_ContinueSelfTest, and a subset of TPM_GetCapability..1314 2. The TSC_PhysicalPresence and TSC_ResetEstablishmentBit commands do not operate1315 on shielded-locations and have no requirement to be self-tested before any use. TPM's1316 SHOULD test these functions before operation.1317 3. The TPM MAY allow TPM_SelfTestFull to be used before completion of the actions of1318 TPM_ContinueSelfTest.1319 4. The TPM MAY implicitly run the actions of TPM_ContinueSelfTest upon receipt of a1320 command that requires untested resources.1321 5. The platform specific specification MUST define the maximum startup self-test time.1322 9.2.1 Operational Self-Test1323 Start of informative comment1324 The completion of self-test is initiated by TPM_ContinueSelfTest. The TPM MAY allow1325 TPM_SelfTestFull to be issued instead of TPM_ContinueSelfTest.1326 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 42 Revision 94 29 March 2006 TCG Published TPM_ContinueSelfTest is the command issued during platform initialization after the1327 platform has made use of the early commands (perhaps for an early measurement), the1328 platform is now performing other initializations, and the TPM can be left alone to complete1329 the self-tests. Before any command other than the limited subset is executed, all self-tests1330 must be complete.1331 TPM_SelfTestFull is a request to have the TPM perform another complete self-test. This test1332 will take some time but provides an accurate assessment of the TPM's ability to perform all1333 operations.1334 The original design of TPM_ContinueSelfTest was for the TPM to test those functions that1335 the original startup did not test. The FIPS-140 evaluation of the specification requested a1336 change such that TPM_ContinueSelfTest would perform a complete self-test. The rationale1337 is that the original tests are only part of the initialization of the TPM; if they fail, the TPM1338 does not complete initialization. Performing a complete test after initialization meets the1339 FIPS-140 requirements. The TPM may work differently in FIPS mode or the TPM may simply1340 write the TPM_ContinueSelfTest command such that it always performs the complete check.1341 TPM_ContinueSelfTest causes a test of the TPM internal functions. When1342 TPM_ContinueSelfTest is asynchronous, the TPM immediately returns a successful result1343 code before starting the tests. When testing is complete, the TPM does not return any1344 result. When TPM_ContinueSelfTest is synchronous, the TPM completes the self-tests and1345 then returns a success or failure result code.1346 The TPM may reject any command other than the limited subset if self test has not been1347 completed. Alternatively, the actions of TPM_ContinueSelfTest may start automatically if the1348 TPM receives a command and there has been no testing of the underlying functionality. If1349 the TPM implements this implicit self-test, it may immediately return a result code1350 indicating that it is doing self-test. Alternatively, it may do the self-test, then do the1351 command, and return only the result code of the command.1352 Programmers of TPM drivers should take into account the time estimates for self-test and1353 minimize the polling for self-test completion. While self-test is executing, the TPM may1354 return an out-of-band "busy" signal to prevent command from being issued. Alternatively,1355 the TPM may accept the command but delay execution until after the self-test completes.1356 Either of those alternatives may appear as if the TPM is blocking to upper software layers.1357 Alternatively, the TPM may return an indication that is doing a self-test.1358 Upon the completion of the self-tests, the result of the self-tests are held in the TPM such1359 that a subsequent call to TPM_GetTestResult returns the self-test result.1360 In version 1.1, there was a separate command to create a signed self-test,1361 TPM_CertifySelfTest. Version 1.2 deprecates the command. The new use model is to perform1362 TPM_GetTestResult inside of a transport session and then use1363 TPM_ReleaseTransportSigned to obtain the signature.1364 If self-tests fail, the TPM goes into failure state and does not allow most other operations to1365 continue. The TPM_GetTestResult will operate in failure mode so an outside observer can1366 obtain information as to the reason for the self-test failure.1367 A TPM may take three courses of action when presented with a command that requires an1368 untested resource.1369 1. The TPM may return TPM_NEEDS_SELFTEST, indicating that the execution of the1370 command requires TPM_ContinueSelfTest.1371 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 43 TCG Published 2. The TPM may implicitly execute the self-test and return a TPM_DOING_SELFTEST1372 return code, causing the external software to retry the command.1373 3. The TPM may implicitly execute the self-test, execute the ordinal, and return the results1374 of the ordinal.1375 The following example shows how software can detect either mechanism with a single piece1376 of code1377 1. SW sends TPM_xxx command1378 2. SW checks return code from TPM1379 3. If return code is TPM_DOING_SELFTEST, SW attempts to resend1380 a. If the TIS times out waiting for TPM ready, pause for self-test time then resend1381 b. if TIS timeout, then error1382 4. else if return code is TPM_NEEDS_SELFTEST1383 a. Send TPM_ContinueSelfTest1384 5. else1385 a. Process the ordinal return code1386 End of informative comment1387 1. The TPM MUST provide startup self-tests. The TPM MUST provide mechanisms to allow1388 the self-tests to be run on demand. The response from the self-tests is pass or fail.1389 2. The TPM MUST complete the startup self-tests in a manner and timeliness that allows1390 the TPM to be of use to the BIOS during the collection of integrity metrics.1391 3. The TPM MUST complete the required checks before a given feature is in use. If a1392 function self-test is not complete the TPM MUST return TPM_NEEDS_SELFTEST or1393 TPM_DOING_SELFTEST, or do the self-test before using the feature.1394 4. There are two sections of startup self-tests: required and recommended. The1395 recommended tests are not a requirement due to timing constraints. The TPM1396 manufacturer should perform as many tests as possible in the time constraints.1397 5. The TPM MUST report the tests that it performs.1398 6. The TPM MUST provide a mechanism to allow self-test to execute on request by any1399 challenger.1400 7. The TPM MUST provide for testing of some operations during each execution of the1401 operation.1402 8. The TPM MUST check the following:1403 a. RNG functionality1404 b. Reading and extending the integrity registers. The self-test for the integrity registers1405 will leave the integrity registers in a known state.1406 c. Testing the EK integrity, if it exists1407 i. This requirement specifies that the TPM will verify that the endorsement key pair1408 can sign and verify a known value. This test also tests the RSA sign and verify1409 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 44 Revision 94 29 March 2006 TCG Published engine. If the EK has not yet been generated the TPM action is manufacturer1410 specific.1411 d. The integrity of the protected capabilities of the TPM1412 i. This means that the TPM must ensure that its "microcode" has not changed, and1413 not that a test must be run on each function.1414 e. Any tamper-resistance markers1415 i. The tests on the tamper-resistance or tamper-evident markers are under1416 programmable control. There is no requirement to check tamper-evident tape or1417 the status of epoxy surrounding the case.1418 9. The TPM SHOULD check the following:1419 a. The hash functionality1420 i. This check will hash a known value and compare it to an expected result. There is1421 no requirement to accept external data to perform the check.1422 ii. The TPM MAY support a test using external data.1423 b. Any symmetric algorithms1424 i. This check will use known data with a random key to encrypt and decrypt the1425 data1426 c. Any additional asymmetric algorithms1427 i. This check will use known data to encrypt and decrypt.1428 d. The key-wrapping mechanism1429 i. The TPM should wrap and unwrap a key. The TPM MUST NOT use the1430 endorsement key pair for this test.1431 e. Any other internal mechanisms1432 10.Self-Test Failure1433 a. When the TPM detects a failure during any self-test, the part experiencing the failure1434 MUST enter a shutdown mode. This shutdown mode will allow only the following1435 operations to occur:1436 i. Update. The update function MAY replace invalid microcode, providing that the1437 parts of the TPM that provide update functionality have passed self-test.1438 ii. TPM_GetTestResult. This command can assist the TPM manufacturer in1439 determining the cause of the self-test failure.1440 iii. TPM_GetCapability may return only the manufacturer and version.1441 iv. All other operations will return the error code TPM_FAILEDSELFTEST.1442 b. Upon entering failure mode, the TPM clears all information except those items1443 specified in TPM_OwnerClear.1444 c. If the TPM detects an attack, by whatever mechanism the TPM uses, the TPM MUST1445 invalidate all session keys and any internal keys, like AES, in use to store off-chip1446 blobs.1447 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 45 TCG Published 11.Prior to the completion of the actions of TPM_ContinueSelfTest the TPM MAY respond in1448 two ways1449 a. The TPM MAY automatically invoke the actions of TPM_ContinueSelfTest.1450 i. The TPM MAY return TPM_DOING_SELFTEST.1451 ii. The TPM may complete the self-test, execute the command, and return the1452 command result.1453 b. The TPM MAY return the error code TPM_NEEDS_SELFTEST1454 9.3 Startup1455 Start of informative comment1456 Startup transitions the TPM from the initialization state to an operational state. The1457 transition includes information from the platform to inform the TPM of the platform1458 operating state. TPM_Startup has three options: Clear, State and Deactivated.1459 The Clear option informs the TPM that the platform is starting in a "cleared" state or most1460 likely a complete reboot. The TPM is to set itself to the default values and operational state1461 specified by the TPM Owner.1462 The State option informs the TPM that the platform is requesting the TPM to recover a saved1463 state and continue operation from the saved state. The platform previously made the1464 TPM_SaveState request to the TPM such that the TPM prepares values to be recovered later.1465 The Deactivated state informs the TPM that it should not allow further operations and1466 should fail all subsequent command requests. The Deactivated state can only be reset by1467 performing another TPM_Init.1468 End of informative comment1469 9.4 Operational Mode1470 Start of informative comment1471 After the TPM completes both TPM_Startup and self-tests, the TPM is ready for operation.1472 There are three discrete states, enabled or disabled, active or inactive and owned or1473 unowned. These three states when combined form eight operational modes.1474 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 46 Revision 94 29 March 2006 TCG Published 1475 Figure 9:c - Eight Modes of Operation1476 S1 is the fully operational state where all TPM functions are available. S8 represents a mode1477 where all TPM features (except those to change the state) are off.1478 Given the eight modes of operation, the TPM can be flexible in accommodating a wide range1479 of usage scenarios. The default delivery state for a TPM should be S8 (disabled, inactive and1480 unowned). In S8, the only mechanism available to move the TPM to S1 is having physical1481 access to the platform.1482 Two examples illustrate the possibilities of shipping combinations.1483 Example 11484 The customer does not want the TPM to attest to any information relative to the platform.1485 The customer does not want any remote entity to attempt to change the control options that1486 the platform owner is setting. For this customer the platform manufacturer sets the TPM in1487 S8 (disabled, deactivated and unowned).1488 To change the state of the platform the platform owner would assert physical presence and1489 enable, activate and insert the TPM Owner shared secret. The details of how to change the1490 various modes is in subsequent sections.1491 This particular sequence gives maximum control to the customer.1492 Example 21493 A corporate customer wishes to have platforms shipped to their employees and the IT1494 department wishes to take control of the TPM remotely. To satisfy these needs the TPM1495 should be in S5 (enabled, active and unowned). When the platform connects to the1496 corporate LAN the IT department would execute the TPM_TakeOwnership command1497 remotely.1498 This sequence allows the IT department to accept platforms into their network without1499 having to have physical access to each new machine.1500 End of informative comment1501 The TPM MUST have commands to perform the following:1502 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 47 TCG Published 1. Enable and disable the TPM. These commands MUST work as TPM Owner authorized or1503 with the assertion of physical presence1504 2. Activate and deactivate the TPM. These commands MUST work as TPM Owner1505 authorized or with the assertion of physical presence1506 3. Activate and deactivate the ability to take ownership of the TPM1507 4. Assert ownership of the TPM.1508 9.4.1 Enabling a TPM1509 Informative comment1510 A disabled TPM is not able to execute commands that use the resources of a TPM. While1511 some commands are available (SHA-1 for example) the TPM is not able to load keys and1512 perform TPM_Seal and other such operations. These restrictions are the same as for an1513 inactive TPM. The difference between inactive and disabled is that a disabled TPM is unable1514 to execute the TPM_TakeOwnership command. A disabled TPM that has a TPM Owner is not1515 able to execute normal TPM commands.1516 1517 pFlags.tpmDisabled contains the current enablement status. When set to TRUE the TPM is1518 disabled, when FALSE the TPM is enabled.1519 Changing the setting pFlags.tpmDisabled has no effect on any secrets or other values held1520 by the TPM. No keys, monotonic counters or other resources are invalidated by changing1521 TPM enablement. There is no guarantee that session resources (like transport sessions)1522 survive the change in enablement, but there is no loss of secrets.1523 The TPM_OwnerSetDisable command can be used to transition in either Enabled or1524 Disabled states. The desired state is a parameter to TPM_OwnerSetDisable. This command1525 requires TPM Owner authentication to operate. It is suitable for post-boot and remote1526 invocation.1527 An unowned TPM requires the execution of TPM_PhysicalEnable to enable the TPM and1528 TPM_PhysicalDisable to disable the TPM. Operators of an owned TPM can also execute1529 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 48 Revision 94 29 March 2006 TCG Published these two commands. The use of the physical commands allows a platform operator to1530 disable the TPM without TPM Owner authorization.1531 TPM_PhysicalEnable transitions the TPM from Disabled to Enabled state. This command is1532 guarded by a requirement of operator physical presence. Additionally, this command can be1533 invoked by a physical event at the platform, whether or not the TPM has an Owner or there1534 is a human physically present. This command is suitable for pre-boot invocation.1535 TPM_PhysicalDisable transitions the TPM from Enabled to Disabled state. It has the same1536 guard and invocation properties as TPM_PhysicalEnable.1537 The subset of commands the TPM is able to execute is defined in the structures document1538 in the persistent flag section.1539 Misuse of the disabled state can result in denial-of-service. Proper management of Owner1540 AuthData and physical access to the platform is a critical element in ensuring availability of1541 the system.1542 End of informative comment1543 1. The TPM MUST provide an enable and disable command that is executed with TPM1544 Owner authorization.1545 2. The TPM MUST provide an enable and disable command this is executed locally using1546 physical presence.1547 9.4.2 Activating a TPM1548 Informative comment1549 A deactivated TPM is not able to execute commands that use TPM resources. A major1550 difference between deactivated and disabled is that a deactivated TPM CAN execute the1551 TPM_TakeOwnership command.1552 Activation control is with both persistent and volatile flags. The persistent flag is never1553 directly checked by the TPM, rather it is the source of the original setting for the volatile1554 flag. During TPM initialization the value of pFlags.tpmDeactivated is copied to1555 vFlags.tpmDeactivated. When the TPM execution engine checks for TPM activation, it only1556 references vFlags.tpmDeactivated.1557 Toggling the state of pFlags.tpmDeactivated uses TPM_PhysicalSetDeactivated. This1558 command requires physical presence. There is no associated TPM Owner authenticated1559 command as the TPM Owner can always execute TPM_OwnerSetDisabled which results in1560 the same TPM operations. The toggling of this flag does not affect the current operation of1561 the TPM but requires a reboot of the platform such that the persistent flag is again copied1562 to the volatile flag.1563 The volatile flag, vFlags.tpmDeactivated, is set during initialization by the value of1564 pFlags.tpmDeactivated. If vFlags.tpmDeactivated is TRUE the only way to reactivate the1565 TPM is to reboot the platform and have pFlags reset the vFlags value.1566 If vFlags is FALSE and the TPM running TPM_SetTempDeactivated will set1567 vFlags.tpmDeactivated to TRUE and then require a reboot of the platform to reactivate the1568 platform.1569 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 49 TCG Published 1570 Figure 9:d - Activated and Deactivated States1571 TPM activation is for Operator convenience. It allows the operator to deactivate the platform1572 during a user session when the operator does not want to disclose platform or attestation1573 identity.1574 The subset of commands that are available when the TPM is deactivated is contained in the1575 structures document. The TPM_TakeOwnership command is available when deactivated.1576 End of informative comment1577 1. The TPM MUST maintain a non-volatile flag that indicates the activation state1578 2. The TPM MUST provide for the setting of the non-volatile flag using a command that1579 requires physical presence1580 3. The TPM MUST sets a volatile flag using the current setting of the non-volatile flag.1581 4. The TPM MUST provide for a command that deactivates the TPM immediately1582 5. The only mechanism to reactivate a TPM once deactivated is to power-cycle the system.1583 9.4.3 Taking TPM Ownership1584 Start of informative comment1585 The owner of the TPM has ultimate control of the TPM. The owner of the TPM can enable or1586 disable the TPM, create AIK and set policies for the TPM. The process of taking ownership1587 must be a tightly controlled process with numerous checks and balances.1588 The protections around the taking of ownership include the enablement status, specific1589 persistent flags and the assertion of physical presence.1590 Control of the TPM revolves around knowledge of the TPM Owner authentication value.1591 Proving knowledge of authentication value proves the calling entity is the TPM Owner. It is1592 possible for more than one entity to know the TPM Owner authentication value.1593 The TPM provides no mechanisms to recover a lost TPM Owner authentication value.1594 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 50 Revision 94 29 March 2006 TCG Published Recovery from a lost or forgotten TPM Owner authentication value involves removing the old1595 value and installing a new one. The removal of the old value invalidates all information1596 associated with the previous value. Insertion of a new value can occur after the removal of1597 the old value.1598 A disabled and inactive TPM that has no TPM Owner cannot install an owner.1599 To invalidate the TPM Owner authentication value use either TPM_OwnerClear or1600 TPM_ForceClear.1601 End of informative comment1602 1. The TPM Owner authentication value MUST be a 160-bits1603 2. The TPM Owner authentication value MUST be held in persistent storage1604 3. The TPM MUST have no mechanisms to recover a lost TPM Owner authentication value1605 9.4.3.1 Enabling Ownership1606 Informative comment1607 The state that a TPM must be in to allow for TPM_TakeOwnership to succeed is; enabled1608 and fFlags.OwnershipEnabled TRUE.1609 The following diagram shows the states and the operational checks the TPM makes before1610 allowing the insertion of the TPM Ownership value.1611 1612 1613 The TPM checks the disabled flag and then the inactive flag. If the flags indicate enabled1614 then the TPM checks for the existence of a TPM Owner. If an Owner is not present the TPM1615 then checks the OwnershipDisabled flag. If TRUE the TPM_TakeOwnership command will1616 execute.1617 While the TPM has no Owner but is enabled and active there is a limited subset of1618 commands that will successfully execute.1619 The TPM_SetOwnerInstall command toggles the state of the pFlags.OwnershipDisabled.1620 TPM_SetOwnerInstall requires the assertion of physical presence to execute.1621 End of informative comment1622 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 51 TCG Published 9.4.4 Transitioning Between Operational States1623 Start of informative comment1624 The following table is a recap of the commands necessary to transition a TPM from one state1625 to another.1626 State TPM Owner Auth Physical Presence Persistence Disabled to Enabled TPM_OwnerSetDisable TPM_PhysicalEnable permanent Enabled to Disabled TPM_OwnerSetDisable TPM_PhysicalDisable permanent Inactive to Active TPM_PhysicalSetDeactivated permanent Active to Inactive TPM_PhysicalSetDeactivated permanent Active to Inactive TPM_SetTempDeactivated boot cycle 1627 End of informative comment1628 9.5 Clearing the TPM1629 Start of informative comment1630 Clearing the TPM is the process of returning the TPM to factory defaults. It is possible the1631 platform owner will change when in this state.1632 The commands to clear a TPM require either TPM Owner authentication or the assertion of1633 physical presence.1634 The clear process performs the following tasks:1635 Invalidate the SRK. Once invalidated all information stored using the SRK is now1636 unavailable. The invalidation does not change the blobs using the SRK rather there is no1637 way to decrypt the blobs after invalidation of the SRK.1638 Invalidate tpmProof. tpmProof is a value that provides the uniqueness to values stored off of1639 the TPM. By invalidating tpmProof all off TPM blobs will no longer load on the TPM.1640 Invalidate the TPM Owner authentication value. With the authentication value invalidated1641 there are no TPM Owner authenticated commands that will execute.1642 Reset volatile and non-volatile data to manufacturer defaults.1643 The clear must not affect the EK.1644 Once cleared the TPM will return TPM_NOSRK to commands that require authentication.1645 The PCR values are undefined after a clear operation. The TPM must go through TPM_Init to1646 properly set the PCR values.1647 Clear authentication comes from either the TPM owner or the assertion of physical1648 presence. As the clear commands present a real opportunity for a denial of service attack1649 there are mechanisms in place disabling the clear commands.1650 Disabling TPM_OwnerClear uses the TPM_DisableOwnerClear command. The state of ability1651 to execute TPM_OwnerClear is then held as one of the non-volatile flags.1652 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 52 Revision 94 29 March 2006 TCG Published Enablement of TPM_ForceClear is held in the volatile disableForceClear flag.1653 disableForceClear is set to FALSE during TPM_Init. To disable the command software1654 should issue the TPM_DisableForceClear command.1655 During the TPM startup processing anyone with physical access to the machine can issue1656 the TPM_ForceClear command. This command performs the clear operations if it has not1657 been disabled by vFlags.DisabledForceClear being TRUE.1658 The TPM can be configured to block all forms of clear operations. It is advisable to block1659 clear operations to prevent an otherwise trivial denial-of-service attack. The assumption is1660 the system startup code will issue the TPM_DisableForceClear on each power-cycle after it1661 is determined the TPM_ForceClear command will not be necessary. The purpose of the1662 TPM_ForceClear command is to recover from the state where the Owner has lost or1663 forgotten the TPM Owner-authentication-data.1664 The TPM_ForceClear must only be possible when the issuer has physical access to the1665 platform. The manufacturer of a platform determines the exact definition of physical access.1666 The commands to clear a TPM require either TPM Owner authentication, TPM_OwnerClear,1667 or the assertion of physical presence, TPM_ForceClear.1668 End of informative comment1669 1. The TPM MUST support the clear operations.1670 a. Clear operations MUST be authenticated by either the TPM Owner or physical1671 presence1672 b. The TPM MUST support mechanisms to disable the clear operations1673 2. The clear operation MUST perform at least the following actions1674 a. SRK invalidation1675 b. tpmProof invalidation1676 c. TPM Owner authentication value invalidation1677 d. Resetting non-volatile values to defaults1678 e. Invalidation of volatile values1679 f. Invalidation of internal resources1680 3. The clear operation must not affect the EK.1681 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 53 TCG Published 10. Physical Presence1682 Start of informative comment1683 This specification describes commands that require physical presence at the platform before1684 the command will operate. Physical presence implies direct interaction by a person ­ i.e.1685 Operator with the platform / TPM.1686 The type of controls that imply special privilege include:1687 * Clearing an existing Owner from the TPM,1688 * Temporarily deactivating a TPM,1689 * Temporarily disabling a TPM.1690 Physical presence implies a level of control and authorization to perform basic1691 administrative tasks and to bootstrap management and access control mechanisms.1692 Protection of low-level administrative interfaces can be provided by physical and electrical1693 methods; or by software; or a combination of both. The guiding principle for designers is the1694 protection mechanism should be difficult or impossible to spoof by rogue software.1695 Designers should take advantage of restricted states inherent in platform operation. For1696 example, in a PC, software executed during the power-on self-test (POST) cannot be1697 disturbed without physical access to the platform. Alternatively, a hardware switch1698 indicating physical presence is very difficult to circumvent by rogue software or remote1699 attackers.1700 TPM and platform manufacturers will determine the actual implementation approach. The1701 strength of the protection mechanisms is determined by an evaluation of the platform.1702 Physical presence indication is implemented as a flag in volatile memory known as the1703 PhysicalPresenceV flag. When physical presence is established (TRUE) several TPM1704 commands are able to function. They include:1705 TPM_PhysicalEnable,1706 TPM_PhysicalDisable,1707 TPM_PhysicalSetDeactivated,1708 TPM_ForceClear,1709 TPM_SetOwnerInstall,1710 In order to execute these commands, the TPM must obtain unambiguous assurance that1711 the operation is authorized by physical-presence at the platform. The command processor1712 in the I/O component checks the physicalPresenceV flag before continuing processing of1713 TPM command blocks. The volatile physicalPresenceV flag is set only while the Operator is1714 indeed physically present.1715 TPM designers should take precautions to ensure testing of the physicalPresenceV flag1716 value is not mask-able. For example, a special bus cycle could be used or a dedicated line1717 implemented.1718 There is an exception to physical presence semantics that allows a remote entity the ability1719 to assert physical presence when that entity is not physically present. The1720 TSC_PhysicalPresence command is used to change polarity of the physicalPresenceV flag.1721 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 54 Revision 94 29 March 2006 TCG Published Its use is heavily guarded. See sections describing the TPM Opt-In component; and Volatile1722 and Non-volatile memory components.1723 The following diagram illustrates the flow of logic controlling updates to the1724 physicalPresenceV flag:1725 AND HW pin physicalPresenceCMDEnable physicalPresenceCMDEnableV OR physicalPresenceHWEnable AND TSC_PhysicalPresence() PhysicalPresenceV NOT Rev 0.3 1726 Figure 10:a - Physical Presence Control Logic1727 This diagram shows that the vFlags.physicalPresenceV flag may be updated by either a HW1728 pin or through the TSC_PhysicalPresence command, but gated by persistent control flags1729 and a temporal lock. Observe, the reverse logic surrounding the use of1730 TSC_PhysicalPresence command. When the physicalPresenceCMDEnable flag is set, and1731 the physicalPresenceCMDEnableV is not set, and the TSC_PhysicalPresence command may1732 execute.1733 The physicalPresenceV flag may be overridden by unambiguous physical presence.1734 Conceptually, the use of dedicated electrical hardware providing a trusted path to the1735 Operator has higher precedence than the physicalPresenceV flag value. Implementers1736 should take this into consideration when implementing physical presence indicators.1737 End of informative comment1738 1. The requirement for physical presence MUST be met by the platform manufacturer1739 using some physical mechanism.1740 2. It SHALL be impossible to intercept or subvert indication of physical presence to the1741 TPM by the execution of software on the platform.1742 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 55 TCG Published 11. Root of Trust for Reporting (RTR)1743 Start of informative comment1744 The RTR is responsible for establishing platform identities, reporting platform1745 configurations, protecting reported values and establishing a context for attesting to1746 reported values. The RTR shares responsibility of protecting measurement digests with the1747 RTS.1748 The interaction between the RTR and RTS is a critical component. The design and1749 implementation of the interaction between the RTR and RTS should mitigate observation1750 and tampering with the messages. It is strongly encouraged that the RTR and RTS1751 implementation occur in the same package such there are no external observation points.1752 For a silicon based TPM this would imply that the RTR and RTS are in the same silicon1753 package with no external busses.1754 End of informative comment1755 1. An instantiation of the RTS and RTR SHALL do the following:1756 a. Be resistant to all forms of software attack and to the forms of physical attack1757 implied by the platform's Protection Profile1758 b. Supply an accurate digest of all sequences of presented integrity metrics1759 11.1 Platform Identity1760 Start of informative comment1761 The RTR is a cryptographic identity in use to distinguish and authenticate an individual1762 TPM. The TPM uses the RTR to provide As the RTR is cryptographically unique the use of1763 the RTR must only occur in controlled circumstances.1764 In the TPM, the Endorsement Key (EK) is the RTR.1765 Prior to any use of the TPM, the RTR must be instantiated. Instantiation may occur during1766 TPM manufacturing or platform manufacturing. The business issues and manufacturing1767 flow determines how a specific TPM and platform is personalized.1768 The EK is cryptographically unique and bound to the TPM.1769 The EK is only available for two operations: establishing the TPM Owner and establishing1770 Attestation Identity Key (AIK) values and credentials. There is a prohibition on the use of the1771 EK for any other operation.1772 End of informative comment1773 1. The RTR MUST have a cryptographic identity.1774 a. The cryptographic identity of the RTR is the Endorsement Key (EK).1775 2. The EK MUST be1776 a. Statistically unique1777 b. Difficult to forge or counterfeit1778 c. Verifiable during the AIK creation process1779 3. The EK SHALL only participate in1780 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 56 Revision 94 29 March 2006 TCG Published a. TPM Ownership insertion1781 b. AIK creation and verification1782 11.2 RTR to Platform Binding1783 Start of informative comment1784 When performing validation of the EK and the platform the challenger wishes to have1785 knowledge of the binding of RTR to platform. The RTR is bound to a TPM hence if the1786 platform can show the binding of TPM to platform the challenger can reasonably believe the1787 RTR and platform binding.1788 The TPM cannot provide all of the information necessary for the challenger to trust in the1789 binding. That information comes from the manufacturing process and occurs outside the1790 control of the TPM.1791 End of informative comment1792 1. The EK is transitively bound to the Platform via the TPM as follows:1793 a. An EK is bound to one and only one TPM (i.e., there is a one to one correspondence1794 between an Endorsement Key and a TPM.)1795 b. A TPM is bound to one and only one Platform. (i.e., there is a one to one1796 correspondence between a TPM and a Platform.)1797 c. Therefore, an EK is bound to a Platform. (i.e., there is a one to one correspondence1798 between an Endorsement Key and a Platform.)1799 11.3 Platform Identity and Privacy Considerations1800 Start of informative comment1801 The uniqueness property of cryptographic identities raises concerns that use of that identity1802 could result in aggregation of activity logs. Analysis of the aggregated activity could reveal1803 personal information that a user of a platform would not otherwise approve for distribution1804 to the aggregators. Both EK and AIK identities have this property.1805 To counter undesired aggregation, TCG encourages the use of domain specific AIK keys and1806 restricts the use of the EK key. The platform owner controls generation and distribution of1807 AIK public keys.1808 If a digital signature was performed by the EK, then any entity could track the use of the1809 EK. So use of the EK as a signature is cryptographically sound, but this does not ensure1810 privacy. Therefore, a mechanism to allow verifiers (human or machine) to determine that1811 the TPM really signed the message without using the EK is required.1812 End of informative comment1813 11.4 Attestation Identity Keys1814 Start of informative comment1815 An Attestation Identity Key (AIK) is an alias for the EK. AIK provide signatures and not1816 encryption. The TPM can create a virtually unlimited number of AIK.1817 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 57 TCG Published The AIK must contain identification such that the TPM can properly enforce the restrictions1818 placed on an AIK.1819 The AIK is an asymmetric key pair. For interoperability, the AIK is an RSA 2048-bit key. The1820 TPM must protect the private portion of the asymmetric key and ensure that the value is1821 never exposed.1822 The AIK only signs PCR data. The TPM must enforce this restriction. If the AIK did sign1823 additional information, it is possible for an attacker to create a block of data that appears to1824 be a PCR value. By enforcing the PCR restriction this attack is never possible.1825 End of informative comment1826 1. The TPM MUST permanently mark an AIK such that all subsequent uses of the AIK the1827 AIK restrictions are enforced.1828 2. An AIK MUST be:1829 a. Statistically unique1830 b. Difficult to forge or counterfeit1831 c. Verifiable to challengers1832 3. For interoperability the AIK MUST be1833 a. An RSA 2048-bit key1834 4. The AIK MUST only sign data generated by the TPM1835 11.4.1 AIK Creation1836 Start of informative comment1837 As the AIK is an alias for the EK, the AIK creation process requires TPM Owner1838 authorization. The process actually requires two TPM Owner authorizations; creation and1839 credential activation.1840 The credential creation process is outside the control of the TPM; however, the entity1841 identification that will create the credential must occur during the creation process.1842 End of informative comment1843 1. The TPM Owner MUST authorize the AIK creation process.1844 2. The TPM MUST use a protected function to perform the AIK creation.1845 3. The TPM Owner MUST indicate the entity that will provide the AIK credential as part of1846 the AIK creation process.1847 4. The TPM Owner MAY indicate that NO credential will ever be created. If the TPM Owner1848 does indicate that no credential will be provided the TPM MUST ensure that no1849 credential can be created.1850 5. The TTP MAY apply policies to determine if the presented AIK should be granted a1851 credential.1852 6. The credential request package MUST be useable by only the Privacy CA selected by the1853 TPM Owner.1854 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 58 Revision 94 29 March 2006 TCG Published 7. The AIK credential MUST be only obtainable by the TPM that created the AIK credential1855 request.1856 11.4.2 AIK Storage1857 Start of informative comment1858 The AIK may be stored on some general-purpose storage device.1859 When held outside of the TPM the AIK sensitive data must be encrypted and integrity1860 protected.1861 End of informative comment1862 1. When held outside of the TPM AIK encryption and integrity protection MUST protect the1863 AIK sensitive information1864 2. The migration of AIK from one TPM to another MUST be prohibited1865 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 59 TCG Published 12. Root of Trust for Storage (RTS)1866 Start of informative comment1867 The RTS provides protection on data in use by the TPM but held in external storage devices.1868 The RTS provides confidentiality and integrity for the external blobs.1869 The RTS also provides the mechanism to ensure that the release of information only occurs1870 in a named environment. The naming of an environment uses the PCR selection to1871 enumerate the values.1872 Data protected by the RTS can migrate to other TPM.1873 End of informative comment1874 1. The number and size of values held by the RTS SHOULD be limited only by the volume1875 of storage available on the platform1876 2. The TPM MUST ensure that TPM_PERMANENT_DATA -> tpmProof is only inserted into1877 TPM internally generated and non-migratable information.1878 12.1 Loading and Unloading Blobs1879 Start of informative comment1880 The TPM provides several commands to store and load RTS controlled data.1881 Class Command Analog Comment 1 Data / Internal / TPM TPM_MakeIdentity TPM_ActivateIdentity Special purpose data 2 Data / External / TPM TSS_Bind TPM_Unbind 3 Data / Internal / PCR TPM_Seal TPM_Unseal 4 Data / External / PCR 5 Key / Internal / TPM TPM_CreateWrapKey TPM_LoadKey 6 Key / External / TPM TSS_WrapKey TPM_LoadKey 7 Key / Internal / PCR 8 Key / External / PCR TSS_WrapKeyToPcr TPM_LoadKey Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 60 Revision 94 29 March 2006 TCG Published 13. Transport Sessions and Authorization Protocols1882 Start of informative comment1883 The purpose of the authorization protocols and mechanisms is to prove to the TPM that the1884 requestor has permission to perform a function and use some object. The proof comes from1885 the knowledge of a shared secret.1886 AuthData is available for the TPM Owner and each entity (keys, for example) that the TPM1887 controls. The AuthData for the TPM Owner and the SRK are held within the TPM itself and1888 the AuthData for other entities are held with the entity.1889 The TPM Owner AuthData allows the Owner to prove ownership of the TPM. Proving1890 ownership of the TPM does not immediately allow all operations ­ the TPM Owner is not a1891 "super user" and additional AuthData must be provided for each entity or operation that1892 has protection.1893 The TPM treats knowledge of the AuthData as complete proof of ownership of the entity. No1894 other checks are necessary. The requestor (any entity that wishes to execute a command on1895 the TPM or use a specific entity) may have additional protections and requirements where1896 he or she (or it) saves the AuthData; however, the TPM places no additional requirements.1897 There are three protocols to securely pass a proof of knowledge of AuthData from requestor1898 to TPM; the "Object-Independent Authorization Protocol" (OIAP), the "Object-Specific1899 Authorization Protocol" (OSAP) and the "Delegate-Specific Authorization Protocol" (DSAP).1900 The OIAP supports multiple authorization sessions for arbitrary entities. The OSAP1901 supports an authentication session for a single entity and enables the confidential1902 transmission of new authorization information. The DSAP supports the delegation of owner1903 or entity authorization.1904 New authorization information is inserted by the "AuthData Insertion Protocol" (ADIP)1905 during the creation of an entity. The "AuthData Change Protocol" (ADCP) and the1906 "Asymmetric Authorization Change Protocol" (AACP) allow the changing of the AuthData for1907 an entity. The protocol definitions allow expansion of protocol types to additional TCG1908 required protocols and vendor specific protocols.1909 The protocols use a "rolling nonce" paradigm. This requires that a nonce from one side be in1910 use only for a message and its reply. For instance, the TPM would create a nonce and send1911 that on a reply. The requestor would receive that nonce and then include it in the next1912 request. The TPM would validate that the correct nonce was in the request and then create1913 a new nonce for the reply. This mechanism is in place to prevent replay attacks and man-1914 in-the-middle attacks.1915 The basic protocols do not provide long-term protection of AuthData that is the hash of a1916 password or other low-entropy entities. The TPM designer and application writer must1917 supply additional protocols if protection of these types of data is necessary.1918 The design criterion of the protocols is to allow for ownership authentication, command and1919 parameter authentication and prevent replay and man-in-the-middle attacks.1920 The passing of the AuthData, nonces and other parameters must follow specific guidelines1921 so that commands coming from different computer architectures will interoperate properly.1922 End of informative comment1923 1. AuthData MUST use one of the following protocols1924 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 61 TCG Published a. OIAP1925 b. OSAP1926 c. DSAP1927 2. Entity creation MUST use one of the following protocols1928 a. ADIP1929 3. Changing AuthData MUST use one of the following protocols1930 a. ADCP1931 b. AACP1932 4. The TPM MAY support additional protocols to authenticate, insert and change1933 AuthData.1934 5. When a command has more than one AuthData value1935 a. Each AuthData MUST use the same SHA-1 of the parameters1936 6. Keys MAY specify authDataUsage -> TPM_AUTH_NEVER1937 a. If the caller changes the tag from TPM_TAG_RQU_AUTH1_xxx to1938 TPM_TAG_RQU_XXX the TPM SHALL ignore the AuthData values1939 b. If the caller leaves the tag as TPM_TAG_RQU_AUTH11940 i. The TPM will compute the AuthData based on the value store in the AuthData1941 location within the key, IGNORING the state of the AuthDataUsage flag.1942 c. Users may choose to use a well-known value for the AuthData when setting1943 AuthDataUsage to NEVER.1944 d. If a key has AuthDataUsage set to TPM_AUTH_ALWAYS but is received in a1945 command with the tag TPM_TAG_RQU_COMMAND, the command MUST return an1946 error code.1947 7. For commands that normally have 2 authorization sessions, if the tag specifies only one1948 in the parameter array, then the first session listed is ignored (authDataUsage must be1949 NEVER for this key) and the incoming session data is used for the second auth session1950 in the list.1951 8. Keys MAY specify AuthDataUsage -> TPM_AUTH_PRIV_USE_ONLY1952 a. If the key used in a command to read/access the public portion of the key (e.g.1953 TPM_CertifyKey, TPM_GetPubKey)1954 i. If the caller changes the tag from TPM_TAG_RQU_AUTH1_xxx to1955 TPM_TAG_RQU_XXX the TPM SHALL ignore the AuthData values1956 ii. If the caller leaves the tag as TPM_TAG_RQU_AUTH11957 iii. The TPM will compute the AuthData based on the value store in the AuthData1958 location within the key, IGNORING the state of the AuthDataUsage flag1959 b. else if the key used in command to read/access the private portion of the key(e.g.1960 TPM_Sign)1961 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 62 Revision 94 29 March 2006 TCG Published i. If the tag is TPM_TAG_RQU_COMMAND, the command MUST return an error1962 code.1963 13.1 Authorization Session Setup1964 Start of informative comment1965 The TPM provides two protocols for authorizing the use of entities without revealing the1966 AuthData on the network or the connection to the TPM. In both cases, the protocol1967 exchanges nonce-data so that both sides of the transaction can compute a hash using1968 shared secrets and nonce-data. Each side generates the hash value and can compare to the1969 value transmitted. Network listeners cannot directly infer the AuthData from the hashed1970 objects sent over the network.1971 The first protocol is the Object-Independent Authorization Protocol (OIAP), which allows the1972 exchange of nonces with a specific TPM. Once an OIAP session is established, its nonces1973 can be used to authorize the use of any entity managed by the TPM. The session can live1974 indefinitely until either party requests the session termination. The TPM_OIAP function1975 starts the OIAP session.1976 The second protocol is the Object Specific Authorization Protocol (OSAP)". The OSAP allows1977 establishment of an authentication session for a single entity. The session creates nonces1978 that can authorize multiple commands without additional session-establishment overhead,1979 but is bound to a specific entity. The TPM_OSAP command starts the OSAP session. The1980 TPM_OSAP specifies the entity to which the authorization is bound.1981 Most commands allow either form of authorization protocol. In general, however, the OIAP1982 is preferred ­ it is more generally useful because it allows usage of the same session to1983 provide authorization for different entities. The OSAP is, however, necessary for operations1984 that set or reset AuthData.1985 OIAP sessions were designed for reasons of efficiency; only one setup process is required for1986 potentially many authorizations.1987 An OSAP session is doubly efficient because only one setup process is required for1988 potentially many authorization calculations and the entity AuthData secret is required only1989 once. This minimizes exposure of the AuthData secret and can minimize human interaction1990 in the case where a person supplies the AuthData information. The disadvantage of the1991 OSAP is that a distinct session needs to be setup for each entity that requires authorization.1992 The OSAP creates an ephemeral secret that is used throughout the session instead of the1993 entity AuthData secret. The ephemeral secret can be used to provide confidentiality for the1994 introduction of new AuthData during the creation of new entities. Termination of the OSAP1995 occurs in two ways. Either side can request session termination (as usual) but the TPM1996 forces the termination of an OSAP session after use of the ephemeral secret for the1997 introduction of new AuthData.1998 For both the OSAP and the OIAP, session setup is independent of the commands that are1999 authorized. In the case of OIAP, the requestor sends the TPM_OIAP command, and with the2000 response generated by the TPM, can immediately begin authorizing object actions. The2001 OSAP is very similar, and starts with the requestor sending a TPM_OSAP operation, naming2002 the entity to which the authorization session should be bound.2003 The DSAP session is to provide delegated authorization information.2004 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 63 TCG Published All session types use a "rolling nonce" paradigm. This means that the TPM creates a new2005 nonce value each time the TPM receives a command using the session.2006 Example OIAP and OSAP sessions are used to illustrate session setup and use. The2007 fictitious command named TPM_Example occupies the place where an ordinary TPM2008 command might be used, but does not have command specific parameters. The session2009 connects to a key object within the TPM. The key contains AuthData that will be used to2010 secure the session.2011 There could be as many as 2 authorization sessions applied to the execution of a single TPM2012 command or as few as 0. The number of sessions used is determined by TCG 1.2 Command2013 Specification and is indicated by the command ordinal parameter.2014 It is also possible to secure authorization sessions using ephemeral shared-secrets. Rather2015 than using AuthData contained in the stored object (e.g. key), the AuthData is supplied as a2016 parameter to OIAP or OSAP session creation. In the examples below the key.usageAuth2017 parameter is replaced by the ephemeral secret.2018 End of informative comment2019 13.2 Parameter Declarations for OIAP and OSAP Examples2020 Start of informative comment2021 To follow OIAP and OSAP protocol examples (Table 13:c and Table 13:d), the reader should2022 become familiar with the parameters declared in Table 13:a and Table 13:b.2023 Several conventions are used in the parameter tables that may facilitate readability.2024 The Param column (Table 13:a) identifies the sequence in which parameters are packaged2025 into a command or response message as well as the size in bytes of the parameter value. If2026 this entry in the row is blank, that parameter is not included in the message. <> in the size2027 column means that the size of the element is variable. It is defined either explicitly by the2028 preceding parameter, or implicitly by the parameter type.2029 The HMAC column similarly identifies the parameters that are included in HMAC2030 calculations. This column also indicates the default parameters that are included in the2031 audit log. Exceptions are noted under the specific ordinal, e.g. TPM_ExecuteTransport.2032 The Type column identifies the TCG data type corresponding to the passed value. An2033 encapsulation of the parameter type is not part of the command message.2034 The Name column is a fictitious variable name that aids in following the examples and2035 descriptions.2036 The double-lined row separator distinguishes authorization session parameters from2037 command parameters. In Table 13:a the TPM_Example command has three parameters;2038 keyHandle, inArgOne and inArgTwo. The tag, paramSize and ordinal parameters are2039 message header values describing contents of a command message. The parameters below2040 the double-lined row are OIAP / OSAP /DSAP or transport authorization session related. If2041 a second authorization session were used, the table would show a second authorization2042 section delineated by a second double-lined row. The authorization session parameters2043 identify shared-secret values, session nonces, session digest and flags.2044 In this example, a single authorization session is used signaled by the2045 TPM_TAG_RQU_AUTH1_COMMAND tag.2046 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 64 Revision 94 29 March 2006 TCG Published For an OIAP or transport session, the TPM_AUTHDATA description column specifies the2047 HMAC key.2048 For an OSAP or DSAP session, the HMAC key is the shared secret that was calculated2049 during the session setup, not the key specified in the description. The key specified in the2050 description was previously used in the shared secret calculation.2051 Param HMAC # Sz # Sz Type Name Description 1 2 TPM_TAG tag TPM_TAG_RQU_AUTH1_COMMAND 2 4 UINT32 paramSize Total number of input bytes including paramSize and tag 3 4 1S 4 TPM_COMMAND_CODE ordinal Command ordinal, fixed value of TPM_Example 4 4 TPM_KEY_HANDLE keyHandle Handle of a loaded key. 5 1 2S 1 BOOL inArgOne The first input argument 6 20 3S 20 UNIT32 inArgTwo The second input argument. 7 4 TPM_AUTHHANDLE authHandle The authorization handle used for keyHandle authorization. 2H1 20 TPM_NONCE authLastNonceEven Even nonce previously generated by TPM to cover inputs 8 20 3 H1 20 TPM_NONCE nonceOdd Nonce generated by system associated with authHandle 9 1 4 H1 1 BOOL continueAuthSession The continue use flag for the authorization handle 1 0 20 TPM_AUTHDATA inAuth The AuthData digest for inputs and keyHandle. HMAC key: key.usageAuth. 2052 Table 13:a - Authorization Protocol Input Parameters2053 2054 Table 13:b - Authorization Protocol Output Parameters2055 2056 End of informative comment2057 Param HMAC # Sz # Sz Type Name Description 1 2 TPM_TAG Tag TPM_TAG_RSP_AUTH1_COMMAND 2 4 UINT32 paramSize Total number of output bytes including paramSize and tag 3 4 1S 4 TPM_RESULT returnCode The return code of the operation. See section 4.3. 2S 4 TPM_COMMAND_CODE ordinal Command ordinal, fixed value of TPM_Example 4 4 3S 4 UINT32 outArgOne Output argument 5 20 2 H1 20 TPM_NONCE nonceEven Even nonce newly generated by TPM to cover outputs 3 H1 20 TPM_NONCE nonceOdd Nonce generated by system associated with authHandle 6 1 4 H1 1 BOOL continueAuthSession Continue use flag, TRUE if handle is still active 7 20 TPM_AUTHDATA resAuth The AuthData digest for the returned parameters. HMAC key: key.usageAuth. TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 65 TCG Published 13.2.1 Object-Independent Authorization Protocol (OIAP)2058 Start of informative comment2059 The purpose of this section is to describe the authorization-related actions of a TPM when it2060 receives a command that has been authorized with the OIAP protocol. OIAP uses the2061 TPM_OIAP command to create the authorization session.2062 Many commands use OIAP authorization. The following description is therefore necessarily2063 abstract. A fictitious TPM command, TPM_Example is used to represent ordinary TPM2064 commands.2065 Assume that a TPM user wishes to send command TPM_Example. This is an authorized2066 command that uses the key denoted by keyHandle. The user must know the AuthData for2067 keyHandle (key.usageAuth) as this is the entity that requires authorization and this secret2068 is used in the authorization calculation. Let us assume for this example that the caller of2069 TPM_Example does not need to authorize the use of keyHandle for more than one2070 command. This use model points to the selection of the OIAP as the authorization protocol.2071 For the TPM_Example command, the inAuth parameter provides the authorization to2072 execute the command. The following table shows the commands executed, the parameters2073 created and the wire formats of all of the information.2074 is the result of the following calculation: SHA1(ordinal, inArgOne,2075 inArgTwo). is the result of the following calculation: SHA1(returnCode,2076 ordinal, outArgOne). inAuthSetupParams refers to the following parameters, in this order:2077 authLastNonceEven, nonceOdd, continueAuthSession. OutAuthSetupParams refers to the2078 following parameters, in this order: nonceEven, nonceOdd, continueAuthSession2079 There are two even nonces used to execute TPM_Example, the one generated as part of the2080 TPM_OAIP command (labeled authLastNonceEven below) and the one generated with the2081 output arguments of TPM_Example (labeled as nonceEven below).2082 Caller On the wire Dir TPM Send TPM_OIAP TPM_OIAP Create session Create authHandle Associate session and authHandle Generate authLastNonceEven Save authLastNonceEven with authHandle Save authHandle, authLastNonceEven authHandle, authLastNonceEven ß Returns Generate nonceOdd Compute inAuth = HMAC (key.usageAuth, inParamDigest, inAuthSetupParams) Save nonceOdd with authHandle Send TPM_Example tag paramSize ordinal keyHandle inArgOne inArgTwo authHandle nonceOdd TPM retrieves key.usageAuth (key must have been previously loaded) Verify authHandle points to a valid session, mismatch returns TPM_E_INVALIDAUTH Retrieve authLastNonceEven from internal session storage HM = HMAC (key.usageAuth, inParamDigest, inAuthSetupParams) Compare HM to inAuth. If they do not compare return with TPM_E_INVALIDAUTH Execute TPM_Example and create returnCode Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 66 Revision 94 29 March 2006 TCG Published continueAuthSession inAuth Generate nonceEven to replace authLastNonceEven in session Set resAuth = HMAC( key.usageAuth, outParamDigest, outAuthSetupParams) Save nonceEven HM = HMAC( key.usageAuth, outParamDigest, outAuthSetupParams) Compare HM to resAuth. This verifies returnCode and output parameters. tag paramSize returnCode outArgOne nonceEven continueAuthSession resAuth ß Return output parameters If continueAuthSession is FALSE then destroy session Suppose now that the TPM user wishes to send another command using the same session.2083 For the purposes of this example, we will assume that the same example command is used2084 (ordinal = TPM_Example). However, a different key (newKey) with its own secret2085 (newKey.usageAuth) is to be operated on. To re-use the previous session, the2086 continueAuthSession output boolean must be TRUE.2087 The previous example shows the command execution reusing an existing authorization2088 session. The parameters created and the wire formats of all of the information.2089 In this case, authLastNonceEven is the nonceEven value returned by the TPM with the2090 output parameters from the first protocol example2091 2092 Caller On the wire Dir TPM Generate nonceOdd Compute inAuth = HMAC (newKey.usageAuth, inParamDigest, inAuthSetupParams) Save nonceOdd with authHandle Send TPM_Example tag paramSize ordinal keyHandle inArgOne inArgTwo nonceOdd continueAuthSession inAuth TPM retrieves newKey.usageAuth (newKey must have been previously loaded) Retrieve authLastNonceEven from internal session storage HM = HMAC (newKey.usageAuth, inParamDigest, inAuthSetupParams) Compare HM to inAuth. If they do not compare return with TPM_E_INVALIDAUTH Execute TPM_Example and create returnCode Generate nonceEven to replace authLastNonceEven in session Set resAuth = HMAC(newKey.usageAuth, outParamDigest, outAuthSetupParams) Save nonceEven HM = HMAC( newKey.usageAuth, outParamDigest, outAuthSetupParams) Compare HM to resAuth. This verifies returnCode and output parameters. tag paramSize returnCode outArgOne nonceEven continueAuthSession resAuth ß Return output parameters If continueAuthSession is FALSE then destroy session The TPM user could then use the session for further authorization sessions. Suppose,2093 however, that the TPM user no longer requires the authorization session. There are three2094 possibilities in this case:2095 The user issues a TPM_Terminate_Handle command to the TPM (section 5.3).2096 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 67 TCG Published The input argument continueAuthSession can be set to FALSE for the last command. In2097 this case, the output continueAuthSession value will be FALSE.2098 In some cases, the TPM automatically terminates the authorization session regardless of the2099 input value of continueAuthSession. In this case as well, the output continueAuthSession2100 value will be FALSE.2101 When an authorization session is terminated for any reason, the TPM invalidates the2102 session's handle and terminates the session's thread (releases all resources allocated to the2103 session).2104 End of informative comment2105 2106 OIAP Actions2107 1. The TPM MUST verify that the authorization handle (H, say) referenced in the command2108 points to a valid session. If it does not, the TPM returns the error code2109 TPM_INVALID_AUTHHANDLE2110 2. The TPM SHALL retrieve the latest version of the caller's nonce (nonceOdd) and2111 continueAuthSession flag from the input parameter list, and store it in internal TPM2112 memory with the authSession `H'.2113 3. The TPM SHALL retrieve the latest version of the TPM's nonce stored with the2114 authorization session H (authLastNonceEven) computed during the previously executed2115 command.2116 4. The TPM MUST retrieve the secret AuthData (SecretE, say) of the target entity. The2117 entity and its secret must have been previously loaded into the TPM.2118 5. The TPM SHALL perform a HMAC calculation using the entity secret data, ordinal, input2119 command parameters and authorization parameters according to previously specified2120 normative regarding HMAC calculation.2121 6. The TPM SHALL compare HM to the AuthData value received in the input parameters. If2122 they are different, the TPM returns the error code TPM_AUTHFAIL if the authorization2123 session is the first session of a command, or TPM_AUTH2FAIL if the authorization2124 session is the second session of a command. Otherwise, the TPM executes the command2125 which (for this example) produces an output that requires authentication.2126 7. The TPM SHALL generate a nonce (nonceEven).2127 8. The TPM creates an HMAC digest to authenticate the return code, return values and2128 authorization parameters to the same entity secret according to previously specified2129 normative regarding HMAC calculation.2130 9. The TPM returns the return code, output parameters, authorization parameters and2131 AuthData digest.2132 10.If the output continueUse flag is FALSE, then the TPM SHALL terminate the session.2133 Future references to H will return an error.2134 13.3 Object-Specific Authorization Protocol (OSAP)2135 Start of informative comment2136 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 68 Revision 94 29 March 2006 TCG Published This section describes the actions of a TPM when it receives a TPM command via OSAP2137 session. Many TPM commands may be sent to the TPM via an OSAP session. Therefore, the2138 following description is necessarily abstract.2139 The OSAP session is initialized through the creation of an ephemeral secret which is used to2140 protect session traffic. Sessions are created using the TPM_OSAP command. This section2141 illustrates OSAP using a fictitious command called TPM_Example.2142 Assume that a TPM user wishes to send the TPM_Example command to the TPM. The2143 keyHandle signifies that an OSAP session is being used and has the value "Auth1". The2144 user must know the AuthData for keyHandle (key.usageAuth) as this is the entity that2145 requires authorization and this secret is used in the authorization calculation.2146 Let us assume that the sender needs to use this key multiple times but does not wish to2147 obtain the key secret more than once. This might be the case if the usage AuthData were2148 derived from a typed password. This use model points to the selection of the OSAP as the2149 authorization protocol.2150 For the TPM_Example command, the inAuth parameter provides the authorization to2151 execute the command. The following table shows the commands executed, the parameters2152 created and the wire formats of all of the information.2153 is the result of the following calculation: SHA1(ordinal, inArgOne,2154 inArgTwo). is the result of the following calculation: SHA1(returnCode,2155 ordinal, outArgOne). inAuthSetupParams refers to the following parameters, in this order:2156 authLastNonceEven, nonceOdd, continueAuthSession. OutAuthSetupParams refers to the2157 following parameters, in this order: nonceEven, nonceOdd, continueAuthSession2158 In addition to the two even nonces generated by the TPM (authLastNonceEven and2159 nonceEven) that are used for TPM_OIAP, there is a third, labeled nonceEvenOSAP that is2160 used to generate the shared secret. For every even nonce, there is also an odd nonce2161 generated by the system.2162 Caller On the wire Dir TPM Send TPM_OSAP TPM_OSAP keyHandle nonceOddOSAP Create session & authHangle Generate authLastNonceEven Save authLastNonceEven with authHandle Save the ADIP encryption scheme with authHandle Generate nonceEvenOSAP Generate sharedSecret = HMAC(key.usageAuth, nonceEvenOSAP, nonceOddOSAP) Save keyHandle, sharedSecret with authHandle Save authHandle, authLastNonceEven Generate sharedSecret = HMAC(key.usageAuth, nonceEvenOSAP, nonceOddOSAP) Save sharedSecret authHandle, authLastNonceEven nonceEvenOSAP ß Returns Generate nonceOdd & save with authHandle. Compute inAuth = HMAC (sharedSecret, inParamDigest, inAuthSetupParams) Send TPM_Example tag paramSize ordinal Verify authHandle points to a valid session, mismatch returns TPM_AUTHFAIL Retrieve authLastNonceEven from internal session storage HM = HMAC (sharedSecret, inParamDigest, inAuthSetupParams) TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 69 TCG Published keyHandle inArgOne inArgTwo authHandle nonceOdd continueAuthSession inAuth Compare HM to inAuth. If they do not compare return with TPM_AUTHFAIL Execute TPM_Example and create returnCode. If TPM_Example requires ADIP encryption, use the algorithm indicated when the OSAP session was set up. Generate nonceEven to replace authLastNonceEven in session Set resAuth = HMAC(sharedSecret, outParamDigest, outAuthSetupParams) Save nonceEven HM = HMAC( sharedSecret, outParamDigest, outAuthSetupParams) Compare HM to resAuth. This verifies returnCode and output parameters. tag paramSize returnCode outArgOne nonceEven continueAuthSession resAuth ß Return output parameters If continueAuthSession is FALSE then destroy session Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 70 Revision 94 29 March 2006 TCG Published Table 13:c - Example OSAP Session2163 Suppose now that the TPM user wishes to send another command using the same session2164 to operate on the same key. For the purposes of this example, we will assume that the same2165 ordinal is to be used (TPM_Example). To re-use the previous session, the2166 continueAuthSession output boolean must be TRUE.2167 The following table shows the command execution, the parameters created and the wire2168 formats of all of the information.2169 In this case, authLastNonceEven is the nonceEven value returned by the TPM with the2170 output parameters from the first execution of TPM_Example.2171 2172 Caller On the wire Dir TPM Generate nonceOdd Compute inAuth = HMAC (sharedSecret, inParamDigest, inAuthSetupParams) Save nonceOdd with authHandle Send TPM_Example tag paramSize ordinal keyHandle inArgOne inArgTwo nonceOdd continueAuthSession inAuth Retrieve authLastNonceEven from internal session storage HM = HMAC (sharedSecret, inParamDigest, inAuthSetupParams) Compare HM to inAuth. If they do not compare return with TPM_AUTHFAIL Execute TPM_Example and create returnCode Generate nonceEven to replace authLastNonceEven in session Set resAuth = HMAC(sharedSecret, outParamDigest, outAuthSetupParams) Save nonceEven HM = HMAC( sharedSecret, outParamDigest, outAuthSetupParams) Compare HM to resAuth. This verifies returnCode and output parameters. tag paramSize returnCode outArgOne nonceEven continueAuthSession resAuth ß Return output parameters If continueAuthSession is FALSE then destroy session Table 13:d - Example Re-used OSAP Session2173 The TPM user could then use the session for further authorization sessions or terminate it2174 in the ways that have been described above in TPM_OIAP. Note that termination of the2175 OSAP session causes the TPM to destroy the shared secret.2176 End of informative comment2177 OSAP Actions2178 1. The TPM MUST have been able to retrieve the shared secret (Shared, say) of the target2179 entity when the authorization session was established with TPM_OSAP. The entity and2180 its secret must have been previously loaded into the TPM.2181 2. The TPM MUST verify that the authorization handle (H, say) referenced in the command2182 points to a valid session. If it does not, the TPM returns the error code2183 TPM_INVALID_AUTHHANDLE.2184 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 71 TCG Published 3. The TPM MUST calculate the HMAC (HM1, say) of the command parameters according2185 to previously specified normative regarding HMAC calculation.2186 4. The TPM SHALL compare HM1 to the AuthData value received in the command. If they2187 are different, the TPM returns the error code TPM_AUTHFAIL if the authorization session2188 is the first session of a command, or TPM_AUTH2FAIL if the authorization session is the2189 second session of a command., the TPM executes command C1 which produces an2190 output (O, say) that requires authentication and uses a particular return code (RC, say).2191 5. The TPM SHALL generate the latest version of the even nonce (nonceEven).2192 6. The TPM MUST calculate the HMAC (HM2) of the return parameters according to2193 previously specified normative regarding HMAC calculation.2194 7. The TPM returns HM2 in the parameter list.2195 8. The TPM SHALL retrieve the continue flag from the received command. If the flag is2196 FALSE, the TPM SHALL terminate the session and destroy the thread associated with2197 handle H.2198 9. If the shared secret was used to provide confidentiality for data in the received2199 command, the TPM SHALL terminate the session and destroy the thread associated with2200 handle H.2201 10.Each time that access to an entity (key) is authorized using OSAP, the TPM MUST2202 ensure that the OSAP shared secret is that derived from the entity using TPM_OSAP.2203 13.4 Authorization Session Handles2204 Start of informative comment2205 The TPM generates authorization handles to allow for the tracking of information regarding2206 a specific authorization invocation.2207 The TPM saves information specific to the authorization, such as the nonce values,2208 ephemeral secrets and type of authentication in use.2209 The TPM may create any internal representation of the handle that is appropriate for the2210 TPM's design. The requestor always uses the handle in the authorization structure to2211 indicate authorization structure in use.2212 The TPM must support a minimum of two concurrent authorization handles. The use of2213 these handles is to allow the Owner to have an authorization active in addition to an active2214 authorization for an entity.2215 To ensure garbage collection and the proper removal of security information, the requestor2216 should terminate all handles. Termination of the handle uses the continue-use flag to2217 indicate to the TPM that the handle should be terminated.2218 Termination of a handle instructs the TPM to perform garbage collection on all AuthData.2219 Garbage collection includes the deletion of the ephemeral secret.2220 End of informative comment2221 1. The TPM MUST support authorization handles. The TPM MUST support a minimum of2222 three concurrent authorization handles.2223 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 72 Revision 94 29 March 2006 TCG Published 2. The TPM MUST support authorization-handle termination. The termination includes2224 secure deletion of all authorization session information.2225 13.5 Authorization-Data Insertion Protocol (ADIP)2226 Start of informative comment2227 The creation of AuthData is the responsibility of the entity owner. He or she may use2228 whatever process he or she wishes. The transmission of the AuthData from the owner to the2229 TPM requires confidentiality and integrity. The encryption of the AuthData meets these2230 requirements. The confidentiality and integrity requirements assume the insertion of the2231 AuthData occurs over a network. While local insertions of the data would not require these2232 measures, the protocol is established to be consistent with both local and remote insertions.2233 When the requestor is sending the AuthData to the TPM, the command to load the data2234 requires the authorization of the entity owner. For example, to create a new TPM ID and set2235 its AuthData requires the AuthData of the TPM Owner.2236 The confidentiality of the transmission comes from the encryption of the AuthData, and the2237 integrity comes from the ability of the owner to verify that the authorization is being sent to2238 a TPM and that only a specific TPM can decrypt the data.2239 The mandatory mechanism uses the following features of the TPM, OSAP and HMAC.2240 The creation of a new entity requires the authorization of the entity owner. When the2241 requestor starts the creation process, the creator must use OSAP.2242 The creator builds an encryption key using a SHA-1 hash of the shared secret from the2243 OSAP mechanism and the nonce (authLastNonceEven) returned by the TPM from the2244 TPM_OSAP command.2245 The creator encrypts the new AuthData using the key from the previous step as a one-time2246 pad with XOR and then sends this encrypted data along with the creation request to the2247 TPM.2248 The TPM may support AES as an additional ADIP encryption algorithm.2249 The TPM decrypts the AuthData using the OSAP shared secret and authLastNonceEven,2250 creates the new entity.2251 The TPM includes the sends the reply back to the creator using the new AuthData as the2252 secret value of the HMAC.2253 The creator believes that the OSAP creates a shared secret known only to the creator and2254 the TPM. The TPM believes that the creator is the entity owner by their knowledge of the2255 parent entity AuthData. The creator believes that the process completed correctly and that2256 the AuthData is correct because the HMAC will only verify with the OSAP secret.2257 The ADIP allows for the creation of new entities and the secure insertion of the new entity2258 AuthData. The transmission of the new AuthData uses encryption with the key being a2259 shared secret of an OSAP session.2260 The OSAP session must be created using the owner of the new entity.2261 In the following example, we want to send the previously described command2262 TPM_EXAMPLE to create a new entity. In the example, we assume there is a third input2263 parameter newAuth, and that one of the input parameters is named parentHandle to2264 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 73 TCG Published reference the parent for the new entity (TPM Owner in some circumstances such as the SRK2265 and its children, otherwise a key).2266 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 74 Revision 94 29 March 2006 TCG Published 2267 Caller On the wire Dir TPM Send TPM_OSAP TPM_OSAP parentHandle nonceOddOSAP Create session & authHangle Generate authLastNonceEven Save authLastNonceEven with authHandle Save the ADIP encryption schemewith authHandle Generate nonceEvenOSAP Generate sharedSecret = HMAC(parent.usageAuth, nonceEvenOSAP, nonceOddOSAP) Save parentHandle, sharedSecret with authHandle Save authHandle, authLastNonceEven Generate sharedSecret = HMAC(parent.usageAuth, nonceEvenOSAP, nonceOddOSAP) Save sharedSecret authHandle, authLastNonceEven nonceEvenOSAP ß Returns Generate nonceOdd & save with authHandle. Compute input parameter newAuth = XOR( entityAuthData, SHA1(sharedSecret, authLastNonceEven)) Compute inAuth = HMAC (sharedSecret, inParamDigest, inAuthSetupParams) Send TPM_Example tag paramSize ordinal keyHandle inArgOne inArgTwo newAuth authHandle nonceOdd continueAuthSession inAuth Verify authHandle points to a valid session, mismatch returns TPM_AUTHFAIL Retrieve authLastNonceEven from internal session storage HM = HMAC (sharedSecret, inParamDigest, inAuthSetupParams) Compare HM to inAuth. If they do not compare return with TPM_AUTHFAIL Compute entityAuthData = XOR( newAuth, SHA1(sharedSecret, authLastNonceEven)) Execute TPM_Example, create entity and build returnCode. If TPM_Example requires ADIP encryption, use the algorithm indicated when the OSAP session was set up. Generate nonceEven to replace authLastNonceEven in session Set resAuth = HMAC(sharedSecret, outParamDigest, outAuthSetupParams) TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 75 TCG Published 2268 Save nonceEven HM = HMAC( sharedSecret, outParamDigest, outAuthSetupParams) Compare HM to resAuth. This verifies returnCode and output parameters. tag paramSize returnCode outArgOne nonceEven continueAuthSession resAuth ß Return output parameters Destroy auth session associated with authHandle Table 13:e - Example ADIP Session2269 2270 End of informative comment2271 1. The TPM MUST enable ADIP by using the OSAP. The TPM MUST encrypt the AuthData2272 for the new entity by performing an XOR using the shared secret created by the OSAP.2273 2. The TPM MUST destroy the OSAP session whenever a new entity is created.2274 13.6 AuthData Change Protocol (ADCP)2275 Start of informative comment2276 All entities from the Owner to the SRK to individual keys and data blobs have AuthData.2277 This data may need to change at some point in time after the entity creation. The ADCP2278 allows the entity owner to change the AuthData. The entity owner of a wrapped key is the2279 owner of the parent key.2280 A requirement is that the owner must remember the old AuthData. The only mechanism to2281 change the AuthData when the entity owner forgets the current value is to delete the entity2282 and then recreate it.2283 To protect the data from exposure to eavesdroppers or other attackers, the AuthData uses2284 the same encryption mechanism in use during the ADIP.2285 Changing AuthData requires opening two authentication handles. The first handle2286 authenticates the entity owner (or parent) and the right to load the entity. This first handle2287 is an OSAP and supplies the data to encrypt the new AuthData according to the ADIP2288 protocol. The second handle can be either an OIAP or an OSAP, it authorizes access to the2289 entity for which the AuthData is to be changed.2290 The AuthData in use to generate the OSAP shared secret must be the AuthData of the2291 parent of the entity to which the change will be made.2292 When changing the AuthData for the SRK, the first handle OSAP must be setup using the2293 TPM Owner AuthData. This is because the SRK does not have a parent, per se.2294 If the SRKAuth data is known to userA and userB, userA can snoop on userB while userB2295 is changing the AuthData for a child of the SRK, and deduce the chilďs newAuth.2296 Therefore, if SRKAuth is a well known value, TPM_ChangeAuthAsymStart and2297 TPM_ChangeAuthAsymFinish are preferred over TPM_ChangeAuth when changing2298 AuthData for children of the SRK.2299 This applies to all children of the SRK, including TPM identities.2300 End of informative comment2301 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 76 Revision 94 29 March 2006 TCG Published 1. Changing AuthData for the TPM SHALL require authorization of the current TPM Owner.2302 2. Changing AuthData for the SRK SHALL require authorization of the TPM Owner.2303 3. If SRKAuth is a well known value, TPM_ChangeAuth SHOULD NOT be used to change2304 the AuthData value of a child of the SRK, including the TPM identities.2305 4. All other entities SHALL require authorization of the parent entity.2306 13.7 Asymmetric Authorization Change Protocol (AACP)2307 Start of informative comment2308 This is now deprecated. Use the normal change session inside of a transport session with2309 confidentiality.2310 This asymmetric change protocol allows the entity owner to change entity authorization,2311 under the parenťs execution authorization, to a value of which the parent has no2312 knowledge.2313 In contrast, the TPM_ChangeAuth command uses the parent entity AuthData to create the2314 shared secret that encrypts the new AuthData for an entity. This creates a situation where2315 the parent entity ALWAYS knows the AuthData for entities in the tree below the parent.2316 There may be instances where this knowledge is not a good policy.2317 This asymmetric change process requires two commands and the use of an authorization2318 session.2319 End of informative comment2320 1. Changing AuthData for the SRK SHALL involve authorization by the TPM Owner.2321 2. If SRKAuth is a well known value,2322 3. TPM_ChangeAuthAsymStart and TPM_ChangeAuthAsymFinish SHOULD be used to2323 change the AuthData value of a child of the SRK, including the TPM identities.2324 4. All other entities SHALL involve authorization of the parent entity.2325 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 77 TCG Published 14. FIPS 140 Physical Protection2326 Start of informative comment2327 The FIPS 140-2 program provides assurance that a cryptographic device performs properly.2328 It is appropriate for TPM vendors to attempt to obtain FIPS 140-2 certification.2329 The TPM design should be such that the TPM vendor has the opportunity of obtaining FIPS2330 140-2 certification.2331 End of informative comment2332 14.1 TPM Profile for FIPS Certification2333 Start of informative comment2334 The FIPS mode of the TPM does require some changes over the normal TPM. These changes2335 are listed here such that there is a central point of determining the necessary FIPS changes.2336 Key creation and use2337 TPM_LoadKey, TPM_CMK_CreateKey and TPM_CreateWrapKey changed to disallow the2338 creation or loading of AUTH_NEVER, legacy and keys less than 1024 bits.2339 TPM_MakeIdentity changed to disallow AUTH_NEVER.2340 End of informative comment2341 1. Each TPM Protected Capability MUST be designed such that some profile of the2342 Capability is capable of obtaining FIPS 140-2 certification2343 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 78 Revision 94 29 March 2006 TCG Published 15. Maintenance2344 Start of informative comment2345 The maintenance feature is a vendor-specific feature, and its implementation is vendor-2346 specific. The implementation must, however, meet the minimum security requirements so2347 that implementations of the maintenance feature do not result in security weaknesses.2348 There is no requirement that the maintenance feature is available, but if it is implemented,2349 then the requirements must be met.2350 The maintenance feature described in the specification is an example only, and not the only2351 mechanism that a manufacturer could implement that meets these requirements.2352 Maintenance is different from backup/migration, because maintenance provides for the2353 migration of both migratory and non-migratory data. Maintenance is an optional TPM2354 function, but if a TPM enables maintenance, the maintenance capabilities in this2355 specification are mandatory ­ no other migration capabilities shall be used. Maintenance2356 necessarily involves the manufacturer of a Subsystem.2357 When maintaining computer systems, it is sometimes the case that a manufacturer or its2358 representative needs to replace a Subsystem containing a TPM. Some manufacturers2359 consider it a requirement that there be a means of doing this replacement without the loss2360 of the non-migrational keys held by the original TPM.2361 The owner and users of TCG platforms need assurance that the data within protected2362 storage is adequately protected against interception by third parties or the manufacturer.2363 This process MUST only be performed between two platforms of the same manufacturer and2364 model. If the maintenance feature is supported, this section defines the required functions2365 defined at a high level. The final function definitions and entire maintenance process is left2366 to the manufacturer to define within the constraints of these high level functions.2367 Any maintenance process must have certain properties. Specifically, any migration to a2368 replacement Subsystem must require collaboration between the Owner of the existing2369 Subsystem and the manufacturer of the existing Subsystem. Further, the procedure must2370 have adequate safeguards to prevent a non-migrational key being transferred to multiple2371 Subsystems.2372 The maintenance capabilities TPM_CreateMaintenanceArchive and2373 TPM_LoadMaintenanceArchive enable the transfer of all Protected Storage data from a2374 Subsystem containing a first TPM (TPM1) to a Subsystem containing a second TPM (TPM2):2375 A manufacturer places a public key in non-volatile storage into its TPMs at manufacture2376 time.2377 The Owner of TPM1 uses TPM_CreateMaintenanceArchive to create a maintenance archive2378 that enables the migration of all data held in Protected Storage by TPM1. The Owner of TPM12379 must provide his or her authorization to the Subsystem. The TPM then creates the2380 TPM_MIGRATE_ASYMKEY structure and follows the process defined.2381 The XOR process prevents the manufacturer from ever obtaining plaintext TPM1 data.2382 The additional random data provides a means to assure that a maintenance process cannot2383 subvert archive data and hide such subversion.2384 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 79 TCG Published The random mask can be generated by two methods, either using the TPM RNG or MGF1 on2385 the TPM Owners AuthData.2386 The manufacturer takes the maintenance blob, decrypts it with its private key, and satisfies2387 itself that the data bundle represents data from that Subsystem manufactured by that2388 manufacturer. Then the manufacturer checks the endorsement certificate of TPM2 and2389 verifies that it represents a platform to which data from TPM1 may be moved.2390 The manufacturer dispatches two messages.2391 The first message is made available to CAs, and is a revocation of the TPM1 endorsement2392 certificate.2393 The second message is sent to the Owner of TPM2, which will communicate the SRK,2394 tpmProof and the manufacturer's permission to install the maintenance blob only on TPM22395 The Owner uses TPM_LoadMaintenanceArchive to install the archive copy into TPM2, and2396 overwrite the existing TPM2-SRK and TPM2-tpmProof in TPM2. TPM2 overwrites TPM2-SRK2397 with TPM1-SRK, and overwrites TPM2-tpmProof with TPM1-tpmProof.2398 Note that the command TPM_KillMaintenanceFeature prevents the operation of2399 TPM_CreateMaintenanceArchive and TPM_LoadMaintenanceArchive. This enables an Owner2400 to block maintenance (and hence the migration of non-migratory data) either to or from a2401 TPM.2402 It is required that a manufacturer takes steps that prevent further access of migrated data2403 by TPM1. This may be achieved by deleting the existing Owner from TPM1, for example.2404 For the manufacturer to validate that the maintenance blob is coming from a valid TPM, the2405 manufacturer can require that a TPM identity sign the maintenance blob. The identity2406 would be from a CA under the control of the manufacturer and hence the manufacturer2407 would be satisfied that the blob is from a valid TPM.2408 End of informative comment2409 1. The maintenance feature MUST ensure that the information can be on only one TPM at2410 a time. Maintenance MUST ensure that at no time the process will expose a shielded2411 location. Maintenance MUST require the active participation of the Owner.2412 2. Any migration of non-migratory data protected by a Subsystem SHALL require the2413 cooperation of both the Owner of that non-migratory data and the manufacturer of that2414 Subsystem. That manufacturer SHALL NOT cooperate in a maintenance process unless2415 the manufacturer is satisfied that non-migratory data will exist in exactly one2416 Subsystem. A TPM SHALL NOT provide capabilities that support migration of non-2417 migratory data unless those capabilities are described in the TCG specification.2418 3. The maintenance feature MUST move the following2419 4. TPM_KEY for SRK. The maintenance process will reset the SRK AuthData to match the2420 TPM Owners AuthData2421 5. TPM_PERMANENT_DATA -> tpmProof2422 6. TPM Owner's authorization2423 15.1 Field Upgrade2424 Start of informative comment2425 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 80 Revision 94 29 March 2006 TCG Published A TPM, once in the field, may need to update the protected capabilities. This command,2426 which is optional, provides the mechanism to perform the update.2427 End of informative comment2428 The TPM SHOULD have provisions for upgrading the subsystem after shipment from the2429 manufacturer. If provided the mechanism MUST implement the following guidelines:2430 1. The upgrade mechanisms in the TPM MUST not require the TPM to hold a global secret.2431 The definition of global secret is a secret value shared by more than one TPM.2432 2. The TPM is not allowed to pre-store or use unique identifiers in the TPM for the purpose2433 of field upgrade. The TPM MUST NOT use the endorsement key for identification or2434 encryption in the upgrade process. The upgrade process MAY use a TPM Identity (AIK) to2435 deliver upgrade information to specific TPM devices.2436 3. The upgrade process can only change protected-capabilities.2437 4. The upgrade process can only access data in shielded-locations where this data is2438 necessary to validate the TPM Owner, validate the TPME and manipulate the blob2439 5. The TPM MUST conform to the TCG specification, protection profiles and security targets2440 after the upgrade. The upgrade MAY NOT decrease the security values from the original2441 security target.2442 6. The security target used to evaluate this TPM MUST include this command in the TOE.2443 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 81 TCG Published 16. Proof of Locality2444 Start of informative comment2445 When a platform is designed with a trusted process, the trusted process may wish to2446 communicate with the TPM and indicate that the command is coming from the trusted2447 process. The definition of a trusted process is a platform specific issue.2448 The commands that the trusted process sends to the TPM are the normal TPM commands2449 with a modifier that indicates that the trusted process initiated the command. The TPM2450 accepts the command as coming from the trusted process merely due to the fact that the2451 modifier is set. The TPM itself is not responsible how the signal is asserted; only that it2452 honors the assertions The TPM cannot verify the validity of the modifier.2453 The definition of the modifier is a platform specific issue. Depending on the platform the2454 modifier could be a special bus cycle or additional input pins on the TPM. The assumption2455 is that to spoof the modifier to the TPM requires more than just a simple hardware attack2456 but would require expertise and possibly special hardware. One example would be special2457 cycles on the LPC bus that inform the TPM it is under the control of a process on the PC2458 platform.2459 To allow for multiple mechanisms and for finer grained reporting the TPM will include 42460 locality modifiers. These four modifiers allow the platform specific specification to properly2461 indicate exactly what is occurring and for TPM's to properly respond to locality.2462 End of informative comment2463 1. The TPM modifies the receipt of a command and indicates that the trusted process sent2464 the command when the TPM determines that the modifier is on. The modifier MUST only2465 affect the individual command just received and MUST NOT affect any other commands.2466 However the TPM_ExecuteTransport MUST propagate the modifier to the wrapped2467 command.2468 2. A TPM platform specific specification MAY indicate the presence of a maximum of 4 local2469 modifiers. The modifier indication uses the TPM_MODIFIER_INDICATOR structure.2470 3. The modifiers may occur singularly or in combination.2471 4. The definition of the trusted source is in the platform specific specification.2472 5. For ease in reading this specification the indication that the TPM has received any2473 modifier will be LOCAL_MOD = TRUE.2474 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 82 Revision 94 29 March 2006 TCG Published 17. Monotonic Counter2475 Start of informative comment2476 The monotonic counter provides an ever-increasing incremental value. The TPM must2477 support at least 4 concurrent counters. Implementations inside the TPM may create 42478 unique counters or there may be one counter with pointers to keep track of the pointers2479 current value. A naming convention to allow for unambiguous reference to the various2480 components the following terms are in use:2481 Internal Base ­ This is the main counter. It is in use internally by the TPM and is not2482 directly accessible by any outside process.2483 External Counter ­ A counter in use by external processes. This could be related to the2484 main counter via pointers and difference values or it could be a totally unique value. The2485 value of an external counter is not affected by any use, increment or deletion of any other2486 external counter.2487 Max Value ­ The max count value of all counters (internal and external). So if there were 32488 external counters having values of 10, 15 and 201 and the internal base having a value of2489 201 then Max Value is 201. In the same example if the internal base was 502 then Max2490 Value would be 502.2491 There are two methods of obtaining an external count, signed or unsigned. The external2492 counter must allow for 7 years of increments every 5 seconds without causing a hardware2493 failure. The output of the counter is a 32-bit value.2494 The TPM may create a throttling mechanism that limits the ability to increment an external2495 counter within a certain time range. The TPM must support an increment rate of once every2496 5 seconds.2497 To create an external counter requires TPM Owner authorization. To increment an external2498 counter the command must pass authorization to use the counter.2499 External counters can be tagged with a short text string to facilitate counter administration.2500 Manufacturers are free to implement the monotonic counter using any mechanism.2501 To illustrate the counters and base the following example is in use. This mechanism uses2502 two saving values (diff and start), however this is only an example and not meant to indicate2503 any specific implementation.2504 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 83 TCG Published 2505 The internal base (IB) always moves forward and can never be reset. IB drives all external2506 counters on the machine..2507 The purpose of the following example is to show the two external counters always moving2508 forward independent of the other and how the IB moves forward also.2509 Starting condition is that IB is at 22 and no other external counters are active.2510 Start external counter A2511 Increment IB (set new Max Value) IB = 232512 Assign start value of A to 23 (or Max Value)2513 Assign difference of A to 23 (we always start at current value of IB)2514 Assign a handle for A2515 Increment A 5 times2516 IB is now 282517 Request current A value2518 Return 28 = 28 (IB) + 23 (difference) ­ 23 (start value)2519 Counter A has gone from the start of 23 to 28 incremented 5 times.2520 TPM_Startup(ST_CLEAR)2521 Start Counter B2522 Save A difference 28 = 23 (old difference) + 28 (IB) ­ 23 (start value)2523 Increment IB (set new Max Value) IB = 292524 Set start value of B to 29 (or Max Value)2525 Assign difference of B to 292526 Assign handle for B2527 Increment B 8 times2528 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 84 Revision 94 29 March 2006 TCG Published IB is now 372529 Request B value2530 Return 37 = 37 (IB) + 29 (difference) ­ 29 (start value)2531 TPM_Startup(ST_CLEAR)2532 Increment A2533 Store B difference (37)2534 Load A start value of 372535 Increment IB to 382536 Return A value2537 Return 29 = 38 (IB) + 28 (difference) ­ 37 (start value)2538 2539 Notice that A has gone from 28 to 29 which is correct, while B is at 37. Depending on the2540 order of increments A may pass B or it may always be less than B.2541 End of informative comment2542 1. The counter MUST be designed to not wear out in the first 7 years of operation. The2543 counter MUST be able to increment at least once every 5 seconds. The TPM, in response2544 to operations that would violate these counter requirements, MAY throttle the counter2545 usage (cause a delay in the use of the counter) or return the error2546 TPM_E_COUNTERUSAGE.2547 2. The TPM MUST support at least 4 concurrent counters.2548 3. The establishment of a new counter MUST prevent the reuse of any previous counter2549 value. I.E. if the TPM has 3 counters and the max value of a current counter is at 362550 then the establishment of a new counter would start at 37.2551 4. After a successful TPM_Startup(ST_CLEAR) the first successful TPM_IncrementCounter2552 sets the counter handle. Any attempt to issue TPM_IncrementCounter with a different2553 handle MUST fail.2554 5. TPM_CreateCounter does NOT set the counter handle.2555 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 85 TCG Published 18. Transport Protection2556 Start of informative comment2557 The creation of sessions allows for the grouping of a set of commands into a session. The2558 session provides a log of all commands and can provide confidentiality of the commands2559 using the session.2560 Session establishment creates a shared secret and then uses the shared secret to authorize2561 and protect commands sent to the TPM using the session.2562 After establishing the session, the caller uses the session to wrap a command to execute.2563 The user of the transport session can wrap any command except for commands that would2564 create nested transport sessions.2565 The log of executed commands uses a structure that includes the parameters and current2566 tick count. The session log provides a record of each command using the session.2567 The transport session uses the same rolling nonce protocol that authorization sessions use.2568 This protocol defines two nonces for each command sent to the TPM; nonceOdd provided by2569 the caller and nonceEven generated by the TPM.2570 For confidentiality, the caller can use the MGF1 function to create an XOR string the same2571 size as the command to execute. The inputs to the MGF1 function are the shared secret,2572 nonceOdd and nonceEven. A symmetric key encryption algorithm can also be specified.2573 There is no explicit close session as the caller can use the continueSession flag set to false2574 to end a session. The caller can also call the sign session log, which also ends the session. If2575 the caller losses track of which sessions are active the caller should use the flush2576 commands to regain control of the TPM resources.2577 For an attacker to successfully break the encryption the attacker must be able to determine2578 from a few bits what an entire SHA-1 output was. This is equivalent to breaking SHA-1. The2579 reason that the attacker will know some bits is that the commands are in a known format.2580 This then allows the attacker to determine what the XOR bits were. Knowledge of 159 bits of2581 the XOR stream does not provide any greater that 50% probability of knowing the 160th bit.2582 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 86 Revision 94 29 March 2006 TCG Published 2583 This picture shows the protection of a TPM_Quote command. Previously executed was2584 session establishment. The nonces in use for the TPM_Quote have no relationship with the2585 nonces that are in use for the TPM_ExecuteTransport command.2586 End of informative comment2587 1. The TPM MUST support a minimum of one transport session.2588 2. The TPM MUST NOT support the nesting of transport sessions. The definition of nesting2589 is attempting to execute a wrapped command that is a transport session command. So2590 for example when executing TPM_ExecuteTransport the wrapped command MUST not be2591 TPM_ExecuteTransport.2592 3. The TPM MUST ensure that if transport logging is active that the inclusion of the tick2593 count in the session log does not provide information that would make a timing attack2594 on the operations using the session more successful.2595 4. The transport session MAY be exclusive. Any command executed outside of the exclusive2596 transport session MUST cause the invalidation of the exclusive transport session.2597 a. The TPM_ExecuteTransport command specifying the exclusive transport session is2598 the only command that does not terminate the exclusive session.2599 5. It MAY be ineffective to wrap TPM_SaveState in a transport session. Since the TPM MAY2600 include transport sessions in the saved state, the saved state MAY be invalidated by the2601 wrapping TPM_ExecuteTransport.2602 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 87 TCG Published 18.1 Transport encryption and authorization2603 Start of informative comment2604 The confidentially of the transport protection is provided by a encrypting the wrapped2605 command. Encryption of various items in the wrapped command makes resource2606 management of a TPM impossible. For this reason, encryption of the entire command is not2607 possible. In addition to the encryption issue, there are difficulties with creating the HMAC2608 for the TPM_ExecuteTransport authorization.2609 The solution to these problems is to provide limited encryption and HMAC information.2610 The HMAC will only include two areas from the wrapped command, the command header2611 information up to the handles, and the data after the handles. The format of all TPM2612 commands is such that all handles are in the data stream prior to the payload or data. After2613 the data comes the authorization information. To enable resource management, the HMAC2614 for TPM_ExecuteTransport only includes the ordinal, header information and the data. The2615 HMAC does not include handles and the authorization handles and nonces.2616 The exception is TPM_OwnerReadInternalPub, which uses fixed value key handles that are2617 included in the encryption and HMAC calculation.2618 2619 2620 A more exact representation of the execute transport command would be the following2621 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 88 Revision 94 29 March 2006 TCG Published ***********************************************2622 * TAGet | LENet | ORDet | wrappedCmd | AUTHet *2623 ***********************************************2624 2625 wrappedCmd looks like2626 *******************************************************************2627 * TAGw | LENw | ORDw | HANDLESw | DATAw | AUTH1w (o) | AUTH2w (o) *2628 *******************************************************************2629 A more exact representation of the execute transport response would be the following2630 **********************************************2631 * TAGet | LENet | RCet | wrappedRsp | AUTHet *2632 **********************************************2633 2634 wrappedRsp looks like2635 ******************************************************************2636 * TAGw | LENw | RCw | HANDLESw | DATAw | AUTH1w (o) | AUTH2w (o) *2637 ******************************************************************2638 2639 The calculation for AUTHet takes as the data component of the HMAC calculation the2640 concatenation of ORDw and DATAw. A normal HMAC calculation would have taken the2641 entire wrappedCmd value but for the executeTransport calculation only the above two2642 values are active. This does require the executeTransport command to parse the2643 wrappedCmd to find the appropriate values.2644 The data for the command HMAC calculation is the following:2645 H1 = SHA-1 (ORDw || DATAw)2646 inParamDigest = SHA-1 (ORDet || wrappedCmdSize || H1)2647 AUTHet = HMAC (inParamDigest || lastNonceEven(et) || nonceOdd(et) || continue(et))2648 The data for the response HMAC calculation is the following:2649 H2 = SHA-1 (RCw || ORDw || DATAw)2650 outParamDigest = SHA-1 (RCet || ORDet || currentTicks || locality || wrappedRspSize ||2651 H1)2652 AUTHet = HMAC (outParamDigest || nonceEven(et) || nonceOdd(et) || continue(et))2653 DATAw is the unencrypted data. wrappedCmdSize and wrappedRspSize ares the actual size2654 of the DATAw area and not the size of H1 or H2.2655 End of informative comment2656 The TPM MUST release a transport session and all information related to the session when:2657 1. TPM_ReleaseTransportSigned is executed2658 2. TPM_ExecuteTransport is executed with continueTransSession set to FALSE2659 3. Any failure of the integrity check during execution of TPM_ExecuteTransport2660 4. If the session has TPM_TRANSPORT_LOG set and the TPM tick session is interrupted for2661 any reason. This is due to the return of tick values without the nonces associated with2662 the session.2663 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 89 TCG Published 5. The TPM executes some command that deactivates the TPM or removes the TPM Owner2664 or EK.2665 18.1.1 MGF1 parameters2666 Start of informative comment2667 MGF1 provides the confidentiality for the transport session. MGF1 is a function from PKCS2668 1 version 2.0. This function provides a mechanism to distribute entropy over a large2669 sequence. The sequence provides a value to XOR over the message. This in effect creates a2670 stream cipher but not one that is available for bulk encryption.2671 Transport confidentiality uses MGF1 as a stream cipher and obtains the entropy for each2672 message from the following three parameters; nonceOdd, nonceEven and session authData.2673 It is imperative that the stream cipher not use the same XOR sequence at any time. The2674 following illustrates how the sequence changes for each message (both input and output).2675 M1Input ­ N2, N1, sessionSecret)2676 M1Output ­ N4, N1, sessionSecret)2677 M2Input ­ N4, N3, sessionSecret)2678 M2Output ­ N6, N3, sessionSecret)2679 There is an issue with this sequence. If the caller does not change N1 to N3 between2680 M1Output and M2Input then the same sequence will be generated. The TPM does not2681 enforce the requirement to change this value so it is possible to leak information.2682 The fix for this is to add one more parameter, the direction. So the sequence is now this:2683 M1Input ­ N2, N1, "in", sessionSecret)2684 M1Output ­ N4, N1, "out", sessionSecret)2685 M2Input ­ N4, N3, "in", sessionSecret)2686 M2Output ­ N6, N3, "out", sessionSecret)2687 Where "in" indicates the in direction and "out" indicates the out direction.2688 Notice the calculation for M1Output uses "out" and M2Input uses "in", so if the caller2689 makes a mistake and does not change nonceOdd, the sequence will still be different.2690 nonceEven is under control of the TPM and is always changing, so there is no need to worry2691 about nonceEven not changing.2692 End of informative comment2693 18.1.2 HMAC calculation2694 Start of informative comment2695 The HMAC calculation for transports presents some issues with what should and should2696 not be in the calculation. The idea is to create a calculation for the wrapped command and2697 add that to the wrapper.2698 So the data area for a wrapped command is not entirely HMAC'd like a normal command2699 would be.2700 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 90 Revision 94 29 March 2006 TCG Published The process is to calculate the inParamDigest of the unencrypted wrapped command2701 according to the normal rules of command HMAC calculations. Then use that value as the2702 3S parameter in the calculation. 2S is the actual wrapped command size, and not the size2703 of inParamDigest.2704 Example using a wrapped TPM_LoadKey command2705 Calculate the SHA-1 value for the TPM_LoadKey command (ordinal and data) as per the2706 normal HMAC rules. Take the digest and use that value as 3S for the2707 TPM_ExecuteTransport HMAC calculation.2708 End of informative comment2709 18.1.3 Transport log creation2710 Start of informative comment2711 The log of information that a transport session creates needs a mechanism to tie any keys2712 in use during the session to the session. As the HMAC and encryption for the command2713 specifically exclude handles, there is no direct way to create the binding.2714 When creating the input log, if a handle points to a key, the hash of the public key is added2715 to the log. The session owner knows the value of any keys in use and hence can still create2716 a log that shows the values used by the log and can validate the session.2717 When creating the transport input log, if there is one input key, the TPM will create a hash2718 of the public key. If there are two input keys, the TPM will create a hash of each public key,2719 concatenate the hashes, and create a hash of the result. The result, along with the2720 parameter digest, is used to extend that transport log.2721 End of informative comment2722 18.1.4 Additional Encryption Mechanisms2723 Start of informative comment2724 The TPM can optionally implement alternate algorithms for the encryption of commands2725 sent to the TPM_ExecuteTransport command. The designation of the algorithm uses the2726 TPM_AGORITHM_ID element of the TPM_TRANSPORT_PUBLIC parameter of2727 TPM_EstablishTransport command.2728 The anticipation is that AES and 3DES will be available algorithms supported by various2729 TPM's. Symmetric algorithms have options available to them like key size, block size and2730 operating mode. When using an algorithm other than MGF1 the algorithm must specify2731 these options.2732 End of informative comment2733 1. The TPM MAY support other symmetric algorithms for the confidentiality requirement in2734 TPM_EstablishTransport2735 18.2 Transport Error Handling2736 Start of informative comment2737 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 91 TCG Published With the transport hiding the actual execution of commands and the transport capable of2738 generating errors, rules must be established to allow for the errors and the results of2739 commands to be properly passed to TPM callers.2740 End of informative comment2741 1. There are 3 error cases:2742 2. C1 is the case where an error occurs during the processing of the transport package at2743 the TPM. In this case, the wrapped command has not been sent to the command2744 decoder. Errors occurring during C1 are sent back to the caller as a response to the2745 TPM_ExecuteTransport command. The error response does not have confidentiality.2746 3. C2 is the case where an error occurs during the processing of the wrapped command.2747 This results in an error response from the command. The session returns the error2748 response according to the attributes of the session.2749 4. C3 is the case where an error occurs after the wrapped command has completed2750 processing and the TPM is preparing the response to the TPM_ExecuteTransport2751 command. In this case, where the TPM does have an internal error, the TPM has no2752 choice but to return the error as in C1. This however hides the results of the wrapped2753 command. If the wrapped command completed successfully then there are session2754 nonces that are being returned to the caller that are lost. The loss of these nonces2755 causes the caller to be unsure of the state of the TPM and requires the reestablishment2756 of sessions and keys.2757 18.3 Exclusive Transport Sessions2758 Start of informative comment2759 The caller may establish an exclusive session with the TPM. When an exclusive session is2760 running, execution of any command other then TPM_ExecuteTransport or2761 TPM_ReleaseTransportSigned targeting the exclusive session causes the abnormal2762 invalidation of the exclusive transport session. Invalidation means that the handle is no2763 longer valid and all subsequent attempts to use the handle return an error.2764 The design for the exclusive session provides an assurance that no other command2765 executed on the TPM. It is not a lock to prevent other operations from occurring. Therefore,2766 the caller is responsible for ensuring no interruption of the sequence of commands using2767 the TPM.2768 One exclusive session2769 The TPM only supports one exclusive session at a time. There is no nesting or other2770 commands possible. The TPM maintains an internal flag that indicates the existence of an2771 exclusive session.2772 TSS responsibilities2773 It is the responsibility of the TSS (or other controlling software) to ensure that only2774 commands using the session reach the TPM. As the purpose of the session is to show that2775 nothing else occurred on the TPM during the session, the TSS should control access to the2776 TPM and prevent any other uses of the TPM. The TSS design must take into account the2777 possibility of exclusive session handle invalidation.2778 Sleep states2779 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 92 Revision 94 29 March 2006 TCG Published Exclusive sessions as defined here do not work across TPM_SaveState and2780 TPM_Startup(ST_STATE) invocations. To have this sequence work properly there would2781 need to be exceptions to allowing only TPM_ExecuteTranport and2782 TPM_ReleaseTransportSigned in an exclusive session. The requirement for these exceptions2783 would come from the attempt of the TSS to understand the current state of the TPM.2784 Commands like TPM_GetCapability and others would have to execute to inform the TSS as2785 to the internal state of the TPM. For this reason, there are no exceptions to the rule and the2786 exclusive session does not remain active across a TPM_SaveState command.2787 End of informative comment2788 1. The TPM MUST support only one exclusive transport session2789 2. The TPM MUST invalidate the exclusive transport session upon the receipt of any2790 command other than TPM_ExecuteTransport or TPM_ReleaseTransportSigned targeting2791 the exclusive session.2792 a. Invalidation includes the release of any resources assigned to the session2793 18.4 Transport Audit Handling2794 Start of informative comment2795 Auditing of TPM_ExecuteTransport occurs as any other command that may require2796 auditing. There are two entries in the log, one for input one for output. The execution of the2797 wrapped command can create an anomaly in the log.2798 Assume that both TPM_ExecuteTransport and the wrapped commands require auditing, the2799 audit flow would look like the following:2800 TPM_ExecuteTransport input parameters2801 wrapped command input parameters2802 wrapped command output parameters2803 TPM_ExecuteTransport output parameters2804 End of informative comment2805 1. Audit failures are reported using the AUTHFAIL error commands and reflect the success2806 or failure of the wrapped command.2807 18.4.1 Auditing of wrapped commands2808 Start of informative comment2809 Auditing provides information to allow an auditor to recreate the operations performed.2810 Confidentiality on the transport channel is to hide what operations occur. These two2811 features are in conflict. According to the TPM design philosophy, the TPM Owner takes2812 precedence.2813 For a command sent on a transport session, with the session using confidentiality and the2814 command requiring auditing, the TPM will execute the command however the input and2815 output parameters for the command are set to NULL.2816 End of informative comment2817 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 93 TCG Published 1. When the wrapped command requires auditing and the transport session specifies2818 encryption, the TPM MUST perform the audit. However, when computing the audit2819 digest:2820 a. For input, only the ordinal is audited.2821 b. For output, only the ordinal and return code are audited.2822 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 94 Revision 94 29 March 2006 TCG Published 19. Audit Commands2823 Start of informative comment2824 To allow the TPM Owner the ability to determine that certain operations on the TPM have2825 been executed, auditing of commands is possible. The audit value is a digest held internally2826 to the TPM and externally as a log of all audited commands. With the log held externally to2827 the TPM, the internal digest must allow the log auditor to determine the presence of attacks2828 against the log. The evidence of tampering may not provide evidence of the type of attack2829 mounted against the log.2830 The TPM cannot enforce any protections on the external log. It is the responsibility of the2831 external log owner to properly maintain and protect the log.2832 The TPM provides mechanisms for the external log maintainer to resynchronize the internal2833 digest and external logs.2834 The Owner has the ability to set which functions generate an audit event and to change2835 which functions generate the event at any time.2836 The status of the audit generation is not sensitive information and so the command to2837 determine the status of the audit generation is not an owner authorized command.2838 It is important to note the difference between auditing and the logging of transport sessions.2839 The audit log provides information on the execution of specific commands. There will be a2840 very limited number of audited commands, most likely those commands that provide2841 identities and control of the TPM. Commands such as TPM_Unseal would not be audited.2842 They would use the logging functions of a transport session.2843 The auditing of an ordinal happens in a two-step process. The first step involves auditing2844 the receipt of the command and the input parameters; the second step involves auditing the2845 response to the command and the output parameters. This two-step process is in place to2846 lower the amount of memory necessary to keep track of the audit while executing the2847 command. This two-step process makes no memory requirements on a TPM to save any2848 audit information while a command is executing.2849 There is a requirement to enable verification of the external audit log both during a power2850 session and across power sessions and to enable detection of partial or inconsistent audit2851 logs throughout the lifetime of a TPM.2852 A TPM will hold an internal record consisting of a non-volatile counter (that increments2853 once per session, when the first audit event of that session occurs) and a digest (that holds2854 the digest of the current session). Most probably, the audit digest will be volatile. Note,2855 however, that nothing in this specification prevents the use of a non-volatile audit digest.2856 This arrangement of counter and digest is advantageous because it is easier to build a high2857 endurance non-volatile counter than a high endurance non-volatile digest. This2858 arrangement is insufficient, however, because the truncation of an audit log of any session2859 is possible without trace. It is therefore necessary to perform an explicit close on the audit2860 session. If there is no record of a close-audit event in an audit session, anything could have2861 happened after the last audit event in the audit log. The essence of a typical TPM audit2862 recording mechanism is therefore:2863 The TPM contains a volatile digest used like a PCR, where the "integrity metrics" are digests2864 of command parameters in the current audit session.2865 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 95 TCG Published An audit session opens when the volatile "PCR" digest is "extended" from its NULL state.2866 This occurs whenever an audited command is executed AND no audit session currently2867 exists, and in no other circumstances. When an audit session opens, a non-volatile counter2868 is automatically incremented.2869 An audit session closes when a TPM receives TPM_GetAuditDigestSigned with a closeAudit2870 parameter asserted. An audit session must be considered closed if the value in the volatile2871 digest is invalid (for whatever reason).2872 TPM_GetCapability should report the effect of TPM_Startup on the volatile digest. (TPMs2873 may initialize the volatile digest on the first audit command after TPM_Startup(ST_CLEAR),2874 or on the first audit command after any version of TPM_Startup, or may be independent of2875 TPM_Startup.)2876 When the TPM signs its audit digest, it signs the concatenation of the non-volatile counter2877 and the volatile digest, and exports the value of the non-volatile counter, plus the value of2878 the volatile digest, plus the value of the signature.2879 If the audit digest is initialized by TPM_Startup(ST_STATE), then it may be useless to audit2880 the TPM_SaveState ordinal. Any command after TPM_SaveState MAY invalidate the saved2881 state. If authorization sessions are part of the saved state, TPM_GetAuditDigestSigned will2882 most likely invalidate the state as it changes the preserved authorization session nonce. It2883 may therefore be impossible to get the audit results.2884 The system designer needs to ensure that the selected TPM can handle the specific2885 environment and avoid burnout of the audit monotonic counter.2886 End of informative comment2887 1. Audit functionality is optional2888 a. If the platform specific specification requires auditing, the specification SHALL2889 indicate how the TPM implements audit2890 2. The TPM MUST maintain an audit monotonic count that is only available for audit2891 purposes.2892 a. The increment of this audit counter is under the sole control of the TPM and is not2893 usable for other count purposes.2894 b. This monotonic count MUST BE incremented by one whenever the audit digest is2895 "extended" from a NULL state.2896 3. The TPM MUST maintain an audit digest.2897 a. This digest MUST be set to NULL upon the execution of TPM_GetAuditDigestSigned2898 with a TRUE value of closeAudit provided that the signing key is an identity key.2899 b. This digest MAY be set to NULL on TPM_Startup[ST_CLEAR] or2900 TPM_Startup[ST_STATE].2901 c. When an audited command is executed, this register MUST be extended with the2902 digest of that command.2903 4. Each command ordinal has an indicator in non-volatile TPM memory that indicates if2904 execution of the command will generate an audit event. The setting of the ordinal2905 indicator MUST be under control of the TPM Owner.2906 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 96 Revision 94 29 March 2006 TCG Published 5. Updating of auditDigest MAY cease when TPM_STCLEAR_FLAGS -> deactivated is TRUE.2907 This is because a deactivated TPM performs no useful service until the2908 TPM_Startup(ST_CLEAR), at which point TPM_STCLEAR_FLAGS -> deactivated is2909 reinitialized.2910 19.1 Audit Monotonic Counter2911 Start of informative comment2912 The audit monotonic counter (AMC) performs the task of sequencing audit logs across audit2913 sessions. The AMC must have no other uses other than the audit log.2914 The TPM and platform should be matched such that the expected AMC endurance matches2915 the expected platform audit sessions and sleep cycles.2916 Given the size of the AMC it is not anticipated that the AMC would roll over. If the AMC2917 were to roll over, and the storage of the AMC still allowed updates, the AMC could cycle and2918 start at 0 again.2919 End of informative comment2920 1. The AMC is a TPM_COUNTER_VALUE.2921 2. The AMC MUST last for 7 years or at least 1,000,000 audit sessions, whichever occurs2922 first. After this amount of usage, there is no guarantee that the TPM will continue to2923 properly increment the monotonic counter.2924 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 97 TCG Published 20. Design Section on Time Stamping2925 Start of informative comment2926 The TPM provides a service to apply a time stamp to various blobs. The time stamp provided2927 by the TPM is not an actual universal time clock (UTC) value but is the number of timer2928 ticks the TPM has counted. It is the responsibility of the caller to associate the ticks to an2929 actual UTC time.2930 The TPM counts ticks from the start of a timing session. Timing sessions are platform2931 dependent events that may or may not coincide with TPM_Init and TPM_Startup sessions.2932 The reason for this difference is the availability of power to the TPM. In a PC desktop, for2933 instance power could be continually available to the TPM by using power from the wall2934 socket. For a PC mobile platform, power may not be available when only using the internal2935 battery. It is a platform designer's decision as to when and how they supply power to the2936 TPM to maintain the timing ticks.2937 The TPM can provide a time stamping service. The TPM does not maintain an internal2938 secure source of time rather the TPM maintains a count of the number of ticks that have2939 occurred since the start of a timing session.2940 On a PC, the TPM may use the timing source of the LPC bus or it may have a separate clock2941 circuit. The anticipation is that availability of the TPM timing ticks and the tick resolution is2942 an area of differentiation available to TPM manufactures and platform providers.2943 End of informative comment2944 1. This specification makes no requirement on the mechanism required to implement the2945 tick counter in the TPM.2946 2. This specification makes no requirement on the ability for the TPM to maintain the2947 ability to increment the tick counter across power cycles or in different power modes on2948 a platform.2949 20.1 Tick Components2950 Start of informative comment2951 The TPM maintains for each tick session the following values:2952 Tick Count Value (TCV) ­ The count of ticks for the session.2953 Tick Increment Rate (TIR) ­ The rate at which the TCV is incremented. There is a set2954 relationship between TIR and seconds, the relationship is set during manufacturing of the2955 TPM and platform. This is the TPM_CURRENT_TICKS -> tickRate parameter.2956 Tick Session Nonce (TSN) ­ The session nonce is set at the start of each tick session.2957 End of informative comment2958 1. The TCV MUST be set to 0 at the start of each tick session. The TPM MUST start a new2959 tick session if the TPM loses the ability to increment the TCV according to the TIR.2960 2. The TSN MUST be set to the next value from the TPM RNG at the start of each new tick2961 session. When the TPM loses the ability to increment the TCV according to the TIR the2962 TSN MUST be set to NULLS.2963 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 98 Revision 94 29 March 2006 TCG Published 3. If the TPM discovers tampering with the tick count (through timing changes etc) the TPM2964 MUST treat this as an attack and shut down further TPM processing as if a self-test had2965 failed.2966 20.2 Basic Tick Stamp2967 Start of informative comment2968 The TPM does not provide a secure time source, nor does it provide a signature over some2969 time value. The TPM does provide a signature over some current tick counter. The signature2970 covers a hash of the blob to stamp, the current counter value, the tick session nonce and2971 some fixed text.2972 The Tick Stamp Result (TSR) is the result of the tick stamp operation that associates the2973 TCV, TSN and the blob. There is no association with the TCV or TSR with any UTC value at2974 this point.2975 End of informative comment2976 20.3 Associating a TCV with UTC2977 Start of informative comment2978 An outside observer would like to associate a TCV with a relevant time value. The following2979 shows how to accomplish this task. This protocol is not required but shows how to2980 accomplish the job.2981 EntityA wants to have BlobA time stamped. EntityA performs TPM_TickStamp on BlobA.2982 This creates TSRB (TickStampResult for Blob). TSRB records TSRBTCV, the current value of2983 the TCV, and associates TSRBTCV with the TSN.2984 Now EntityA needs to associate a TCV with a real time value. EntityA creates blob TS which2985 contains some known text like "Tick Stamp". EntityA performs TPM_TickStamp on blob TS2986 creating TSR1. This records TSR1TCV, the current value of the TCV, and associates2987 TSR1TCV with the TSN.2988 EntityA sends TSR1 to a Time Authority (TA). TA creates TA1 which associates TSR1 with2989 UTC1.2990 EntityA now performs TPM_TickStamp on TA1. This creates TSR2. TSR2 records TSR2TCV,2991 the current values of the TCV, and associates TSR2TCV with the TSN.2992 Analyzing the associations2993 EntityA has three TSR's; TSRB the TSR of the blob that we wanted to time stamp, TSR1 the2994 TSR associated with the TS blob and TSR2 the TSR associated with the information from2995 the TA. EntityA wants to show an association between the various TSR such that there is a2996 connection between the UTC and BlobA.2997 From TSR1 EntityA knows that TSR1TCV is less than the UTC. This is true since the TA is2998 signing TSR1 and the creation of TSR1 has to occur before the signature of TSR1. Stated2999 mathematically:3000 TSR1TCV < UTC13001 From TSR2 EntityA knows that TSR2TCV is greater than the UTC. This is true since the3002 TPM is signing TA1 which must be created before it was signed. Stated mathematically:3003 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 99 TCG Published TSR2TCV > UTC13004 EntityA now knows TSR1TCV and TSR2TCV bound UTC1. Stated mathematically:3005 TSR1TCV < UTC1 < TSR2TCV3006 This association holds true if the TSN for TSR1 matches the TSN for TSR2. If some event3007 occurs that causes the TPM to create a new TSN and restart the TCV then EntityA must3008 start the process all over again.3009 EntityA does not know when UTC1 occurred in the interval between TSR1TCV and3010 TSR2TCV. In fact, the value TSR2TCV minus TSR1TCV (TSRDELTA) is the amount of3011 uncertainty to which a TCV value should be associated with UTC1. Stated mathematically:3012 TSRDELTA = TSR2TCV ­ TSR1TCV iff TSR1TSN = TSR2TSN3013 EntityA can obtains k1 the relationship between ticks and seconds using the3014 TPM_GetCapability command. EntityA also obtains k2 the possible errors per tick. EntityA3015 now calculate DeltaTime which is the conversion of ticks to seconds and the TSRDELTA.3016 State mathematically:3017 DeltaTime = (k1 * TSRDELTA) + (k2 * TSRDELTA)3018 3019 To make the association between DeltaTime, UTC and TSRB note the following:3020 DeltaTime = (k1*TSRDelta) + Drift = TimeChange + Drift3021 Where ABSOLUTEVALUE(Drift) TSR1TCV - UTC1 > -DeltaTime = -TimeChange - Drift3031 (Multiply through by -1)3032 (5) TimeChange/2 > [ TSR1TCV - (UTC1-TimeChange/2)] > -TimeChange/2 - Drift3033 (add TimeChange/2 to all sides)3034 (6) TimeChange/2 + ABSOLUTEVALUE(Drift) > [ TSR1TCV - (UTC1-TimeChange/2)]3035 > -TimeChange/2 - ABSOLUTEVALUE(Drift)3036 Making the large side of an equality bigger, and potentially making the small side smaller.3037 (7) ABSOLUTEVALUE[ TSR1TCV - (UTC1-TimeChange/2)] < TimeChange/2 +3038 ABSOLUTEVALUE(Drift)3039 (Definition of Absolute Value, and TimeChange is positive)3040 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 100 Revision 94 29 March 2006 TCG Published 3041 From which we see that TSR1TCV is approximately UTC1-TimeChange/2 with a symmetric3042 possible error of TimeChange/2 + AbsoluteValue(Drift)3043 We can calculate this error as being less than k1*TSRDelta/2 + k2*TSRDelta.3044 3045 EntityA now has the ability to associate UTC1 with TSBTSV and by allow others to know3046 that BlobA was signed at a certain time. First TSBTSN must equal TSR1TSN. This3047 relationship allows EntityA to assert that TSRB occurs during the same session as TSR13048 and TSR2.3049 EntityA calculates HashTimeDelta which is the difference between TSR1TCV and TSRBTCV3050 and the conversion of ticks to seconds. HashTimeDelta includes the same k1 and k2 as3051 calculated above. Stated mathematically:3052 E = k2(TSR1TCV ­ TSRBTCV)3053 HashTimeDelta = k1(TSR1TCV ­ TSRBTCV) + E3054 Now the following relationships hold:3055 (1) UTC1 ­ DeltaTime < TSRBTCV ­ (TSRBTCV ­ TSR1TCV) < UTC13056 (2) UTC1 ­ DeltaTime < TSRBTCV + HashTimeDelta + E < UTC13057 (3) UTC1 ­ HashTimeDelta ­ DeltaTime ­ E < TSRBTCV < UTC1 ­ HashTimeDelta + E3058 (4) TSRBTCV = (UTC1 ­ HashTimeDelta ­ DeltaTime/2) + (E + DeltaTime/2)3059 This has the correct properties3060 As DeltaTime grows so does the error bar (or the uncertainty of the time association)3061 As the difference between the time of the measurement and the time of the time stamp3062 grows, so does the E as a function of E is HashTimeDelta3063 End of informative comment3064 20.4 Additional Comments and Questions3065 Start of informative comment3066 Time Difference3067 If two things are time stamped, say at TCVs and TCVe (for TCV at start, TCV at end) then3068 any entity can calculate the time difference between the two events and will get:3069 TimeDiff = k1*|TCVe ­ TCVs| + k2*|TCVe ­ TCVs|3070 This TimeDiff does not indicate what time the two events occurred at it merely gives the3071 time between the events. This time difference doesn't require a Time Authority.3072 Why is TSN (tick session nonce) required?3073 Without it, there is no way to associate a Time Authority stamp with any TSV, as the TSV3074 resets at the start of every tick session. The TSN proves that the concatenation of TSV and3075 TSN is unique.3076 How does the protocol prevent replay attacks?3077 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 101 TCG Published The TPM signs the TSR sent to the TA. This TSR contains the unique combination of TSV3078 and TSN. Since the TSN is unique to a tick session and the TSV continues to increment any3079 attempt to recreate the same TSR will fail. If the TPM is reset such that the TSV is at the3080 same value, the TSN will be a new value. If the TPM is not reset then the TSV continues to3081 increment and will not repeat.3082 How does EntityA know that the TSR1 that the TA signs is recent?3083 It doesn't. EntityA checks however to ensure that the TSN is the same in all TSR. This3084 ensures that the values are all related. If TSR1 is an old value then the HashTimeDelta will3085 be a large value and the uncertainty of the relation of the signing to the UTC will be large.3086 Why does associating a UTC time with a TSV take two steps?3087 This is because it takes some time between when a request goes to a time authority and3088 when the response comes. The protocol measures this time and uses it to create the time3089 deltas. The relationship of TSV to UTC is somewhere between the request and response.3090 Affect of power on the tick counter3091 As the TPM is not required to maintain an internal clock and battery, how the platform3092 provides power to the TPM affects the ability to maintain the tick counter. The original3093 mechanism had the TPM maintaining an indication of how the platform provided the power.3094 Previous performance does not predict what might occur in the future, as the platform may3095 be unable to continue to provide the power (dead battery, pulled plug from wall etc). With3096 the knowledge that the TPM cannot accurately report the future, the specification deleted3097 tick type from the TPM.3098 The information relative to what the platform is doing to provide power to the TPM is now a3099 responsibility of the TSS. The TSS should first determine how the platform was built, using3100 the platform credential. The TSS should also attempt to determine the actual performance3101 of the TPM in regards to maintaining the tick count. The TSS can help in this determination3102 by keeping track of the tick nonce. The tick nonce changes each time the tick count is lost.3103 By comparing the tick nonce across system events the TSS can obtain a heuristic that3104 represents how the platform provides power to the TPM.3105 The TSS must define a standard set of values as to when the tick nonce continues to3106 increment across system events.3107 The following are some PC implementations that give the flavor of what is possible regarding3108 the clock on a specific platform.3109 TICK_INC - No TPM power battery. Clock comes from PCI clock, may stop from time to time3110 due to clock stopping protocols such as CLKRUN.3111 TICK_POWER - No TPM power battery. Clock source comes from PCI clock, always runs3112 except in S3+.3113 TICK_STSTATE - External power (might be battery) consumed by TPM during S3 only. Clock3114 source comes either from a system clock that runs during S3 or from crystal/internal TPM3115 source.3116 TICK_STCLEAR - Standby power used to drive counter. In desktop, may be related to when3117 system is plugged into wall. Clock source comes either from a system clock that runs when3118 standby power is available or from crystal/internal TPM source.3119 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 102 Revision 94 29 March 2006 TCG Published TICK_ALWAYS - TPM power battery. Clock source comes either from a battery powered3120 system clock that crystal/internal TPM source.3121 End of informative comment3122 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 103 TCG Published 21. Context Management3123 Start of informative comment3124 The TPM is a device that contains limited resources. Caching of the resources may occur3125 without knowledge or assistance from the application that loaded the resource. In version3126 1.1 there were two types of resources that had need of this support keys and authorization3127 sessions. Each type had a separate load and restore operation. In version 1.2 there is the3128 addition of transport sessions. To handle these situations generically 1.2 is defining a single3129 context manager that all types of resources may use.3130 The concept is simple, a resource manager requests that wrapping of a resource in a3131 manner that securely protects the resource and only allows the restoring of the resource on3132 the same TPM and during the same operational cycle.3133 Consider a key successfully loaded on the TPM. The parent keys that loaded the key may3134 have required a different set of PCR registers than are currently set on the TPM. For3135 example, the end result is to have key5 loaded. Key3 is protected by key2, which is3136 protected by key1, which is protected by the SRK. Key1 requires PCR1 to be in a certain3137 state, key2 requires PCR2 to load and key3 requires PCR3. Now at some point in time after3138 key1 loaded key2, PCR1 was extended with additional information. If key3 is evicted then3139 there is no way to reload key3 until the platform is rebooted. To avoid this type of problem3140 the TPM can execute context management routines. The context management routines save3141 key3 in its current state and allow the TPM to restore the state without having to use the3142 parent keys (key1 and key2).3143 There are numerous issues with performing context management on sessions. These issues3144 revolve around the use of the nonces in the session. If an attacker can successfully store,3145 attack, fail and then reload the session the attacker can repeat the attack many times.3146 The key that the TPM uses to encrypt blobs may be a volatile or non-volatile key. One3147 mechanism would be for the TPM to generate a new key on each TPM_Startup command.3148 Another would be for the TPM to generate the key and store it persistently in the3149 TPM_PERMANENT_DATA area.3150 The symmetric key should be relatively the same strength as a 2048-bit RSA key. 128-bit3151 AES or a full three key triple DES would be appropriate.3152 End of informative comment3153 1. Context management is a required function.3154 2. Execution of the context commands MUST NOT cause the exposure of any TPM shielded3155 location.3156 3. The TPM MUST NOT allow the context saving of the EK or the SRK.3157 4. The TPM MAY use either symmetric or asymmetric encryption. For asymmetric3158 encryption the TPM MUST use a 2048 RSA key.3159 5. A wrapped session blob MUST only be loadable once. A wrapped key blob MAY be3160 reloadable.3161 6. The TPM MUST support a minimum of 16 concurrent saved contexts other than keys.3162 There is no minimum or maximum number of concurrent saved key contexts.3163 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 104 Revision 94 29 March 2006 TCG Published 7. All external session blobs (of type TPM_RT_TRANS or TPM_RT_AUTH) can be invalidated3164 upon specific request (via TPM_FlushXXX using TPM_RT_CONTEXT as resource type),3165 this does not include session blobs of type TPM_RT_KEY.3166 8. External session blobs are invalidated on TPM_Startup(ST_CLEAR) or on3167 TPM_Startup(any) based on the startup effects settings3168 a. Session blobs of type TPM_RT_KEY with the attributes of parentPCRStatus = FALSE3169 and IsVolatile = FALSE SHOULD not invalidated on TPM_Startup(any)3170 9. All external session invalidate automatically upon installation of a new owner due to the3171 setting of a new tpmProof.3172 10.If the TPM enters failure mode ALL session blobs (including keys) MUST be invalidated3173 a. Invalidation includes ensuring that contextNonceKey and contextNonceSession will3174 change when the TPM recovers from the failure.3175 11.Attempts to restore a wrapped blob after the successful completion of3176 TPM_Startup(ST_CLEAR) MUST fail. The exception is a wrapped key blob which may be3177 long-term and which MAY restore after a TPM_Startup(ST_CLEAR).3178 12.The save and load context commands are the generic equivalent to the context3179 commands in 1.1. Version 1.2 deprecates the following commands:3180 a. TPM_AuthSaveContext3181 b. TPM_AuthLoadContext3182 c. TPM_KeySaveContext3183 d. TPM_KeyLoadContext3184 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 105 TCG Published 22. Eviction3185 Start of informative comment3186 The TPM has numerous resources held inside of the TPM that may need eviction. The need3187 for eviction occurs when the number or resources in use by the TPM exceed the available3188 space. For resources that are hard to reload (i.e. keys tied to PCR values) the outside entity3189 should first perform a context save before evicting items.3190 In version 1.1 there were separate commands to evict separate resource types. This new3191 command set uses the resource types defined for context saving and creates a generic3192 command that will evict all resource types.3193 End of informative comment3194 1. The TPM MUST NOT flush the EK or SRK using this command.3195 2. Version 1.2 deprecates the following commands:3196 a. TPM_Terminate_Handle3197 b. TPM_EvictKey3198 c. TPM_Reset3199 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 106 Revision 94 29 March 2006 TCG Published 23. Session pool3200 Start of informative comment3201 The TPM supports two types of sessions that use the rolling nonce protocol, authorization3202 and transport. These sessions require much of the same handling and internal storage by3203 the TPM. To allow more flexibility the internal storage for these sessions will be defined as3204 coming from the same pool (or area).3205 The pool requires that three (3) sessions be available. The entities using the TPM can3206 determine the usage models of what sessions are active. This allows a TPM to have 33207 authorization sessions or 3 transport sessions at one time.3208 Using all available pool resources for transport sessions is not a very usable model. If all3209 resources are in use by transport there is no resources available for authorization sessions3210 and hence no ability to execute any commands requiring authorization. A more realistic3211 model would be to have two transport sessions and one authorization session. While this is3212 an unrealistic model for actual execution there will be no requirement that the TPM prevent3213 this from happening. A model of how it could occur would be when there are two3214 applications running, both using 2 transport sessions and one authorization session. When3215 switching between the applications if the requirement was that only 2 transport sessions3216 could be active the TSS that would provide the context switch would have to ensure that the3217 transport sessions were context saved first.3218 Sessions can be virtualized, so while the TPM may only have 3 loaded sessions, there may3219 be an unlimited number of context saved sessions stored outside the TPM.3220 End of informative comment3221 1. The TPM MUST support a minimum of three (3) concurrent sessions. The sessions MAY3222 be any mix of authentication and transport sessions.3223 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 107 TCG Published 24. Initialization Operations3224 Start of informative comment3225 Initialization is the process where the TPM establishes an operating environment from a no3226 power state. Initialization occurs in many different flavors with PCR, keys, handles, sessions3227 and context blobs all initialized, reloaded or unloaded according to the rules and platform3228 environment.3229 Initialization does not affect the operational characteristics of the TPM (like TPM3230 Ownership).3231 Clear is the process of returning the TPM to factory defaults. The clear commands need3232 protection from unauthorized use and must allow for the possibility of changing Owners.3233 The clear process requires authorization to execute and locks to prevent unauthorized3234 operation.3235 The clear functionality performs the following tasks:3236 Invalidate SRK. Invalidating the SRK invalidates all protected storage areas below the SRK3237 in the hierarchy. The areas below are not destroyed they just have no mechanism to be3238 loaded anymore.3239 All TPM volatile and non-volatile data is set to default value except the endorsement key3240 pair. The clear includes the Owner-AuthData, so after performing the clear, the TPM has no3241 Owner. The PCR values are undefined after a clear operation.3242 The TPM shall return TPM_NOSRK until an Owner is set. After the execution of the clear3243 command, the TPM must go through a power cycle to properly set the PCR values.3244 The Owner has ultimate control of when a clear occurs.3245 The Owner can perform the TPM_OwnerClear command using the TPM Owner3246 authorization. If the Owner wishes to disable this clear command and require physical3247 access to perform the clear, the Owner can issue the TPM_DisableOwnerClear command.3248 During the TPM startup processing anyone with physical access to the machine can issue3249 the TPM_ForceClear command. This command performs the clear. The3250 TPM_DisableForceClear disables the TPM_ForceClear command for the duration of the3251 power cycle. TSS startup code that does not issue the TPM_DisableForceClear leaves the3252 TPM vulnerable to a denial of service attack. The assumption is that the TSS startup code3253 will issue the TPM_DisableForceClear on each power cycle after the TSS determines that it3254 will not be necessary to issue the TPM_ForceClear command. The purpose of the3255 TPM_ForceClear command is to recover from the state where the Owner has lost or3256 forgotten the TPM Ownership token.3257 The TPM_ForceClear must only be possible when the issuer has physical access to the3258 platform. The manufacturer of a platform determines the exact definition of physical access.3259 End of informative comment3260 1. The TPM MUST support proper initialization. Initialization MUST properly configure the3261 TPM to execute in the platform environment.3262 2. Initialization MUST ensure that handles, keys, sessions, context blobs and PCR are3263 properly initialized, reloaded or invalidated according to the platform environment.3264 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 108 Revision 94 29 March 2006 TCG Published 3. The description of the platform environment arrives at the TPM in a combination of3265 TPM_Init and TPM_Startup.3266 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 109 TCG Published 25. HMAC digest rules3267 Start of informative comment3268 The order of calculation of the HMAC is critical to being able to validate the authorization3269 and parameters of a command. All commands use the same order and format for the3270 calculation.3271 A more exact representation of a command would be the following3272 *****************************************************************3273 * TAG | LEN | ORD | HANDLES | DATA | AUTH1 (o) | AUTH2 (o) *3274 *****************************************************************3275 The text area for the HMAC calculation would be the concatenation of the following:3276 ORD || DATA3277 End of informative comment3278 The HMAC digest of parameters uses the following order3279 1. Skip tag and length3280 2. Include ordinal. This is the 1S parameter in the HMAC column for each command3281 3. Skip handle(s). This includes key and other session handles3282 4. Include data and other parameters for the command. This starts with the 2S parameter3283 in the HMAC column for each command.3284 5. Skip all AuthData values.3285 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 110 Revision 94 29 March 2006 TCG Published 26. Generic authorization session termination rules3286 Start of informative comment3287 These rules are the generic rules that govern all authorization sessions, a specific session3288 type may have additional rules or modifications of the generic rules3289 End of informative comment3290 1. A TPM SHALL unilaterally perform the actions of TPM_FlushSpecific for a session upon3291 any of the following events3292 a. "continueUse" flag in the authorization session is FALSE3293 b. Shared secret of the session in use to create the exclusive-or for confidentiality of3294 data. Example is TPM_ChangeAuth terminates the authorization session.3295 TPM_ExecuteTransport does not terminate the session due to protections inherent in3296 transport sessions.3297 c. When the associated entity is invalidated3298 d. When the command returns a fatal error. This is due to error returns not setting a3299 nonceEven. Without a new nonceEven the rolling nonces sequence is broken hence3300 the TPM MUST terminate the session.3301 e. Failure of an authorization check at the start of the command3302 f. Execution of TPM_Startup(ST_CLEAR)3303 2. The TPM MAY perform the actions of TPM_FlushSpecific for a session upon the following3304 events3305 a. Execution of TPM_Startup(ST_STATE)3306 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 111 TCG Published 27. PCR Grand Unification Theory3307 Start of informative comment3308 This section discusses the unification of PCR definition and use with locality.3309 The PCR allow the definition of a platform configuration. With the addition of locality, the3310 meaning of a configuration is somewhat larger. This section defines how the two combine to3311 provide the TPM user information relative to the platform configuration.3312 These are the issues regarding PCR and locality at this time3313 Definition of configuration3314 A configuration is the combination of PCR, PCR attributes and the locality.3315 Passing the creators configuration to the user of data3316 For many reasons, from the creator's viewpoint and the user's viewpoint, the configuration3317 in use by the creator is important information. This information needs transmitting to the3318 user with the data and with integrity.3319 The configuration must include the locality and may not be the same configuration that will3320 use the data. This allows one configuration to seal a value for future use and the end user3321 to know the genealogy of where the data comes from.3322 Definition of "Use"3323 See the definition of TPM_PCR_ATTRIBUTES for the attributes and the normative3324 statements regarding the use of the attributes. The use of a configuration is when the TPM3325 needs to ensure that the proper platform configuration is present. The first example is for3326 Unseal, the TPM must only release the information sealed if the platform configuration3327 matches the configuration specified by the seal creator. Here the use of locality is implicit in3328 the PCR attributes, if PCR8 requires locality 2 to be present then the seal creator ensures3329 that locality 2 is asserted by defining a configuration that uses PCR8.3330 The creation of a blob that specifies a configuration for use is not a "use" itself. So the SEAL3331 command does is not a use for specifying the use of a PCR configuration.3332 3333 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 112 Revision 94 29 March 2006 TCG Published 3334 By using the "new style" or TPM_PCR_INFO_LONG structure the user can determine that3335 Blob2 is different that Blob3.3336 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 113 TCG Published 3337 Case B is the only failure and this shows the use of the locality modifier and PCR locality3338 attribute.3339 Additional attempts are obvious failures, config3 and config4 are unable to unseal any of3340 the 4 blobs.3341 One example is illustrative of the problems of just specifying locality without an3342 accompanying PCR. Assume Blob5 which specifies a dar of config1 and a locality 4 modifier.3343 Now either config2 or config4 can unseal Blob5. In fact there is no way to restrict ANY3344 process that gains access to locality 4 from performing the unseal. As many platforms will3345 have no restrictions as to which process can load in locality 4 there is no additional benefit3346 of specifying a locality modifier. If the sealer wants protections, they need to specify a PCR3347 that requires a locality modifier.3348 Defining locality modifiers dynamically3349 This feature would enable the platform to specify how and when a locality modifier applies3350 to a PCR. The current definition of PCR attributes has the values set in TPM manufacturing3351 and static for all TPM in a specific platform type (like a PC).3352 Defining dynamic attributes would make the use of a PCR very difficult. The sealer would3353 have to have some way of ensuring that their wishes were enforced and challengers would3354 have to pay close attention to the current PCR attributes. For these reasons the setting of3355 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 114 Revision 94 29 March 2006 TCG Published the PCR attributes is defined as a static operation made during the platform specific3356 specification.3357 End of informative comment3358 27.1 Validate Key for use3359 Start of informative comment3360 The following shows the order and checks done before the use of a key that has PCR or3361 locality restrictions.3362 Note that there is no check for the PCR registers on the DSAP session. This is due to the3363 fact that DSAP checks for the continued validity of the PCR that are attached to the DSAP3364 and any change causes the invalidation of the DSAP session.3365 The checks must validate the locality of the DSAP session as the PCR registers in use could3366 have locality restrictions.3367 End of informative comment3368 1. If the authorization session is DSAP3369 a. If the DSAP -> localityAtRelease is not 0x1F (or in other words some localities are not3370 allowed)3371 i. Validate that TPM_STANY_FLAGS -> localityModifier is matched by DSAP ->3372 pcrInfo -> localityAtRelease, on mismatch return TPM_BAD_LOCALITY3373 b. If DSAP -> digestAtRelease is not 03374 i. Calculate the current digest and compare to digestAtRelease, return3375 TPM_BAD_PCR on mismatch3376 c. If the DSAP points to an ordinal delegation3377 i. Check that the DSAP authorizes the use of the intended ordinal3378 d. If the DSAP points to a key delegation3379 i. Check that the DSAP authorizes the use of the key3380 e. If the key delegated is a CMK key3381 i. The TPM MUST check the CMK_DELEGATE restrictions3382 2. Set LK to the loaded key that is being used3383 3. If LK -> pcrInfoSize is not 03384 a. If LK -> pcrInfo -> releasePCRSelection identifies the use of one or more PCR3385 i. Calculate H1 a TPM_COMPOSITE_HASH of the PCR selected by LK -> pcrInfo ->3386 releasePCRSelection3387 ii. Compare H1 to LK -> pcrInfo -> digestAtRelease on mismatch return3388 TPM_WRONGPCRVAL3389 b. If localityAtRelease is NOT 0x1F3390 i. Validate that TPM_STANY_FLAGS -> localityModifier is matched by LK -> pcrInfo -3391 > localityAtRelease on mismatch return TPM_BAD_LOCALITY3392 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 115 TCG Published 4. Allow use of the key3393 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 116 Revision 94 29 March 2006 TCG Published 28. Non Volatile Storage3394 Start of informative comment3395 The TPM contains protected non-volatile storage. There are many uses of this type of area;3396 however, a TPM needs to have a defined set of operations that touch any protected area.3397 The idea behind these instructions is to provide an area that the manufacturers and owner3398 can use for storing information in the TPM.3399 The TCG will define a limited set of information that it sees a need of storing in the TPM.3400 The TPM and platform manufacturer may add additional areas.3401 The NV storage area has a limited use before it will no longer operate, hence the NV3402 commands are under TPM Owner control.3403 A defined set of indexes are available when no TPM Owner is present to allow TPM and3404 platform manufacturers the ability to fill in values before a TPM Owner exists.3405 To locate if an index is available, use TPM_GetCapability to return the index and the size of3406 the are in use by the index.3407 The area may not be larger than the TPM input buffer. The TPM will report the maximum3408 size available to allocate.3409 The storage area is an opaque area to the TPM. The TPM, other than providing the storage,3410 does not review the internals of the area.3411 To SEAL a blob the creator of the area specifies the use of PCR registers to read the value.3412 This is the exact property of SEAL.3413 To obtain a signed indication of what is in a NV store area the caller would setup a3414 transport session with logging on and then get the signed log. The log shows the parameters3415 so the caller can validate that the TPM holds the value.3416 There is an attribute, for each index, that defines the expected write scheme for the index.3417 The TPM may handle data storage differently based on the write scheme attribute that3418 defines the expected for the index. Whenever possible the NV memory should be allocated3419 with the write scheme attribute set to update as one block and not as individual bytes.3420 End of informative comment3421 1. The TPM MUST support the NV commands. The TPM MUST support the NV area as3422 defined by the TPM_NV_INDEX values.3423 2. The TPM MAY manage the storage area using any allocation and garbage collection3424 scheme.3425 3. To remove an area from the NV store the TPM owner would use the3426 TPM_NV_DefineSpace command with a size of 0. Any authorized user can change the3427 value written in the NV store.3428 4. The TPM MUST treat the NV area as a shielded location.3429 a. The TPM does not provide any additional protections (like additional encryption) to3430 the NV area.3431 5. If a write operation is interrupted, then the TPM makes no guarantees about the data3432 stored at the specified index. It MAY be the previous value, MAY be the new value or3433 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 117 TCG Published MAY be undefined or unpredictable. After the interruption the TPM MAY indicate that3434 the index contains unpredictable information.3435 a. The TPM MUST ensure that in case of interruption of a write to an index that all3436 other indexes are not affected3437 6. Minimum size of NV area is platform specific. The maximum area is TPM vendor specific.3438 7. A TPM MUST NOT use the NV area to store any data dependent on data structures3439 defined in Part II of the TPM specifications, except for the NV Storage Structures implied3440 by required index values or reserved index values3441 8. A TPM MUST NOT use the NV area to store any data dependent on data structures3442 defined in Part II of the TPM specifications, except for the NV Storage Structures implied3443 by required index values or reserved index values3444 28.1 NV storage design principles3445 Start of informative comment3446 This section lists the design principles that motivate the NV area in the TPM. There was the3447 realization that the current design made use of NV storage but not necessarily efficiently.3448 The DIR, BIT and other commands placed demands on the TPM designer and required3449 areas that while allowing for flexible use reserved space most likely never used (like DIR for3450 locality 1).3451 The following are the design principles that drive the function definitions.3452 1. Provide efficient use of NV area on the TPM. NV storage is a very limited resource and3453 data stored in the NV area should be as small as possible.3454 2. The TPM does not control, edit, validate or manipulate in any manner the information in3455 the NV store. The TPM is merely a storage device. The TPM does enforce the access rules as3456 set by the TPM Owner.3457 3. Allocation of the NV area for a specific use must be under control of the TPM Owner.3458 4. The TPM Owner, when defining the area to use, will set the access and use policy for the3459 area. The TPM Owner can set AuthData values, delegations, PCR values and other controls3460 on the access allowed to the area.3461 5. There must be a capability to allow TPM and platform manufacturers to use this area3462 without a TPM Owner being present. This allows the manufacturer to place information into3463 the TPM without an onerous manufacturing flow. Information in this category would3464 include EK credential and platform credential.3465 6. The management and use of the NV area should not require a large number of ordinals.3466 7. The management and use of the NV area should not introduce new operating strategies3467 into the TPM and should be easy to implement.3468 End of informative comment3469 28.1.1 NV Storage use models3470 Start of informative comment3471 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 118 Revision 94 29 March 2006 TCG Published This informative section describes some of the anticipated use models and the attributes a3472 user of the storage area would need to set.3473 3474 Owner authorized for all access3475 TPM_NV_DefineSpace: attributes = PER_OWERREAD || PER_OWNERWRITE3476 WriteValue(TPM Owner Auth, data)3477 ReadValue(TPM Owner Auth, data)3478 3479 Set AuthData value3480 TPM_NV_DefineSpace: attributes = PER_AUTHREAD || PER_AUTHWRITE, auth =3481 authValue3482 WriteValue( authValue, data)3483 ReadValue( authValue, data)3484 3485 Write once, only way to change is to delete and redefine3486 TPM_NV_DefineSpace: attributes = PER_WRITEDEFINE3487 WriteValue( size = x, data) // successful3488 WriteValue(size = 0) // locks3489 WriteValue(size = x) // fails3490 ...3491 TPM_Startup(ST_Clear) // Does not affect lock3492 WriteValue(size = x, data) // fails3493 3494 Write until specific index is locked, lock reset on Startup(ST_Clear)3495 TPM_NV_DefineSpace: index = 3, attributes = PER_WRITE_STCLEAR3496 TPM_NV_DefineSpace: index = 5, attributes = PER_WRITE_STCLEAR3497 WriteValue( index = 3, size = x, data) // successful3498 WriteValue( index = 5, size = x, data) // successful3499 WriteValue(index = 3, size = 0) // locks3500 WriteValue( index = 3, size = x, data) // fails3501 WriteValue( index = 5, size = x, data) // successful3502 ...3503 TPM_Startup(ST_Clear) // clears lock3504 WriteValue( index = 3, size = x, data) // successful3505 WriteValue( index = 5, size = x, data) // successful3506 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 119 TCG Published 3507 Write until index 0 is locked, lock reset by Startup(ST_Clear)3508 TPM_NV_DefineSpace: attributes = PER_GLOBALLOCK, index = 53509 TPM_NV_DefineSpace: attributes = PER_GLOBALLOCK, index = 33510 WriteValue( index = 3, size = x, data) // successful3511 WriteValue( index = 5, size = x, data) // successful3512 3513 WriteValue(index = 0) // sets SV -> bGlobalLock to TRUE3514 WriteValue( index = 3, size = x, data) // fails3515 WriteValue( index = 5, size = x, data) // fails3516 ...3517 TPM_Startup(ST_Clear) // clears lock3518 WriteValue( index = 3, size = x, data) // successful3519 WriteValue( index = 5, size = x, data) // successful3520 End of informative comment3521 28.2 Use of NV storage during manufacturing3522 Start of informative comment3523 The TPM needs the ability to write values to the NV store during manufacturing. It is3524 possible that the values written at this time would require authorization during normal TPM3525 use. The actual enforcement of these authorizations during manufacturing would cause3526 numerous problems for the manufacturer.3527 The TPM will not enforce the NV authorization restrictions until the execution of a3528 TPM_NV_DefineSpace with the handle of TPM_NV_INDEX_LOCK.3529 End of informative comment3530 1. The TPM MUST NOT enforce the NV authorizations (auth values, PCR etc.) prior to the3531 execution of TPM_NV_DefineSpace with an index of TPM_NV_INDEX_LOCK3532 a. While the TPM is not enforcing NV authorizations, the TPM SHALL allow the use of3533 TPM_NV_DefineSpace in any operational state (disabled, deactivated)3534 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 120 Revision 94 29 March 2006 TCG Published 29. Delegation Model3535 Start of informative comment3536 The TPM Owner is an entity with a single "super user" privilege to control TPM operation.3537 Thus if any aspect of a TPM requires management, the TPM Owner must perform that task3538 himself or reveal his privilege information to another entity. This other entity thereby3539 obtains the privilege to operate all TPM controls, not just those intended by the Owner.3540 Therefore the Owner often must have greater trust in the other entity than is strictly3541 necessary to perform an arbitrary task.3542 This delegation model addresses this issue by allowing delegation of individual TPM Owner3543 privileges (the right to use individual Owner authorized TPM commands) to individual3544 entities, which may be trusted processes.3545 Basic requirements:3546 Consumer user does not need to enter or remember a TPM Owner password. This is an3547 ease of use and security issue. Not remembering the password may lead to bad security3548 practices, increased tech support calls and lost data.3549 Role based administration and separation of duty. It should be possible to delegate just3550 enough Owner privileges to perform some administration task or carry out some duty,3551 without delegating all Owner privileges.3552 TPM should support multiple trusted processes. When a platform has the ability to load3553 and execute multiple trusted processes then the TPM should be able to participate in the3554 protection of secrets and proper management of the processes and their secrets. In fact, the3555 TPM most likely is the root of storage for these values. The TPM should enable the proper3556 management, protection and distribution of values held for the various trusted processes3557 that reside on the same platform.3558 Trusted processes may require restrictions. A fundamental security tenet is the principle3559 of least privilege, that is, to limit process functionality to only the functions necessary to3560 accomplish the task. This delegation model provides a building block that allows a system3561 designer to create single purpose processes and then ensure that the process only has3562 access to the functions that it requires to complete the task.3563 Maintain the current authorization structure and protocols. There is no desire to3564 remove the current TPM Owner and the protocols that authorize and manage the TPM3565 Owner. The capabilities are a delegation of TPM Owner responsibilities. The delegation3566 allows the TPM Owner to delegate some or all of the actions that a TPM Owner can perform.3567 The TPM Owner has complete control as to when and if the capability delegation is in use.3568 End of informative comment3569 29.1 Table Requirements3570 Start of informative comment3571 No ocean front property in table ­ We want the table to be virtually unlimited in size.3572 While we need some storage, we do not want to pick just one number and have that be the3573 min and max. This drives the need for the ability to save, off the TPM, delegation elements.3574 Revoking a delegation, does not affect other delegations ­ The TPM Owner may, at any3575 time, determine that a delegation is no longer appropriate. The TPM Owner needs to be able3576 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 121 TCG Published to ensure the revocation of all delegations in the same family. The TPM Owner also wants to3577 ensure that revocation done in one family does not affect any other family of delegations.3578 Table seeded by OEM ­ The OEM should do the seeding of the table during manufacturing.3579 This allows the OEM to ship the platform and make it easy for the platform owner to3580 startup the first time. The definition of manufacturing in this context includes any time3581 prior to or including the time the user first turns on the platform.3582 Table not tied to a TPM owner ­ The table is not tied to the existence of a TPM owner. This3583 facilitates the seeding of the table by the OEM.3584 External delegations need authorization and assurance of revocation ­ When a3585 delegation is held external to the TPM, the TPM must ensure authorization of the delegation3586 when loading the delegation. Upon revocation of a family or other family changes the TPM3587 must ensure that prior valid delegations are not successfully loaded.3588 90% case, no need for external store ­ The normal case should be that the platform does3589 not need to worry about having external delegations. This drives the need for some NV3590 storage to hold a minimum number of table rows.3591 End of informative comment3592 29.2 How this works3593 Start of informative comment3594 The existing TPM owner authorization model is that certain TPM commands require the3595 authorization of the TPM Owner to operate. The authorization value is the TPM Owners3596 token. Using the token to authorize the command is proof of TPM Ownership. There is only3597 one token and knowledge of this token allows all operations that require proof of TPM3598 Ownership.3599 This extension allows the TPM Owner to create a new AuthData value and to delegate some3600 of the TPM Ownership rights to the new AuthData value.3601 The use model of the delegation is to create an authorization session (DSAP) using the3602 delegated AuthData value instead of the TPM Owner token. This allows delegation to work3603 without change to any current command.3604 The intent is to permit delegation of selected Owner privileges to selected entities, be they3605 local or remote, separate from the current software environment or integrated into the3606 current software environment. Thus Owner privileges may be delegated to entities on other3607 platforms, to entities (trusted processes) that are part of the normal software environment3608 on the Owner's platform, or to a minimalist software environment on the Owner's platform3609 (created by booting from a CDROM, or special disk partition), for example.3610 Privileges may be delegated to a particular entity via definition of a particular process on the3611 Owner's platform (by dictating PCR values), and/or by stipulating a particular AuthData3612 value. The resultant TPM_DELEGATE_OWNER_BLOB and any AuthData value must be3613 passed by the Owner to the chosen entity.3614 Delegation to an external entity (not on the Owner's platform) probably requires an3615 AuthData value and a NULL PCR selection. (But the AuthData value might be sealed to a3616 desired set of PCRs in that remote platform.)3617 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 122 Revision 94 29 March 2006 TCG Published Delegation to a trusted process provided by the local OS requires a PCR that indicates the3618 trusted process. The authorization token should be a fixed value (any well known value),3619 since the OS has no means to safely store the authorization token without sealing that3620 token to the PCR that indicates the trusted process. It is suggested that the value3621 0x111...111 be used.3622 Delegation to a specially booted entity requires either a PCR or an authorization token, and3623 preferably both, to recognize both the process and the fact that the Owner wishes that3624 process to execute.3625 The central delegation data structure is a set of tables. These tables indicate the command3626 ordinals delegated by the TPM Owner to a particular defined environment. The tables allow3627 the distinction of delegations belonging to different environments.3628 The TPM is capable of storing internally a few table elements to enable the passing of the3629 delegation information from an entity that has no access to memory or storage of the3630 defined environment.3631 The number of delegations that the tables can hold is a dynamic number with the3632 possibility of adding or deleting entries at any time. As the total number is dynamic, and3633 possibly large, the TPM provides a mechanism to cache the delegations. The cache of a3634 delegation must include integrity and confidentiality. The term for the encrypted cached3635 entity is blob. The blob contains a counter (verificationCount) validated when the TPM loads3636 the blob.3637 An Owner uses the counter mechanism to prevent the use of undesirable blobs; they3638 increment verificationCount inside the TPM and insert the current value of3639 verificationCount into selected table elements, including temporarily loaded blobs. (This is3640 the reason why a TPM must still load a blob that has an incorrect verificationCount.) An3641 Owner can verify the delegation state of his platform (immediately after updating3642 verificationCount) by keeping copies of the elements that have just been given the current3643 value of verificationCount, signing those copies, and sending them to a third party.3644 Verification probably requires interaction with a third party because acceptable table3645 profiles will change with time and the most important reason for verification is suspicion of3646 the state of a TOS in a platform. Such suspicion implies that the verification check must be3647 done by a trusted security monitor (perhaps separate trusted software on another platform3648 or separate trusted software on CDROM, for example). The signature sent to the third party3649 must include a freshness value, to prevent replay attacks, and the security monitor must3650 verify that a response from the third party includes that freshness value. In situations3651 where the highest confidence is required, the third party could provide the response by an3652 out-of-band mechanism, such as an automated telephone service with spoken confirmation3653 of acceptability of platform state and freshness value.3654 A challenger can verify an entire family using a single transport session with logging, that3655 increments the verification count, updates the verification count in selected blobs, reads the3656 tables and obtains a single transport session signature over all of the blobs in a family.3657 If no Owner is installed, the delegation mechanisms are inoperative and third party3658 verification of the tables is impossible, but tables can still be administered and corrected.3659 (See later for more details.)3660 To perform an operation using the delegation the entity establishes an authorization session3661 and uses the delegated AuthData value for all HMAC calculations. The TPM validates the3662 AuthData value, and in the case of defined environments checks the PCR values. If the3663 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 123 TCG Published validation is successful, the TPM then validates that the delegation allows the intended3664 operation.3665 There can be at least two delegation rows stored in non-volatile storage inside a TPM, and3666 these may be changed using Owner privilege or delegated Owner privilege. Each delegation3667 table row is a member of a family, and there can be at least eight family rows stored in non-3668 volatile storage inside a TPM. An entity belonging to one family can be delegated the3669 privilege to create a new family and edit the rows in its own family, but no other family.3670 In addition to tying together delegations, the family concept and the family table also3671 provides the mechanism for validation and revocation of exported delegate table rows, as3672 well as the mechanism for the platform user to perform validation of all delegations in a3673 family.3674 End of informative comment3675 29.3 Family Table3676 Start of informative comment3677 The family table has three main purposes.3678 1 - To provide for the grouping of rows in the TPM_DELEGATE_TABLE; entities identified in3679 delegate table rows as belonging to the same family can edit information in the other3680 delegate table rows with the same family ID. This allows a family to manage itself and3681 provides an easier mechanism during upgrades.3682 2 - To provide the validation and revocation mechanism for exported3683 TPM_DELEGATE_ROWS and those stored on the TPM in the delegation table3684 3 - To provide the ability to perform validation of all delegations in a family3685 The family table must have eight rows, and may have more. The maximum number of rows3686 is TPM vendor-defined and is available using the TPM_GetCapability command.3687 As the family table has a limited number of rows, there is the possibility that this number3688 could be insufficient. However, the ability to create a virtual amount of rows, like done for3689 the TPM_DELEGATE_TABLE would create the need to have all of the validation and3690 revocation mechanisms that the family table provides for the delegate table. This could3691 become a recursive process, so for this version of the specification, the recursion stops at3692 the family table.3693 The family table contains four pieces of information: the family ID, the family label, the3694 family verification count, and the family flags.3695 The family ID is a 32-bit value that provides a sequence number of the families in use.3696 The family label is a one-byte field that family table manager software would use to help3697 identify the information associated with the family. Software must be able to map the3698 numeric value associated with each family to the ASCII-string family name displayable in3699 the user interface.3700 The family verification count is a 32-bit sequence number that identifies the last outside3701 verification and attestation of the family information.3702 Initialization of the family table occurs by using the TPM_Delegate_Manage command with3703 the TPM_FAMILY_CREATE option.3704 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 124 Revision 94 29 March 2006 TCG Published The verificationCount parameter enables a TPM to check that all rows of a family in the3705 delegate table are approved (by an external verification process), even if rows have been3706 stored off-TPM.3707 The family flags allow the use and administration of the family table row, and its associated3708 delegate table rows.3709 Row contents3710 Family ID ­ 32-bits3711 Row label ­ One byte3712 Family verification count ­ 32-bits3713 Family enable/disable use/admin flags ­ 32-bits3714 End of informative comment3715 29.4 Delegate Table3716 Start of informative comment3717 The delegate table has three main purposes, from the point of view of the TPM. This table3718 holds:3719 The list of ordinals allowable for use by the delegate3720 The identity of a process that can use the ordinal list3721 The AuthData value to use the ordinal list3722 The delegate table has a minimum of two (2) rows; the maximum number of rows is TPM3723 vendor-defined and is available using the TPM_GetCapability command. Each row3724 represents a delegation and, optionally, an assignment of that delegation to an identified3725 trusted process.3726 The non-volatile delegate rows permit an entity to pass delegation rows to a software3727 environment without regard to shared memory between the entity and the software3728 environment. The size of the delegate table does not restrict the number of delegations3729 because TPM_Delegate_CreateOwnerDelegation can create blobs for use in a DSAP session,3730 bypassing the delegate table.3731 The TPM Owner controls the tables that control the delegations, but (recursively) the TPM3732 Owner can delegate the management of the tables to delegated entities. Entities belonging3733 to a particular group (family) of delegation processes may edit delegate table entries that3734 belong to that family.3735 After creation of a delegation entry there is no restriction on the use of the delegation in a3736 properly authorized session. The TPM Owner has properly authorized the creation of the3737 delegation so the use of the delegation occurs whenever the delegate wishes to use it.3738 The rows of the delegate table held in non-volatile storage are only changeable under TPM3739 Owner authorization.3740 The delegate table contains six pieces of information: PCR information, the AuthData value3741 for the delegated capabilities, the delegation label, the family ID, the verification count, and3742 a profile of the capabilities that are delegated to the trusted process identified by the PCR3743 information.3744 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 125 TCG Published Row Elements3745 ASCII label ­ Label that provides information regarding the row. This is not a sensitive item.3746 Family ID ­ The family that the delegation belongs to; this is not a sensitive item.3747 Verification count ­ Specifies the version, or generation, of this row; version validity3748 information is in the family table. This is not a sensitive value.3749 Delegated capabilities ­ The capabilities granted, by the TPM Owner, to the identified3750 process. This is not a sensitive item.3751 Authorization and Identity3752 The creator of the delegation sets the AuthData value and the PCR selection. The creator is3753 responsible for the protection and dissemination of the AuthData value. This is a sensitive3754 value.3755 End of informative comment3756 1. The TPM_DELEGATE_TABLE MUST have at least two (2) rows; the maximum number of3757 table rows is TPM-vendor defined and MUST be reported in response to a3758 TPM_GetCapability command3759 2. The AuthData value and the PCR selection must be set by the creator of the delegation3760 29.5 Delegation Administration Control3761 Start of informative comment3762 The delegate tables (both family and delegation) present some control problems. The tables3763 must be initialized by the platform OEM, administered and controlled by the TPM Owner,3764 and reset on changes of TPM Ownership. To provide this level of control there are three3765 phases of administration with different functions available in the phases.3766 The three phases of table administration are; manufacturing (P1), no-owner (P2) and owner3767 present (P3). These three phases allow different types of administration of the delegation3768 tables.3769 Manufacturing (P1)3770 A more accurate definition of this phase is open, un-initialized and un-owned. It occurs3771 after TPM manufacturing and as a result of TPM_OwnerClear or TPM_ForceClear.3772 In P1 TPM_Delegate_Manage can initialize and manage non-volatile family rows in the TPM.3773 TPM_Delegate_LoadOwnerDelegation can load non-volatile delegation rows in the TPM.3774 Attacks that attempt to burnout the TPM's NV storage are frustrated by the NV store's own3775 limits on the number of writes when no Owner is installed.3776 No-Owner (P2)3777 This phase occurs after the platform has been properly setup. The setup can occur in the3778 platform manufacturing flow, during the first boot of the platform or at any time when the3779 platform owner wants to lock the table settings down. There is no TPM Owner at this time.3780 TPM_Delegate_Manage locks both the family and delegation rows. This lock can be opened3781 only by the Owner (after the Owner has been installed, obviously) or by the act of removing3782 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 126 Revision 94 29 March 2006 TCG Published the Owner (even if no Owner is installed). Thus locked tables can be unlocked by asserting3783 Physical Presence and executing TPM_ForceClear, without having to install an Owner.3784 In P2, the relevant TPM_Delegate_xxx commands all return the error3785 TPM_DELEGATE_LOCKED. This is not an issue as there is no TPM Owner to delegate3786 commands, so the inability to change the tables or create delegations does not affect the3787 use of the TPM.3788 Owned (P3)3789 In this phase, the TPM has a TPM Owner and the TPM Owner manages the table as the3790 Owner sees fit. This phase continues until the removal of the TPM Owner.3791 Moving from P2 to P3 is automatic upon establishment of a TPM Owner. Removal of the3792 TPM Owner automatically moves back to P1.3793 The TPM Owner always has the ability to administer any table. The TPM Owner may3794 delegate the ability to manipulate a single family or all families. Such delegations are3795 operative only if delegations are enabled.3796 End of informative comment3797 1. When DelegateAdminLock is TRUE the TPM MUST disallow any changes to the delegate3798 tables3799 2. With a TPM Owner installed, the TPM Owner MUST authorize all delegate table changes3800 29.5.1 Control in Phase 13801 Start of informative comment3802 The TPM starts life in P1. The TPM has no owner and the tables are empty. It is desirable3803 for the OEM to initialize the tables to allow delegation to start immediately after the Owner3804 decides to enable delegation. As the setup may require changes and validation, a simple3805 mechanism of writing to the area once is not a valid option.3806 TPM_Delegate_Manage and TPM_Delegate_LoadOwnerDelegation allow the OEM to fill the3807 table, read the public parts of the table, perform reboots, reset the table and when finally3808 satisfied as to the state of the platform, lock the table.3809 Alternatively, the OEM can leave the tables NULL and turn off table administration leaving3810 the TPM in an unloaded state waiting for the eventual TPM Owner to fill the tables, as they3811 need.3812 Flow to load tables3813 Default values of DelegateAdminLock are set either during manufacturing or are the result3814 of TPM_OwnerClear or TPM_ForceClear.3815 TPM_Delegate_Manage verifies that DelegateAdminLock is FALSE and that there is no TPM3816 Owner. The command will therefore load or manipulate the family tables as specified in the3817 command.3818 TPM_Delegate_LoadOwnerDelegation verifies that DelegateAdminLock is FALSE and no TPM3819 owner is present. The command loads the delegate information specified in the command.3820 End of informative comment3821 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 127 TCG Published 29.5.2 Control in Phase 23822 Start of informative comment3823 In phase 2, no changes are possible to the delegate tables. The platform owner must install3824 a TPM Owner and then manage the tables, or use TPM_ForceClear to revert to phase 1.3825 End of informative comment3826 29.5.3 Control in Phase 33827 Start of informative comment3828 The TPM_DELEGATE_TABLE requires commands that manage the table. These commands3829 include filling the table, turning use of the table on or off, turning administration of the3830 table on or off, and using the table.3831 The commands are:3832 TPM_Delegate_Manage ­ Manages the family table on a row-by-row basis: creates a new3833 family, enables/disables use of a family table row and delegate table rows that share the3834 same family ID, enables/disables administration of a family's rows in both the family table3835 and the delegate table, and invalidates an existing family.3836 TPM_Delegate_CreateOwnerDelegation increments the family verification count (if3837 desired) and delegates the Owner's privilege to use a set of command ordinals, by creating a3838 blob. Such blobs can be used as input data for TPM_DSAP or3839 TPM_Delegate_LoadOwnerDelegation. Incrementing the verification count and creating a3840 delegation must be an atomic operation. Otherwise no delegations are operative after3841 incrementing the verification count.3842 TPM_Delegate_LoadOwnerDelegation loads a delegate blob into a non-volatile delegate3843 table row, inside the TPM.3844 TPM_Delegate_ReadTable is used to read from the TPM the public contents of the family3845 and delegate tables that are stored on the TPM.3846 TPM_Delegate_UpdateVerification sets the verificationCount in an entity (a blob or a3847 delegation row) to the current family value, in order that the delegations represented by that3848 entity will continue to be accepted by the TPM.3849 TPM_Delegate_VerifyDelegation loads a delegate blob into the TPM, and returns success3850 or failure, depending on whether the blob is currently valid.3851 TPM_DSAP ­ opens a deferred authorization session, using either an input blob (created by3852 TPM_Delegate_CreateOwnerDelegation) or a cached blob (loaded by3853 TPM_Delegate_LoadOwnerDelegation into one of the TPM's non-volatile delegation rows).3854 End of informative comment3855 29.6 Family Verification3856 Start of informative comment3857 The platform user may wish to have confirmation that the delegations in use provide a3858 coherent set of delegations. This process would require some evaluation of the processes3859 granted delegations. To assist in this confirmation the TPM provides a mechanism to group3860 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 128 Revision 94 29 March 2006 TCG Published all delegations of a family into a signed blob. The signed blob allows the verification agent to3861 look at the delegations, the processes involved and make an assessment as the validity of3862 the delegations. The third party then sends back to the platform owner the results of the3863 assessment.3864 To perform the creation of the signed blob the platform owner needs the ability to group all3865 of the delegations of a single family into a transport session. The platform owner also wants3866 an assurance that no management of the table is possible during the verification.3867 This verification does not prove to a third party that the platform owner is not cheating.3868 There is nothing to prevent the platform owner from performing the validation and then3869 adding an additional delegation to the family.3870 Here is one example protocol that retrieves the information necessary to validate the rows3871 belonging to a particular family. Note that the local method of executing the protocol must3872 prevent a man-in-the-middle attack using the nonce supplied by the user.3873 The TPM Owner can increment the family verification count or use the current family3874 verification count. Using the current family verification count carries the risk that3875 unexamined delegation blobs permit undesirable delegations. Using an incremented3876 verification count eliminates that risk. The entity gathering the verification data requires3877 Owner authorization or access to a delegation that grants access to transport session3878 commands, plus other commands depending on whether verificationCount is to be3879 incremented. This delegation could be a trusted process that can use the delegations3880 because of its PCR measurements, a remote entity that can use the delegations because the3881 Owner has sent it a TPM_DELEGATE_OWNER_BLOB and AuthData value, or the host3882 platform booted from a CDROM that can use the delegations because of its PCR3883 measurements, and TPM_DELEGATE_OWNER_BLOB and AuthData value submitted by the3884 Owner, for example.3885 Verification using the current verificationCount3886 The gathering entity requires access to a delegation that grants access to at least the3887 ordinals to perform a transport session, plus TPM_Delegate_ReadTable and3888 TPM_Delegate_VerifyDelegation.3889 The TPM Owner creates a transport session with the "no other activity" attribute set. This3890 ensures notification if other operations occur on the TPM during the validation process. (If3891 other operations do occur, the validation processes may have been subverted.) All3892 subsequent commands listed are performed using the transport session.3893 TPM_Delegate_ReadTable displays all public values (including the permissions and PCR3894 values) in the TPM.3895 TPM_Delegate_VerifyDelegation loads each cached blob, with all public values (including the3896 permissions and PCR values) in plain text.3897 After verifying all blobs, TPM_ReleaseTransportSigned signs the list of transactions.3898 The gathering entity sends the log of the transport session plus any supporting information3899 to the validation entity, which evaluates the signed transport session log and informs the3900 platform owner of the result of the evaluation. This could be an out-of-band process.3901 Verification using an incremented verificationCount3902 The gathering entity requires Owner authorization or access to a delegation that grants3903 access to at least the ordinals to perform a transport session, plus3904 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 129 TCG Published TPM_Delegate_CreateOwnerDelegation, TPM_Delegate_ReadTable, and3905 TPM_Delegate_UpdateVerification.3906 The TPM Owner creates a transport session with the "no other activity" attribute set.3907 To increment the count the TPM Owner (or a delegate) must use3908 TPM_Delegate_CreateOwnerDelegation with increment == TRUE. That blob permits creation3909 of new delegations or approval of existing tables and blobs. That delegation must set the3910 PCRs of the desired (local) process and the desired AuthData value of the process. As noted3911 previously, AuthData values should be a fixed value if the gathering entity is a trusted3912 process that is part of the normal software environment.3913 If new delegations are to be created, TPM_Delegate_CreateOwnerDelegation must be used3914 with increment == FALSE.3915 If existing blobs and delegation rows are to be reapproved,3916 TPM_Delegate_UpdateVerification must be used to install the new value of verificationCount3917 into those existing blobs and non-volatile rows. This exposes the blobs' public information3918 (including the permissions and PCR values) in plain text to the transport session.3919 TPM_Delegate_ReadTable then exposes all public values (including the permissions and3920 PCR values) of tables to the transport session.3921 Again, after verifying all blobs, TPM_ReleaseTransportSigned signs the list of transactions.3922 End of informative comment3923 29.7 Use of commands for different states of TPM3924 Start of informative comment3925 Use the ordinal table to determine when the various commands are available for use3926 End of informative comment3927 29.8 Delegation Authorization Values3928 Start of informative comment3929 This section describes why, when a PCR selection is set, the AuthData value may be a fixed3930 value, and, when the PCR selection is null, the delegation creator must select an AuthData3931 value.3932 A PCR value is an indication of a particular (software) environment in the local platform.3933 Either that PCR value indicates a trusted process or not. If the trusted process is to execute3934 automatically, there is no point in allocating a meaningful AuthData value. (The only way3935 the trusted process could store the AuthData value is to seal it to the process's PCR values,3936 but the delegation mechanism is already checking the process's PCR values.) If execution of3937 the trusted process is dependent upon the wishes of another entity (such as the Owner), the3938 AuthData value should be a meaningful (private) value known only to the TPM, the Owner,3939 and that other entity. Otherwise the AuthData value should be a fixed, well known, value.3940 If the delegation is to be controlled from a remote platform, these simple delegation3941 mechanisms provide no means for the platform to verify the PCRs of that remote platform,3942 and hence access to the delegation must be based solely upon knowledge of the AuthData3943 value.3944 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 130 Revision 94 29 March 2006 TCG Published End of informative comment3945 29.8.1 Using the authorization value3946 Start of informative comment3947 To use a delegation the TPM will enforce any PCR selection on use. The use definition is any3948 command that uses the delegation authorization value to take the place of the TPM Owner3949 authorization.3950 PCR Selection defined3951 In this case, the delegation has a PCR selection structure defined. Each time the TPM uses3952 the delegation authorization value instead of the TPM Owner value the TPM would validate3953 that the current PCR settings match the settings held in the delegation structure. The PCR3954 selection includes the definition of localities and checks of locality occur with the checking3955 of the PCR values. The TPM enforces use of the correct authorization value, which may or3956 may not be a meaningful (private) value.3957 PCR selection NULL3958 In this case, the delegation has no PCR selection structure defined. The TPM does not3959 enforce any particular environment before using the authorization value. Mere knowledge of3960 the value is sufficient.3961 End of informative comment3962 29.9 DSAP description3963 Start of informative comment3964 The DSAP opens a deferred auth session, using either a TPM_DELEGATE_BLOB as input3965 parameter or a reference to the TPM_DELEGATE_TABLE_ROW, stored inside the TPM. The3966 DSAP command creates an ephemeral secret to authenticate a session. The purpose of this3967 section is to illustrate the delegation of user keys or TPM Owner authorization by creating3968 and using a DSAP session without regard to a specific command.3969 A key defined for a certain usage (e.g. TPM_KEY_IDENTITY) can be applied to different3970 functions within the use model (e.g. TPM_Quote or TPM_CertifiyKey). If an entity knows the3971 AuthData for the key (key.usageAuth) it can perform all the functions, allowed for that use3972 model of that particular key. This entity is also defined as delegation creation entity, since it3973 can initiate the delegation process. Assume that a restricted usage entity should only be3974 allowed to execute a subset or a single functions denoted as TPM_Example, within the3975 specific use model of a key. (e.g. Allow the usage of a TPM_IDENTITY_KEY only for3976 Certifying Keys, but no other function). This use model points to the selection of the DSAP3977 as the authorization protocol to execute the TPM_Example command.3978 To perform this scenario the delegation creation entity must know the AuthData for the key3979 (key.usageAuth). It then has to initiate the delegation by creating a3980 TPM_DELEGATE_KEY_BLOB via the TPM_Delegate_CreateKeyDelegation command. As a3981 next step the delegation creation entity has to pass the TPM_DELEGATE_KEY_BLOB and3982 the delegation AuthData (TPM_DELEGATE_SENSITIVE.authValue) to the restricted usage3983 entity. The specification offers the TPM_DelTable_ReadAuth mechanism to perform this3984 function. Other mechanisms may be used.3985 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 131 TCG Published The restricted usage entity can now start an TPM_DSAP session by using the3986 TPM_DELEGATE_KEY_BLOB as input.3987 For the TPM_Example command, the inAuth parameter provides the authorization to3988 execute the command. The following table shows the commands executed, the parameters3989 createdand the wire formats of all of the information.3990 is the result of the following calculation: SHA1(ordinal, inArgOne,3991 inArgTwo). is the result of the following calculation: SHA1(returnCode,3992 ordinal, outArgOne). inAuthSetupParams refers to the following parameters, in this order:3993 authLastNonceEven, nonceOdd, continueAuthSession. OutAuthSetupParams refers to the3994 following parameters, in this order: nonceEven, nonceOdd, continueAuthSession3995 In addition to the two even nonces generated by the TPM (authLastNonceEven and3996 nonceEven) that are used for TPM_OIAP, there is a third, labeled nonceEvenOSAP that is3997 used to generate the shared secret. For every even nonce, there is also an odd nonce3998 generated by the system.3999 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 132 Revision 94 29 March 2006 TCG Published 4000 Caller On the wire Dir TPM Send TPM_DSAP TPM_DSAP keyHandle nonceOddOSAP entityType entityValue Decrypt sensitiveArea of entityValue If entityValue==TPM_ET_DEL_BLOB verify the integrity of the blob, and if a TPM_DELEGATE_KEY_BLOB is input verify that KeyHandle and entityValue match Create session & authHangle Generate authLastNonceEven Save authLastNonceEven with authHandle Generate nonceEvenOSAP Generate sharedSecret = HMAC(sensitiveArea.authValue., nonceEvenOSAP, nonceOddOSAP) Save keyHandle, sharedSecret with authHandle and permissions Save authHandle, authLastNonceEven Generate sharedSecret = HMAC(sensitiveArea.authValue, nonceEvenOSAP, nonceOddOSAP) Save sharedSecret authHandle, authLastNonceEven nonceEvenOSAP ß Returns Generate nonceOdd & save with authHandle. Compute inAuth = HMAC (sharedSecret, inParamDigest, inAuthSetupParams) Send TPM_Example tag paramSize ordinal inArgOne inArgTwo authHandle nonceOdd continueAuthSession inAuth Verify authHandle points to a valid session, mismatch returns TPM_AUTHFAIL Retrieve authLastNonceEven from internal session storage HM = HMAC (sharedSecret, inParamDigest, inAuthSetupParams) Compare HM to inAuth. If they do not compare return with TPM_AUTHFAIL Check if command ordinal of TPM_Example is allowed in permissions. If not return TPM_DISABLED_CMD Execute TPM_Example and create returnCode Generate nonceEven to replace authLastNonceEven in session Set resAuth = HMAC(sharedSecret, outParamDigest, outAuthSetupParams) Save nonceEven HM = HMAC( sharedSecret, outParamDiges t, outAuthSetupParams) Compare HM to resAuth. This verifies returnCode and output parameters. tag paramSize returnCode outArgOne nonceEven continueAuthSession resAuth ß Return output parameters If continueAuthSession is FALSE then destroy session 4001 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 133 TCG Published 4002 Suppose now that the TPM user wishes to send another command using the same session4003 to operate on the same key. For the purposes of this example, we will assume that the same4004 ordinal is to be used (TPM_Example). To re-use the previous session, the4005 continueAuthSession output boolean must be TRUE.4006 The following table shows the command execution, the parameters created and the wire4007 formats of all of the information.4008 In this case, authLastNonceEven is the nonceEven value returned by the TPM with the4009 output parameters from the first execution of TPM_Example.4010 Caller On the wire Dir TPM Generate nonceOdd Compute inAuth = HMAC (sharedSecret, inParamDigest, inAuthSetupParams) Save nonceOdd with authHandle Send TPM_Example tag paramSize ordinal inArgOne inArgTwo nonceOdd continueAuthSession inAuth Retrieve authLastNonceEven from internal session storage HM = HMAC (sharedSecret, inParamDigest, inAuthSetupParams) Compare HM to inAuth. If they do not compare return with TPM_AUTHFAIL Execute TPM_Example and create returnCode Generate nonceEven to replace authLastNonceEven in session Set resAuth = HMAC(sharedSecret, outParamDigest, outAuthSetupParams) Save nonceEven HM = HMAC( sharedSecret, outParamDigest, outAuthSetupParams) Compare HM to resAuth. This verifies returnCode and output parameters. tag paramSize returnCode outArgOne nonceEven continueAuthSession resAuth ß Return output parameters If continueAuthSession is FALSE then destroy session 4011 The TPM user could then use the session for further authorization sessions or terminate it4012 in the ways that have been described above in TPM_OIAP. Note that termination of the4013 DSAP session causes the TPM to destroy the shared secret.4014 End of informative comment4015 1. The DSAP session MUST enforce any PCR selection on use. The use definition is any4016 command that uses the delegation authorization value to take the place of the TPM4017 Owner authorization.4018 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 134 Revision 94 29 March 2006 TCG Published 30. Physical Presence4019 Start of informative comment4020 Physical presence is a signal from the platform to the TPM that indicates the operator4021 manipulated the hardware of the platform. Manipulation would include depressing a4022 switch, setting a jumper, depressing a key on the keyboard or some other such action.4023 TCG does not specify an implementation technique. The guideline is the physical presence4024 technique should make it difficult or impossible for rogue software to assert the physical4025 presence signal.4026 A PC-specific physical presence mechanism might be an electrical connection from a switch,4027 or a program that loads during power on self-test.4028 End of informative comment4029 The TPM MUST support a signal from the platform for the assertion of physical presence. A4030 TCG platform specific specification MAY specify what mechanisms assert the physical4031 presence signal.4032 The platform manufacturer MUST provide for the physical presence assertion by some4033 physical mechanism.4034 30.1 Use of Physical Presence4035 Start of informative comment4036 For control purposes there are numerous commands on the TPM that require TPM Owner4037 authorization. Included in this group of commands are those that turn the TPM on or off4038 and those that define the operating modes of the TPM. The TPM Owner always has complete4039 control of the TPM. What happens in two conditions: there is no TPM Owner or the TPM4040 Owner forgets the TPM Owner AuthData value. Physical presence allows for an4041 authorization to change the state in these two conditions.4042 No TPM Owner4043 This state occurs when the TPM ships from manufacturing (it can occur at other times4044 also). There is no TPM Owner. It is imperative to protect the TPM from remote software4045 processes that would attempt to gain control of the TPM. To indicate to the TPM that the4046 TPM operating state can change (allow for the creation of the TPM Owner) the human4047 asserts physical presence. The physical presence assertion than indicates to the TPM that4048 changing the operating state of the TPM is authorized.4049 Lost TPM Owner authorization4050 In the case of lost, or forgotten, authorization there is a TPM Owner but no way to manage4051 the TPM. If the TPM will only operate with the TPM Owner authorization then the TPM is no4052 longer controllable. Here the operator of the machine asserts physical presence and4053 removes the current TPM Owner. The assumption is that the operator will then immediately4054 take ownership of the TPM and insert a new TPM Owner AuthData value.4055 Operator disabling4056 Another use of physical presence is to indicate that the operator wants to disable the use of4057 the TPM. This allows the operator to temporarily turn off the TPM but not change the4058 permanent operating mode of the TPM as set by the TPM Owner.4059 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 135 TCG Published End of informative comment4060 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 136 Revision 94 29 March 2006 TCG Published 31. TPM Internal Asymmetric Encryption4061 Start of Informative comment4062 For asymmetric encryption schemes, the TPM is not required to perform the blocking of4063 information where that information cannot be encrypted in a single cryptographic4064 operation. The schemes TPM_ES_RSAESOAEP_SHA1_MGF1 and TPM_ES_RSAESPKCSV154065 allow only single block encryption. When using these schemes, the caller to the TPM must4066 perform any blocking and unblocking outside the TPM. It is the responsibility of the caller4067 to ensure that multiple blocks are properly protected using a chaining mechanism.4068 Note that there are inherent dangers associated with splitting information so that it can be4069 encrypted in multiple blocks with an asymmetric key, and then chaining together these4070 blocks together. For example, if an integrity check mechanism is not used, an attacker can4071 encrypt his own data using the public key, and substitute this rogue block for one of the4072 original blocks in the message, thus forcing the TPM to replace part of the message upon4073 decryption.4074 There is also a more subtle attack to discover the data encrypted in low-entropy blocks. The4075 attacker makes a guess at the plaintext data, encrypts it, and substitutes the encrypted4076 guess for the original block. When the TPM decrypts the complete message, a successful4077 decryption will indicate that his guess was correct.4078 There are a number of solutions which could be considered for this problem ­ One such4079 solution for TPMs supporting symmetric encryption is specified in PKCS#7, section 10, and4080 involves using the public key to encrypt a symmetric key, then using that symmetric key to4081 encrypt the long message.4082 For TPMs without symmetric encryption capabilities, an alternative solution may be to add4083 random padding to each message block, thus increasing the block's entropy.4084 End of informative comment4085 1. For a TPM_UNBIND command where the parent key has pubKey.algorithmId equal to4086 TPM_ALG_RSA and pubKey.encScheme set to TPM_ES_RSAESPKCSv15 the TPM SHALL4087 NOT expect a PAYLOAD_TYPE structure to prepend the decrypted data.4088 2. The TPM MUST perform the encryption or decryption in accordance with the4089 specification of the encryption scheme, as described below.4090 3. When a null terminated string is included in a calculation, the terminating null SHALL4091 NOT be included in the calculation.4092 31.1.1 TPM_ES_RSAESOAEP_SHA1_MGF14093 1. The encryption and decryption MUST be performed using the scheme RSA_ES_OAEP4094 defined in [PKCS #1v2.0: 7.1] using SHA1 as the hash algorithm for the encoding4095 operation.4096 2. Encryption4097 a. The OAEP encoding P parameter MUST be the 4 character string "TCPA".4098 b. While the TCG now controls this specification the string value will NOT change to4099 allow for interoperability and backward compatibility with TCPA 1.1 TPM's4100 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 137 TCG Published c. If there is an error with the encryption, the TPM must return the error4101 TPM_ENCRYPT_ERROR.4102 3. Decryption4103 a. The OAEP decoding P parameter MUST be the 4 character string "TCPA".4104 b. While the TCG now controls this specification the string value will NOT change to4105 allow for interoperability and backward compatibility with TCPA 1.1 TPM's4106 c. If there is an error with the decryption, the TPM must return the error4107 TPM_DECRYPT_ERROR.4108 31.1.2 TPM_ES_RSAESPKCSV154109 1. The encryption MUST be performed using the scheme RSA_ES_PKCSV15 defined in4110 [PKCS #1v2.0: 7.2].4111 2. Encryption4112 a. If there is an error with the encryption, return the error TPM_ENCRYPT_ERROR.4113 3. Decryption4114 a. If there is an error with the decryption, return the error TPM_DECRYPT_ERROR.4115 31.1.3 TPM_ES_SYM_CNT4116 Start of informative comment4117 This defines an encryption mode in use with symmetric algorithms. The actual definition is4118 at4119 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf4120 The underlying symmetric algorithm may be AES128, AES192, AES256 or 3DES. The4121 definition for these algorithms is in the NIST document Appendix E.4122 End of informative comment4123 1. Given a current counter value, the next counter value is obtained by treating the lower4124 32 bits of the current counter value as an unsigned 32-bit integer x, then replacing the4125 lower 32 bits of the current counter value with the bits of the incremented integer (x + 1)4126 mod 2^32. This method is described in Appendix B.1 of the NIST document4127 (b=32).30.1.3 TPM_ES_SYM_CNT4128 31.1.4 TPM_ES_SYM_OFB4129 Start of informative comment4130 This defines an encryption mode in use with symmetric algorithms. The actual definition is4131 at4132 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf4133 The underlying symmetric algorithm may be AES128, AES192, AES256 or 3DES. The4134 definition for these algorithms is in the NIST document Appendix E.4135 End of informative comment4136 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 138 Revision 94 29 March 2006 TCG Published 31.2 TPM Internal Digital Signatures4137 Start of informative comment4138 These values indicate the approved schemes in use by the TPM to generate digital4139 signatures.4140 End of informative comment4141 4142 The TPM MUST perform the signature or verification in accordance with the specification of4143 the signature scheme, as described below.4144 31.2.1 TPM_SS_RSASSAPKCS1v15_SHA14145 1. The signature MUST be performed using the scheme RSASSA-PKCS1-v1.5 defined in4146 [PKCS #1v2.0: 8.1] using SHA1 as the hash algorithm for the encoding operation.4147 31.2.2 TPM_SS_RSASSAPKCS1v15_DER4148 Start of informative comment4149 This signature scheme is designed to permit inclusion of DER coded information before4150 signing, which is inappropriate for most TPM capabilities4151 End of informative comment4152 1. The signature MUST be performed using the scheme RSASSA-PKCS1-v1.5 defined in4153 [PKCS #1v2.0: 8.1]. The caller must properly format the area to sign using the DER4154 rules. The provided area maximum size is k-11 octets.4155 2. TPM_Sign SHALL be the only TPM capability that is permitted to use this signature4156 scheme. If a capability other than TPM_Sign is requested to use this signature scheme,4157 it SHALL fail with the error code TPM_INAPPROPRIATE_SIG4158 31.2.3 TPM_SS_RSASSAPKCS1v15_INFO4159 Start of informative comment4160 This signature scheme is designed to permit signatures on arbitrary information but also4161 protect the signature mechanism from being misused.4162 End of informative comment4163 1. The scheme MUST work just as TPM_SS_RSASSAPKCS1V15_SHA1 except in the4164 TPM_Sign command4165 a. In the TPM_Sign command the scheme MUST use a properly constructed4166 TPM_SIGN_INFO structure, and hash it before signing4167 31.2.4 Use of Signature Schemes4168 Start of informative comment4169 The PKCS1v15_INFO scheme is a new addition for 1.2. It causes a new functioning for 1.14170 and 1.2 keys. The following details the use of the new scheme and how the TPM handles4171 signatures and hashing4172 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 139 TCG Published End of informative comment4173 1. For the commands (TPM_GetAuditDigestSigned, TPM_TickStampBlob,4174 TPM_ReleaseTransportSigned):4175 a. The TPM MUST create a TPM_SIGN_INFO and sign it using the key specified and4176 TPM_SS_RSASSAPKCS1v15_SHA14177 2. For the commands (TPM_IdentityKey, TPM_Quote and TPM_CertifyKey):4178 a. Create the structure as defined by the command and sign using4179 TPM_SS_RSASSAPKCS1v15_SHA1 for either SHA1 or SIGN_INFO4180 3. For TPM_Sign:4181 a. Create the structure as defined by the command and key scheme4182 b. If key->sigScheme is SHA1 sign the 20 byte parameter4183 c. If key->sigScheme is DER, sign the DER value using4184 TPM_SS_RSASSAPKCS1v15_DER4185 d. If key->sigScheme is SIGN_INFO, sign any value using the SIGN_INFO structure and4186 TPM_SS_RSASSAPKCS1v15_INFO4187 4. When data is signed and the data comes from INSIDE the TPM, the TPM is MUST do the4188 hash, and prepend the DER encoding correctly before performing the padding and4189 private key operation.4190 5. When data is signed and the data comes from OUTSIDE the TPM, the software, not the4191 TPM, MUST do the hash.4192 6. When the TPM knows, or is told by implication, that the hash used is SHA-1, the TPM4193 MUST prepend the DER encoding correctly before performing the padding and private4194 key operation4195 7. When the TPM does not know, or told by implication, that the hash used is SHA-1, the4196 software, not the TPM) MUST provide the DER encoding to be prepended.4197 8. The TPM MUST perform the padding and private key operation in any signing operations4198 it does.4199 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 140 Revision 94 29 March 2006 TCG Published 32. Key Usage Table4200 This table summarizes the types of keys associated with a given TPM command.4201 It is the responsibility of each command to check the key usage prior to executing the4202 command4203 First Key Second KeyName FirstKey SecondKey SIGNING STORAGE IDENTITY AUTHCHG BIND LEEGACY SIGNING STORAGE IDENTITY AUTHCHG BIND LEGACY TPM_ActivateIdentity idKey x TPM_CertifyKey certKey inKey x x x x x x x x TPM_CertifyKey2(Note 3) inKey certKey x x x x x x x x TPM_CertifySelfTest key x x x TPM_ChangeAuth parent blob x 2 2 2 2 2 2 TPM_ChangeAuthAsymFinish parent ephemeral x x TPM_ChangeAuthAsymStart idKey ephemeral x x TPM_CMK_ConvertMigration parent x TPM_CMK_CreateBlob parent x TPM_CMK_CreateKey parent x TPM_ConvertMigrationBlob parent x TPM_CreateMigrationBlob parent blob x 2 2 2 2 2 2 TPM_CreateWrapKey parent x TPM_Delegate_CreateKeyDelegation key x x x x x x TPM_DSAP entity x x x x x x TPM_EstablishTransport key x x TPM_GetAuditDigestSigned certKey x x x TPM_GetAuditEventSigned certKey x x TPM_GetCapabilitySigned key x x x TPM_GetPubKey key x x x x x x TPM_KeyControlOwner key x x x x x TPM_LoadKey 2 parent inKey x x x x x x TPM_LoadKey parent inKey x x x x x x TPM_MigrateKey maKey 1 TPM_OSAP entity x x x x x x TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 141 TCG Published TPM_Quote key x x x TPM_Quote2 key x x x TPM_Seal key x TPM_Sealx key x TPM_Sign key x x TPM_UnBind key x x TPM_Unseal parent x TPM_ReleaseTransport key x TPM_TickStampBlob key x x x Notes4204 1 ­ Key is not a storage key but TPM_MIGRATE_KEY4205 2 ­ TPM unable to determine key type4206 3 ­ The order is correct; the reason is to support a single auth version.4207 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 142 Revision 94 29 March 2006 TCG Published 33. Direct Anonymous Attestation4208 Start of informative comment4209 TPM_DAA_Join and TPM_DAA_Sign are highly resource intensive commands. They require4210 most of the internal TPM resources to accomplish the complete set of operations. A TPM4211 may specify that no other commands are possible during the join or sign operations. To4212 allow for other operations to occur the TPM does allow the TPM_SaveContext command to4213 save off the current join or sign operation.4214 Operations that occur during a join or sign result in the loss of the join or sign session in4215 favour of the interrupting command.4216 End of informative comment4217 1. The TPM MUST support one concurrent TPM_DAA_Join or TPM_DAA_Sign session. The4218 TPM MAY support additional sessions4219 2. The TPM MAY invalidate a join or sign session upon the receipt of any additional4220 command other than the join/sign or TPM_SaveContext4221 33.1 TPM_DAA_JOIN4222 Start of informative comment4223 TPM_DAA_Join creates new JOIN data. If a TPM supports only one JOIN/SIGN operation,4224 TPM_DAA_Join invalidates any previous DAA attestation information inside a TPM. The4225 JOIN phase of a DAA context requires a TPM to communicate with an issuer.4226 TPM_DAA_Join outputs data to be sent to an issuing authority and receives data from that4227 issuing authority. The operation potentially requires several seconds to complete, but is4228 done in a series of atomic stages and TPM_SaveContext/RestoreContext can be used to4229 cache data off-TPM in between atomic stages.4230 The JOIN process is designed so a TPM will normally receive exactly the same DAA4231 credentials from a given issuer, no matter how many times the JOIN process is executed4232 and no matter whether the issuer changes his keys. This property is necessary because an4233 issuer must give DAA credentials to a platform after verifying that the platform has the4234 architecture of a trusted platform. Unless the issuer repeats the verification process, there4235 is no justification for giving different DAA credentials to the same platform. Even after4236 repeating the verification process, the issuer should give replacement (different) DAA4237 credentials only when it is necessary to retire the old DAA credentials. Replacement DAA4238 credentials erase the previous DAA history of the platform, at least as far as the DAA4239 credentials from that issuer are concerned. Replacement might be desirable, as when a4240 platform changes hands, for example, in order to eliminate any association via DAA between4241 the seller and the buyer. On the other hand, replacement might be undesirable, since it4242 enables a rogue to rejoin a community from which he has been barred. Replacement is done4243 by submitting a different "count" value to the TPM during a JOIN process. A platform may4244 use any value of "count" at any time, in any order, but only "counts" accepted by the issuer4245 will elicit DAA credentials from that issuer.4246 The TPM is forced to verify an issuer's public parameters before using an issuer's public4247 parameters. This verification provides proof that the public parameters (which include a4248 public key) were approved by an entity that knows the private key corresponding to that4249 public key; in other words that the JOIN has previously been approved by the issuer. This4250 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 143 TCG Published verification is necessary to prevent an attack by a rogue using a genuine issuer's public4251 parameters, which could reveal the secret created by the TPM using those public4252 parameters. Verification uses a signature (provided by the issuer) over the public4253 parameters.4254 The exponent of the issuer's key is fixed at 2^16+1, because this is the only size of exponent4255 that a TPM is required to support. The modulus of the issuer's public key is used to create4256 the pseudonym with which the TPM contacts the issuer. Hence the TPM cannot produce the4257 same pseudonym for different issuers (who have different keys). The pseudonym is always4258 created using the issuer's first key, even if the issuer changes keys, in order to produce the4259 property described earlier. The issuer proves to the TPM that he has the right to use that4260 first key to create a pseudonym by creating a chain of signatures from the first key to the4261 current key, and submitting those signatures to the TPM. The method has the desirable4262 property that only signatures and the most recent private key need be retained by the4263 issuer: once the latest link in the signature chain has been created, previous private keys4264 can be discarded.4265 The use of atomic operations minimises the contiguous time that a TPM is busy with4266 TPM_DAA_Join and hence unavailable for other commands. JOIN can therefore be done as4267 a background activity without inconveniencing a user. The use of atomic operations also4268 minimises the peak value of TPM resources consumed by the JOIN phase.4269 The use of atomic operations introduces a need for consistency checks, to ensure that the4270 same parameters are used in all atomic operations of the same JOIN process.4271 DAA_tpmSpecific therefore contains a digest of the associated DAA_issuerSettings4272 structure, and DAA_session contains a digest of associated DAA_tpmSpecific and4273 DAA_joinSession structures. Each atomic operation verifies digests to ensure use of4274 mutually consistent sets of DAA_issuerSettings, DAA_tpmSpecific, DAA_session, and4275 DAA_joinSession data.4276 JOIN operations and data structures are designed to minimise the amount of data that4277 must be stored on a TPM in between atomic operations, while ensuring use of mutually4278 consistent sets of data. Digests of public data are held in the TPM between atomic4279 operations, instead of the actual public data (if a digest is smaller than the actual data). In4280 each atomic operation, consistency checks verify that any public data loaded and used in4281 that operation matches the stored digest. Thus non-secret DAA_generic_X parameters4282 (loaded into the TPM only when required), are checked using digests DAA_digest_X4283 (preloaded into the TPM in the structure DAA_issuerSettings).4284 JOIN includes a challenge from the issuer, in order to defeat simple Denial of Service4285 attacks on the issuer's server by rogues pretending to be arbitrary TPMs.4286 A first group of atomic operations generate all TPM-data that must be sent to the issuer.4287 The platform performs other operations (that do not need to be trusted) using the TPM-data,4288 and sends the resultant data to the issuer. The issuer sends values u2 and u3 back to the4289 TPM. A second group of atomic operations accepts this data from the issuer and completes4290 the protocol.4291 The TPM outputs encrypted forms of DAA_tpmSpecific, v0 and v1. These encrypted data are4292 later interpreted by the same TPM and not by any other entity, so any manufacturer-4293 specific wrapping can be used. It is suggested, however, that enc(DAA_tpmSpecific) or4294 enc(v0) or enc(v1) data should be created by adapting a TPM_CONTEXT_BLOB structure.4295 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 144 Revision 94 29 March 2006 TCG Published After executing TPM_DAA_Join, it is prudent to perform TPM_DAA_Sign, to verify that the4296 JOIN process completed correctly. A host platform may choose to verify JOIN by performing4297 TPM_DAA_Sign as both the target and the verifier (or could, of course, use an external4298 verifier).4299 End of informative comment4300 33.2 TPM_DAA_Sign4301 Start of informative comment4302 TPM_DAA_Sign responds to a challenge and proves the attestation held by a TPM without4303 revealing the attestation held by that TPM. The operation is done in a series of atomic4304 stages to minimise the contiguous time that a TPM is busy and hence unavailable for other4305 commands. TPM_SaveContext can be used to save a DAA context in between atomic stages.4306 This enables the response to the challenge to be done as a background activity without4307 inconveniencing a user, and also minimises the peak value of TPM resources consumed by4308 the process.4309 The use of atomic operations introduces a need for consistency checks, to ensure that the4310 same parameters are used in all atomic operations of the same SIGN process.4311 DAA_tpmSpecific therefore contains a digest of the associated DAA_issuerSettings4312 structure, and DAA_session contains a digest of associated DAA_tpmSpecific structure.4313 Each atomic operation verifies these digests and hence ensures use of mutually consistent4314 sets of DAA_issuerSettings, DAA_tpmSpecific, and DAA_session data.4315 SIGN operations and data structures are designed to minimise the amount of data that4316 must be stored on a TPM in between atomic operations, while ensuring use of mutually4317 consistent sets of data. Digests of public and private data are held in the TPM between4318 atomic operations, instead of the actual public or private data (if a digest is smaller than the4319 actual data). At each atomic operation, consistency checks verify that any data loaded and4320 used in that operation matches the stored digest. Thus parameters DAA_digest_X are4321 digests (preloaded into the TPM in the structure DAA_issuerSettings) of non-secret4322 DAA_generic_X parameters (loaded into the TPM only when required), for example.4323 The design enables the use of any number of issuer DAA-data, private DAA-data, and so on.4324 Strictly, the design is that the *TPM* puts no limit on the number of sets of issuer DAA-data4325 or sets of private DAA-data, or restricts what set is in the TPM at any time, but supports4326 only one DAA-context in the TPM at any instant. Any number of DAA-contexts can, of4327 course, be swapped in and out of the TPM using saveContext /loadContext, so applications4328 do not perceive a limit on the number of DAA-contexts.4329 TPM_DAA_Sign accepts a freshness challenge from the verifier and generate all TPM-data4330 that must be sent to the verifier. The platform performs other operations (that do not need4331 to be trusted) using the TPM-data, and sends the resultant data to the verifier. At one stage,4332 the TPM incorporates a loaded public (non-migratable) key into the protocol. This is4333 intended to permit the setup of a session, for any specific purpose, including doing the4334 same job in TPM_ActivateIdentity as the EK.4335 End of informative comment4336 33.3 DAA Command summary4337 Start of informative comment4338 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 145 TCG Published The following is a conceptual summary of the operations that are necessary to setup a TPM4339 for DAA, execute the JOIN process, and execute the SIGN process.4340 The summary is partitioned according to the "stages" of the actual TPM commands. Thus4341 the operations listed in JOIN under stage-2 briefly describe the operation of TPM_DAA_Join4342 at stage-2, for example.4343 This summary is in place to help in the connection between the mathematical definition of4344 DAA and this implementation in a TPM.4345 End of informative comment4346 33.3.1 TPM setup4347 1. A TPM generates a TPM-specific secret S (160-bit) from the RNG and stores S in4348 nonvolatile store on the TPM. This value will never be disclosed and changed by the4349 TPM.4350 33.3.2 JOIN4351 Start of informative comment4352 This entire section is informative4353 1. When the following is performed, this process does not increment the stage counter.4354 a. TPM imports a non-secret values n0 (2048-bit).4355 b. TPM computes a non-secret value N0 (160-bit) = H(n0).4356 c. TPM computes a TPM-specific secret DAA_rekey (160-bit) = H(S, H(n0)).4357 d. TPM stores a self-consistent set of (N0, DAA_rekey)4358 2. The following is performed 0 or several times: (Note: If the stage mechanism is being4359 used, then this branch does not increment the stage counter.)4360 a. TPM imports4361 i. a self consistent set of (N0, DAA_rekey)4362 ii. a non-secret value DAA_SEED_KEY (2048-bit)4363 iii. a non-secret value DEPENDENT_SEED_KEY (2048-bit)4364 iv. a non-secret value SIG_DSK (2048-bit)4365 b. TPM computes DIGEST (160-bit) = H(DAA_SEED_KEY)4366 c. If DIGEST != N0, TPM refuses to continue4367 d. If DIGEST == N0, TPM verifies validity of signature SIG_DSK on4368 DEPENDENT_SEED_KEY with key (DAA_SEED_KEY, e0 (= 2^16 + 1)) by using4369 TPM_Sign_Verify (based on PKCS#1 2.0). If check fails, TPM refuses to continue.4370 e. TPM sets N0 = H(DEPENDENT_SEED_KEY)4371 f. TPM stores a self consistent set of (N0, DAA_JOIN)4372 3. Stage 24373 a. TPM imports a set of values, including4374 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 146 Revision 94 29 March 2006 TCG Published i. a non-secret value n0 (2048-bit),4375 ii. a non-secret value R0 (2048-bit),4376 iii. a non-secret value R1 (2048-bit),4377 iv. a non-secret value S0 (2048-bit),4378 v. a non-secret value S1 (2048-bit),4379 vi. a non-secret value n (2048-bit),4380 vii.a non-secret value n1 (1024-bit),4381 viii. a non-secret value gamma (2048-bit),4382 ix. a non-secret value q (208-bit),4383 x. a non-secret value COUNT (8-bit),4384 xi. a self consistent set of (N0, DAA_rekey).4385 xii.TPM saves them as part of a new set A.4386 b. TPM computes DIGEST (160-bit) = H(n0)4387 c. If DIGEST != N0, TPM refuses to continue.4388 d. If DIGEST == N0, TPM computes DIGEST (160-bit) = H(R0, R1, S0, S1, n, n1, G, q)4389 e. TPM imports a non-secret value SIG_ISSUER_KEY (2048-bit).4390 f. TPM verifies validity of signature SIG_ISSUER_KEY (2048-bit) on DIGEST with key (n0,4391 e0) by using TPM_Sign_Verify (based on PKCS#1 2.0). If check fails, TPM refuses to4392 continue.4393 g. TPM computes a TPM-specific secret f (208-bit) = H(DAA_rekey, COUNT,4394 0)||H(DAA_rekey, COUNT, 1) mod q.4395 h. TPM computes a TPM-specific secret f0 (104-bit) = f mod 2104.4396 i. TPM computes a TPM-specific secret f1 (104-bit) = f >> 104.4397 j. TPM save f, f0 and f1 as part of set A.4398 4. Stage 34399 a. TPM generates a TPM-specific secret u0 (1024-bit) from the RNG.4400 b. TPM generates a TPM-specific secret u'1 (1104-bit) from the RNG.4401 c. TPM computes u1 (1024-bit) = u'1 mod n1.4402 d. TPM stores u0 and u1 as part of set A.4403 5. Stage 44404 a. TPM computes a non-secret value P1 (2048-bit) = (R0^f0) mod n and stores P1 as part of4405 set A.4406 6. Stage 54407 a. TPM computes a non-secret value P2 (2048-bit) = P1*(R1^f1) mod n, stores P2 as part of4408 set A and erases P1 from set A.4409 7. Stage 64410 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 147 TCG Published a. TPM computes a non-secret value P3 (2048-bit) = P2*(S0^u0) mod n, stores P3 as part of4411 set A and erases P2 from set A.4412 8. Stage 74413 a. TPM computes a non-secret value U (2048-bit) = P3*(S1^u1) mod n.4414 b. TPM erases P3 from set A4415 c. TPM computes and saves U1 (160-bit) = H(U||COUNT||N0) as part of set A.4416 d. TPM exports U.4417 9. Stage 84418 a. TPM imports ENC_NE (2048-bit).4419 b. TPM decrypts NE (160-bit) from ENC_NE (2048-bit) by using privEK: NE =4420 decrypt(privEK, ENC_NE).4421 c. TPM computes U2 (160-bit) = H(U1||NE).4422 d. TPM erases U1 from set A.4423 e. TPM exports U2.4424 10.Stage 94425 a. TPM generates a TPM-specific secret r0 (344-bit) from the RNG.4426 b. TPM generates a TPM-specific secret r1 (344-bit) from the RNG.4427 c. TPM generates a TPM-specific secret r2 (1024-bit) from the RNG.4428 d. TPM generates a TPM-specific secret r3 (1264-bit) from the RNG.4429 e. TPM stores r0, r1, r2, r3 as part of set A.4430 f. TPM computes a non-secret value P1 (2048-bit) = (R0^r0) mod n and stores P1 as part of4431 set A.4432 11.Stage 104433 a. TPM computes a non-secret value P2 (2048-bit) = P1*(R1^r1) mod n, stores P2 as part of4434 set A and erases P1 from set A.4435 12.Stage 114436 a. TPM computes a non-secret value P3 (2048-bit) = P2*(S0^r2) mod n, stores P3 as part of4437 set A and erases P2 from set A.4438 13.Stage 124439 a. TPM computes a non-secret value P4 (2048-bit) = P3*(S1^r3) mod n, stores P4 as part of4440 set A and erases P3 from set A.4441 b. TPM exports P4.4442 14.Stage 134443 a. TPM imports w (2048-bit).4444 b. TPM computes w1 = w^q mod G.4445 c. TPM verifies if w1 = 1 holds. If it doesn't hold, TPM refuses to continue.4446 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 148 Revision 94 29 March 2006 TCG Published d. If it does hold, TPM saves w as part of set A.4447 15.Stage 144448 a. TPM computes a non-secret value E (2048-bit) = w^f mod G.4449 b. TPM exports E.4450 16.Stage 154451 a. TPM computes a TPM-specific secret r (208-bit) = r0 + 2^104*r1 mod q.4452 b. TPM computes a non-secret value E1 (2048-bit) = w^r mod G.4453 c. TPM exports E1 and erases w from set A.4454 17.Stage 164455 a. TPM imports a non-secret value c1 (160-bit).4456 b. TPM generates a non-secret value NT (160-bit) from the RNG.4457 c. TPM computes a non-secret value c (160-bit) = H(c1||NT).4458 d. TPM save c as part of set A.4459 e. TPM exports NT4460 18.Stage 174461 a. TPM computes a non-secret value s0 (352-bit) = r0 + c*f0 over the integers.4462 b. TPM exports s0.4463 19.Stage 184464 a. TPM computes a non-secret value s1 (352-bit) = r1 + c*f1 over the integers.4465 b. TPM exports s1.4466 20.Stage 194467 a. TPM computes a non-secret value s2 (1024-bit) = r2 + c*u0 mod 21024.4468 b. TPM exports s2.4469 21.Stage 204470 a. TPM computes a non-secret value s'2 (1024-bit) = (r2 + c*u0) >> 1024 over the integers.4471 b. TPM saves s'2 as part of set A.4472 c. TPM exports c4473 22.Stage 214474 a. TPM computes a non-secret value s3 (1272-bit) = r3 + cu1 + s'2 over the integers.4475 b. TPM exports s3 and erases s'2 from set A.4476 23.Stage 224477 a. TPM imports a non-secret value u2 (1024-bit).4478 b. TPM computes a TPM-specific secret v0 (1024-bit) = u2 + u0 mod 21024.4479 c. TPM stores v0 as part of A.4480 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 149 TCG Published d. TPM computes a TPM-specific secret v'0 (1024-bit) = (u2 + u0) >> 1024 over the integers.4481 e. TPM saves v'0 as part of set A.4482 24.Stage 234483 a. TPM imports a non-secret value u3 (1512-bit).4484 b. TPM computes a TPM-specific secret v1 (1520-bit) = u3 + u1 + v'0 over the integers.4485 c. TPM stores v1 as part of A.4486 d. TPM erases v'0 from set A.4487 25.Stage 244488 a. TPM makes self consistent set of all the data (n0, COUNT, R0, R1, S0, S1, n, G, q, v0,4489 v1), where the values v0, v1 are secret ­ they need to be stored safely with the consistent4490 set, and the remaining is non-secret.4491 b. TPM erases set A.4492 End of informative comment4493 33.3.3 SIGN4494 Start of informative comment4495 This entire section is informative4496 1. Stage 0 & 14497 a. TPM imports and verifies a self consistent set of all the data including:4498 i. n0 (2048-bit),4499 ii. COUNT (8-bit),4500 iii. R0 (2048-bit),4501 iv. R1 (2048-bit),4502 v. S0 (2048-bit),4503 vi. S1 (2048-bit),4504 vii.n (2048-bit),4505 viii. gamma (2048-bit),4506 ix. q (208-bit),4507 x. v0 (1024-bit),4508 xi. v1 (1520-bit).4509 xii.If the verification does not succeed, TPM refuses to continue.4510 b. TPM stores the above values as part of a new set A.4511 c. TPM computes a TPM-specific secret f0 (104-bit) = f mod 2104.4512 d. TPM computes a TPM-specific secret f1 (104-bit) = f >> 104.4513 e. TPM stores f0 and f1 as part of set A.4514 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 150 Revision 94 29 March 2006 TCG Published f. TPM generates a TPM-specific secret r0 (344-bit) from the RNG.4515 g. TPM generates a TPM-specific secret r1 (344-bit) from the RNG.4516 h. TPM generates a TPM-specific secret r2 (1024-bit) from the RNG.4517 i. TPM generates a TPM-specific secret r4 (1752-bit) from the RNG.4518 j. TPM stores r0, r1, r2, r4, as part of set A.4519 2. Stage 24520 a. TPM computes a non-secret value P1 (2048-bit) = (R0^r0) mod n and stores P1 as part of4521 set A.4522 3. Stage 34523 a. TPM computes a non-secret value P2 (2048-bit) = P1*(R1^r1) mod n, stores P2 as part of4524 set A and erases P1 from set A.4525 4. Stage 44526 a. TPM computes a non-secret value P3 (2048-bit) = P2*(S0^r2) mod n, stores P3 as part of4527 set A and erases P2 from set A.4528 5. Stage 54529 a. TPM computes a non-secret value T (2048-bit) = P3*(S1^r4) mod n.4530 b. TPM erases P3 from set A.4531 c. TPM exports T.4532 6. Stage 64533 a. TPM imports a non-secret value w (2048-bit).4534 b. TPM computes w1 = w^q mod G.4535 c. TPM verifies if w1 = 1 holds. If it doesn't hold, TPM refuses to continue.4536 d. If it does hold, TPM saves w as part of set A.4537 7. Stage 74538 a. TPM computes a non-secret value E (2048-bit) = w^f mod G.4539 b. TPM exports E and erases f from set A.4540 8. Stage 84541 a. TPM computes a TPM-specific secret r (208-bit) = r0 + 2^104*r1 mod q.4542 b. TPM computes a non-secret value E1 (2048-bit) = w^r mod G.4543 c. TPM exports E1 and erases w and E1 from set A.4544 9. Stage 94545 a. TPM imports a non-secret value c1 (160-bit).4546 b. TPM generates a non-secret value NT (160-bit) from the RNG.4547 c. TPM computes a non-secret value c2 (160-bit) = H(c1||NT) and erases c1 from set A.4548 d. TPM saves c2 as part of set A.4549 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 151 TCG Published e. TPM exports NT.4550 10.Stage 104551 a. TPM imports a non-secret value b (1-bit).4552 b. If b = = 1, TPM imports a non-secret value m (160-bit).4553 c. TPM computes a non-secret value c (160-bit) = H(c2||b||m) and erases c2 from set A.4554 d. If b = = 0, TPM imports an RSA public key, eAIK (= 2^16 + 1) and nAIK (2048-bit).4555 e. TPM computes a non-secret value c (160-bit) = H(c2||b||nAIK) and erases c2 from set4556 A.4557 f. TPM exports c.4558 11.Stage 114559 a. TPM computes a non-secret value s0 (352-bit) = r0 + c*f0 over the integers.4560 b. TPM exports s0.4561 12.Stage 124562 a. TPM computes a non-secret value s1 (352-bit) = r1 + c*f1 over the integers.4563 b. TPM exports s1.4564 13.Stage 134565 a. TPM computes a non-secret value s2 (1024-bit) = r2 + c*v0 mod 21024.4566 b. TPM exports s2.4567 14.Stage 144568 a. TPM computes a non-secret value s'2 (1024-bit) = (r2 + c*v0) >> 1024 over the integers.4569 b. TPM saves s'2 as part of set A.4570 15.Stage 154571 a. TPM computes a non-secret value s3 (1760-bit) = r4 + cv1 + s'2 over the integers.4572 b. TPM exports s3 and erases s'2 from set A.4573 c. TPM erases set A.4574 End of informative comment4575 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 152 Revision 94 29 March 2006 TCG Published 34. General Purpose IO4576 Start of informative comment4577 The GPIO capability allows an outside entity to output a signal on a GPIO pin, or read the4578 status of a GPIO pin. The solution is for a single pin, with no timing information. There is4579 no support for sending information on specific busses like SMBus or RS232. The design4580 does support the designation of more than one GPIO pin.4581 There is no requirement as to the layout of the GPIO pin, or the routing of the wire from the4582 GPIO pin on the platform. A platform specific specification can add those requirements.4583 To avoid the designation of additional command ordinals, the architecture uses the NV4584 Storage commands. A set of GPIO NV indexes map to individual GPIO pins.4585 TPM_NV_INDEX_GPIO_00 maps to the first GPIO pin. The platform specific specification4586 indicates the mapping of GPIO zero to a specific package pin.4587 The TPM does not reserve any NV storage for the indicated pin; rather the TPM uses the4588 authorization mechanisms for NV storage to allow a rich set of controls on the use of the4589 GPIO pin. The TPM owner can specify when and how the platform can use the GPIO pin.4590 While there is no NV storage for the pin value, TRUE or FALSE, there is NV storage for the4591 authorization requirements for the pin.4592 Using the NV attributes the GPIO pin may be either an input pin or an output pin.4593 End of informative comment4594 1. The TPM MAY support the use of a GPIO pin defined by the NV storage mechanisms.4595 2. The GPIO pin MAY be either an input or an output pin.4596 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 153 TCG Published 35. Redirection4597 Informative comment4598 Redirection allows the TPM to output the results of operations to hardware other than the4599 normal TPM communication bus. The redirection can occur to areas internal or external to4600 the TPM. Redirection is only available to key operations (such as TPM_UnBind,4601 TPM_Unseal, and TPM_GetPubKey). To use redirection the key must be created specifying4602 redirection as one of the keys attributes.4603 When redirecting the output the TPM will not interpret any of the data and will pass the4604 data on without any modifications.4605 The TPM_SetRedirection command connects a destination location or port to a loaded key.4606 This connection remains so long as the key is loaded, and is saved along with other key4607 information on a saveContext(key), loadContext(key). If the key is reloaded using4608 TPM_LoadKey, then TPM_SetRedirection must be run again.4609 Any use of TPM_SetRedirection with a key that does not have the redirect attribute must4610 return an error. Use of key that has the redirect attribute without TPM_SetRedirection being4611 set must return an error.4612 End of informative comments4613 1. The TPM MAY support redirection4614 2. If supported, the TPM MUST only use redirection on keys that have the redirect attribute4615 set4616 3. A key that is tagged as a "redirect" key MUST be a leaf key in the TPM Protected Storage4617 blob hierarchy. A key that is tagged as a "redirect" key CAN NEVER be a parent key.4618 4. Output data that is the result of a cryptographic operation using the private portion of a4619 "redirect" key:4620 a. MUST be passed to an alternate output channel4621 b. MUST NOT be passed to the normal output channel4622 c. MUST NOT be interpreted by the TPM4623 5. When command input or output is redirected the TPM MUST respond to the command4624 as soon as the ordinal finishes processing4625 a. The TPM MUST indicate to any subsequent commands that the TPM is busy and4626 unable to accept additional command until the redirection is complete4627 b. The TPM MUST allow for the resetting of the redirection channel4628 6. Redirection MUST be available for the following commands:4629 a. TPM_Unseal4630 b. TPM_UnBind4631 c. TPM_GetPubKey4632 d. TPM_Seal4633 e. TPM_Quote4634 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 154 Revision 94 29 March 2006 TCG Published 36. Structure Versioning4635 Start of informative comment4636 In version 1.1 some structures also contained a version indicator. The TPM set the indicator4637 to indicate the version of the TPM that was creating the structure. This was incorrect4638 behavior. The functionality of determining the version of a structure is radically different in4639 1.2.4640 Most structures will contain a TPM_STRUCTURE_TAG. All future structures must contain4641 the tag, the only structures that do not contain the tag are 1.1 structures that are not4642 modified in 1.2. This restriction keeps backwards compatibility with 1.1.4643 Any 1.2 structure must not contain a 1.1 tagged structure. For instance the TPM_KEY4644 complex, if set at 1.2, must not contain a PCR_INFO structure. The TPM_KEY 1.2 structure4645 must contain a PCR_INFO_LONG structure. The converse is also true 1.1 structures must4646 not contain any 1.2 structures.4647 The TPM must not allow the creation of any mixed structures. This implies that a command4648 that deals with keys, for instance, must ensure that a complete 1.1 or 1.2 structure is4649 properly built and validated on the creation and use of the key.4650 The tag structure is set as a UINT16. This allows for a reasonable number of structures4651 without wasting space in the buffers.4652 To obtain the current TPM version the caller must use the TPM_GetCapability command.4653 The tag is not a complete validation of the validity of a structure. The tag provides a4654 reference for the structure and the TPM or caller is responsible for determining the validity4655 of any remaining fields. For instance, in the TPM_KEY structure the tag would indicate4656 TPM_KEY but the TPM would still use tpmProof and the various digests to ensure the4657 structure integrity.4658 7. Compatibility and notification4659 In 1.1 TPM_CAP_VERSION (index 19) returned a version structure with 1.1.x.x. The x.x was4660 for manufacturer information and the x.x also was set version structures. In 1.24661 TPM_CAP_VERSION will return 1.1.0.0. Any 1.2 structure that uses the version information4662 will set the x.x to 0.0 in the structure. TPM_CAP_MANUFACTURER_VER (index 21) will4663 return 1.2.x.x. The 1.2 structures do not contain the version structure. The rationale4664 behind this is that the structure tag will indicate the version of the structure. So changing a4665 correct structure will result in a new tag and there is no need for a separate version4666 structure.4667 For further compatibility the quote function always returns 1.1.0.0 in the version4668 information regardless of the size of the incoming structure. All other functions may regard4669 a 2 byte sizeofselect structure as indicative of a 1.1 structure. The TPM handles all of the4670 structures according to the input, the only exception being TPM_CertifyKey where the TPM4671 does not need to keep the input version of the structure.4672 End of informative comment4673 1. The TPM MUST support 1.1 and 1.2 defined structures4674 2. The TPM MUST ensure that 1.1 and 1.2 structures are not mixed in the same overall4675 structure4676 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 155 TCG Published a. For instance in the TPM_KEY structure if the structure is 1.1 then PCR_INFO MUST4677 be set and if 1.2 the PCR_INFO_LONG structure must be set4678 3. On input the TPM MUST ignore the lower two bytes of the version structure4679 4. On output the TPM MUST set the lower two bytes to 0 of the version structure4680 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 156 Revision 94 29 March 2006 TCG Published 37. Certified Migration Key Type4681 Start of informative comment4682 In version 1.1 there were two key types, non-migration and migration keys. The TPM would4683 only certify non-migrating keys. There is a need for a key that allows migration but allows4684 for certification. This proposal is to create a key that allows for migration but still has4685 properties that the TPM can certify.4686 These new keys are "certifiable migratable keys" or CMK. This designation is to separate the4687 keys from either the normal migration or non-migration types of keys. The TPM Owner is4688 not required to use these keys.4689 Two entities may participate in the CMK process. The first is the Migration-Selection4690 Authority and the second is the Migration Authority (MA).4691 Migration Selection Authority (MSA)4692 The MSA controls the migration of the key but does not handle the migrated itself.4693 Migration Authority (MA)4694 A Migration Authority actually handles the migrated key.4695 Use of MSA and MA4696 Migration of a CMK occurs using TPM_CMK_CreateBlob (TPM_CreateMigrationBlob cannot4697 be used). The TPM Owner authorizes the migration destination (as usual), and the key4698 owner authorizes the migration transformation (as usual). An MSA authorizes the migration4699 destination as well. If the MSA is the migration destination, no MSA authorization is4700 required.4701 End of informative comment4702 37.1 Certified Migration Requirements4703 Start of informative comment4704 The following list details the design requirements for the controlled migration keys4705 Key Protections4706 The key must be protected by hardware and an entity trusted by the key user.4707 Key Certification4708 The TPM must provide a mechanism to provide certification of the key protections (both4709 hardware and trusted entity)4710 Owner Control4711 The TPM Owner must control the selection of the trusted entity4712 Control Delegation4713 The TPM Owner may delegate the ability to create the keys but the decision must be explicit4714 Linkage4715 The architecture must not require linking the trusted entity and the key user4716 Key Type4717 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 157 TCG Published The key may be any type of migratable key (storage or signing)4718 Interaction4719 There must be no required interaction between the trusted entity and the TPM during the4720 key creation process4721 End of informative comment4722 37.2 Key Creation4723 Start of informative comment4724 The command TPM_CMK_CreateKey creates a CMK where control of the migration is by a4725 MSA or MA. The process uses the MSA public key (actually a digest of the MA public key) as4726 input to TPM_CMK_CreateKey. The key creation process establishes a migrationAuth that is4727 SHA-1(tpmProof || SHA-1(MA pubkey) || SHA-1(source pubkey)).4728 The use of tpmProof is essential to prove that CMK creation occurs on a TPM. The use of4729 "source pubkey" explicitly links a migration AuthData value to a particular public key, to4730 simplify verification that a specific key is being migrated.4731 End of informative comment4732 37.3 Migrate CMK to a MA4733 Start of informative comment4734 Migration of a CMK to a destination other than the MSA:4735 TPM_MIGRATIONKEYAUTH Creation4736 The TPM Owner authorizes the creation of a TPM_MIGRATIONKEYAUTH structure using4737 TPM_AuthorizeMigrationKey command. The structure contains the destination4738 migrationKey, the migrationScheme (which must be set to TPM_MS_RESTRICT_APPROVE4739 or TPM_MS_RESTRICT_APPROVE_DOUBLE) and a digest of tpmProof.4740 MA Approval4741 The MA signs a TPM_CMK_AUTH structure, which contains the digest of the MA public key,4742 the digest of the destination (or parent) public key and a digest of the public portion of the4743 key to be migrated4744 TPM Owner Authorization4745 The TPM Owner authorizes the MA approval using TPM_CMK_CreateTicket and produces a4746 signature ticket4747 Key Owner Authorization4748 The CMK owner passes the TPM Owner MA authorization, the MSA Approval and the4749 signature ticket to the TPM_CMK_CreateBlob using the key owners authorization.4750 Thus the TPM owner, the key's owner, and the MSA, all cooperate to migrate a key4751 produced by TPM_CMK_CreateBlob.4752 End of informative comment4753 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 158 Revision 94 29 March 2006 TCG Published 37.4 Migrate CMK to a MSA4754 Start of informative comment4755 Migrate CMK directly to a MSA4756 TPM_MIGRATIONKEYAUTH Creation4757 The TPM Owner authorizes the creation of a TPM_MIGRATIONKEYAUTH structure using4758 TPM_AuthorizeMigrationKey command. The structure contains the destination4759 migrationKey (which must be the MSA public key), the migrationScheme (which must be set4760 to TPM_MS_RESTRICT_MIGRATE) and a digest of tpmProof.4761 Key Owner Authorization4762 The CMK owner passes the TPM_MIGRATIONKEYAUTH to the TPM in a4763 TPM_CMK_CreateBlob using the CMK owner authorization.4764 Double Wrap4765 If specified, through the MS_MIGRATE scheme, the TPM double wraps the CMK information4766 such that the only way a recipient can unwrap the key is with the cooperation of the CMK4767 owner.4768 Proof of Control4769 To prove to the MA and to a third party that migration of a key is under MSA control, a4770 caller passes the MA's public key (actually its digest) to TPM_CertifyKey, to create a4771 TPM_CERTIFY_INFO structure. This now contains a digest of the MA's public key.4772 A CMK be produced without cooperation from the MA: the caller merely provides the MSA's4773 public key. When the restricted key is to be migrated, the public key of the intended4774 destination, plus the CERTIFY_INFO structure are sent to the MSA. The MSA extracts the4775 migrationAuthority digest from the CERTIFY_INFO structure, verifies that4776 migrationAuthority corresponds to the MSA's public key, creates and signs a4777 TPM_RESTRICTEDKEYAUTH structure, and sends that signature back to the caller. Thus4778 the MSA never needs to touch the actual migrated data.4779 End of informative comment4780 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 159 TCG Published 38. Revoke Trust4781 Start of informative comment4782 There are circumstances where clearing all keys and values within the TPM is either4783 desirable or necessary. These circumstances may involve both security and privacy4784 concerns.4785 Platform trust is demonstrated using the EK Credential, Platform Credential and the4786 Conformance Credentials. There is a direct and cryptograph relationship between the EK4787 and the EK Credential and the Platform Credential. The EK and Platform credentials can4788 only demonstrate platform trust when they can be validated by the Endorsement Key.4789 This command is called revoke trust because by deleting the EK, the EK Credential and the4790 Platform Credential are dissociated from platform therefore invalidating them resulting in4791 the revocation of the trust in the platform. From a trust perspective, the platform associated4792 with these specific credentials no longer exists. However, any transaction that occurred4793 prior to invoking this command will remain valid and trusted to the same extent they would4794 be valid and trusted if the platform were physically destroyed.4795 This is a non-reversible function. Also, along with the EK, the Owner is also deleted4796 removing all non-migratable keys and owner-specified state.4797 It is possible to establish new trust in the platform by creating a new EK using the4798 TPM_CreateRevocableEK command. (It is not possible to create an EK using the4799 TPM_CreateEndorsementKeyPair because that command is not allowed if the revoke trust4800 command is allowed.) Establishing trust in the platform, however, is more than just4801 creating the EK. The EK Credential and the Platform Credential must also be created and4802 associated with the new EK as described above. (The conformance credentials may be4803 obtained from the TPM and Platform manufacturer.) These credentials must be created by4804 an entity that is trusted by those entities interested in the trust of the platform. This may4805 not be a trivial task. For example, an entity willing to create these credentials my want to4806 examine the platform and require physical access during the new EK generation process.4807 Besides calling one of the two EK creation functions to create the EK, the EK may be4808 "squirted" into the TPM by an external source. If this method is used, tight controls must be4809 placed on the process used to perform this function to prevent exposure or intentional4810 duplication of the EK. Since the revocation and re-creation of the EK are functions intended4811 to be performed after the TPM leaves the trusted manufacturing process, squiring of the EK4812 must be disallowed if the revoke trust command is executed.4813 End of informative comment4814 1. The TPM MUST not allow both the TPM_CreateRevocableEK and the4815 TPM_CreateEndorsementKeyPair functions to be operational.4816 2. After an EK is created the TPM MUST NOT allow a new EK to be "squirted" for the4817 lifetime of the TPM.4818 3. The EK Credential MUST provide an indication within the EK Credential as to how the4819 EK was created. The valid permutations are:4820 a. Squirted, non-revocable4821 b. Squirted, revocable4822 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 160 Revision 94 29 March 2006 TCG Published c. Internally generated, non-revocable4823 d. Internally generated, revocable4824 4. If the method for creating the EK during manufacturing is squiring the EK may be either4825 non-revocable or revocable. If it is revocable, the method must provide the insertion or4826 extraction of the EKreset value.4827 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 161 TCG Published 39. Mandatory and Optional Functional Blocks4828 Start of informative comment4829 This section lists the main functional blocks of a TPM (in arbitrary order), states whether4830 that block is mandatory or optional in the main TPM specification, and provides brief4831 justification for that choice.4832 Important notes:4833 1. The default classification of a TPM function block is "mandatory", since reclassification4834 from mandatory to optional enables the removal of a function from existing4835 implementations, while reclassification from optional to mandatory may require the addition4836 of functionality to existing implementations.4837 2. Mandatory functions will be reclassified as optional functions if those functions are not4838 required in some particular type of TCG trusted platform.4839 3. If a functional block is mandatory in the main specification, the functionality must be4840 present in all TCG trusted platforms.4841 4. If a functional block is optional in the main specification, each individual platform-4842 specific specification must declare the status of that functionality as either (1) "mandatory-4843 specific" (the functionality must be present in all platforms of that type), or (2) "optional-4844 specific" (the functionality is optional in that type of platform), or (3) "excluded-specific" (the4845 functionality must not be present in that type of platform).4846 End of informative comment4847 Classification of TPM functional blocks4848 1. Legacy (v1.1b) features4849 a. Anything that was mandatory in v1.1b continues to be mandatory in v1.2. Anything4850 that was optional in v1.1b continues to be optional in v1.2.4851 b. V1.2 must be backwards compatible with v1.1b. All TPM features in v1.1b were4852 discussed in depth when v1.1b was written, and anything that wasn't thought4853 strictly necessary was tagged as "optional".4854 2. Number of PCRs4855 a. The platform specific specification controls the number of PCR on a platform. The4856 TPM MUST implement the mandatory number of PCR specified for a particular4857 platform4858 i. TPMs designed to work on multiple platforms MUST provide the appropriate4859 number of TPM for all intended platforms. I.e. if one platform requires 16 PCR4860 and the other platform 24 the TPM would have to supply 24 PCR.4861 b. For TPMs providing backwards compatibility with 1.1 TPM on the PC platform, there4862 MUST be 16 static PCR.4863 3. Sessions4864 a. The TPM MUST support a minimum of 3 active sessions4865 i. Active means currently loaded and addressable inside the TPM4866 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 162 Revision 94 29 March 2006 TCG Published ii. Without 3 active sessions many TPM commands cannot function4867 b. The TPM MUST support a minimum of 16 concurrent sessions4868 i. The contextList of currently available session has a minimum size of 164869 ii. Providing for more concurrent sessions allows the resource manager additional4870 flexibility and speed4871 4. NVRAM4872 a. There are 20 bytes mandatory of NVRAM in v1.2 as specified by the main4873 specification. A platform specific specification can require a larger amount of NVRAM4874 b. Cost is important. The mandatory amount of NVRAM must be as small as possible,4875 because different platforms will require different amounts of NVRAM. 20 bytes are4876 required for (DIR) backwards compatibility with v1.1b.4877 5. New key types4878 a. The new signing keys are mandatory in v1.2 because they plug a security hole.4879 6. Direct Anonymous Attestation4880 a. This is optional in v1.24881 b. Cost is important. The DAA function consumes more TPM resources than any other4882 TPM function, but some platform specific specifications (some servers, for example)4883 may have no need for the anonymity and pseudonymity provided by DAA.4884 7. Transport sessions4885 a. These are mandatory in v1.2.4886 b. Transport sessions4887 i. Enable protection of data submitted to a TPM and produced by a TPM4888 ii. Enable proof of the TPM commands executed during an arbitrary session.4889 8. Resettable Endorsement Key4890 a. This is optional in v1.24891 b. Cost is important. Resettable EKs are valuable in some markets segments, but cause4892 more complexity than non-resettable EKs, which are expected to be the dominant4893 type of EK4894 9. Monotonic Counter4895 a. This is mandatory in v1.24896 b. A monotonic counter is essential to enable software to defeat certain types of attack,4897 by enabling it to determine the version (revision) of dynamic data.4898 10.Time Ticks4899 a. This is mandatory in v1.24900 b. Time stamping is a function that is potentially beneficial to both a user and system4901 software.4902 11.Delegation (includes DSAP)4903 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 163 TCG Published a. This is mandatory in v1.24904 b. Delegation enables the well-established principle of least privilege to be applied to4905 Owner authorized commands.4906 12.GPIO4907 a. This is optional in v1.24908 b. Cost is important. Not all types of platform will require a secure intra-platform4909 method of key distribution4910 13.Locality4911 a. The use of locality is optional in v1.24912 b. The structures that define locality are mandatory4913 c. Locality is an essential part of many (new) TPM commands, but the definition of4914 locality varies widely from platform to platform, and may not be required by some4915 types of platforms.4916 d. It is mandatory that a platform specific specification indicate the definitions of4917 locality on the platform. It is perfectly reasonable to only define one locality and4918 ignore all other uses of locality on a platform4919 14.TPM-audit4920 a. This is optional in v1.24921 b. Proper TPM-audit requires support to reliably store logs and control access to the4922 TPM, and any mechanism (an OS, for example) that could provide such support is4923 potentially capable of providing an audit log without using TPM-audit. Nevertheless,4924 TPM-audit might be useful to verify operation of any and all software, including an4925 OS. TPM-audit is believed to be of no practical use in a client, but might be valuable4926 in a server, for example.4927 15.Certified Migration4928 a. This is optional in v1.24929 b. Cost is important. Certified Migration enables a business model that may be4930 nonsense for some platforms.4931 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 164 Revision 94 29 March 2006 TCG Published 40. Optional Authentication Encryption4932 Start of informative comment4933 The standard authorization encryption mechanism is to use XOR. This is sufficient for4934 almost all use models. There may be additional use models where a different encryption4935 mechanism would be beneficial. This section adds an optional encryption mechanism for4936 those authorizations.4937 The encryption algorithm is either AES or 3DES. The key and IV for the encryption uses the4938 shared secret generated with the OSAP session.4939 End of informative comment4940 1. The TPM MAY support AES or 3DES encryption of AuthData secrets4941 a. Encrypted AuthData values occur in the following commands4942 i. TPM_CreateWrapKey4943 ii. TPM_ChangeAuth4944 iii. TPM_ChangeAuthOwner4945 iv. TPM_Seal4946 v. TPM_Sealx4947 vi. TPM_MakeIdentity4948 vii.TPM_CreateCounter4949 viii. TPM_CMK_CreateKey4950 ix. TPM_NV_DefineSpace4951 x. TPM_Delegate_CreateKeyDelegation4952 xi. TPM_Delegate_CreateOwnerDelegation4953 2. The user indicates the use of the optional encryption by using a different entity type4954 during the OSAP session creation.4955 a. The upper byte of the entity type indicates the encryption algorithm.4956 b. The TPM internally stores the encryption indication as part of the session and4957 enforces the encryption choice on all subsequent uses of the session.4958 c. When TPM_ENTITY_TYPE is used for ordinals other than TPM_OSAP or TPM_DSAP4959 (i.e., for cases where there is no ADIP encryption action), the TPM_ENTITY_TYPE4960 upper byte MUST be 0x00.4961 3. If TPM_PERMANENT_FLAGS -> FIPS is TRUE4962 a. Then all encrypted authorizations MUST use AES4963 4. The key for the encryption algorithm is the OSAP shared secret.4964 a. For AES128, the key is the first 16 bytes of the OSAP shared secret4965 i. There is no support for AES keys greater than 1284966 5. The IV is SHA-1 of (authLastNonceEven || nonceOdd)4967 TPM Main Part 1 Design Principles TCG Copyright Specification Version 1.2 Revision 94 29 March 2006 165 TCG Published a. For AES128, use the first 16 bytes of the IV4968 i. TPM_CreateWrapKey also uses nonceOdd for the IV4969 Copyright TCG TPM Main Part 1 Design Principles Specification Version 1.2 166 Revision 94 29 March 2006 TCG Published 41. 1.1a and 1.2 Differences4970 Start of informative comment4971 All 1.2 TPM commands are completely compliant with 1.1b commands with the following4972 known exceptions.4973 1. TSC_PhysicalPresence does not support configuration and usage in a single step.4974 2. TPM_GetPubKey is unable to read the SRK unless TPM_PERMANENT_FLAGS ->4975 readSRKPub is TRUE4976 3. TPM_SetTempDeactivated now requires either physical presence or TPM Operators4977 authorization to execute4978 4. TPM_OwnerClear does not modify TPM_PERMANENT_DATA -> authDIR[0].4979 End of informative comment4980