Three hardware components are the foundation of Samsung KNOX’s trusted environment.
The Device Root Key (DRK) is a device-unique asymmetric key that is signed by Samsung through an X.509 certificate. This certificate attests that the DRK was produced by Samsung.
The DRK is injected in the device during the manufacturing process in the Samsung factory, and is only accessible by specially privileged software modules within the TrustZone Secure World.
Because the DRK is device-unique, it can be used to identify a device. For example, a certificate included with TIMA attestation data is signed by DRK (more precisely, through a key attested by the DRK), which proves that the attestation data originated from the TrustZone Secure World on a Samsung device. KNOX also uses device-unique hardware keys and keys derived from the hardware keys, which are only accessible in the TrustZone Secure World. Such keys can be used to tie data to a device. KNOX Workspace data, for example, is encrypted using such a key, and cannot be decrypted on any other devices.
The Samsung Secure Boot key is used to sign Samsung-approved executables of boot components. The public part of the Samsung Secure Boot key is stored in hardware at the time of manufacture in the Samsung factory. The Secure Boot process uses this public key to verify whether each boot component is approved.
Rollback prevention fuses are hardware fuses that encode the minimum acceptable version of Samsung-approved executables. Because old images may contain known vulnerabilities that can be exploited, this feature prevents approved-but-old versions of boot executables from being loaded.
Secure Boot and Trusted Boot
The startup process for Android begins with the primary bootloader, which is loaded from Read-only Memory (ROM). This code performs basic system initialization and then loads another bootloader, called a secondary bootloader, from the file system into Random-Access Memory (RAM) and executes it. Multiple secondary bootloaders may be present, each for a specific task.
The boot process is sequential in nature with each secondary bootloader completing its task and executing the next secondary bootloader in the sequence, finally loading the last bootloader (sometimes known as aboot), which loads the Android kernel.
Secure Boot is a security mechanism that prevents unauthorized bootloaders and operating systems from loading during the startup process. Secure Boot is implemented by each bootloader cryptographically verifying the signature of the next bootloader in the sequence using a certificate chain that has its root-of-trust resident in hardware. The boot process is terminated if verification fails at any step.
Secure Boot is effective in preventing unauthorized bootloaders (and sometimes the kernel when it is also applied to the kernel binary). However, Secure Boot is unable to distinguish between different versions of authorized binaries, for example, a bootloader with a known vulnerability versus a later patched version, since both versions have valid signatures.
Samsung KNOX implements Trusted Boot (in addition to Secure Boot) to address this limitation. With Trusted Boot, measurements of the bootloaders are recorded in secure memory during the boot process. At runtime, TrustZone applications use these measurements to make security-critical decisions, such as verifying the release of cryptographic keys from the TIMA KeyStore, container activation, and so on.
Additionally, if the final bootloader is unable to verify the Android kernel, a one-time programmable memory area (colloquially called a fuse) is written to indicate suspected tampering. Even if the Android kernel is restored to its original factory state, this evidence of tampering remains. However, the boot process is not halted, and the final bootloader continues to boot the Android kernel. This process ensures that normal operation of the device is not affected.
Security Enhancements for Android
Samsung KNOX introduced Security Enhancements for Android (SE for Android) in 2012 to enforce Mandatory Access Control (MAC) policies. These Android enhancements, and the security policies we enforce, protect applications and data by strictly defining what each process is allowed to do, and which data it can access. Samsung remains the leader in SE for Android experience and continues to add features to protect sensitive data and actions without negatively impacting user productivity.
Samsung has also built an innovative global policy validation system that can detect when prohibited actions are attempted on Samsung devices. This data gives us unique visibility into how our devices are used and can alert us to new threats. Determining which usage patterns are benign or malicious helps us to refine our security policies for best security and performance.
The Security Enhancements for Android Management Service (SEAMS) provides Application Programming Interface (API)-level control of the SE for Android policy engine. The SEAMS APIs allow software protection to be tailored for each organization by allowing dynamic creation of security containers to isolate applications and their data.
The system protection offered by SE for Android relies on the assumption of Operating System (OS) kernel integrity. If the kernel itself is compromised (by a perhaps as yet unknown future vulnerability) SE for Android security mechanisms could potentially be disabled and rendered ineffective. Samsung’s TrustZone-based Integrity Measurement Architecture (TIMA) was developed to close this vulnerability. TIMA leverages hardware features, specifically TrustZone, to ensure that it cannot be preempted or disabled by malicious software.
TIMA Periodic Kernel Measurement (PKM)
TIMA PKM performs continuous periodic monitoring of the kernel to detect if legitimate kernel code and data have been modified by malicious software. In addition, TIMA also monitors key SE for Android data structures in OS kernel memory to detect malicious attacks that corrupt them and potentially disable SE for Android.
Real-time Kernel Protection (RKP)
RKP performs ongoing, strategically-placed real-time monitoring of the operating system to prevent tampering with the kernel. RKP intercepts critical kernel events, which are then inspected in TrustZone. If an event is determined to have impact on the integrity of the OS kernel, RKP either stops the event, or logs an alert that tampering is suspected. This alert information is included in remote attestation results sent to the MDM for IT Admins to determine any further actions required by the enterprises security policies. This protects against malicious modifications and injections to kernel code, including those that coerce the kernel into corrupting its own data. RKP checks are performed in an isolated environment that is inaccessible to the kernel, so potential kernel exploitations cannot be extended to compromise RKP. Depending on the device model, this isolated environment can be in the TrustZone Secure World or the hypervisor extensions.
Remote Attestation (sometimes simply called attestation) is based on Trusted Boot and used to verify the integrity of the platform. Remote attestation can be requested on-demand by the enterprise's Mobile Device Management (MDM) system, typically before creating the KNOX Workspace.
When requested, attestation reads the Trusted Boot collected measurement data and returns them to the attestation requestor. To simplify the handling in MDM servers, the attestation agent on the device produces a verdict indicating the overall status of attestation. It compares these measurements to the factory values inside the TrustZone Secure World. Trusted Boot measurement data includes a hardware fuse value that indicates if the device booted into an unauthorized kernel in the past. Trusted Boot measurement data, along with the SE for Android enforcement setting, forms the basis of the produced attestation verdict. This verdict, essentially a coarse indication that tampering is suspected, is returned to the requesting MDM. In addition to the verdict, the attestation data includes all the trusted boot measurements, RKP and PKM logs that can indicate the presence of malicious software in the device, and other device information that can be used to bind the attestation result to the device.