You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: examples/attestation/README.md
+2-6Lines changed: 2 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,6 +12,8 @@ Complete list of the required examples is shown below:
12
12
*`./examples/attestation/activate_credential`: Used by a client to decrypt the challenge and respond
13
13
*`./examples/keygen/keygen`: Used to create a primary key(PK) and attestation key(AK)
14
14
15
+
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.
16
+
15
17
## Technology introduction
16
18
17
19
Remote Attestation is the process of a client providing an evidence to an attestation server that verifies if the client is in a known state.
@@ -41,7 +43,6 @@ Note:
41
43
Using the `keygen` example we can create the necessary TPM 2.0 Attestation Key and TPM 2.0 Primary Storage Key that will be used as a Primary Attestation Key(PAK).
42
44
43
45
```
44
-
45
46
$ ./examples/keygen/keygen -rsa
46
47
TPM2.0 Key generation example
47
48
Key Blob: keyblob.bin
@@ -53,15 +54,13 @@ RSA AIK template
53
54
Creating new RSA key...
54
55
Created new key (pub 280, priv 222 bytes)
55
56
Wrote 508 bytes to keyblob.bin
56
-
57
57
```
58
58
59
59
### Make Credential Example Usage
60
60
61
61
Using the `make_credential` example an attestation server can generate remote attestation challenge. The secret is 32 bytes of randomly generated seed that could be used for a symmetric key in some remote attestation schemes.
62
62
63
63
```
64
-
65
64
$ ./examples/attestation/make_credential
66
65
Using default values
67
66
Demo how to create a credential blob for remote attestation
@@ -72,7 +71,6 @@ Reading the private part of the key
72
71
AK loaded at 0x80000001
73
72
TPM2_MakeCredential success
74
73
Wrote credential blob and secret to cred.blob, 514 bytes
75
-
76
74
```
77
75
78
76
The transfer of the PAK and AK public parts between the client and attestation server is not part of the `make_credential` example, because the exchange is implementation specific.
@@ -82,7 +80,6 @@ The transfer of the PAK and AK public parts between the client and attestation s
82
80
Using the `activate_credential` example a client can decrypt the remote attestation challenge. The secret will be exposed in plain and can be exchanged with the attestation server.
83
81
84
82
```
85
-
86
83
$ ./examples/attestation/activate_credential
87
84
Using default values
88
85
Demo how to create a credential blob for remote attestation
Read credential blob and secret from cred.blob, 514 bytes
99
96
TPM2_ActivateCredential success
100
-
101
97
```
102
98
103
99
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.
0 commit comments