Cryptogram Security via Native Library Integrity Verification
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current payment transaction systems using software smart card emulation on communication devices face security concerns due to vulnerabilities in native libraries, which can be compromised, leading to data lifting and code-lifting attacks, compromising the integrity of transactions.
Innovation Solution
Implementing countermeasures such as anti-cloning, anti-replay, and anti-tampering mechanisms using device fingerprints and timestamps to secure the computation of transaction cryptograms, ensuring that even if the native library is compromised, the transaction will be rejected, and the malicious activity remains undetectable.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If native libraries are used for transaction cryptogram computation, then performance is improved, but security is worsened due to susceptibility to compromise and code-lifting attacks
Solution Approach 1:
The patent divides the application into two distinct parts: a Java application layer and a native library layer. The Java code handles high-level transaction logic while the native library performs critical cryptogram computation. This segmentation allows the security-sensitive native code to be isolated and protected through separate verification mechanisms (signature checking and cryptographic binding), enabling performance optimization in the native layer while maintaining security through the Java layer's verification capabilities.
Solution Approach 2:
The patent implements preliminary security actions by verifying the signature of the native library and establishing cryptographic bindings before the native library is executed or called. The Java application checks the digital signature of the native library during installation or first execution, and creates cryptographic bindings that link the Java code to the specific native library version. This preliminary verification prevents compromised native libraries from being used, addressing the security concern before it can affect transaction integrity.
2Ease of operation
If native libraries are dynamically loaded, then ease of operation is improved, but security is worsened due to ease of replacement and compromise
Solution Approach 1:
The patent implements feedback mechanisms where the Java application continuously verifies the integrity of the native library through signature checking and cryptographic binding validation. Before each use of the native library, the system checks whether the library's signature matches the expected value and whether the cryptographic binding between the Java code and native library is valid. This feedback loop ensures that even if a native library is dynamically loaded or replaced, the system detects the compromise and prevents its execution, maintaining security while preserving dynamic loading capabilities.
3Reliability
If cryptographic binding is applied to protect native libraries, then security is improved, but performance is worsened due to negative impact on function call performance
Solution Approach 1:
The cryptographic binding is established once during the initialization phase, creating a trusted relationship between the Java application and the native library. This binding includes verifying digital signatures and establishing cryptographic links before the native library is executed. By performing this security verification in advance rather than on every function call, the patent minimizes the performance impact while maintaining strong integrity protection throughout the application's execution.
Solution Approach 2:
The patent separates security verification operations from transaction processing operations. The cryptographic binding and signature verification are performed in the initialization/setup phase, while the native library's cryptogram computation functions operate at full performance during transaction processing. This segmentation ensures that security checks do not bottleneck the performance-critical transaction processing path.
Data Source
Figure 1~2
Figure 3
Figure 4
AI summary
This invention concerns a method and system for improving the security of transaction in an emulated Integrated Circuit (ICC). The present invention proposes a method directed for proposing counter-measures against data lifting and code-lifting for dynamically linked native library of a mobile application. The result of the countermeasures method implemented are used as input to compute a countermeasure value which may be used as input during the computation of the cryptogram. If the native shared library is compromised, the computed countermeasure value is wrongly computed. With the wrongly computed cryptogram, the transaction will be rejected at the remote computer side. With the present invention, none stop condition is inserted into the mobile application when the native library is compromised. Instead, the execution of the mobile application continue corrupting silently the computation of the cryptogram, the malicious individual will not be able to understand why and when the generation of the cryptogram is failing.