- Basics
- About Knox
- Knox licenses
- Knox white paper
- Sign up for Samsung Knox
- Latest release notes
- General Knox FAQ
- General Knox KBAs
- Submit a support ticket
- User Acceptance Testing
- For IT admins
- Knox Admin Portal
- Knox Suite
- Knox Platform for Enterprise
- Knox Mobile Enrollment
- Knox Configure
- Mobile
- Introduction
- Get started
- Features
- License management
- Release notes
- Troubleshoot
- Wearables
- Shared Device
- FAQ
- KBAs
- Mobile
- Knox Capture
- Welcome
- Overview
- How-to guides
- Manage licenses
- Scanning profiles
- Apps and activities
- Scan engine settings
- Keystroke output and data formatting
- Export configuration and deploy through EMM
- Set the camera scan trigger
- Connect a hardware scanner
- Configure the output path
- Check a configuration in test mode
- Use intent output
- Knox Capture AR
- Get started
- How-to videos
- Release notes
- FAQ
- KBAs
- Troubleshoot
- Knox Capture: Scandit Edition
- Introduction
- How it works
- IT admins: Get started
- Getting started with Knox Capture
- Step 1: Launch Knox Capture
- Step 2: Create a scanning profile
- Step 3: Select apps and activities
- Step 4: Configure the scanner
- Step 5: Set keystroke output rules
- Step 6: Test apps in your configuration
- Step 7: Share your configuration
- Step 8: Deploy Knox Capture in Managed mode
- End users: Get started
- Features
- Knox Asset Intelligence
- Knox Manage
- Introduction
- How-to videos
- Get started
- Video: Getting started with Knox Manage
- Integration with Managed Service Provider
- Access Knox Manage
- Configure basic environments
- Create user accounts
- Create groups
- Create organization
- Set up devices and profiles
- Create a new profile
- Assign profiles to groups and organizations
- Enroll devices
- Shared Android device quickstart
- Non-shared Android device enrollment quickstart
- Android Management API device enrollment quickstart
- Apple User Enrollment quickstart
- View device information
- Apply profiles to organizations
- Set up Knox Manage deployment with a Knox Suite license
- Manage Chromebooks
- Manage Android devices with the Android Management API
- Manage Shared iPads
- Configure
- Licenses
- Organization
- Users
- Sync user information
- Groups
- Devices
- Content
- Applications
- Profile
- Knox E-FOTA
- Certificates
- Advanced settings
- Monitor
- Kiosk devices
- Knox Remote Support
- Active Directory
- Microsoft Exchange
- Mobile Admin
- Appendix
- Release notes
- Features
- FAQ
- KBAs
- Knox E-FOTA
- Introduction
- How-to videos
- Get started
- Features
- EMM integration
- Appendix
- Release notes
- FAQ
- KBAs
- Troubleshoot
- Knox E-FOTA On-Premises
- Legacy Knox E-FOTA products
- Knox Guard
- Samsung Care+ for Business
- For Knox Partners
- Knox Deployment Program
- Knox MSP Program

Knox White Paper
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 allowlist for certificates, allowing the certificate installer to define which apps are allowed to perform cryptographic operations based on their certificates. This certificate allowlist 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.