Knox SDK frequently asked questions — Security
Yes. Use the Knox SDK API method setExternalStorageEncryption (boolean isEncrypt) for SD card encryption. Set the boolean isEncrypt to true if encryption is required, or false if decryption is required.
This API method does not encrypt silently. It sends a notification to prompt the device user to start/cancel the encryption/decryption.
Knox does not enforce authentication by default with Knox SDK v3.x. Enterprises can leverage Knox password policy APIs to enforce a password based on their own unique authentication needs.
Yes, the Mobile Device Fundamentals Protection Profile (MDFPP), a security standard for mobiles devices in an enterprise environment. The functional requirement for Data Protection, Data-At-Rest (FDP-DAR) requires that apps protect any file that may potentially contain sensitive data.
Direct access to the device root key is disabled for security reasons. However, attestation can be used to check the device’s integrity.
For more information on this topic, click here and learn about how you can customize your devices without rooting them.
In order to ensure that certificates will be saved in the TrustZone, you need to use the public boolean enableTimaKeystore(Boolean enable) API method. Enabling the TIMA KeyStore also requires TIMA CCM to be enabled for apps to store certificates in the TrustZone. Existing certificates stored in the Android KeyStore will not be impacted and only the new certificates will be stored in TrustZone after enabling the TIMA KeyStore and the TIMA CCM for affected apps.
If there is a maximum amount of failed attempts, the user is locked out of the container and prompted to contact their administrator.
Use the API method KnoxContainerManager.unlock() to unlock the container and to reset the password attempts back to 10.
You can see an error message, “Security policy prevents installation of this application” when you perform the following steps:
- Install an MDM app onto a device (using Android Studio ADB).
- Create a Knox container.
- Change MDM app code and install it on the device again.
The Android Multiple User Framework will attempt to install the MDM app into all user spaces, including the Knox container. For security reasons, you cannot use ADB to install apps into the Knox container.
You must remove the Knox container before you can re-install your MDM app. To do this, disable the Device Administrator from Settings > Security > Device > Administrators. If you need to re-install your MDM app regularly, for debugging purposes, you should programmatically do this as an active admin by calling:
ComponentName devAdminReceiver = new ComponentName(getBaseContext(), TestAdmin.class); // Context and class name of your device admin
DevicePolicyManager dpm = (DevicePolicyManager)getBaseContext().getSystemService(Context.DEVICE_POLICY_SERVICE);
dpm.removeActiveAdmin(devAdminReceiver);
When using the API method setWifiProfile, the SSID and password can be a maximum of 32 characters long.
The API method PasswordPolicy.setPasswordVisibilityEnabled(false) is user scope API and it works inside a container and outside.
This can happen if you create an email account, tap Manual setup, and set Security type to SSL (Accept all certificates).
if you use this option, you might expose user information because you allow all certificates. So device show “Cannot safely connect to server” message.
The API method isActivePasswordSufficient() checks for:
- Max character occurrences
- Max character sequence length
- Max numeric sequence length
It does not check the following policies as we do not have raw password:
- Forbidden strings
- Patterns
This is due to the implementation of Android’s Device Policy Manager, which checks only length if the password quality is less than or equal to AlphaNumeric. It considers other constraints like upper/lower case, symbols, letters, and non-letters only if password quality is set as Complex. It is not possible to change the Device Policy Manager.
For the ContainerConfigurationPolicy.resetContainerPassword() API method, in order to use the second timeout parameter, you must not have null as the first parameter
The first parameter of resetContainerPassword() API method should be the key that was given during container creation. We commonly call it as “reset password token”. Without this, the API timeout has no effect, and the user is prompted to reset their password immediately.
The API method setMaximumTimeToLock() configures the maximum lock screen timeout.
This setting is tied to Settings > Display > Screen timeout.
For example, if you have a display screen timeout set to 5 minutes, and you set the maximum lock screen timeout to 8 minutes and 20 seconds, the maximum lock screen timeout is counted at 3 minutes and 20 seconds. The five minutes from the display screen timeout is subtracted.
This API method is available since MDM 5.0.
You can use the API method setPasswordMinimumLength(ComponentName admin, int length) to set the minimum length of the backup password for fingerprint access. Note that if a user has already set the fingerprint and backup password, this API method will have no effect until the user manually changes the backup password or deletes the saved fingerprint.
When an app calls the API method setExternalStorageEncryption(), a device notification appears only if there is a change in the SD card state. There are several scenarios:
-
SD card is already encrypted, and you call setExternalStorageEncryption(true). No notification appears in this case, as there is no change in the SD card state.
-
SD card is not encrypted, and you call setExternalStorageEncryption(true). A notification appears to prompt users to Tap to Mount SD Card. If the user taps Apply, this enables SD card encryption.
-
SD card is not encrypted, and you call setExternalStorageEncryption(false), the notification is ignored or cancelled.
If the user ignores or cancels the notification to Tap to Mount SD Card, they will not be prompted again, even if you call the API method setExternalStorageEncryption(true) again. To get the notification again, restart the device or re-mount the SD card.
With the SDP APIs, you can use either a device unlock password or an app-specific password to generate cryptographic keys for data encryption and decryption. Cryptographic keys used by Knox are stored by the TIMA (TrustZone-based Integrity Measurement Architecture) keystore. The keys are further encrypted with a device-unique hardware key that can only be decrypted by the hardware from within the ARM TrustZone. All cryptographic operations are performed only within ARM TrustZone, and are disabled if the system is compromised.
Yes, you can use the API method setBiometricAuthenticationEnabled(). It does not turn on the fingerprint lock, but instead enables/disables it from the device lock screen settings.
No. As a workaround, you can use the API method setMaximumFailedPasswordsForWipe() and set it to 5. In this case, the device cannot be unlocked via Google without performing a factory reset that would wipe the data after 5 failed attempts.
Yes. App developers can use the API method addRules(FirewallRule[] rules) to add rules to allow, block, or redirect IP requests.
This applies only to the class FirewallPolicy in the deprecated Knox Standard SDK version 4.1 or lower. The proxy rules apply only to HTTP requests (port 80) and not HTTPS requests (port 8443).
With the Knox SDK or Knox Standard SDK version 5.0+, you can call the API method setGlobalProxy() to set a global proxy on the device. This API supports both HTTP and HTTPS requests for the whole device.
Is this page helpful?