如何确保在 TPM 内部创建密钥？
How to ensure that keys are created inside TPM?
我需要
- 运行 客户端计算机上的 .exe，它将在 TPM 中创建密钥对。
- 然后我将使用 TPM 生成的密钥对的 public 密钥部分创建 CSR。
我担心的是如何确保密钥是在 TPM 内部创建的，而不是由欺骗性 TPM 创建的。这将使私钥能够被迁移和复制。
我听说这就是 AIK 的用途，但我不明白这如何防止 TPM 被欺骗？
我能想到的一个解决方案是：我转到客户端，从受信任的 USB 启动 OS，然后获取 EKpub。
证明密钥源自 TPM 的过程称为：
- 对于 TPM 2.0：凭据激活，通过
TPM2_ActivateCredential 强制执行
- 对于 TPM 1.2：身份激活，通过
TPM_ActivateIdentity 强制执行
这项技术完成了很多事情，但其中之一是证明在向 TPM 发出请求后生成的密钥实际上来自受信任的 TPM，并且没有被欺骗。对于 TPM 1.2，因为这就是问题所在，身份激活是一个 8 步过程，如下所示（以下是 TCG AIK Certificate Enrollment 的摘录）：
Step 1: Platform asks the TPM to create the AIK key pair.
- (a) The platform (or application software on the platform) issues to the TSS the
CollateIdentityRequest command. In turn the TSS
issues the MakeIdentity command to the TPM. This results in the TPM
generating a fresh AIK public key pair.
- (b) Within the
MakeIdentity function the TPM creates the IDENTITY_CONTENTS structure containing the following items: (i) The
structure version, (ii) TPM command ordinal, (iii) PrivCADigest
label and (iv) AIK_pub_key.
- (c) The TPM signs
IDENTITY_CONTENTS structure using the AIK_priv_key, with the resulting signature portion being referred to
as the identityBinding.
- (d) The TPM outputs two (2) items as a result of the
MakeIdentity command: AIK_pub_key and the identityBinding.
Step 2: TSS produces proof structure concerning the AIK
- (a) Following from the previous step, the TSS creates the
IDENTITY_PROOF structure. This structure consists of the following
items: (i) The identityBinding structure from Step 1(d). (Note: The
identityBinding structure is the signature portion only over the
IDENTITY_CONTENTS structure). Note: It must be noted that the
identityBinding structure is NOT cryptographic proof that the AIK is
a TPM-resident key and that the AIK has been certified using the EK.
It only demonstrates that some key pair exists. (ii) The TPM spec
version (iii) The SubjectPublicKeyInfo (i.e. the AIK_pub_key) (iv)
The IdentityLabel (v) EK certificate (vi) Platform certificate
- (b) The TSS then generates a symmetric key
K1 (local random number from the TPM) and encrypts the IDENTITY_PROOF structure using
this symmetric key K1.
- (c) The TSS then encrypts key
K1 using the public key of the ACA. This encryption using public-key of the Attestation CA is
intended to limit disclosure of K1 to the ACA only. The results of
this step are two items: the encrypted IDENTITY_PROOF structure and
the encrypted symmetric key K1. Encrypted IDENTITY_PROOF and
encrypted K1 are bundled into an IDENTITY_REQ structure that
includes identifiers for the symmetric and asymmetric algorithms used
to encrypt the structures plus sizes of the encrypted structures.
- Step 3: Platform sends AIK certificate request to the ACA. The platform (or application software on the platform) takes the
IDENTITY_REQ resulting from the previous step, encrypts it, and
sends it to the ACA.
- Step 4: ACA verifies certificate request. Upon receiving the certificate request, the ACA must perform a number of verifications.
- (a) To get access to the AIK certificate request structure, ACA must first decrypt the key
K1 using its ACA private key.
- (b) The ACA then uses
K1 to decrypt the IDENTITY_PROOF structure.
- (c) The ACA must then recreate the
IDENTITY_CONTENTS structure and verify that the signature (as represented by the received
identityBinding) is correct. The ACA can perform the verification
because it now has the items listed in Step 2 above and can assemble
the same PrivCADigestLabel as was provided to the TPM. As part of
the verification, the ACA is expected to validate the received
certificates (ie. EK and Platform Certificates). It is expected that
the ACA will use standard X.509 certificate validation techniques,
such as CRL checking [14] and/or querying the appropriate OCSP
responders [15] to the issuer of the EK certificate (e.g. TPM
manufacturer site).
- Step 5: ACA issues a new AIK certificate. The ACA then creates a new AIK certificate, using (as the public key) the received AIK public
key in the previous step. The ACA issues (signs) the new AIK
certificate using its own AIK signing key.
- Step 6: ACA encrypts the new AIK certificate. In this phase, the ACA must prepare the newly issued AIK certificate in a form
recognizable by the TPM. As part of the
TPM_ActivateIdentity command
(Section 15.2 of [5]), the TPM expects input in the TPM_EK_BLOB or
the (older spec version) ASYM_CA_CONTENTS structure. The ACA
performs the following tasks:
- (a) The ACA generates a random symmetric encryption key
K2. This random K2 is unique for each AIK certificate request.
- (b) The ACA encrypts the new AIK certificate using key
K2.
- (c) The ACA then creates either a
TPM_EK_BLOB or ASYM_CA_CONTENTS (depending on the TPM version) structure which
contains the following: (i) The hash of the AIK public key (namely the
AIK public key as found in the original request). (ii) The symmetric
key K2. (iii) Optional PCR information – for TPM_EK_BLOB only. The
TPM checks to ensure that the TPM PCR’s and locality are in the
correct state as anticipated by the ACA to unlock K2.
- (d) The ACA encrypts the
TPM_EK_BLOB or ASYM_CA_CONTENTS structure using the EK public key (as found in the EK certificate in
the original request). The purpose of the last step is to ensure that
only the same requesting TPM will be the sole entity that can decrypt
the newly issued AIK certificate, since only that TPM possesses the EK
private key (which is a TPM-resident key).
- Step 7: ACA delivers the new AIK certificate to the TPM on the Platform. The ACA then delivers the encrypted result (encrypted AIK
certificate + either the blob or ASYM struct) to the requestor
platform/TPM.
- Step 8: Decryption of new AIK certificate by the TPM. Upon receiving the (encrypted) AIK certificate from the ACA, the platform
must input the structure (either the blob or ASYM struct) (into the
TPM and activate it using the TSS
Tspi_TPM_ActivateIdentity command.
This command decrypts the (encrypted) symmetric key K2 from the ACA
using the EK-private-key (which resides only in the TPM) after
ensuring an AIK with a matching pub key resides in the TPM. It then
uses the symmetric key K2 to decrypt the AIK certificate.
这里的关键部分是倒数第二句：
This command decrypts the (encrypted) symmetric key K2 from the ACA
using the EK-private-key (which resides only in the TPM) after
ensuring an AIK with a matching pub key resides in the TPM.
规范强制要求 EK 不会解密 TPM_EK_BLOB 对象，除非在 TPM 中找到请求激活的私钥。并且由于对象是在不使用 TPM 机密的情况下由 TSS 加密的，并且您已经验证了制造商 CA 证书链上的 EK public 密钥，因此可以确保请求身份激活的密钥源自于由可信实体制造的 TPM。
我需要
- 运行 客户端计算机上的 .exe，它将在 TPM 中创建密钥对。
- 然后我将使用 TPM 生成的密钥对的 public 密钥部分创建 CSR。
我担心的是如何确保密钥是在 TPM 内部创建的，而不是由欺骗性 TPM 创建的。这将使私钥能够被迁移和复制。
我听说这就是 AIK 的用途，但我不明白这如何防止 TPM 被欺骗？
我能想到的一个解决方案是：我转到客户端，从受信任的 USB 启动 OS，然后获取 EKpub。
证明密钥源自 TPM 的过程称为：
- 对于 TPM 2.0：凭据激活，通过
TPM2_ActivateCredential 强制执行
- 对于 TPM 1.2：身份激活，通过
TPM_ActivateIdentity 强制执行
这项技术完成了很多事情，但其中之一是证明在向 TPM 发出请求后生成的密钥实际上来自受信任的 TPM，并且没有被欺骗。对于 TPM 1.2，因为这就是问题所在，身份激活是一个 8 步过程，如下所示（以下是 TCG AIK Certificate Enrollment 的摘录）：
Step 1: Platform asks the TPM to create the AIK key pair.
- (a) The platform (or application software on the platform) issues to the TSS the
CollateIdentityRequestcommand. In turn the TSS issues theMakeIdentitycommand to the TPM. This results in the TPM generating a fresh AIK public key pair.- (b) Within the
MakeIdentityfunction the TPM creates theIDENTITY_CONTENTSstructure containing the following items: (i) The structure version, (ii) TPM command ordinal, (iii)PrivCADigestlabel and (iv)AIK_pub_key.- (c) The TPM signs
IDENTITY_CONTENTSstructure using theAIK_priv_key, with the resulting signature portion being referred to as theidentityBinding.- (d) The TPM outputs two (2) items as a result of the
MakeIdentitycommand:AIK_pub_keyand theidentityBinding.Step 2: TSS produces proof structure concerning the AIK
- (a) Following from the previous step, the TSS creates the
IDENTITY_PROOFstructure. This structure consists of the following items: (i) TheidentityBindingstructure from Step 1(d). (Note: TheidentityBindingstructure is the signature portion only over theIDENTITY_CONTENTSstructure). Note: It must be noted that theidentityBindingstructure is NOT cryptographic proof that the AIK is a TPM-resident key and that the AIK has been certified using the EK. It only demonstrates that some key pair exists. (ii) The TPM spec version (iii) TheSubjectPublicKeyInfo(i.e. theAIK_pub_key) (iv) TheIdentityLabel(v) EK certificate (vi) Platform certificate- (b) The TSS then generates a symmetric key
K1(local random number from the TPM) and encrypts theIDENTITY_PROOFstructure using this symmetric keyK1.- (c) The TSS then encrypts key
K1using the public key of the ACA. This encryption using public-key of the Attestation CA is intended to limit disclosure ofK1to the ACA only. The results of this step are two items: the encryptedIDENTITY_PROOFstructure and the encrypted symmetric keyK1. EncryptedIDENTITY_PROOFand encryptedK1are bundled into anIDENTITY_REQstructure that includes identifiers for the symmetric and asymmetric algorithms used to encrypt the structures plus sizes of the encrypted structures.- Step 3: Platform sends AIK certificate request to the ACA. The platform (or application software on the platform) takes the
IDENTITY_REQresulting from the previous step, encrypts it, and sends it to the ACA.- Step 4: ACA verifies certificate request. Upon receiving the certificate request, the ACA must perform a number of verifications.
- (a) To get access to the AIK certificate request structure, ACA must first decrypt the key
K1using its ACA private key.- (b) The ACA then uses
K1to decrypt theIDENTITY_PROOFstructure.- (c) The ACA must then recreate the
IDENTITY_CONTENTSstructure and verify that the signature (as represented by the receivedidentityBinding) is correct. The ACA can perform the verification because it now has the items listed in Step 2 above and can assemble the samePrivCADigestLabelas was provided to the TPM. As part of the verification, the ACA is expected to validate the received certificates (ie. EK and Platform Certificates). It is expected that the ACA will use standard X.509 certificate validation techniques, such as CRL checking [14] and/or querying the appropriate OCSP responders [15] to the issuer of the EK certificate (e.g. TPM manufacturer site).- Step 5: ACA issues a new AIK certificate. The ACA then creates a new AIK certificate, using (as the public key) the received AIK public key in the previous step. The ACA issues (signs) the new AIK certificate using its own AIK signing key.
- Step 6: ACA encrypts the new AIK certificate. In this phase, the ACA must prepare the newly issued AIK certificate in a form recognizable by the TPM. As part of the
TPM_ActivateIdentitycommand (Section 15.2 of [5]), the TPM expects input in theTPM_EK_BLOBor the (older spec version)ASYM_CA_CONTENTSstructure. The ACA performs the following tasks:
- (a) The ACA generates a random symmetric encryption key
K2. This randomK2is unique for each AIK certificate request.- (b) The ACA encrypts the new AIK certificate using key
K2.- (c) The ACA then creates either a
TPM_EK_BLOBorASYM_CA_CONTENTS(depending on the TPM version) structure which contains the following: (i) The hash of the AIK public key (namely the AIK public key as found in the original request). (ii) The symmetric keyK2. (iii) Optional PCR information – forTPM_EK_BLOBonly. The TPM checks to ensure that the TPM PCR’s and locality are in the correct state as anticipated by the ACA to unlockK2.- (d) The ACA encrypts the
TPM_EK_BLOBorASYM_CA_CONTENTSstructure using the EK public key (as found in the EK certificate in the original request). The purpose of the last step is to ensure that only the same requesting TPM will be the sole entity that can decrypt the newly issued AIK certificate, since only that TPM possesses the EK private key (which is a TPM-resident key).- Step 7: ACA delivers the new AIK certificate to the TPM on the Platform. The ACA then delivers the encrypted result (encrypted AIK certificate + either the blob or ASYM struct) to the requestor platform/TPM.
- Step 8: Decryption of new AIK certificate by the TPM. Upon receiving the (encrypted) AIK certificate from the ACA, the platform must input the structure (either the blob or ASYM struct) (into the TPM and activate it using the TSS
Tspi_TPM_ActivateIdentitycommand. This command decrypts the (encrypted) symmetric keyK2from the ACA using the EK-private-key (which resides only in the TPM) after ensuring an AIK with a matching pub key resides in the TPM. It then uses the symmetric keyK2to decrypt the AIK certificate.
这里的关键部分是倒数第二句：
This command decrypts the (encrypted) symmetric key K2 from the ACA using the EK-private-key (which resides only in the TPM) after ensuring an AIK with a matching pub key resides in the TPM.
规范强制要求 EK 不会解密 TPM_EK_BLOB 对象，除非在 TPM 中找到请求激活的私钥。并且由于对象是在不使用 TPM 机密的情况下由 TSS 加密的，并且您已经验证了制造商 CA 证书链上的 EK public 密钥，因此可以确保请求身份激活的密钥源自于由可信实体制造的 TPM。