If you have a Samsung phone, you may have noticed the phrase “Secured by Knox” on the boot screen. What does that even mean? Under the cut – a description of the mobile security platform preloaded on most Samsung smartphones and tablets. This is the first Russian-language review of what mechanics do exist in a Knox solution.

Introduction

In 2019, Samsung Electronics celebrated 50 years, and this year was also marked by another round date – 10 years from the launch of the first Galaxy device – the GT-I7500. This is what this model looked like:

By today's standards, the phone had very modest characteristics: a 3.2-inch screen and a processor with a clock frequency of only 528 MHz, was running one of the first versions of the Android OS. Actually, in 2009 the model was not unique: there were devices on the open Android OS with similar hardware characteristics on the ARM platform on the market. It was clear that success requires a “highlight” that sets the company apart from the rest.

Undoubtedly, the openness of the operating system allowed Google to capture an unprecedented market share of mobile devices: according to IDC estimates for October 2019, Android is installed on 87% of smartphones sold and it continues to grow. But then, and now, the Android security issue is one of the topics that are often discussed.

Samsung introduced the Knox platform as a response to challenges in the field of information security of mobile devices. The first edition of Knox (the old name is “SAFE” or “Samsung for Enterprise”) was released in 2012 along with the Galaxy S3.

The latest majority version of the platform (3.0) was released with the Galaxy S9 in 2018. The current version at the time of writing is 3.4. The name Knox comes from Fort Knox, one of the most secure gold holdings in the world.

What is Knox? Now this name (or more correctly the brand) refers to everything that is connected in Samsung with mobile security. This includes the Samsung Pass password manager, Secure Folder, Samsung Pay payment service, and a whole family of enterprise solutions, but this is based on the Knox platform.

An important feature of the Samsung Knox platform is that it is based on hardware mechanisms. Samsung, as a manufacturer of hardware components, can control the entire process of production, assembly and configuration of the device, and, therefore, design security mechanisms based on hardware capabilities.

This includes the following principles:

• System security is built on the hardware root of trust (HW Root of Trust).
• Device security monitoring should begin at boot time.
• Safety monitoring is mandatory and regular during device operation.
• The system must have a mechanism in place that allows third-party systems to prove their integrity.
• The main value of the device is user data. Their protection is a priority of the system.

Particular attention in the development of the Knox platform is given to specific corporate requirements for device security. Mobile phones have become a working tool: it’s not only the usual office work for everyone (mail, messengers, office suite), but also more exotic options: a phone as a cash register, a scanner in a warehouse, or even a guide in a museum. For companies, the ability to manage these mobile jobs is important.

The Knox platform also solves this problem:

• Corporate data on the device should be conveniently managed.
• The corporate device must have centralized monitoring and control mechanisms.
• The above items should not be implemented to the detriment of the privacy of the end user.

Further details about the device platform Samsung Knox.

Building a trusted environment

Before delving into the consideration of individual mechanisms, a few words should be said about the basis of all the hardware mechanisms for protecting the Knox platform – TrustZone-based Integrity Measurement Architecture (TIMA). It is based on the ARM TrustZone Framework.

There are 2 “worlds” (areas) in the TrustZone paradigm:

• Secure
• Normal or Non-secure ("Normal" or "Insecure" world)

Their separation is carried out at the hardware level and is controlled by a separate component called Monitor. It looks like this:

Source: www.arm.com

The functionality of the phone is divided between these two areas as follows:

Secure World:

• Sensitive computing (for example, encryption).
• Protection of critical information.
• Monitoring the state of the kernel of the OS running in Normal World.
• Access to memory and devices marked as Secure (can only be accessed from Secure World).

Normal World:

• Running the main OS and all user applications.
• Applications running on Secure World are the most privileged and can access the resources of both environments (both Secure World and Normal World). Under normal conditions, applications from Normal World cannot access Secure World resources directly.

From the basics, let's move on to the protection mechanisms themselves in the Knox platform.

Hardware Root of Trust

Already at the time of production at the factory, during the installation of software (software), cryptographic keys are created on the mobile device. Consider 2 main keys:

• Device Unique Hardware Key (DUHK) or Device Unique Hardware Key. A symmetric key unique to each device, which is created directly on the device using a hardware random number generator. Information encrypted with this key can only be decrypted on the same device. DUHK is available only to the hardware encryption module and is not available to any software on the device. Using DUHK, the remaining cryptographic keys on the device are encrypted. When we say that a component is tied to a device, most often it is the use of this key.
• Device Root Key (DRK) or Device Root Key. Unique for each device a pair of asymmetric keys (RSA), signed by the root certificate (X.509) Samsung. DRK is protected by DUHK and is only available from Secure World. It uniquely identifies the device and confirms that it is manufactured by Samsung.

With the above approach, the keys are difficult to compromise or forge, the encrypted data is firmly tied to the hardware, they cannot be transferred and read on another device.

Device manufacturing at Samsung Electronics, Gumi, South Korea

Download device

Secure Boot

The device boot process consists of a chain of bootloaders, each of which checks the signature of the next component, and then starts it. If the test fails, the download process is interrupted. This mechanism is called Secure Boot. In its work, it uses the Samsung Secure Boot Key (SSBK), an asymmetric key pair in hardware storage.
Secure Boot ensures that the device boots only using trusted Samsung bootloaders. If one of the bootloaders is compromised, the device’s startup is interrupted, preventing potential device compromise.

Trusted Boot

Secure Boot by checking the signature solves the problem of third-party bootloaders, but does not solve the problem of old, irrelevant versions that potentially carry a number of known vulnerabilities. Therefore, the Trusted Boot mechanism has been developed, working on top of Secure Boot. It checks the relevance of the bootloader version. Test results are written to protected memory in TrustZone Secure World and can be used for future checks.

Knox Verified Boot (KVB)

At the time the OS starts, another mechanism called Knox Verified Boot is activated. KVB is an extension of the Android Verified Boot (AVB) engine. In addition to the standard metrics controlled by AVB, KVB also takes into account the results obtained by Trusted Boot and Secure Boot (i.e. bootloader integrity and relevance). Due to the execution of all KVB operations in the bootloader, this check is reliable and safe (the procedure is carried out outside the checked object).

The Knox Verified Boot component is fairly new and is supported by devices starting with the Samsung S10 running the Android P operating system or later.

Graphically, the boot process of a device protected by Knox mechanisms can be represented as follows:

Knox Warranty Bit Hardware Flag

Knox Warranty Bit is a security feature that allows you to record the fact that an unofficial version of the system software was installed on the device. Devices with a valid Warranty Bit cannot use some functionality, for example, Knox Workspace. The flag cannot be returned to its original state. It ensures that the Samsung device previously only started with a trusted OS.

Fig. Custom firmware on the left, KNOX WARRANTY VOID 0x1

Hardware lock back to old software versions (Rollback Prevention)

Older versions of bootable components may contain vulnerabilities. Rollback prevention – a function that blocks the return to an older version of the OS. The minimum bootloader version possible for firmware is stored in a protected area. The smallest possible version of the OS kernel is stored in the bootloader itself. With a regular system update, the minimum allowable versions of the bootloader and OS are increased. Going back to a previous or earlier version is not possible.

It is impossible to return from Android P to Android O.

Trusted Environment Integrity

After startup, the integrity of the system must be checked regularly. There are several mechanisms for this in Knox.

Periodic Kernel Measurement Component (PKM)

PKM periodically monitors the OS for modifications to its components from the time it boots. As part of the verification, the kernel checksums and the status of the SE for Android subsystem are tracked (we'll talk about it a little later). PKM works for Secure World. Thus, any abnormal modification of the OS kernel will be detected.

Real-time Kernel Protection (RKP) component

Trusted Boot protects against loading a modified kernel, but the kernel may be attacked while the device is running. Constant monitoring of code integrity and critical data is required. RKP is a security monitoring located in an isolated environment – either in the ARM TrustZone Secure World, or in a "thin" hypervisor protected by virtualization hardware extensions.

RKP uses special methods to monitor memory management in Normal World, intercept critical queries and evaluate their impact before they are executed. The real-time kernel protection mechanism complements periodic kernel integrity checks (PKMs).

Thus, Real-Time Kernel Protection is a guarantee of protection against malicious code execution at the kernel level of the OS.

Trusted Environment Integrity Check

Mobile devices do not work in isolation, usually they are part of a larger system, for example, they are server clients, computing nodes, etc. And for the system to work stably and safely, it must be sure that all its components are “healthy” and they are who they say they are. This is a rather difficult task; within the framework of the Knox platform, it is solved using the remote certification mechanism.

Remote device certification (Knox Attestation)

Remote certification allows a third-party system to make a conclusion about the state of the end device. The following parameters are checked, in particular:

• measurements collected during the Trusted Boot boot process;
• security breach logs from PKM and RKP mechanisms since the last reboot;
• Knox Warranty Bit status
• Various device identifiers, such as IMEI.

A certification message is generated in the ARM TrustZone Secure World. It is correct even if the OS in Normal World is compromised.

In addition to checking individual parameters, certification also evaluates the state of the system as a whole. Only when the measurements collected by the Trusted Boot correspond to the reference values ​​and the Knox Warranty Bit value is not changed, the certification is considered passed.

The certification message cannot be falsified because it is signed using the Samsung Attestation Key (SAK), derived from the Samsung root key. The remote server can verify the integrity of the message using the Samsung root key. The signature contains a cryptographic “additive” generated on the server side (a random number that is used only once) to prevent an attacker from using the old validation message on an already compromised device.

The third-party system may decide on further actions based on the certification results, depending on security policies. For example, you can disconnect from a device, erase content in a secure workspace, request the location of the device, and perform many other actions.

Data protection

Data is the core value of a mobile device and requires separate protection mechanisms.

Internal Storage Encryption

Full encryption of internal memory is a prerequisite for all devices based on Android OS from version 7. Knox develops this concept by storing the key in a secure hardware key storage.

Security Enhancements (SE) for Android

Samsung Knox uses the security extension for Android (Security Enhancement for Android, SE for Android), which adds a Mandatory Access Control (MAC) mechanism to the OS.

SE for Android provides two levels of MAC protection:

1. Kernel Protection
2. Android middleware protection

SE goals for Android include isolating data and applications, restricting the rights of system processes, including those executed on behalf of a superuser.

Knox Containerization

One particular use case for the SE for Android engine is the Knox container.
A container divides applications and data into two independent spaces: a regular and a protected area. The data of the protected area is stored in the internal memory in encrypted form. Encryption keys, in turn, are encrypted using a DUHK key, i.e. they are tied to a specific device. In the event of a device being compromised (Knox Warranty Bit, Trusted Boot, etc.), access to the container is blocked.

It is important to note that the applications installed in the container work, in fact, in a normal environment. As a result, an application written for Android runs in a container without any adaptations or changes to the source code.

Containerization technology is used in several Samsung products, such as Secure Folder and Knox Workspace.

Business Opportunities

All of the above mechanisms are of particular importance when using mobile devices in a corporate environment. This issue deserves a separate consideration, so here we restrict ourselves to the picture:

Posted by: Vladimir Karacharov,
Manager, B2B Pre / Post Sales
Business development team
Samsung R&D Institute Russia