Independent Software Vendors (ISVs) can now use this toolkit to add powerful Knox security features to apps. This toolkit includes:
- Attestation — To check if a device has been rooted or is running unofficial firmware. This opens up the possibility of malware infecting a device and compromising its apps and data. If your app is handling company-confidential data, you can use this tool to avoid being the source of leaked or corrupted information.
- Sensitive Data Protection (SDP) — To keep confidential data encrypted, even after a device boots up. This is specifically designed to follow the Sensitive data section of the Mobile Device Fundamentals Protection Profile (MDFPP), a security standard for mobile devices in an enterprise environment. MDFPP certification is often needed to sell to government agencies.
NOTE – The Universal Credential Management (UCM) feature has been moved from the ISV SDK to the UCM SDK.
Learn more about Knox products version mapping before downloading your SDK.
Already downloaded the SDK? Jump to next steps.
For more about each feature, click one of the tabs below.
With the popular Bring Your Own Device programs, company employees can now potentially use rooted Android devices in the workplace. These devices use custom firmware that provides more flexibility to their users, but introduce the possibility of malware intentionally or accidentally compromising the integrity of a device, its apps, and private company data. Knox Attestation lets you check if a device has been compromised, so that you can take the appropriate actions to protect your app and its valuable data.
Knox keeps track of measurements made from a device's original factory kernel, storing these in a tamper-resistant part of hardware. Attestation compares the original kernel measurements against the current kernel measurements to see if the current kernel is authentic. It also checks the Knox Warranty bit, which gets permanently fused when an unofficial boot loader or kernel is installed. Attestation is similar to Knox's Trusted Boot and essentially uses the same fundamental data sources and procedures. The primary difference is that Attestation can be requested on-demand through a web server. When requested, Attestation assembles its data into an Attestation verdict, which indicates whether tampering is suspected.
Any further action is up to you. You might choose to report the breach to the device user; uninstall your app and erase its data from the device; or use the information to create personalized app behavior.
How it works
You develop both of the following:
- an Android app — This runs on a Samsung device that supports Knox. This app calls just a single API method to start an attestation check on a device.
- a web script — This runs on a back-end server and uses a REST API to communicate with the Samsung Attestation Server.
In the diagram above, the events in red are handled by you.
- Your Android app asks your back-end server to get a nonce, which is an arbitrary number used in cryptographic communication to uniquely identify each attestation result.
- Your Android app then calls an API method to start attestation using the nonce. An Attestation Agent uses the device's secure TrustZone to create a blob (binary large object) containing data about whether the device was ever rooted, more specifically, if the device has a bootloader or firmware file that was not factory installed or part of an official upgrade.
- Your web script can check if the device succeeded or failed its attestation check by either:
- sending the blob to the Attestation Server for a verdict
- using an Attestation Validator tool locally (for added security) to parse the blob and get a verdict yourself
Through the ISV SDK's Attestation feature, you can:
- start an attestation check for a device
- relay the attestation blob back to your web server
Through an Attestation REST API, your web server can:
- initiate an attestation check
- send an attestation blob to the attestation server for a verdict
Protecting Data At Rest (DAR) is an increasing concern for businesses, government agencies, and other institutions as digital assets become vulnerable to sophisticated forms of unauthorized access. DAR on mobile devices is especially at risk as mobile devices can be easily lost or stolen.
Samsung Knox provides defense-grade Sensitive Data Protection (SDP) that is specifically designed to meet the Mobile Device Fundamentals Protection Profile (MDFPP) requirements defined by the National Information Assurance Partnership (NIAP) for DAR.Through SDP, you can protect sensitive data both inside and outside a Knox container.
Even if a device is rooted, Knox can guard the integrity of your data. When it detects that an unofficial bootloader or firmware file is installed on the device, Knox permanently fuses a Knox Warranty Bit on the device, and as a result destroys the encryption key for the Knox file system.
How it works
Knox provides two levels of protection for Data At Rest:
- Protected Data — By default, all data inside a Samsung Knox container is encrypted, even while the device is powered off. Data is decrypted only after device bootup, when an app accesses the data. In addition, the decryption key for protected data is tied to the device hardware. This makes protected data recoverable only on the same device.
- Sensitive Data — You have the option to further secure your data by decrypting it only after a device is unlocked, that is, after the device user has successfully identified themselves, for example, through a password, fingerprint imprint, or SmartCard swipe. The SDP data decryption key is tied to both the device hardware and the user credentials. Therefore, sensitive data is recoverable only on the same device and after user authentication.
Through Knox SDP, you can:
- Protect sensitive databases — You can apply sensitive data protection to selected databases and database columns.
- Protect sensitive files — You can protect an app’s files with sensitive data protection.
- Create a custom SDP engine — By default, you use a default SDP engine, which uses device unlock credentials to generate cryptographic keys for encryption. Alternatively, you can create your own custom SDP engine, by providing an app-specific password (which could be provided by the user) to generate cryptographic keys.
Next steps ...
- Get your ISV license key. You provide this key through your app to identify yourself and verify that you have permission to use the ISV SDK. If you are using the Attestation feature, you also get a REST API key, to identify yourself in the REST API calls sent to the Attestation server. For more info about license keys and how to activate them, see License Keys.
- Review the Tutorials. These walk you step-by-step through the end-to-end process of developing a simple app.
- Check the Sample Apps. These provide the complete source code for apps described in the Tutorials.
- Browse the API Reference. This describes all the API methods, grouped by Android package and Java class.
- Read the Developer Guide. These describe how to set up the development environment and deploy different features through sample code fragments.