enrollz_and_attestz - openconfig/featureprofiles GitHub Wiki
In TPM enrollment workflow the switch owner verifies device's Initial Attestation Key (IAK) and Initial DevID (IDevID) certificates (signed by the switch vendor CA) and installs/rotates owner IAK (oIAK) and owner IDevID (oIDevID) certificates (signed by switch owner CA). In TPM attestation workflow switch owner verifies that the device's end-to-end boot state (bootloader, OS, secure boot policy, etc.) matches owner's expectations.
Test should verify all success and failure/corner-case scenarios for TPM enrollment and attestation workflows that are specified in attestz Readme.
TPM enrollment workflow consists of two APIs defined in openconfig/attestz/blob/main/proto/tpm_enrollz.proto: GetIakCert
and RotateOIakCert
.
TPM attestation workflow consists of a single API defined in openconfig/attestz/blob/main/proto/tpm_attestz.proto: Attest
.
The tests should comprehensively cover the behavior for all three APIs when used both separately and sequentially.
Finally, the tests should cover both initial install/bootstrapping, oIAK/oIDevID rotation and post-install re-attestation workflows.
- Switch vendor provisioned the device with IAK and IDevID certs following TCG spec Section 5.2 and Section 6.2.
- The device successfully completed the bootz workflow where it obtained and applied all configurations/credentials/certificates and booted into the right OS image.
- Device is serving
enrollz
andattestz
gRPC endpoints.
The test validates that the device completes TPM enrollment and attestation during initial device bootstrapping/install.
ID | Case | Result |
---|---|---|
attestz-1.1.1 | Successful enrollment and attestation | Device obtained oIAK and oIDevID certs, updated default SSL profile to rely on the oIDevID cert, and passed attestation for all control cards |
attestz-1.1,2 | IAK/IDevID are not present on the device |
GetIakCert fails with missing IAK/IDevID error |
attestz-1.1.3 | Bad request for GetIakCertRequest , RotateOIakCertRequest and AttestRequest . Examples: ControlCardSelection control_card_selection is not specified or control_card_id.role = 0 . Invalid control_card_id.serial or control_card_id.slot
|
GetIakCert , RotateOIakCert and Attest fail with detailed invalid request error |
attestz-1.1.4 | Store oIAK/oIDevId certs that have different underlying IAK/IDevID pub keys or intended for other control card |
RotateOIakCert fails with detailed invalid request error |
attestz-1.1.5 |
enrollz workflow followed by a device reboot still results in a successful attestz workflow |
Device obtained oIAK and oIDevID certs and passed attestation for all control cards |
attestz-1.1.6 | Full factory reset of the device after a successful enrollz workflow deletes oIAK and oIDevID certs, but does not affect IAK and IDevID certs |
After factory reset the device fails to perform attestz workflow due to missing oIAK and oIDevID certs |
attestz-1.1.7 | Out of bound or repeated pcr_indices in AttestRequest
|
Attest fails with detailed invalid request error |
attestz-1.1.8 | RMA scenarios where an active control card ensures that a newly inserted standby control card completes TPM enrollment and attestation before obtaining its own set of owner-issued production credentials/certificates (no sharing of owner-issued production security artifacts is allowed between control cards) |
attestz on a newly inserted control card fails before the card successfully completes TPM enrollment workflow; all RPCs relying on owner-issued credentials/certs fail on a newly inserted control card before the card successfully completes TPM enrollment and attestation workflows |
attestz-1.1.9 | Regardless of which control card was active during enrollz , both control cards should be able to successfully complete attestz workflow as active control cards |
Device obtained oIAK and oIDevID certs and passed attestation for all control cards |
- Call
GetIakCert
for an active control card with correctControlCardSelection
. - Verify that correct IDevID cert was used for establishing TLS session:
- Cert structure matches TCG specification Section 8.
- Cert is not expired.
- Cert is signed by switch vendor CA.
- Cert is tied to the active control card.
- Verify IAK cert:
- Cert structure matches TCG spec (similar to IDevID above).
- Cert is not expired.
- Cert is signed by switch vendor CA.
- Cert is tied to the active control card.
- IAK and IDevID cert contain the same device serial number field.
- Verify that the device returned the correct
ControlCardVendorId
with all fields populated. - Issue owner IAK (oIAK) and owner IDevID (oIDevID) certs, which are based on the same underlying public keys, have the same structure and fields, but are signed by a different - owner - CA.
- Call
RotateOIakCert
to store newly issued oIAK and oIDevID certs and verify successful response. - Call
GetIakCert
for a standby control card with correctControlCardSelection
. - Repeat step (2) (TLS session will be secured by active control card's IDevID) and verify IDevID cert of standby control card was specified in the response payload.
- Repeat steps (3-6) for the standby control card.
- Call
Attest
for active control card with correctControlCardSelection
, random nonce, hash algo of choice (all should be supported and tested) and all PCR indices. - Verify that the correct oIDevID cert was used for establishing TLS session.
- Verify that the device returned the correct
ControlCardVendorId
with all fields populated. - Verify oIAK cert is the same as the one installed earlier.
- Verify all
pcr_values
match expectations. - Verify
quote_signature
signature with oIAK cert. - Use
pcr_values
andquoted
to recompute PCR Quote digest and verify that it matches the one used inquote_signature
. - Call
Attest
for standby control card with correctControlCardSelection
, random nonce, hash algo of choice (all should be supported and tested) and all PCR indices. - Verify that the oIDevID cert of active control card was used for establishing TLS session and verify that oIDevID cert of standby control card was specified in the response payload.
- Repeat steps (12-16) for the standby control card.
The test validates that the device can rotate oIAK and oIDevID certificates post-install.
ID | Case | Result |
---|---|---|
attestz-1.2.1 | Successful oIAK and oIDevID cert rotation when no owner-issued mTLS cert is available on the device | Device obtained newly-rotated oIAK and oIDevID certs and passed attestation for all control cards relying on the new oIAK and oIDevID certs |
attestz-1.2.2 | Successful oIAK and oIDevID cert rotation when owner-issued mTLS cert is available on the device | Device obtained newly-rotated oIAK and oIDevID certs and passed attestation for all control cards relying on the new oIAK and previously owner-issued mTLS cert |
attestz-1.2.3 | Device is unable to authenticate switch owner (e.g. no suitable TLS trust bundle) during oIAK/oIDevID rotation | Both GetIakCert and RotateOIakCert return authentication failure error |
- Execute "Initial Install" workflow.
- Issue new oIAK and oIDevID certs for active control card, call
RotateOIakCert
to store those on the right card and verify successful response. - Issue new oIAK and oIDevID certs for standby control card, call
RotateOIakCert
to store those on the right card and verify successful response. - Call
Attest
for active and standby control cards and ensure they use the latest oIAK for attestation and, if there is no owner-provisioned TLS cert installed, use latest oIDevID for TLS session. - Do the same verification of attestation responses as in "Initial Install" workflow.
The test validates that the device completes TPM attestation after initial bootstrapping when the device is already handling production traffic and has already been provisioned with oIAK cert and owner-issued mTLS credentials/certs to communicate with owner infrastructure.
ID | Case | Result |
---|---|---|
attestz-1.3.1 | Successful post-install re-attestation relying an owner-issued mTLS cert | Device passed attestation for all control cards relying on the latest oIAK and mTLS certs |
attestz-1.3.2 | Two re-attestations separated by a device reboot result in the same PCR values, but different PCR Quote (due a different random nonce in AttestRequest ) |
Device passed multiple re-attestations separated by a reboot for all control cards relying on the latest oIAK and mTLS certs |
attestz-1.3.2 | When an active control card becomes unavailable, standby control card becomes active and can successfully complete re-attestation | Standby control card passed re-attestation after an active control card failure, relying on the latest oIAK and mTLS certs |
attestz-1.3.3 | Device is unable to authenticate switch owner (e.g. no suitable TLS trust bundle) during attestation |
Attest returns authentication failure error |
- Execute "Initial Install" workflow.
- Provision the device with switch owner mTLS credentials (separate key pair and cert for each control card).
- Call
Attest
for active and standby control cards and ensure they use the new mTLS cert for TLS connection and the latest oIAK for attestation. - Do the same verification of attestation responses as in "Initial Install" workflow.
TODO: Update the Paths and RPCs used.
rpcs:
gnmi:
gNMI.Subscribe: