Samsung KNOX addresses security using a comprehensive, hardware-rooted trusted environment including Hardware Root of Trust, Secure Boot and Trusted Boot, Security Enhancements for Android (SE for Android), TrustZone-based Integrity Measurement Architecture (TIMA), and TrustZone-based Security Services.
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.
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.
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 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.
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.
Figure 2 Samsung KNOX Platform Security Overview
TrustZone-based Client Certificate Management (CCM)
TIMA CCM is a TrustZone-based security service also built on the basis of Trusted Boot. A key feature of TIMA CCM is that if the Trusted Boot measurements do not match the authorized values, or if the KNOX warranty bit is voided, the entire TIMA CCM functions shut down, ensuring the protection of enterprise data in case of device compromise. TIMA CCM enables storage and retrieval of digital certificates, as well as other operations using those certificates such as encryption, decryption, signing, verification, and so on, in a manner similar to the functions of a SmartCard. The CCM TrustZone code provides a PKCS #11 interface to the Android OS, effectively emulating a smart card interface on a mobile device. The certificates and associated keys are encrypted with a device-unique hardware key that can only be decrypted from code running within TrustZone.
All cryptographic components used by CCM are FIPS-140 2 compliant to meet US government requirements for Mobile Device Fundamentals Protection Profile (MDFPP).
Similar to TIMA CCM, TIMA KeyStore is a TrustZone-based security service also built on the basis of Trusted Boot. The KeyStore provides applications with services for generating and maintaining cryptographic keys. The keys are further encrypted with a device-unique hardware key that can only be decrypted by the hardware from within TrustZone. All cryptographic operations are performed only within TrustZone and are disabled if the system is compromised as determined by Trusted Boot.
TrustZone-based On-Device Encryption
The KNOX platform further strengthens the full-device encryption capability offered by the Android platform. In addition to successful password authentication, the system integrity as determined by Trusted Boot is also verified before the data is decrypted. This feature is available only if the enterprise IT Admin activates encryption via the MDM. This ensures that all device data is protected in the unlikely event that the operating system is compromised.