The conditions under which a key can be used matter alongside its storage location. Android Keystore provides platform mechanisms for establishing that boundary.
Evaluation approach
Preventing key export and preventing unauthorized use are different concerns. A compromised process may attempt to invoke a key operation when its conditions allow. Hardware backing depends on the device and the key's properties.
Application example
When a transfer-signing key requires user authentication, test cancellation, lock-setting changes and migration to another device.
Limits and considerations
Keystore does not automatically secure a fixed server secret embedded in an application.
Is keeping the key non-exportable enough?
Preventing key material from leaving its storage boundary is valuable, but it does not by itself prevent the application from using the key for an unwanted operation. Key-use conditions and transaction authorization require their own design.
For a signing operation, inspect the data being signed, whether approval is bound to that data and the scope in which the server accepts the signature. A storage decision remains incomplete without lifecycle plans for key creation, device replacement and loss of access.
Checks and decisions
- Restrict key use
- Verify hardware properties
- Design re-enrollment
Verify key security levels and recovery behavior on supported devices separately.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.