Secure Boot is the method used when Vendors want to make sure that their customers cannot steal their IPR, or when Companies want to ensure that employees can only install applications that are approved and are able to do only the tasks that they are allowed to do. In this document, we will look at the harder problem of securing IPR using Secure boot, for custom-made hardware. It cannot be done on General Purpose off-the-shelf Computer.
The task of protecting IPR depends on several different technologies and ideas. One of the most important is the Intel Secure Guard Extensions (SGX). SGX allows executing applications in an enclave, which cannot be accessed by any code, even if it is running at a higher privilege level.
Secure Boot is required to make sure that authorized software is running on the system. A secure boot, which is verified is the best way to make sure that only authentic software is running. Once user space comes up and the system starts to interact with the external world, it becomes very difficult to ensure system integrity.
An onboard Trusted Platform Module (TPM) chip is used to provide secure storage of measurements, which is used to ensure that keys can be released only if the correct software is running. Verified Boot is done through each component verifying the signatures of the next component before executing them.
Intel Boot Guard is used as the CRTM (Core Root of Trust for Measurement), and enables SRTM (Static Root of Trust for Measurement), for implementing Secure Boot. The CRTM loads, measures, verifies and executes BIOS. BIOS then verifies and loads the first stage bootloader, which in-turn verifies and loads the GRUB. The GRUB then verifies, loads, and executes the Linux Kernel. Note that the Measurement is used only for the BIOS. The BIOS measurement in PCR0 is used to secure the Disk Encryption key. The Intel Boot Guard is used as the CRTM.
The Critical Applications are composed of two parts secure and unsecured. The Insecure part is tasked with creating and loading the secure (encrypted) enclave. The secured enclave is an encrypted and signed (by the user’s signing key) statically linked shared object, defined in SGX format. To load it a sealed encryption key needs to be provided to SGX Protected Code Loader (PCL). The Encryption key is sealed using the derived RSK on the device (derived from the User’s Signing key).
A single per-application AES128 Encryption key is generated and used to encrypt the Critical Application Enclave for all devices. And the key is sealed and stored individually on each device during the factory procedure.
A Self Encrypting drive (SED) should be used for storage. The disk is initialized by the encryption/decryption symmetric key by the BIOS, only when it is sure that the system has booted with an authorized BIOS. A SED is a perfect way to prevent a hacker from interacting with the disk directly on another machine.
The IPR protections are implemented by following procedures
1) Factory procedures for enabling protections
2) Sealing/Unsealing Procedures
3) Secure Boot Procedure
4) Procedure for Loading of IPR Critical Applications
5) Software Upgrade Procedures
The rest of the document is split into sections that describe these procedures in detail.
Factory Procedures
This section covers saving and extracting disk encryption keys in TPM persistent memory. A few things need to be done in the Factory like sealing the disk Encryption/Decryption key into the TPM using BIOS measurement in PCR0. All these could be done through a single script.
1) Create a file containing PCR0.
2) Create a PCR policy using PCR0.
3) Create TPM primary object.
4) Create TPM loadable context with a secret key.
5) Load the TPM loadable context in TPM
6) Persist the TPM loaded context at a predefined persistent handle e.g. 0x81010002
After step 6, the key will be persisted in TPM NV memory and the sealed/persisted disk encryption key can be unsealed/extracted at the time of boot if the measurement in BIOS matches.
This section covers the sealing of the Application Encryption Key using SGX enclave and storing it in TPM Non-Volatile (NV) memory.
1) Create an SGX enclave, providing an Application Encryption Key.
2) The Enclave is signed using the Adder Signing Key.
3) The Enclave will generate a sealed blob in the file.
4) Dump the content of the sealed blob file into TPM NV memory at a specific address.
5) Also store the size of the sealed blob before the Sealed blob data in TPM NV memory.
Procedure for Secure Boot
1) Intel Boot Guard is used to securely boot the BIOS. It is provided with the hash of the public key of the board manufacturer. It is possible to use CoreBoot for replacing the BIOS or UEFI for a faster boot with a smaller and more secure software.
2) The Boot Guard verifies that the Public Key is correct, then uses the public key to verify that the BIOS Signature is correct.
3) The Boot Guard then measures the BIOS (measurement is stored in PCR0 in TPM2.0 device), then loads and executes it.
4) The BIOS unseals the Encryption/Decryption key for the Self Encrypting Disk and configures it.
5) The BIOS then extends PCR0 with a random number so that the Encryption/Decryption key for the SED can no longer be extracted.
6) The BIOS then accesses the SHIM block area on the Disk.
7) BIOS verifies (using Manufacturers Public Key), loads, and then executes the SHIM code.
8) The SHIM accesses Adder Public Key in TPM to verify GRUB in the EFI partition, loads and then executes it.
9) The GRUB decides whether it needs to load the RED or BLACK partition.
10) GRUB mounts the partition, then verifies the Linux FIT image pointed by the symlink /vmlinuz and the Signature pointed by /vmlinuz.sig. Linux FIT image contains Kernel, dtb, and intramfs.
11) GRUB then loads it for execution.
Software Upgrades
Software Upgrade is required for updating software on the device whenever a new release is created. Since Secure boot is designed to prevent the updation of the software, it makes it difficult to do upgrades. This section describes procedures used for updating software.
A Device can support 4 types of upgrades.
1) Partial Upgrades
Partial upgrades are made through packages that are installed in-place. This means that the package can be installed without a reboot. These upgrades will only be used for non-critical patches, i.e. which do not modify the kernel, the GRUB, or the BIOS. These will be installed through the package manager and will not require anything more complex to be done. The protected applications can be updated through partial upgrades. The packages must be signed and the package manager must verify the application before updating the packages.
2) Non-critical Full Upgrades
Full Upgrades are basically disk images that are written over the standby root partition. When the partition image is installed, the user is asked to initiate a reboot whenever possible, so the upgrade becomes active. The Kernel Image will be changed along with the rest of the software through Full Upgrades. The GRUB must be updated following a Full upgrade.
3) GRUB upgrade
GRUB updates require rebuilding the EFI partition with the new GRUB configuration. And the GRUB needs to be reinstalled before a reboot.
4) BIOS upgrade
BIOS upgrade is a lot more complicated and must be done carefully. The BIOS is measured in PCR0, and the measurement is used to seal the Self Encryption Disk Encryption/Decryption Key. If the BIOS measurement changes then the SED will stop functioning. This means that the measurement must be changed during the upgrade. This upgrade will require multiple reboots, as the first reboot will be used to decrypt and store the key. In the second reboot, the key will be sealed with the new BIOS. The procedure will be as follows.
a) Initiate BIOS upgrade.
b) System reboots and BIOS is started.
c) BIOS unseals the disk key and seals it in TPM with a PCR which is extended with a fixed number.
d) BIOS updates itself.
e) System reboots and BIOS is started.
f) BIOS unseals the key with the fixed number, then seals it with PCR0.
g) Normal boot continues.
Note: The fixed number used increases the security of BIOS updates, but the fixed number makes this procedure vulnerable.
Protecting IPR
IPR is normally contained in a few applications or libraries, which need to be protected. Of lower importance is to protect protocols and other configuration data. Disk encryption is used to prevent getting any information from the disk. This improves the security of the system.
Intel’s Software Guard Extensions (SGX) create Enclaves in which encrypted libraries can be decrypted at runtime so that the other programs or even kernel/hypervisor do not have access to the decrypted code.
SGX has negligible performance penalty as long as the code of all protected Applications fits in 128MB Processor Reserved Memory (PRM). This memory contains decrypted code and is available only for enclave code access. If the code does not fit in this memory it will need to be decrypted/encrypted while paging in/out of the PRM.
When the application is executed the unsecured part of the code will read the sealed blob from the TPM and will launch the secure enclave by providing the sealed blob to the PCL.
Conclusion
It is possible to protect Code from being exposed using facilities provided by Intel Processors, provided the security mechanisms are implemented very carefully.
Comments are closed