Intel SGX has been there in the market for while. Yet there are still a lot of misundrestandings and mysteries about this technology. This post provides an introduction to Intel SGX OwnerEpoch and Sealing, discusses their security impacts, and speculates future usages. Note that this post assumes a general understanding of Intel SGX and its key hierarchy.
SGX OwnerEpoch is a 128-bit value used in key derivation, as shown in the figure below :
According to , this value is “loaded into the SGXOWNEREPOCH0 and SGXOWNEREPOCH1 MSRs when Intel SGX is booted”. The whole purpose of this value is to “provide a user with the ability to add personal entropy into the key derivation process”. As a result, it is included in all key derivations by egetkey leaf instruction based on , such as the Sealing key.
While an enclave provides runtime integrity and confidentiality, it cannot persist the secret across reboots. In such a case, sealing is to help. Intel SGX Sealing uses the egetkey leaf instruction to derive the sealing key on the platform. This sealing key is then used to encryt the secret within the enclave before it is written into the disk. Depending on the sealing policy, either public key of the enclave signer (MRSIGNER) or the measurement of the enclave (MRENCLAVE) can be used to derive the key, meaning that only the enclaves from the same signer or the ones with the exact measuremement can unseal (decrypt) the secret. Note that both sealing and unsealing should happen inside an enclave.
2. Security Impacts
Since OwnerEpoch is also included to derive the sealing key, changes of this regsiter would cause unsealing failure on the same platform. Consequently, a malicious cloud provider can launch DoS attacks against all SGX sealed secrets easily by updating the OwnerEpoch. Or in a more realistic case when there is a contract between the cloud provider and user, the cloud provider needs to guarantee that no code outside the TCB can update the OwnerEpoch (which is usually the case since wrmsr is a privilaged instruction, and hyperviosrs can trap it), and that no code outside the TCB can trick the TCB to update the OwnerEpoch (e.g., confused deputy attack and kernel exploitation). In the worst case, the current in-use OwnerEpoch should always have a backup to help restore the value for unsealing.
Although we could have 2 platforms with the exact same model of SGX CPU and exact same value for OwnerEpoch (we also assume the same CPUSVN and etc.), sealing on one platform cannot be unsealed on the other due to the unique device key per CPU package. This means SGX sealing does not support offline cross-platform data migration. As a workaround for this case, SGX remote attestation is needed to establish a shared secret as the sealing key rather than using the egetkey leaf instruction.
A question comes naturally for the OwnerEpoch – why do we need it and what can we do with it? By definition, it is used to provide “user” entropy to the key derivation process. It also implies that the “user” should be the “owner” of the platform (CPU), since both rdmsr and wrmsr are privileged instructions. In a cloud environment, however, this “user==owner” relationship breaks. Cloud users are the “user” while cloud providers being the “owner”.
In a physical environment where the user “own” the infrastructure (IasS), the user should be able to set the OwnerEpoch whatever he wants. It is the same case as people running SGX applications on their own laptops. In this case, rather than providing entropy, the OwnerEpoch might be used as a peronal secret to pretect sealing data. For example, Alice saves the current OwnerEpoch value after sealing, and resets it to a random value. Eve cannot unseal the data even with root permission on Alice’s machine without the right OwnerEpoch.
In a container environment where different users running different containers on the same platform, none of the users would have the permission to update the OwnerEpoch. Instead, the cloud provider sets the value, and all users share the same OwnerEpoch during their key derivation. In this case, the OwnerEpoch seems meaningless for both cloud providers and users except adding more entropy.
In a hypervisor environment where different users running different guest OSes managed by the hypervior that has the sole control of the hardware (e.g., Xen and KVM), it is possible to virtualize the OwnerEpoch per guest (e.g., adding the OwnerEpoch into VMCS). Each user can provide his own OwnerEpoch for SGX key derivation. Note that this per-guest OwnerEpoch is only known to the guest and the cloud provider. As long as the cloud provider is trusted, this per-guest OwnerEpoch can be used as a personal secret as well. Note that this secret usage might be really useful when different users running the same enclave signed by the same ISV. In this case, similar as the physical environment, data sealed by Alice cannot be unsealed by Eve even they are running on the same platform.
While SGXv1 has introduced OwnerEpoch, it is not activated – we cannot write into it. SGXv2 claims the support for updating OwnerEpoch based on , my testing on a SGXv2 CPU said no. In fact, it behaves just like SGXv1 – The first OwnerEpoch read throws an unchecked MSR access error; the following write enables the read opertaion, although the value is always 0, no matter what value is written. To test the OnwerEpoch on your platform, please git clone . My general feeling is that this OwnerEpoch is still not activated for some reason (at least on the SGXv2 CPU I tested). One comment from coreboot also suggests that the OwnerEpoch update mechanism is not determined yet . Another update from  also shows that Provisoning and Provisioning Sealing keys do not rely on OwnerEpoch anymore.
We look into the OwnerEpoch and its connection with key derivations, e.g., SGX sealing. As we discussed above, the introducing of OwnerEpoch as extra entropy seems really vague. Nevertheless, we speculated its usage as a personal secret in the cloud environments. Our trial on SGXv2 seems to suggest that its usage is still unclear.