Intel® Dynamic Application Loader (Intel® DAL) Developer Guide
Visible to Intel only — GUID: GUID-670F7119-90C9-4AD4-9D7F-CBB57BC0B9C8
Visible to Intel only — GUID: GUID-670F7119-90C9-4AD4-9D7F-CBB57BC0B9C8
Applet Encryption
Intel® Dynamic Application Loader (Intel® DAL) provides OEMs with the ability to encrypt the applet's bytecode in order to protect any intellectual property (IP) that the applet may contain, e.g., DRM algorithms and parameters.
Supported from API level 8, currently only on platforms running Intel® Trusted Execution Engine (Intel® TXE) 3.0 firmware.
Provisioning
The OEM generates an RSA key pair with modulus size 2048/3072/4096 bits, known as the OEM Master Key (OMK). The private key component is provisioned by the OEM during manufacturing using the TEE Management library; the OEM's manufacturing facility is assumed to be a trusted environment, and the TEE_ProvisionOemMasterKey command is enabled only if the platform is in pre-End Of Manufacturing (pre-EOM) state. The OMK is used to encrypt the symmetric applet encryption key. If the TEE_ProvisionOemMasterKey command is invoked more than once, the key is overwritten.
Encryption Key Setup
The OEM generates a symmetric 256-bit encryption key, the Intel DAL Encryption Key (DEK), that is used to encrypt the applet bytecode. In order to provide OEMs with the ability to encrypt different applets with different keys, multiple DEKs are supported. The maximum number of keys is five; each key has a key identifier (ID) between one and five.
The TEE Management library is used to set the DEK, which was encrypted by the OMK, in Intel DAL firmware. The encrypt-then-sign approach is utilized to ensure that the OMK is used only to decrypt authentic and valid payloads. The TEE_SetTAEncryptionKey command sends Intel DAL the DEK encrypted by the OMK public component using standard RSA encryption and then signed by the Security Domain. The signature creates a dependency on Security Domain (SD) installation on the platform; therefore a Security Domain must be installed before the encryption key is set up.
To mitigate possible replay attacks when a valid but older Encryption Key setup payload is used, an initial counter value is provisioned with the OMK. Each encryption key setup command contains a counter that is processed as follows:
if (command.counter < current counter)
reject command
else if (command.counter > current counter)
current counter = command.counter
process command
The maximum supported number of successful DEK setup invocations is five per boot.
Encrypted Trusted Application Generation
The applet's Admin Command Package (ACP) contains a byte property, ta_encrypted, that indicates that the package contains JEFF bytecode that is encrypted, and specifies the DEK that was used to encrypt it:
- 0: Default value. Means that the JEFF bytecode is not encrypted.
- 1-5: The ID of the DEK with which the JEFF bytecode is encrypted.
Following is the flow for generating an encrypted applet:
- The Pack Tool generates the applet ACP with the ta_encrypted property set to 0 (not encrypted).
- The Pack Tool signs on the ACP with the Intel debug key.
- The OEM does the following:
- Encrypts the bytecode in place using the DEK key and IV.
- Appends the MAC and IV to the ACP.
- Assigns the value of the ta_encrypted property to the key ID of the DEK.
- Calculates the hash of the new applet and replaces the hash in the ACP.
- Signs the ACP in the same way as a regular ACP (with the OEM DAL signing key).
For debugging purposes, the Pack Tool may be used to create an encrypted applet with a debug DEK. See the Pack Tool pack command arguments for more details.