没有合适的资源?快使用搜索试试~ 我知道了~
首页TCG TSS 2.0 ESAPI规范 v1.0 r14
TCG TSS 2.0 ESAPI规范 v1.0 r14
需积分: 1 0 下载量 47 浏览量
更新于2023-11-23
收藏 1.23MB PDF 举报
《TCG TSS ESAPI v1p0_r14_pub10012021.pdf》是一个TPM软件栈技术规范,由TCG发布。该规范版本为1.00,修订号为14,是在2021年10月1日发布的。该文件共有123页,由Trusted Computing Group版权所有。特别声明,TCG授予使用该规范中源代码的用户全球范围内的不可撤销、非排他性、免版税的版权许可,以复制、创建衍生作品、分发、展示和执行源代码及其衍生作品。
资源详情
资源推荐
Copyright © TCG 2021 TSS Enhanced System API (ESAPI) Specification Version 1.00 Revision 14
Version 1.00, Revision 14 Page 16 of 123 October 1, 2021
2 TSS Enhanced System API Overview
ESAPI Overview
The Enhanced System API (ESAPI) is an interface that is intended to sit directly above the System API.
The primary purpose of the ESAPI is to reduce the programming complexity of applications that desire to
send individual “system level” TPM calls to the TPM, but that also require cryptographic operations on the
data being passed to and from the TPM. In particular, applications that wish to utilize secure sessions to
perform Hash-based Message Authentication Code (HMAC) operations, parameter encryption, parameter
decryption, TPM command audit and TPM policy operations could benefit from using the ESAPI.
Additionally, context and object management are provided by the ESAPI.
While the ESAPI is significantly less complex to use than the System API for cryptographically protected
communications with the TPM, it still requires in-depth understanding about the interface to a TPM 2.0. It
is therefore envisioned that only expert applications will utilize the ESAPI and that typical applications
would utilize a higher-level interface such as the Feature API. It is, however, expected that Feature API
implementations would utilize the ESAPI as appropriate.
ESAPI Functional Description
The ESAPI layer of TSS 2.0 has three primary purposes:
• It provides cryptographic functionality for applications wishing to encrypt the data stream from
TSS 2.0 to the TPM (thus defeating sideband attacks involving probing of the data bus to the
TPM 2.0).
• It provides enhanced session management functionality on top of the base SAPI functionality.
• It provides 100% TPM functionality
NOTE: The FAPI layer provides only about 80% of the TPM’s functionality.
To use the ESAPI, applications (and their programmers) need to understand part 2 and part 3 of the TCG
TPM 2.0 specification. The differences between ESAPI and SAPI are as follows.
Copyright © TCG 2021 TSS Enhanced System API (ESAPI) Specification Version 1.00 Revision 14
Version 1.00, Revision 14 Page 17 of 123 October 1, 2021
There are several functions the ESAPI handles more simply (from the application’s prespective) than the
SAPI does:
• Starting and salting sessions.
• Calculating HMACs.
• Encrypting and decrypting sessions
However implementing an application to the SAPI interface has advantages for the following reasons:
• SAPI implementations have a smaller footprint primarily because they do not include
cryptographic functions.
• SAPI can be used in heapless environments.
• SAPI allows saving RAM by underallocating data structures.
ESAPI Programming Considerations
The ESAPI API has the following high level characteristics:
• The ESAPI is written in C99 to allow it to operate in the broadest range of operating systems and
to simplify the writing of language bindings to other languages (e.g. Java, Python, etc.).
• The ESAPI is designed to enable applications to send commands to the TPM using a single or
very limited number of function calls when using sessions (when compared with the SAPI).
• The ESAPI allows applications to control/set all input parameters and data elements that are
included in TPM commands, except for HMAC session calculation (e.g. nonceCaller).
• The ESAPI manages session handling:
o Session key calculation
o Session salt creation and encryption
o HMAC calculation
o Keeping track of resources’s names
o Session binding
• The ESAPI abstracts all formatting and crypto handling from the application – it is performed in
the ESAPI layer or lower.
• Additionally, the ESAPI does the following:
o HMAC (calculation/verify) with an authValue input
o Encryption/decryption of the first parameter with a key input
o Supports audit sessions
o Cryptographic flexibility/agility (e.g. The ESAPI caller can perform cryptographic
operations with SHA-1, SHA-256, various signing algorithms, various symmetric and
asymmetric cryptographic algorithms, etc.)
ESAPI implementations are not required to maintain state in global variables between calls. State
information is stored in contexts provided to the application. These ESAPI contexts are accessible
simultaneously. No two threads are allowed the same ESAPI context simultaneously. The ESAPI
supports both a synchronous and an asynchronous call model.
The ESAPI also meets the following additional low-level design requirements:
• The ESAPI mimics the TPM 2.0 specification, Part 3 command schematics as much as possible.
This helps programmers understand the code and easily correlate with the spec. Function input
and output parameters are ordered in the way they appear in the Part 3 command schematics
Copyright © TCG 2021 TSS Enhanced System API (ESAPI) Specification Version 1.00 Revision 14
Version 1.00, Revision 14 Page 18 of 123 October 1, 2021
and names match as much as possible. Additionally, the ESAPI provides functionality to
automatically setup and tear down sessions as part of a larger operation.
o ESAPI gives the application full control over all TPM 2.0 part 3 input parameters and
handles.
o The application developer calling ESAPI can get any desired TPM output parameters.
o The application developer calling ESAPI can suppress output parameters from the TPM
that are unwanted.
• Memory for ESAPI output parameters is provided by the callee (the ESAPI implementation).
• Memory for ESAPI input parameters is provided by the caller (the application using the ESAPI)
• The Enhanced System API implementation can do all the work for the caller that System API
implementations do (with greater ease of use). The following are some examples of
simplifications for the application calling the ESAPI:
o The commandSize field for all commands is calculated dynamically by the ESAPI. The
caller doesn’t have to do this.
o The ESAPI operates on complex TPM2B’s and special TPML’s (like
TPML_PCR_SELECT) the same as SAPI with regard to the size field.
o The ESAPI unmarshals output parameters into C structures before returning them to the
caller so that the caller can read fields out of them in a straightforward manner.
• The Enhanced System API implementation handles as much of the cryptographic operation and
data management related to TPM 2.0 sessions as possible. Examples of ESAPI implementation
operations include:
o Centralized management of session-related and TPM resource-related data within an
“ESAPI Object”.
o Computation of the names of TPM resources.
o Formatting and calculation of all information required to compute a command; parameter
hash (cpHash) and response parameter hash (rpHash).
o Computation of HMACs for command integrity sent to the TPM.
o Verification of response HMACs received from the TPM.
o Encryption of the first parameter of commands intended for the TPM.
o Decryption of the first parameter of responses encrypted by the TPM.
• For objects with a nameAlg digest, the Enhanced System API implementation SHALL hash
TPM2B_AUTH values with the nameAlg of the object when the length of the TPM2B_AUTH value
is greater than the length of the nameAlg digest size. This way, auth values larger than the
nameAlg hash length will work and not return TPM2_RC_AUTH_FAIL error from the TPM when
creating the object.
Marshaling/Unmarshaling Description
Marshaling and unmarshaling are required by both the SAPI and ESAPI. Rather than writing the
marshaling and unmarshalling code separately for the SAPI and ESAPI these pieces of code have been
put into a separate namespace that both the SAPI and ESAPI use. The marshaling and unmarshalling
API and header files are specified in the TSS 2.0 Marshaling/Unmarshaling API Specification.
Copyright © TCG 2021 TSS Enhanced System API (ESAPI) Specification Version 1.00 Revision 14
Version 1.00, Revision 14 Page 19 of 123 October 1, 2021
3 TSS ESAPI Use Model
Top-Level ESAPI Usage Model
The application will initialize a context, start sessions and create and load objects via the context, and
finally close the context. The following steps are taken by the caller and ESAPI to establish contexts and
sessions.
1. Application initializes an an ESAPI context
a. ESAPI uses the heap, so ESAPI will dynamically allocate memory to track the metadata it
needs for each TPM resource.
2. Application calls TPM commands and resource handling is partially automated by the ESAPI.
a. If a new resource is created by a command then the ESAPI will create a new ESYS_TR
object to track it and its metadata.
b. For static TPM resources (such as NV and persistent keys) ESYS_TR objects can also
be serialized and deserialized from disk or created directly from the TPM.
c. Application calls Esys_StartAuthSession and the ESAPI manages session metadata
such as SessionKey and NonceRolling and HMAC calculations.
3. Application flushes or closes ESYS_TR objects via ESAPI calls so ESAPI can free the allocated
memory.
a. If a TPM resource is destroyed by a command then the ESAPI will automatically free the
memory used by the object metatdata and mark the ESYS_TR object as invalid.
b. The application may close the ESYS_TR to release the memory used by the ESAPI
without affecting the resource within the TPM.
4. The application closes ESAPI context when done.
The ESAPI Context
The ESYS_CONTEXT (the ESAPI context) is an opaque structure that contains all information that the
ESAPI module needs to store between calls (so that the ESAPI doesn’t need to maintain global state
variables). The ESYS_CONTEXT contains:
• Information needed to communicate to the TPM (e.g. System API command context and TCTI
context).
• Metadata for each ESYS_TR object.
• State information about internally used libraries e.g. cryptographic libraries, and cached TPM
capabilities needed.
The memory for the ESYS_CONTEXT is allocated by the ESAPI.
The lifecycle of an ESYS_CONTEXT is briefly described as follows:
• Create an ESYS_CONTEXT using the Esys_Initialize() function.
• Create or deserialize metadata from disk storage for the session and resource information
structures.
• Use sessions and resources in TPM commands.
• Serialize resource information structures to disk.
• Close ESYS_CONTEXT with Esys_Finalize().
Copyright © TCG 2021 TSS Enhanced System API (ESAPI) Specification Version 1.00 Revision 14
Version 1.00, Revision 14 Page 20 of 123 October 1, 2021
ESAPI Resources
TPM resource metadata is stored in an opaque structure associated with an ESYS_CONTEXT,
referenced by an ESYS_TR handle. An ESYS_TR object created within one ESYS_CONTEXT can be
used only within that ESYS_CONTEXT.
The metadata for an ESYS_TR includes data like:
• The TPM handle for the resource (PCR, NV area, TPM object (key, data), hierarchy).
• The authValue of the resource, if applicable.
• The public area of the resource (TPM2B_PUBLIC or TPM2B_NV_PUBLIC).
• The resource name (can be computed from the above).
The lifecycle for an ESAPI resource is briefly described as follows:
• Create an ESYS_TR object:
o For transient TPM objects, simply call the appropriate load function (e.g. Esys_Load,
Esys_LoadExternal) and the ESAPI module creates a new ESYS_TR object.
o For persistent resources (e.g. evict keys, NV areas):
▪ Create an ESYS_TR using the Esys_TR_FromTPMPublic().
▪ Alternatively deserialize metadata from disk using Esys_TR_Deserialize().
o For TPM metaobjects (e.g. hierarchies and PCRS) each ESYS_CONTEXT contains a
preexisting singleton ESYS_TR object that can be used directly.
o Set the authValue for the resource using the Esys_TR_SetAuth() function.
• Make TPM calls referencing the resource in the handle area using the
Esys_<COMMAND_NAME>() template.
• Serialize metadata to disk (e.g. public area of NVSpace, persistent keys, etc.) using the
Esys_TR_Serialize() function.
• Destroy an ESYS_TR object:
o Flush or remove the resource from the TPM when done using e.g. Esys_FlushContext(),
Esys_NV_UndefineSpace, Esys_NV_UndefineSpaceSpecial, Esys_EvictControl,
functions.
o Close the object using Esys_TR_Close to release the metadata while leaving the
resource in the TPM.
The ESAPI Session
ESAPI session data is stored in an opaque session information structure in an ESYS_CONTEXT,
referenced by an ESYS_TR. The opaque session information structure includes the following types of
data:
• TPM handle for the session.
• Information about session attributes to use in the next command.
• Information related to the bind state and encrypted salt of the session.
• Information related to the generation and storage of the session key.
• Session nonces.
• Policy session-specific information.
剩余122页未读,继续阅读
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功