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: platform/core-concepts.mdx
+13-9Lines changed: 13 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@ This document describes the core concepts integral to the Smallstep platform.
11
11
12
12
## Device Inventory
13
13
14
-
The Smallstep **device inventory** is a canonical list of your approved devices and their hardware identifiers**.** It forms the basis of your device-based authentication policies.
14
+
The Smallstep **device inventory** is a canonical list of your approved devices and their hardware identifiers. It forms the basis of your device-based authentication policies.
15
15
16
16
In order to build an inventory, we need to understand how to identify a device, and how to bootstrap trust with devices.
17
17
@@ -100,7 +100,7 @@ Here’s a typical step-by-step bootstrapping and enrollment workflow on a devic
100
100
5. The agent requests a device attestation certificate from Smallstep’s Attestation CA. The Attestation CA verifies that the request is coming from a device in your inventory where the Endorsement Key (EK) is resident.
101
101
6. Upon successful verification, the Smallstep Attestation CA signs an Attestation Certificate for the agent. This Attestation Certificate is used for remote key attestation.
102
102
7. The agent uses the Attestation certificate to complete an ACME `device-attest-01` challenge from the **Smallstep Agent CA** to obtain a Smallstep **device certificate**. The device certificate cryptographically proves both the identity of the device and the hardware binding of the private key.
103
-
8. Finally, the agent uses the device certificate to enroll short-lived client credentials needed for accessing protected resources. These come from the **Smallstep Account CA** or the **Smallstep Devices CA**, depending on the use case**.**
103
+
8. Finally, the agent uses the device certificate to enroll short-lived client credentials needed for accessing protected resources. These come from the **Smallstep Account CA** or the **Smallstep Devices CA**, depending on the use case.
104
104
105
105
## Other enrollment workflows
106
106
@@ -155,7 +155,7 @@ After enrollment, the resulting device identity certificate can be used for any
155
155
156
156
Now let’s turn our attention toward the client credentials issued by Smallstep.
157
157
158
-
Smallstep [uses](https://www.notion.so/Docs-HOWTO-799081c270f24d188dd2c7966f5997ea?pvs=21) secure elements to offer the most advanced hardware key protection available today. And while secure elements are ubiquitous, application support for them is still uneven. Our goal is to smooth that out by offering the strongest key protection available for a given platform and application.
158
+
Smallstep uses secure elements to offer the most advanced hardware key protection available today. And while secure elements are ubiquitous, application support for them is still uneven. Our goal is to smooth that out by offering the strongest key protection available for a given platform and application.
159
159
160
160
Smallstep uses several private key protection levels depending on the use case, deployment method, and operating system.
161
161
@@ -181,13 +181,17 @@ But, without cryptographic proof of the key’s provenance, a relying party can
181
181
182
182
To support some applications on Apple platforms, our agent can emulate TPM remote key attestation. We use a process similar to the Trusted Computing Group’s remote attestation process. This is not device attestation, however.
183
183
184
-
For this workflow, the Smallstep agent creates a key pair, gets a challenge from the attestation authority, activates the credential in the secure element, and proves that the secure element is in possession of the key by having it sign over a challenge. Finally, we send the signed challenge to the Smallstep CA, which is able to issue a cert.
184
+
Here's the workflow:
185
+
1. The Smallstep agent creates a key pair. The private key is generated in the Secure Enclave, and the public key is sent to the Smallstep attestation authority.
186
+
2. The attestation authority responds with an encrypted secret that can only be decrypted using the private key.
187
+
3. The Smallstep agent then proves to the attestation authority that is in possession of the private key by sending the decrypted secret.
188
+
4. Finally, the attestation authority returns a signed attestation certificate.
185
189
186
-
This attests that the client is in possession of the key, but it does not prove that the key is stored in a genuine Apple Secure Enclave.
190
+
This certificate attests that the client is in possession of the private key, but it cannot prove that the key is stored in a genuine Apple Secure Enclave.
187
191
188
-
Locally, with a CLI tool, it’s possible to confirm that the key the CA has issued a certificate for is stored in the Secure Enclave on the device.
192
+
Locally, with a CLI tool, it’s possible to confirm that the key the CA has issued a certificate for matches the private key protected by the Secure Enclave.
189
193
190
-
This is the lowest level of key protection that Smallstep offers, and it’s only used for applications and use cases that do not support anything stronger. It increases attack cost to a level that is sufficient for some use cases, but its easier to bypass in practice than hardware attestations.
194
+
This is the lowest level of key protection that Smallstep offers, and it’s only used for applications and use cases that do not support anything stronger. It increases attack cost to a level that is sufficient for some use cases. But in practice, its easier to bypass than hardware attestations.
191
195
192
196
This protection level depends on trusted compute primitives available on some platforms (e.g., system integrity protection, binary authorization).
193
197
@@ -223,7 +227,7 @@ These provisioned credentials are short-lived. Their key attestation level varie
0 commit comments