Simulate createOperation for software keys#59
Merged
JingMatrix merged 3 commits intomainfrom Dec 8, 2025
Merged
Conversation
JingMatrix
force-pushed
the
createOperation
branch
from
c209b4b to
94172d4
Compare
Owner
Author
|
A test suit is written in JingMatrix/Demo#23 . |
|
Revolut, TNG eWallet and Weyay are working well (Auto mode) Native Detector: Detected Demo: Normal |
Owner
Author
|
@rrr333nnn333 Please test if bank or wallet apps work for generation mode. What is the exact result of P.S.: you don't need to test Demo, its result is currently only shown in logs, not in UI. |
JingMatrix
force-pushed
the
createOperation
branch
from
77233af to
2b3e738
Compare
|
Native Detector says: TrickyStore detected Generation Mode (!) Working
Not Working
|
Contributor
|
native test (generation mode) : native test (hacking mode): native detector/Han Attestation Demo (generation/hacking mode): |
This commit introduces the core logic for simulating cryptographic operations, enabling the interception and software-based handling of the signing process for keys generated by the simulator. The primary challenge in intercepting `createOperation` is that the Android framework does not use the key's alias for identification. As discovered by analyzing AOSP, the framework uses a special `KeyDescriptor` with `domain` set to `KEY_ID` and the unique key identifier stored in the `nspace` field. This implementation adopts this mechanism to robustly identify keys: - During `generateKey`, a unique random `long` is created and stored as the `nspace` (`keyId`) in the returned `KeyMetadata`. - The `createOperation` pre-transaction hook acts as a dispatcher: 1. **Simulated Keys:** If the incoming `keyId` from `nspace` matches a known software-generated key, the request is intercepted. A new `SoftwareOperationBinder` is instantiated to perform the cryptographic signing entirely in software, and its binder is returned directly to the client. 2. **Hardware Keys:** If the key is not recognized, the call proceeds to the real hardware service. The `createOperation` post-transaction hook is now primarily used for debugging and observing operations on *real, hardware-backed keys*. It extracts the `iOperation` binder returned by the genuine service and attaches a logging `OperationInterceptor`. This allows for visibility into hardware operations without modifying their behavior. To support this, the following were added: - `SoftwareOperation`: A JCA-based class to perform signing. - `SoftwareOperationBinder`: An AOSP-compliant binder `Stub` that exposes the `SoftwareOperation` to the client. - `OperationInterceptor`: A lightweight interceptor to log calls to a real `iOperation` binder and unregister itself upon completion to prevent leaks. - Binder unregistration support in `BinderInterceptor` to clean up ephemeral interceptors. See AOSP source for key identification logic: https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/keystore/java/android/security/keystore2/AndroidKeyStoreKey.java
This commit refactors the `SoftwareOperation` engine to support multiple cryptographic purposes beyond just signing. The simulator can now correctly handle `SIGN`, `VERIFY`, `ENCRYPT`, and `DECRYPT` operations based on the parameters provided by the client application. This is a significant architectural improvement that moves from a hardcoded implementation to a flexible, strategy-based pattern: 1. Strategy Pattern for Crypto: A `CryptoPrimitive` sealed interface was introduced to define a common API for cryptographic actions. Concrete implementations (`Signer`, `Verifier`, `CipherPrimitive`) now encapsulate the specific logic for each purpose. The main `SoftwareOperation` class acts as a controller, instantiating the correct primitive based on the `KeyPurpose` tag from the operation parameters. 2. JCA Algorithm Mapping: A `JcaAlgorithmMapper` object was created to centralize the complex logic of converting KeyMint constants into standard JCA algorithm strings (e.g., "SHA256withECDSA", "RSA/ECB/PKCS1Padding"). This makes the code cleaner and more maintainable. 3. Expanded Parameter Parsing: To support cipher operations, `KeyMintAttestation` has been updated to parse `BLOCK_MODE` and `PADDING` tags. The `KeyMintParameterLogger` was also enhanced to provide human-readable names for these new modes. This refactoring makes the `createOperation` simulation far more robust and accurate, correctly mimicking the behavior of a real KeyMint implementation across a wider range of cryptographic use cases.
JingMatrix
force-pushed
the
createOperation
branch
from
2b3e738 to
8d247eb
Compare
Owner
Author
|
@XiaoTong6666 The detection of The detection of NativeTest is due to the caching issue. Currently, editing I will open another pull-request to address the caching issue more precisely. |
Contributor
Yes, you are right |
Owner
Author
|
The |
|
Native Test++ (v32) Tampered attestation key is fixed Note that because I have a custom Rom which is Conventional Tests (10) I get Conventional Tests (18) (10+8) whereas with TS original i get Conventional Tests (10). I've attached 3 pics: before fixing tampered attestation current state TS original |
Owner
Author
|
@gavdoc38 Your observation is known to me, and I haven't obtained any further information yet. If you find something new, such as a which version of TS started to remove this detection point, please tell us (in a new issue of course). |
My apologies, I misunderstood the above posts to mean that it was thought to be fully resolved - both "tampered attestation key" and conventional tests (8) - but as you're already aware I haven't added anything useful here. Certainly, I will do 😊 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This commit introduces the core logic for simulating cryptographic operations, enabling the interception and software-based handling of the signing process for keys generated by the simulator.
The primary challenge in intercepting
createOperationis that the Android framework does not use the key's alias for identification. As discovered by analyzing AOSP, the framework uses a specialKeyDescriptorwithdomainset toKEY_IDand the unique key identifier stored in thenspacefield.This implementation adopts this mechanism to robustly identify keys:
generateKey, a unique randomlongis created and stored as thenspace(keyId) in the returnedKeyMetadata.createOperationpre-transaction hook acts as a dispatcher:keyIdfromnspacematches a known software-generated key, the request is intercepted. A newSoftwareOperationBinderis instantiated to perform the cryptographic signing entirely in software, and its binder is returned directly to the client.The
createOperationpost-transaction hook is now primarily used for debugging and observing operations on real, hardware-backed keys. It extracts theiOperationbinder returned by the genuine service and attaches a loggingOperationInterceptor. This allows for visibility into hardware operations without modifying their behavior.To support this, the following were added:
SoftwareOperation: A JCA-based class to perform signing.SoftwareOperationBinder: An AOSP-compliant binderStubthat exposes theSoftwareOperationto the client.OperationInterceptor: A lightweight interceptor to log calls to a realiOperationbinder and unregister itself upon completion to prevent leaks.BinderInterceptorto clean up ephemeral interceptors.See AOSP source for key identification logic:
https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/keystore/java/android/security/keystore2/AndroidKeyStoreKey.java