Vol. 3D 39-7

ENCLAVE OPERATION

39.4.2 

Security Version Numbers (SVN) 

Intel® SGX supports a versioning system that allows the signer to identify different versions of the same software 
released by an author. The security version is independent of the functional version an author uses and is intended 
to specify security equivalence. Multiple releases with functional enhancements may all share the same SVN if they 
all have the same security properties or posture. Each enclave has an SVN and the underlying hardware has an 
SVN.
The SVNs are attested to in EREPORT and are included in the derivation of most keys, thus providing separation 
between data for older/newer versions. 

39.4.2.1   Enclave Security Version

In the SIGSTRUCT, the MRSIGNER is associated with a 16-bit Product ID (ISVPRODID) and a 16 bit integer SVN 
(ISVSVN). Together they define a specific group of versions of a specific product. Most keys, including the Seal Key, 
can be bound to this pair. 
To support upgrading from one release to another, EGETKEY will return keys corresponding to any value less than 
or equal to the software's ISVSVN.

39.4.2.2   Hardware Security Version

CPUSVN is a 128 bit value that reflects the microcode update version and authenticated code modules supported 
by the processor. Unlike ISVSVN, CPUSVN is not an integer and cannot be compared mathematically. Not all values 
are valid CPUSVNs. 
Software must ensure that the CPUSVN provided to EGETKEY is valid. EREPORT will return the CPUSVN of the 
current environment. Software can execute EREPORT with TARGETINFO set to zeros to retrieve a CPUSVN from 
REPORTDATA. Software can access keys for a CPUSVN recorded previously, provided that each of the elements 
reflected in CPUSVN are the same or have been upgraded.

39.4.3 Keys

Intel® SGX provides software with access to keys unique to each processor and rooted in HW keys inserted into 
the processor during manufacturing. 
Each enclave requests keys using the EGETKEY leaf function. The key is based on enclave parameters such as 
measurement, the enclave signing key, security attributes of the enclave, and the Hardware Security version of the 
processor itself. A full list of parameter options is specified in the KEYREQUEST structure, see details in Section 
38.17. 
By deriving keys using enclave properties, SGX guarantees that if two enclaves call EGETKEY, they will receive a 
unique key only accessible by the respective enclave. It also guarantees that the enclave will receive the same key 
on every future execution of EGETKEY. Some parameters are optional or configurable by software. For example, a 
Seal key can be based on the signer of the enclave, resulting in a key available to multiple enclaves signed by the 
same party.
The EGETKEY leaf function provides several key types. Each key is specific to the processor, CPUSVN, and the 
enclave that executed EGETKEY. The EGETKEY instruction definition details how each of these keys is derived, see 
Table 41-56. Additionally,

•

SEAL Key: The Seal key is a general purpose key for the enclave to use to protect secrets. Typical uses of the 
Seal key are encrypting and calculating MAC of secrets on disk. There are 2 types of Seal Key described in 
Section 39.4.3.1. 

•

REPORT Key: This key is used to compute the MAC on the REPORT structure. The EREPORT leaf function is used 
to compute this MAC, and destination enclave uses the Report key to verify the MAC. The software usage flow 
is detailed in Section 39.4.3.2. 

•

EINITOKENKEY: This key is used by Launch Enclaves to compute the MAC on EINITTOKENs. These tokens are 
then verified in the EINIT leaf function. The key is only available to enclaves with ATTRIBUTE.

EINITTOKENKEY set 

to 1.