\HeadingLevelB{Key Hierarchy and Derivation}
\label{sec:sgx_hardware_keys}

% Provisioning Base Key known to intel, used to provision DAK in field
%   US 8,972,746 B2 - Table 12-1, columns 40-41
%   US 8,972,746 B2 - 42:52-57
% Provisioning Key is unique to chip package and enclave signer, to fulfill the
% case of multiple provisioning infrastructures.
%   US 8,972,746 B2 - 42:57-62
% Provisioning Seal Key is used to encrypt DAK with a key that can be retrieved
% when the platform changes ownership
%   US 8,972,746 B2 - 42:63-67, 43:1-5
% DAK sources - preferred source has DAK keys fused in, does not match reality;
% second source matches reality
%   US 8,972,746 B2 - 43:25-34, 44:1-3

% Key derivation process
%   US 8,972,746 B2 - 44:17-29, 45:18-26
%   US 8,972,746 B2 - Table 12, columns 44-45

% TCB Key Hierarchy (minus the OOB experience key and EPID key)
%   US 8,972,746 B2 - 46:65-67, 47:1-10
%   US 8,972,746 B2 - Figure 18, labels in 49:1-51
% Key server encrypts fuse key before burning it in
%   US 8,972,746 B2 - 47:36-44

% TCB SVN register: 64 bits, 8 8-bit SVNs
%   US 8,972,746 B2 - 47:18-23
% PRF Loop Derivation -> SVN key (the 288 bits of EPID key got nixed)
%   US 8,972,746 B2 - 47:45-67, 48:1-59
% Provisioning key is CMAC using SVN key over a fixed string
%   US 8,972,746 B2 - 48:60-65






%%% Intel patent summary

% FUSE_KEY
%   US 8,972,746 B2 - Table 4-13, column 19

According to Intel's patents, the SGX implementation relies on a complex key
derivation process rooted on global secret keys in the CPU circuitry, and on
secrets embedded in the processor's eFUSEs. eFUSE information can be extracted
efficiently (Chipworks quotes \$50-250k for extracting the entire eFUSE
contents from an Intel i5 processor), so some of the eFUSE secrets are
encrypted with a master key (referred to as a ``global wrapping logic key'' in
the patents).

The SGX patents describe two ``logic keys'' embedded in the CPU's circuitry,
which are the same for all CPUs in a stepping, making them essentially global
keys. The \textit{global wrapping logic key} (GWK) is a 128-bit AES key, and it is
used to encrypt a subset a 256-bit A.x value used to re-create the CPU's EPID
key, and a 128-bit \textit{pre-seed key 0}. The eFUSEs also contain a 128-bit
\textit{pre-seed key 1} and a 32-bit EPID group ID, which are stored in
cleartext.

\citep{shanbhogue2015gdxcsgx}, which describes mechanisms for protecting SGX
keys in the presence of hardware debuggers, states that some hardware secrets
are stored in ``metal tie-ups and tie-downs'', while other secrets are stored
in e-fuses or in \textit{physically unclonable function} (PUF) circuits \citep{gassend2002puf}.
\citep{brickell2014hardening, gotze2014provisioning} state that the GWK is
embedded into a chip using ``metal tie-ups and tie-downs'', and is shared by
all chips manufactured from the same mask set.

The SGX patents state that encrypting the eFUSE secrets by the logic key makes
them harder to extract via hardware monitoring tools, and protects them while
in transit to the CPU during the manufacturing process. This assumes that it is
very expensive to obtain the global key from a CPU, by virtue of the low
feature size. \citep{gotze2014provisioning} expresses concerns that the GWK can
be reverse-engineered.

\citep{gotze2014provisioning, gotze2014provisioning2} disclose that SGX
processors also employ a PUF, which generates a symmetric key that is used
during the provisioning process.  Specifically, at an early provisioning stage,
the PUF key is encrypted with the GWK and transmitted to the key generation
server. At a later stage, the key generation server encrypts the chip's fuse
key material with the PUF key, and transmits it to the chip. The PUF key
increases the cost of obtaining a chip's fuse key material, as an attacker must
compromise both provisioning stages in order to be able to decrypt the fuse key
material.

