Task #3119
investigate using Android 4.x KeyStore
| Status: | New | Start date: | 03/25/2014 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | - | |||
| Target version: | 0.2 | |||
| Component: |
Description
Android 4.x provides a semi-generic system for storing application secrets in privileged system credential storage known as KeyStore. On some devices this storage may even be hardware backed with a TPM/TrustZone.
"If the device has a hardware-backed key store implementation, keys will be generated outside of the Android OS and won't be directly accessible even to the system (or root user). If the implementation is software only, keys will be encrypted with a per-user key-encryption master key." [1]
An app is allowed to store secrets inside the KeyStore and only requests of the same UID can retrieve the secrets _*_ . The KeyStore's locked status is tied to the phone's locked status. Using a lock screen PIN or password is required to use the KeyStore. However, because stored keys are encrypted with a key derived from the lock screen PIN/pass, if the PIN/pass is changed or removed, all stored keys are lost.
How does this apply to CacheWord?
There are some use cases where the security requirements are less stringent and perhaps the main threat is malware, not physical access to the device. In this cases CacheWord could simply rely on the lock screen password for security and store encryption keys in the KeyStore. This would remove the burden of creating and remembering an application specific password from the user.
* (For hardware backed storage, it's unclear how exactly this would work in practice, since the whole point of HW backed credential storage is that keys are not extractable. But we'll ignore that for now)
Resources