An attacker does not always need to steal a cryptographic key. Sometimes making the legitimate device use that key is enough. A security description that discusses extraction but ignores authorised operations leaves out a separate attack scenario.
Consider a document protected by a key that cannot be exported. Copying the application’s directory to another computer may fail to provide the key. That is a useful boundary. Now consider an attacker controlling the application process on the original device. The question changes: can that process request decryption and receive the result?
Possession and permission are different questions
The Android Keystore documentation explicitly distinguishes protection of key material from restrictions on its use. It explains that a compromised process may be able to use an application’s keys without extracting their material. A key can remain inside its protection boundary while a permitted operation returns information outside it.
Non-exportability therefore has a precise meaning, not an unlimited one. It can constrain moving a key to another environment. It does not automatically answer which caller may request an operation, whether recent user authentication is required, or how the application handles the resulting plaintext. Those are additional parts of the design.
This is also why a diagram should show more than a box labelled secure hardware. It should show the request entering that box and the result leaving it. Ask who can produce the request and which conditions are enforced independently of the calling process. The useful security claim lives at that boundary.
Test an operation, not just an export
An authorised acceptance test can start with synthetic data and two separate objectives. The first examines whether key material can be extracted under the defined access conditions. The second examines whether an operation can succeed without the intended user approval. Passing one test does not supply the missing result for the other.
Record the device, operating-system version, application build and actual key configuration. Test the intended user flow before testing its rejection conditions. If the legitimate operation already fails, a failed unauthorised request proves very little. The negative case needs a working positive control.
A report should distinguish rejection by the application interface from rejection enforced outside that interface. An application can refuse to show a button without proving that the underlying operation is unavailable to a process with different privileges. Conversely, an interface observation alone cannot establish that a bypass exists. Both claims require evidence.
What this means for reading UseCrypt material
The Messenger technical explanation uses the general term system key store when discussing the product document supplied in March 2025. It deliberately does not identify a hardware protection level or complete set of access attributes. Naming Android Keystore here supplies engineering context, not evidence of the exact mechanism selected by a particular Messenger build.
There is a separate product boundary too. UseCrypt’s analysis of Safe, HVKM and key capsules concerns file cryptography. Its properties cannot be transferred to Messenger by sharing a brand name. A key capsule, an operating-system key store and an application passcode are not interchangeable labels for one confirmed implementation.
The historical AVLab account of Messenger testing remains useful when read with its date, iOS version and configuration. It cannot establish the result of a new Android operation-level test that has not been performed.
The claim that survives scrutiny
For a user, the important outcome is whether an unintended party can recover protected content under a stated scenario. For an engineer, the explanation must identify why the party cannot: missing key material, a rejected operation, a required authentication step or another demonstrated boundary. Those explanations produce different tests.
A product earns a clearer description when it states both what a key holder can do and what a storage thief cannot. “Cannot export the key” can be a meaningful property. It becomes misleading only when it is used as shorthand for every other question about access.