The SDM~\citep{intel2015sdm} mentions a 16-byte CPU security version number
(SVN), which contains the version numbers of various TCB components, and is a
source in the key derivation process. The patents further specify that the SVN
register is made up of (most likely 8-bit) sections that contain the SVNs of
each layer in the SGX initialization process, and that each initialization step
sets the corresponding section to its SVN, and then locks it for the duration
of the power-up cycle.

Intel's patents disclose that the key derivation process uses 128-bit AES in
ECB mode as a pseudo-random function (PRF). When an SVN is an input to a key
derivation process, a \textit{PRF loop} is used, where the PRF is applied to
a constant.

\citep{anati2013sgx} confirms that the attestation uses Intel's
EPID~\citep{brickell2009epid} group signature scheme.

The Intel patents indicate that EREPORT's KeyID is initialized to a random
value on each processor power cycle, and is incremented after $2^{32}$ AES
operations that use the value. They also indicate that each EREPORT may
increment the KeyID by 1.


%%% Intel ME speculation

% Key Structures and Provisioning: Ruan 2014 Ch 5

Neither the ISCA 2015 SGX tutorial nor the SDM mention the DAK described above.
However, an Intel-sponsored book on the Management Engine (ME)
\citep{ruan2014intelme}, which is the closest thing available to an official
documentation for the ME, mentions that the ME contains e-fuses that store an
EPID key which is used by the virtual TPM's software attestation feature.

Many aspects in the description of the ME's EPID key match the SGX patents'
depiction of the DAK. Both sources use the same compressed representation of
the EPID key. Also, both documents mention that the EPID key is encrypted with
an AES key.

This coincidence, combined with the apparent lack of an SGX instruction that
can be used to retrieve the DAK, prompts the consideration of the possibility that
the DAK mentioned in the SGX patent is actually stored in the Intel ME's flash
memory or e-fuses. This approach would make sense from a cost standpoint, as
the ME's core uses a larger feature size than the CPU, so adding e-fuses or
NVRAM to the ME die is cheaper than adding them to the CPU die.

While this approach seems attractive from a cost standpoint, if it were to be
true, it would have significant implications on SGX's security properties. The
DMI bus~(\S~\eref{I}{sec:motherboard}) that connects the CPU to the chipset that
contains the ME is untrusted, so the EPID key cannot be transmitted between the
CPU and the ME in plaintext. Below, we outline two possibilities for building a
secure system where the DAK is stored in the ME's flash memory.

The most straightforward approach is having the Provision Enclave encrypt the
DAK using the Provisioning Seal Key, as described in
\S~\eref{I}{sec:sgx_quoting_enclave}. Under this approach, the ME would effectively
be an untrusted flash memory, so it would not be able to run the virtual TPM
application described in \citep{ruan2014intelme}.

Another approach that preserves the virtual TPM functionality would entail
having the ME authenticate the CPU as described in \citep{costan2011spchip}, and
using a key agreement protocol~(\S~\eref{I}{sec:key_agreement}) to establish a
secure communication channel over the DMI bus. In this case, the ME firmware is
responsible for storing the DAK, as described in \citep{ruan2014intelme}, and
can implement a virtual TPM.

The downside of the latter approach is that the ME must be counted as belonging
to the SGX's TCB, as it is trusted to access the DAK. An attack that
successfully plants malicious firmware into the ME, as described in
\S~\eref{I}{sec:device_attacks} and briefly analyzed in
\S~\ref{sec:sgx_vs_device_attacks}, would result in an exposed DAK, and a total
compromise of SGX's security.

% Dynamic Application Loader: Ruan 2014 Ch 11
% Software Guard Extensions: Ruan 2014 Ch 11

In its last chapter, \citep{ruan2014intelme} mentions that the SGX architecture
takes advantage of the ME using its Dynamic Application Loader (DAL) interface.
This may refer to the Protected Audio/Video Path mentioned in an SGX
paper~\citep{hoekstra2013sgx}, or it may refer to the DAK provisioning methods
speculated above.
