-
Notifications
You must be signed in to change notification settings - Fork 62
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Added certify to attestation/README.md. Removed wolfCrypt requirement…
… on certify example.
- Loading branch information
Showing
2 changed files
with
45 additions
and
5 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -10,7 +10,8 @@ Complete list of the required examples is shown below: | |
|
||
* `./examples/attestation/make_credential`: Used by a server to create a remote attestation challenge | ||
* `./examples/attestation/activate_credential`: Used by a client to decrypt the challenge and respond | ||
* `./examples/keygen/keygen`: Used to create a primary key(PK) and attestation key(AK) | ||
* `./examples/attestation/certify`: Used to certify (attest) or prove an object with name is loaded in the TPM. | ||
* `./examples/keygen/create_primary`: Used to create a primary key(PK) and attestation key(AK) | ||
|
||
Note: All of these example allow the use of the Endorsement Key and Attestation Key under the Endorsement Hierarchy. This is done by adding the `-eh` option when executing any of the three examples above. The advantage of using EK/EH is that the private key material of the EK never leaves the TPM. Anything encrypted using the public part of the EK can be encrypted only internally by the TPM owner of the EK, and EK is unique for every TPM chip. Therefore, creating challenges for Remote Attestation using the EK/EH has greater value in some scenarios. One drawback is that by using the EK the identity of the host under attestation is always known, because the EK private-public key pair identifies the TPM and in some scenarios this might rise privacy concerns. Our remote attestation examples support both AK under SRK and AK under EK. It is up to the developer to decide which one to use. | ||
|
||
|
@@ -99,6 +100,45 @@ TPM2_ActivateCredential success | |
|
||
The transfer of the challenge response containing the secret in plain (or used as a symmetric key seed) is not part of the `activate_credential` example, because the exchange is also implementation specific. | ||
|
||
### Certify Example | ||
|
||
This example creates an RSA or ECC initial device identity and attestation identity keys. These are created under the endorsement heiracry and follow the "TPM 2.0 Keys for Device Identity and Attestation" TCG specification for setting up the primary key policies. The IDevID key can be used for signing. This example signs the IAK (attestation key) using the IDevID (device identity key). | ||
|
||
```sh | ||
% ./examples/keygen/create_primary -rsa -eh -iak -keep | ||
TPM2.0 Primary Key generation example | ||
Algorithm: RSA | ||
Unique: IAK | ||
Store Handle: 0x00000000 | ||
Use Parameter Encryption: NULL | ||
Creating new RSA primary key... | ||
|
||
% ./examples/keygen/create_primary -rsa -eh -idevid -keep | ||
TPM2.0 Primary Key generation example | ||
Algorithm: RSA | ||
Unique: IDEVID | ||
Store Handle: 0x00000000 | ||
Use Parameter Encryption: NULL | ||
Creating new RSA primary key... | ||
|
||
% ./examples/attestation/certify -rsa -certify=0x80000000 -signer=0x80000001 | ||
Certify 0x80000000 with 0x80000001 to generate TPM-signed attestation info | ||
EK Policy Session: Handle 0x3000000 | ||
TPM2_Certify complete | ||
Certify Info 172 | ||
RSA Signature: 256 | ||
|
||
% ./examples/management/flush 0x80000001 | ||
Preparing to free TPM2.0 Resources | ||
Freeing 80000001 object | ||
|
||
% ./examples/management/flush 0x80000000 | ||
Preparing to free TPM2.0 Resources | ||
Freeing 80000000 object | ||
``` | ||
|
||
For ECC use the same steps as above, but replace `-rsa` with `-ecc`. | ||
|
||
## More information | ||
|
||
Please contact us at [email protected] if you are interested in more information about Remote Attestation using wolfTPM. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters