Root of Trust
On this page
Imagine every device in your network simultaneously infected with malware and combing through your confidential data. Attacks and exploits continue to mature in sophistication in an attempt to stay ahead of advancing mobile device safeguards. So what's the single solution that works on all devices at the same time? To build a robust Root of Trust stack that minimizes exposure, detects intrusions, and locks down sensitive information.
A Root of Trust is the cornerstone of any modern security protocol. It is a series of stringent checks and balances, beginning at the hardware level rather than the software level. This feature adds a level of security to devices, making them difficult to subvert as hardware is more immutable than software.
A Root of Trust answers many complicated security questions, such as:
- How do you know if a compromised OS was booted at runtime?
- Can you trust that your certificates are stored securely?
- Has an exploit modified the kernel or other system software?
Samsung’s approach to addressing this issue is to bottleneck all security-critical functionality through trustworthy components. These trustworthy components are thoroughly designed, reviewed, and maintained with the following considerations:
- What are the assurances required? High-security enterprise partners require a near-total ability to control and audit the software that interfaces with their systems. End users must have the authority to deny permission to use their device features and data. Each user, partner, and integrated system has its own requirements, many of which are assured in large part through the Roots of Trust.
- How can components contribute to more complex assurances? A Trusted Boot process enables the trustworthy transfer of control from the bootloader to the Android framework. This trustworthy transfer of control plays a key role in the admin's ability to audit apps running on the device. Secure boot is a complex process built on top of many smaller components that validate software, configuration files, deployment processes, and update processes. Each of these smaller components contributes to the secure boot process, and a secure boot process itself contributes to the security of other processes.
- How can we make these components, their assurances, and their usage more robust? Each Trusted Application on a Samsung Knox device ultimately represents a Root of Trust. These Trusted Applications encompass functionality such as device identity, key management, and remote attestation of device health. Samsung Knox uses these same Trusted Applications to provide its own assurances.
Knox Platform trusted environment
The Knox Platform builds a unique, industry-leading trusted environment in four ways:
This process and its components are as follows:
How the Root of Trust works
- Knox Platform security starts in the factory—before users even power on their mobile device—when a Device-Unique Hardware Key (DUHK) is generated on the device using its hardware random number generator.
- Next, the DUHK generates and encrypts the Device Root Key (DRK) and Samsung Attestation Key (SAK). The DRK and SAK contain an authentication code that enables recipients to verify the IMEI and serial number of provisioned devices. Since existing purchasing systems use a device's IMEI and serial number to track devices and not the DRK identifier, this enables users to obtain proof they are interacting with devices they have purchased. The use of the DUHK is only available to the TrustZone operating system. The TrustZone OS uses the DUHK to create subsequent keys unique to each trusted application. Trusted applications uses these keys to securely store data. The DRK and SAK are private keys that enable trusted applications to prove their own identity, as well as the identity of the device they are executing on. These trusted applications integrate deeply with hardware to provide hardware-backed security.
- Upon device start up, Samsung uses the Samsung Secure Boot Key (SSBK) to check all software components. One of the components is the TrustZone Secure World, a chip partition reserved for secure code and data. Only specially privileged software modules running within the TrustZone Secure World can access these keys.
- The software performs a check on each Knox Platform feature before allowing it to run. Since this chain of security checks begins with the very first hardware check, each feature is protected by hardware Root of Trust. No matter which link in the chain an attacker targets, one of the security checks detects it.
The Knox Platform trusted environment leverages the following hardware components:
- ARM TrustZone Secure World — The Secure World is the environment where highly sensitive software runs. The ARM TrustZone hardware ensures memory and components marked secure (for example, a fingerprint reader) can only be accessed in the Secure World. Most of the system, including the kernel, middleware, and apps, run in the Normal World. The Secure World software, on the other hand, is more privileged, and can access both Secure and Normal World resources.
- Bootloader ROM — The Primary Bootloader (PBL) is the first piece of code to run during the boot process. The PBL is trusted to measure and verify the boot chain. To prevent tampering, the PBL is kept in the ROM of the secure hardware. The device hardware loads and runs the PBL from ROM at boot, and the PBL starts the Secure and Trusted Boot processes.
- Device-Unique Hardware Key (DUHK) — Samsung incorporates the DUHK, a device-unique symmetric key, in device hardware during the initial manufacture of the device. The DUHK binds data—for example, device health attestation data— to a particular device and is accessible only to a hardware cryptography module and not directly exposed to any device software. However, software can request that the DUHK encrypt and decrypt data. This DUHK encrypted data is bound to the device, and cannot be decrypted on any other device.
- Device Root Key (DRK) — The DRK is a device-unique, asymmetric RSA key pair that is signed by Samsung's root key through an X.509 certificate. This certificate proves that Samsung produced the DRK. The DRK is generated at manufacture in the Samsung factory and is stored on the device encrypted by the DUHK, thus binding it to the device. The DRK is only accessible from within the TrustZone Secure World and is protected by the DUHK.
The DRK is an important part of the Root of Trust, as it derives other signing keys. Because the DRK is device-unique, it can tie data to a device through cryptographic signatures. Signing keys are derived from the DRK and used to sign data.
- Samsung Secure Boot Key (SSBK) — The SSBK is an asymmetric key pair used to sign Samsung-approved boot executables.
- The private part of the SSBK is used by Samsung to sign secondary and app bootloaders.
- The public part of the SSBK is stored in the hardware's one-time programmable fuse at manufacture in the Samsung factory. The Secure Boot process uses this public key to verify whether each boot component it loads is approved.
- Samsung Attestation Key (SAK) — The SAK is also a device-unique, asymmetric key pair that is signed by Samsung's root key. This signed key pair proves that the SAK was produced by Samsung. The SAK is used to sign the Attestation blob that indicates if the device is in a trusted state. The signature proves that Attestation data originated from the TrustZone Secure World on a Samsung device. Unlike the DRK, the SAK is a set of ECDSA keys. ECDSA is a newer asymmetric algorithm, similar to RSA but smaller and faster for the same strength.
- Rollback Prevention (RP) fuses — RP fuses encode the minimum acceptable version of Samsung-approved bootloaders. Old software may contain known vulnerabilities that may be exploited. Rollback prevention excludes approved, but out-of-date bootloaders from being loaded. The RP fuse version number is set when system software is initially installed and when specific updates occur. Once the RP fuse version number is set, it is impossible to revert back to legacy software versions.
- Warranty fuse — The Knox Platform uses a one-time programmable fuse that signifies whether or not the device has ever booted into an unapproved state. If the Trusted Boot process detects non-approved components are used, or if certain critical security features such as SELinux are disabled, it sets the fuse. When the fuse is set, the following security measures take place: