Knox White Paper

Note: This feature has been deprecated in the Android 10 release with Knox 3.4.1. Although it might still work, it is no longer being tested and will stop working in an upcoming Knox release. We strongly recommend that you use an equivalent feature in Android or stop using the feature altogether.

Client Certificate Manager (CCM)

Samsung builds upon the Android Keystore by providing a tamper-proof, detection-based lock-down of cryptographic keys and certificates. This solution supports a variety of high-security use cases important to enterprises, as described in the following sections.

Granular certificate and key access control

The Knox Platform supports an app whitelist for certificates, allowing the certificate installer to define which apps are allowed to perform cryptographic operations based on their certificates. This certificate whitelist process offers better control and flexibility than simply allowing app-only or device-wide access rights to certificates.

Silent installation

Knox 3.2.1 allows IT admins to install certificates while the device is still locked. This means certificates can be silently installed into a keystore without any interaction from the device-user.

Signing with device-specific certificates

A special certificate called the Device Default Certificate (DDC) resides within each device. What makes this certificate special is that it is tied to that device's hardware, is signed by the Device Root Key (DRK), and can never leave the device.

Any objects signed by the same DDC are guaranteed to have come from the same Samsung device. There is no way to spoof the identity of a device by reusing a DDC and its key pair on a different device.

Device integrity assurance

Objects signed with this certificate were signed while the device was in good health, meaning when the device was uncompromised. If a device fails its integrity checks—by failing the signature check of the kernel or OS or disabling SE for Android—the following happens:

• A tamper fuse is set; and
• The DDC is rendered permanently unusable.

This lockdown helps attest to the health of the device where the data was signed. After all, you can’t trust a signature if the device doing the signing is compromised. The Knox Platform provides a CSR agent that benefits from this device health attestation claim. A CSR produced and signed by the CSR agent carries implicit device health security claims.

Keystore integration with other features

A keystore is only as useful as the use cases it supports. In addition to manual cryptographic actions—such as sign, verify, encrypt, and decrypt—the Knox Platform provides built-in logic to support sensitive certificate-based actions enterprises often need to secure their solutions such as the following:

• Certificate Signing Requests (CSRs) — The ability to complete CSRs with a trusted agent, tied to the Knox Platform's hardware-based Root of Trust, simplifies the secure handling of mobile endpoint requests for digital identity certificates. Instead of sending key pairs and certificates from servers, keys can instead be securely generated on-device and bound to hardware. The public certificate is then included in an appropriate CSR request. Using the CSR agent to validate CSR contents and sign the request avoids trusting sensitive actions to third-party code running in less trusted areas of the device.

• Certificate Enrollment Protocols (CEPs) — Similar to CSR, CEP provides built-in agents for logic that enterprises rely on, saving time and enhancing security claims. For more information, see Certificate Enrollment Protocols.

In addition to the DDC, you can generate or install your own certificate and key pairs and specify they are accessible only if the device is in good health. This additional process locks down the keystore in the event of a device integrity failure.