Security
Last updated
Last updated
When choosing memory for a device, the memory chosen should include mitigations against Rowhammer-style attacks. On the device, secure storage and processing of cryptographic keys available on the device is typically achieved by leveraging hardware-backed Keymaster implemented in an isolated environment such as a Trusted Execution Environment (TEE).
Biometric Verification
Carefully acquire, store, and process biometric data for user authentication. : Specify a primary authentication method before using any other form of authentication, including biometrics.
Require explicit confirmation to indicate intent when using passive biometric modalities (e.g., facial recognition) for transactions involving authentication-bound keys (e.g., payments).
Use a fully secure pipeline for all biometric data and processing. Keep this data in a secure, isolated environment, such as a Trusted Execution Environment (TEE) or secure element.
Dynamically load SELinux policy
Do not dynamically load SELinux policy on Android devices. Avoid the following issues on devices: a. Prevent important security patches from being accepted. b. Allow rooting of the device by reloading the policy. c. Provide vectors for man-in-the-middle attacks against the policy updater. d. Device failure due to policy update errors.
Backdoor programs and development tools
To provide higher security and avoid backdoor attacks, the system manages permissions effectively at the bottom layer, and turns off root permissions and developer mode. ADB is disabled when the hardware device leaves the factory.
Key Management
Do not share signing keys with external parties. If a signing key is compromised, generate new keys and double-sign all apps going forward. Store all keys in highly secure module hardware or services that require multi-factor authentication to access.
Application pre-installation and related audits Pre-installed applications run CTS tests before going online, and pass virus, vulnerability and automation tests.
Application installation and permissions, application signing Grant permissions to pre-installed applications or whitelisted applications, and sign the device without using commonly used public keys.
Isolate applications and processes Root processes are the most common targets of privilege escalation attacks, so reducing the number of root processes helps reduce the risk of privilege escalation. Ensure that the amount of necessary code running as root code on the device is minimized. Use regular Android processes instead of root processes whenever possible. Root code should be isolated from untrusted data as much as possible, and root code should be accessed through inter-process communication (IPC) whenever possible. Root processes do not listen through network sockets. Root processes do not contain general runtimes (such as Java virtual machines).