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 by collateral that is tied to 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 quote and, in turn, the client.
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 information was changed for each client platform, and an unpatched client’s TCB would change from “up to date” to “out of date”.
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 users 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 clients a fixed amount of time to update their systems before they would be declared as “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 service providers 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.
ECDSA Attestation and Intel SGX DCAP
With Intel SGX DCAP, software vendors are in control of the attestation process. Instead of contacting an Intel service for quote verification, the service provider or enterprise obtains the signing and verification collateral for platforms in their environment and uses this collateral to perform quote verification on premise. However, it was IAS that implemented the EPID grace period, so one consequence of removing IAS from the quote verification procedure was that the grace period was removed with it. Solutions running in an Intel SGX DCAP environment and its ECDSA-based attestation process will find that clients are out of date the same day that a patch for their platform is released, unless publication of the refreshed verification collateral that includes details around the new disclosures has been deferred by Intel.
Implementing Grace Periods in Intel SGX 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)
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, or Intel® SGX PCCS, 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 (typically 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® SGX Provisioning Certification Service (Intel SGX® 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 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 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.
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, a grace period appropriate to their needs.
Product and Performance Information
Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.