Intel® Software Guard Extensions (Intel® SGX) is designed with an update mechanism which allows Intel to address security issues that might arise in the future. Intel also provides a mechanism for a client to cryptographically prove that these updates—a process referred to as a Trusted Compute Base (TCB) Recovery—have taken place. During an Intel SGX remote attestation, the client’s quote is signed based on a known TCB and the relying party uses this collateral to determine whether a client is current on security patches as of a certain date, out of date, or current but running with a sub-optimal security configuration. This TCB status provides information that helps the relying party determine whether it should trust the attesting platform.
Understanding Grace Periods
The early releases of Intel SGX used attestation based on the Enhanced Privacy ID, or EPID. In the EPID model, the relying party sent quotes to the Intel Attestation Service (IAS) for verification, and IAS would respond with the client’s TCB status. As new updates were released, the TCB verification collateral was changed for each attesting platform, and an unpatched system’s TCB would change from “up to date” to a response indicating it was not.
One issue with this model, however, was that clients were anonymous and thus not necessarily under the control of the service provider. Immediately changing the TCB status to “out of date” when security updates were released could potentially deny service to large swaths of attesting platforms who simply had not had an opportunity to update their systems. To minimize this impact, Intel’s attestation service implemented a grace period for TCB Recovery events. This grace period gave attesting platforms a fixed amount of time to update their systems before they would be declared “out of date.”
Issues with the EPID Attestation Grace Period
While the grace period for EPID attestations was largely seen as a positive feature, there were several issues with it that could not be resolved under the EPID model. The largest of these was that only one policy for attestation applied to all relying parties because all EPID attestations required the Intel Attestation Service. Some software vendors wanted longer grace periods, some wanted shorter periods, some wanted no grace period whatsoever, and some wanted the grace period to vary based on the service they were providing. IAS could not reasonably implement multiple policies, so Intel chose a default grace period that was satisfactory to most vendors. Based on vendor demand, Intel is introducing a mechanism through which vendors who require earlier access to the updated attestation response will have a means to do so via the use of optional “update” URL parameters. The earliest possible access is public disclosure, and further details can be found in the Attestation Service for Intel SGX API Documentation.
ECDSA Attestation and Intel SGX Data Center Attestation Primitives (Intel® DCAP)
With Intel Data Center Attestation Primitives (Intel® DCAP), software vendors have more control of the attestation process. Instead of contacting an Intel service for quote verification, the relying party or enterprise obtains the verification collateral for platforms in their environment and uses this collateral to perform quote verification directly. Through the Intel® Provisioning Certification Service (Intel® PCS), updated signing and verification collateral will be available 12 months after public disclosure, but can be obtained as early as the day of public disclosure via the use of optional “update” URL parameters. Further details can be found in the API Documentation.
Implementing Grace Periods in Intel DCAP
There are two basic strategies for implementing grace periods:
- Delay verification collateral cache updates
- Use optional functionality built into the Intel® Software Guard Extensions ECDSA Quote Verification library (Intel® SGX ECDSA Quote Verification Library)
Details of these approaches are outlined in sections below.
Alternatively, Intel provides guidance to the ecosystem via this Trusted Computing Base Recovery technical article. Refer to the section “Guidance to Maintain Good Security Posture,” and specifically the custom appraisal policy setup options, which can be used to implement various forms of grace period.
Delay verification collateral cache updates
The first, and easiest method is to download the verification collateral from Intel but not immediately load it into the caching service’s database (the Intel SGX® Provisioning Certification Caching Service, if you are using Intel’s reference components). The grace period would be the delay between when the verification collateral changes as a result of a security update and when it’s loaded into the caching service.
Note that all verification collateral comes with an expiration date (commonly 30 days). The maximum length for the grace period using this method is equivalent to the period of time when the new verification collateral is first issued to the verification collateral expiration date (typically 30 days). The verification collateral expiration date may be extended to allow platform owners additional time to implement security updates.
Under this approach, the procedure for updating the infrastructure with a grace period is as follows:
- Update the verification collateral the day before the new verification collateral becomes available (this assumes the maximum grace period is desired). Download the TCBInfo, QEIdentity, and QvEIdentity collateral. This step is the start of the grace period.
- Update the microcode and/or Intel SGX DCAP software which was the source of the Intel SGX TCB Recovery event as time allows.
- Update the PCK certificates from the Intel PCS).
- Download the current TCBInfo, QEIdentity, and QvEIdentity collateral. This step ends the grace period.
This strategy allows environments to use the Intel reference components, but it enforces the same grace period on all workloads (limited by the expiration date of the verification collateral).
Since this approach is based on collateral updates in the caching service, it is only practical for service providers, enterprises, or similar platform owners.
Customize the Intel® SGX/Intel® TDX ECDSA Quote Verification Library
If more granular control is needed, if a grace period longer than verification collateral expiration is required, or if the service provider is not the platform owner, then grace periods can be implemented by using the functionality built into the Intel SGX/Intel® Trust Domain Extensions (Intel® TDX) ECDSA Quote Verification Library.
The sgx_qv_verify_quote() function provides an optional output parameter named p_supplemental_data and tailored policies can be created by processing the tcb_level_date_tag and tcb_eval_dataset_num members of this data structure. This would allow grace periods to be set per relying party, and even per enclave.
To create a grace period longer than verification collateral expiration, the function also supports the option to accept expired collateral. The parameter p_collateral_expiration_status will return non-zero if the collateral has expired, and this value can be ignored as needed.
For more information, see the section on verifying quotes with supplemental data in the Intel® Software Guard Extensions (Intel® SGX) Data Center Attestation Primitives: ECDSA Quote Library API.
Conclusion
Intel SGX DCAP does not define a grace period for expired collateral, but it provides mechanisms to enable them in local deployments. This allows enterprises, service providers, and even individual applications to implement, or not implement, grace periods appropriate to their needs.