Description:FIELD OF INVENTION
[0001] Embodiments of the present disclosure relate to the field of mobile communication , and more particularly to a system and method for runtime integrity validation to detect tampering of a mobile application.
BACKGROUND
[0002] Application tampering on mobile devices involves modifying an application’s code or its environment to change its behaviour, bypass security mechanisms, or exploit vulnerabilities. Detecting tampering of the applications is crucial for protecting user data, ensuring application integrity and preventing unauthorized access.
[0003] Several existing solutions to application tampering focus on statis analysis or pre-installation checks, such as code signing and application signature verification. However, such solutions fail to provide real-time detection during application execution. Further, the existing solutions are static in nature, such as one-time integrity checks is not sufficient to protect against sophisticated tampering. The attackers constantly evolve their tampering techniques, which makes it challenging for static solutions to survive. Furthermore, the existing solutions only indicates whether an application has been tampered or not. They fail to identify specific components or code of the application that has been tampered. Moreover, the existing solutions focus on one aspect or technique (for instance, code modification, resource tampering and injection of malicious code), while neglecting the others. This may lead to leaving other vulnerabilities exposed. For instance, an app that verifies its code integrity might still be susceptible to runtime code injection if it doesn’t implement runtime monitoring or memory protection. To effectively safeguard against tampering, it's essential to adopt a comprehensive security strategy that addresses all potential attack vectors.
[0004] Hence, there is a need for an improved system and method for runtime integrity validation to detect tampering of an application which addresses the aforementioned issue(s).
OBJECTIVE OF THE INVENTION
[0005] An objective of the present invention is to provide runtime integrity validation of a mobile application by actively monitor the mobile application’s code and resources during runtime, thereby allowing for immediate detection of tampering attempts as they occur.
[0006] Yet another objective of the present invention is to employ dynamic adaptation by using techniques like checksum verification, integrity checks and anti-debugging mechanisms. This adaptive approach enables it to stay ahead of evolving tampering methods and maintain effective detection capabilities.
[0007] Yet another objective of the present invention is to detect tampering attempts and also provide detailed information on the modified components, thereby allowing targeted mitigation and forensic analysis.
[0008] Yet another objective of the present invention is to allow integration of the method with existing app security frameworks and techniques such as code signing, certificate pinning and secure network communication protocols. This integration enhances overall app security and complements other security measures implemented by developers.
BRIEF DESCRIPTION
[0009] In accordance with an embodiment of the present disclosure, a system for runtime integrity validation to detect tampering of a mobile application is provided. The system includes. a processing subsystem hosted on a server, wherein the processing subsystem is configured to execute on a network to control bidirectional communications among a plurality of modules. The system includes a tampering detection module configured to constantly monitor the mobile application and one or more resources of the mobile application during runtime. The tampering detection module is also configured to detect in real time a modification of at least one of the mobile application and the one or more resources of the mobile application and provide information of the modification. The system also includes a checksum verification module operatively coupled to the tampering detection module wherein the checksum verification module is configured to share a checksum value pertaining to at least one of the mobile application and the one or more resources of the mobile application to a user. The checksum verification module is also configured to verify the checksum value with a database to check the integrity of the at least one of the mobile application and the one or more resources of the mobile application. The system includes an encryption module operatively coupled to the checksum verification module wherein the encryption module is configured to perform multiple encryptions on the checksum value with a public key. The encryption module is also configured to decrypt the checksum value with a private key or a symmetric key to access the at least one of the mobile application and the one or more resources of the mobile application. The system includes a replay attack prevention module operatively coupled to the encryption module wherein the replay attack prevention module is configured to generate and amend a nonce value to the checksum in response to a request from the user for request of trust. Further, the system includes a processing module operatively coupled to the replay attack prevention module wherein the processing module is configured to generate a random number and return with mobile application static signature over the nonce value. The processing module is also configured to transmit the mobile application static signature to the server to validate the trust and receive a response from the server upon validation, wherein the response implies a success or a failure of the modification.
[0010] In accordance with another embodiment of the present disclosure, a method for runtime integrity validation to detect tampering of a mobile application is provided. The method includes constantly monitoring, by a tampering detection module, the mobile application and one or more resources of the mobile application during runtime. The method includes detecting, by the tampering detection module, in real time a modification of at least one of the mobile application and the one or more resources of the mobile application. The method includes providing, by the tampering detection module, information of the modification. The method includes sharing, by a checksum verification module, a checksum value pertaining to at least one of the mobile application and the one or more resources of the mobile application to a user. The method includes verifying, by the checksum verification module, the checksum value with a database to check the integrity of the at least one of the mobile application and the one or more resources of the mobile application. The method includes performing, by an encryption module, multiple encryptions on the checksum value with a public key. The method includes decrypting, by the encryption module, the checksum value with a private key or a symmetric key to access the at least one of the mobile application and the one or more resources of the mobile application. Further, the method includes generating, by a processing module, a random number and return with mobile application static signature over the nonce value. Furthermore, the method includes transmitting, by the processing module, the mobile application static signature to the server to validate the trust. Moreover, the method includes receiving, by the processing module, a response from the server upon validation, wherein the response implies a success or a failure of the modification.
[0011] To further clarify the advantages and features of the present disclosure, a more particular description of the disclosure will follow by reference to specific embodiments thereof, which are illustrated in the appended figures. It is to be appreciated that these figures depict only typical embodiments of the disclosure and are therefore not to be considered limiting in scope. The disclosure will be described and explained with additional specificity and detail with the appended figures.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] The disclosure will be described and explained with additional specificity and detail with the accompanying figures in which:
[0013] FIG. 1 is a block diagram representation of a system for runtime integrity validation to detect tampering of a mobile application, in accordance with an embodiment of the present disclosure;
[0014] FIG. 2 is a schematic representation of the relationship between the mobile application, processing subsystem and server of FIG. 1, in accordance with an embodiment of the present disclosure;
[0015] FIG. 3 is a schematic representation of an integration between a server, a mobile application and a processing subsystem of FIG. 1, in accordance with an embodiment of the present disclosure;
[0016] FIG. 4a and FIG. 4b is a schematic representation of communication for runtime integrity validation to detect tampering of a mobile application of FIG. 1, in accordance with an embodiment of the present disclosure;
[0017] FIG. 5 is a block diagram of a computer or a server in accordance with an embodiment of the present disclosure;
[0018] FIG. 6a illustrates a flow chart representing the steps involved in a method for a runtime integrity validation to detect tampering of a mobile application in accordance with an embodiment of the present disclosure; and
[0019] FIG. 6b illustrates a flow chart illustrating continued steps of the method of FIG. 6(a) in accordance with an embodiment of the present disclosure.
[0020] Further, those skilled in the art will appreciate that elements in the figures are illustrated for simplicity and may not have necessarily been drawn to scale. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the figures by conventional symbols, and the figures may show only those specific details that are pertinent to understanding the embodiments of the present disclosure so as not to obscure the figures with details that will be readily apparent to those skilled in the art having the benefit of the description herein.
DETAILED DESCRIPTION
[0021] For the purpose of promoting an understanding of the principles of the disclosure, reference will now be made to the embodiment illustrated in the figures and specific language will be used to describe them. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended. Such alterations and further modifications in the illustrated system, and such further applications of the principles of the disclosure as would normally occur to those skilled in the art are to be construed as being within the scope of the present disclosure.
[0022] The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such a process or method. Similarly, one or more devices or subsystems or elements or structures or components preceded by "comprises... a" does not, without more constraints, preclude the existence of other devices, sub-systems, elements, structures, components, additional devices, additional sub-systems, additional elements, additional structures or additional components. Appearances of the phrase "in an embodiment", "in another embodiment" and similar language throughout this specification may, but not necessarily do, all refer to the same embodiment.
[0023] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this disclosure belongs. The system, methods, and examples provided herein are only illustrative and not intended to be limiting.
[0024] In the following specification and the claims, reference will be made to a number of terms, which shall be defined to have the following meanings. The singular forms “a”, “an”, and “the” include plural references unless the context clearly dictates otherwise.
[0025] In accordance with an embodiment of the present disclosure, a system for runtime integrity validation to detect tampering of a mobile application is provided. The system includes a tampering detection module configured to constantly monitor the mobile application and one or more resources of the mobile application during runtime. The tampering detection module is also configured to detect in real time a modification of at least one of the mobile application and the one or more resources of the mobile application and provide information of the modification. The system also includes a checksum verification module operatively coupled to the tampering detection module wherein the checksum verification module is configured to share a checksum value pertaining to at least one of the mobile application and the one or more resources of the mobile application to a user. The checksum verification module is also configured to verify the checksum value with a database to check the integrity of the at least one of the mobile application and the one or more resources of the mobile application. The system includes an encryption module operatively coupled to the checksum verification module wherein the encryption module is configured to perform multiple encryptions on the checksum value with a public key. The encryption module is also configured to decrypt the checksum value with a private key or a symmetric key to access the at least one of the mobile application and the one or more resources of the mobile application. The system includes a replay attack prevention module operatively coupled to the encryption module wherein the replay attack prevention module is configured to generate and amend a nonce value to the checksum in response to a request from the user for request of trust. Further, the system includes a processing module operatively coupled to the replay attack prevention module wherein the processing module is configured to generate a random number and return with mobile application static signature over the nonce value. The processing module is also configured to transmit the mobile application static signature to the server to validate the trust and receive a response from the server upon validation, wherein the response implies a success or a failure of the modification.
[0026] FIG. 1 is a block diagram representation of a system for runtime integrity validation to detect tampering of a mobile application, in accordance with an embodiment of the present disclosure. The system (100) includes a processing subsystem (105) hosted on a server (110). In one embodiment, the server (110) may include a cloud server. In another embodiment, the server (110) may include a local server. In a specific embodiment, the server (110) is a mobile application backend server. The processing subsystem (105) is configured to execute on a network (145) to control bidirectional communications among a plurality of modules. In a preferred embodiment, the network (145) may include a Wireless local area network (WLAN) network, a cellular network and a Low-power wide-area (LPWA) network. In one embodiment, the network (145) may also include a wired network such as local area network (LAN), Wi-Fi, Bluetooth, Zigbee, near field communication (NFC), infra-red communication (RFID) or the like. Further, the plurality of modules includes a tampering detection module (120), a checksum verification module (125), an encryption module (130), a replay attack prevention module (135) and a processing module (140).
[0027] The tampering detection module (120) is configured to constantly monitor the mobile application and one or more resources of the mobile application during runtime. These resources could include files, databases, configuration settings, or other components that the mobile application relies on. The tampering detection module (120) continuously observe and keep track of specific aspects of the mobile application, ensuring that monitoring happens in real-time or throughout the operation of the mobile application. This means the monitoring takes place while the mobile application is actively running, as opposed to during installation, update, or at rest.
[0028] Further, the tampering detection module (120) is configured to detect in real time a modification of at least one of the mobile application and the one or more resources of the mobile application. The tampering detection module (120) is adapted to detect unauthorized changes or interference with the mobile application.
[0029] Furthermore, the tampering detection module (120) is configured to provide information of the modification. In other words, details of the modification are generated and shared.
[0030] The checksum verification module (125) is operatively coupled to the tampering detection module (120) wherein the checksum verification module (125) is configured to share a checksum value pertaining to at least one of the mobile application and the one or more resources of the mobile application to a user. A checksum is a value derived from a data set (in this case, the mobile application or its resources) that is used to verify data integrity. The checksum verification module (125) is adapted to to communicate the checksum value to a user. This value can be used by the user to verify that the mobile application or its resources have not been tampered with. The checksum value can be related to the entire mobile application or specific resources (for instance, files, configurations) within the mobile application.
[0031] Further, the checksum verification module (125) is configured to verify the checksum value with a database (150) to check the integrity of the at least one of the mobile application and the one or more resources of the mobile application. The checksum verification module (125) compares the checksum value it has generated (or received) with a reference checksum stored in a database (150). The purpose of this comparison is to determine whether the mobile application or its resources have been altered. If the checksum value matches the one in the database (150), the mobile application or resource is likely intact and unaltered. If it does not match, this suggests possible tampering or corruption.
[0032] The database (150) is a structured collection of data organized to facilitate efficient access, management, and updating. It serves as a central repository for storing and retrieving information, enabling mobile applications to store, retrieve, and manipulate data easily. The database (150) can range from simple flat file systems to complex relational databases like Structured query language (SQL), which use tables to store data in rows and columns. They are crucial in modern mobile applications for maintaining data integrity, ensuring scalability, and supporting transactions. Common database management systems include MySQL, Oracle, and MongoDB, each offering unique features suited to different use cases and scale requirements.
[0033] The encryption module (130) is operatively coupled to the checksum verification module (125) wherein the encryption module (130) is configured to perform multiple encryptions on the checksum value with a public key. The encryption module (130) is configured to apply encryption to the checksum value more than once. This might involve encrypting the checksum value several times, possibly using different techniques or keys to enhance security. The encryption is performed using a public key, which is a part of a public/private key pair in asymmetric cryptography. The public key is used for encryption, and only the corresponding private key can decrypt the encrypted checksum value.
[0034] Further, the encryption module (130) is configured to decrypt the checksum value with a private key or a symmetric key to access the at least one of the mobile application and the one or more resources of the mobile application. The encryption module (130) is not only capable of encrypting the checksum value but also of decrypting it. In the context of asymmetric cryptography, the private key is paired with the public key used for encryption. The private key is kept secret and is the only key that can decrypt data encrypted with its corresponding public key. In symmetric cryptography, the same key is used for both encryption and decryption. This is different from the asymmetric key pair system.
[0035] The encryption module (130) is flexible and can use either a private key (if asymmetric encryption was used) or a symmetric key (if symmetric encryption was used) to decrypt the checksum value. Decrypting the checksum value is necessary to verify the integrity of the mobile application or its resources. Only after successful decryption can the module confirm that the mobile application or its resources are authentic and have not been tampered with. In one embodiment, the encryption module (130 is configured with Rivest-Shamir-Adleman and advanced encryption standard techniques.

[0036] The replay attack prevention module (135) is operatively coupled to the encryption module (130) wherein the replay attack prevention module (135) is configured to generate and amend a nonce value to the checksum in response to a request from the user for request of trust. Typically, the replay attack prevention module (135) is configured to prevent replay attacks, which are security attacks where a valid data transmission is maliciously or fraudulently repeated or delayed. A nonce is a random or pseudo-random number that is used only once in a cryptographic communication. It helps in preventing replay attacks by ensuring that old communications cannot be reused maliciously. The replay attack prevention module (135) generates the nonce and attaches it to the checksum. This ensures that each checksum is unique for every request, making it impossible for an attacker to reuse an old checksum (which would be recognized as invalid due to the different nonce). When the user requests verification or confirmation, the replay attack prevention module (135) creates and adds a nonce to the checksum. This ensures the integrity of the request, thereby preventing any potential replay attacks.
[0037] The processing module (140) is operatively coupled to the replay attack prevention module (135) wherein the processing module (140) is configured to generate a random number and return with mobile application static signature over the nonce value. The random number is used in the cryptographic operations the enhance security. The mobile application static signature refers to a fixed or predetermined cryptographic signature associated with the mobile application. A signature is typically generated using a cryptographic key and serves to verify the authenticity and integrity of data. The processing module (140) uses the random number and the nonce value (which was generated and attached to the checksum by the replay attack prevention module (135)) to create this signature. This process essentially "signs" the nonce value with the mobile application's static signature, ensuring that the nonce is valid and associated with the specific mobile application.
[0038] Further, the processing module (140) is configured to transmit the mobile application static signature to the server to validate the trust. Typically, the server (110) is accountable for managing data, validating requests, and ensuring the security of interactions within a system (100). Specifically, the server (110) checks the signature to confirm the authenticity and integrity of the mobile application or the request. If the signature is valid, it indicates that the request or data being transmitted is trustworthy and has not been tampered with.
[0039] Furthermore, the processing module (140) is configured to receive a response from the server upon validation, wherein the response implies a success or a failure of the modification. After transmitting the mobile application static signature to the server (110) for validation, the processing module (140) is responsible for receiving a response back from the server (110). The response from the server (110) comes after it has completed the process of validating the mobile application static signature. This validation determines whether the request or modification being processed is authentic and secure. Further, if the validation is successful, the response from the server will indicate that the modification (likely a change or update to the mobile application or its resources) has been accepted and applied correctly. Likewise, if the validation fails, the server's response will indicate that the modification was unsuccessful. This could mean that the request was deemed untrustworthy, possibly due to a mismatch in the signature or other security concerns.
[0040] In one embodiment, the processing module (140) is configured to receive the nonce value and perform a plurality of validation techniques. The plurality of validation techniques comprises anti-reversing engineering, anti-debugging controls and runtime checksum with nonce validation. In one embodiment, the server (110) stores the nonce value for a predetermined time.
[0041] Consider a non-limiting example of a banking mobile application that runs runtime integrity validation to detect tampering. The banking mobile application includes a tampering detection module that constantly monitors its own code and resources during runtime. The tampering detection module is designed to detect any unauthorized modifications, such as changes in code, assets, configuration files, or other resources. Suppose a hacker attempts to tamper with the application by injecting malicious code or altering certain resources. The tampering detection module detects this modification in real-time. Upon detecting tampering, the tampering detection module logs details of the modification, such as which file was altered, the nature of the change, and the time it occurred. This information is then forwarded to relevant security components within the application. The mobile application’s checksum verification module computes a checksum value for the application and its resources. This value is shared with the user and checked against a database of known good values to determine if any part of the application has been altered. To secure the checksum, the checksum verification module encrypts it using a public key and later decrypts it using a private key (or symmetric key). This ensures that only authorized entities can access and verify the integrity of the checksum. To further strengthen security, the application's processing module generates a random nonce (a unique number used once) and computes a static signature over this nonce using a secure algorithm. This signature is unique to the current session and application instance. The processing module sends the generated signature to the bank's secure server to validate the application's trustworthiness. The server verifies the signature against known values and determines if the application is genuine or has been tampered with. It sends a response back to the application indicating whether the validation was successful or if a tampering attempt was detected. If tampering is detected, the application might lock itself, notify the user, or send an alert to the bank's security team for further investigation. If no tampering is detected, the mobile application continues to function normally.
[0042] FIG. 2 is a schematic representation of the relationship between the mobile application, processing subsystem and server of FIG. 1, in accordance with an embodiment of the present disclosure. A mobile application first requests for a trust (210) to the processing subsystem (105) of the system (100). A request to initialize (215) is simultaneously sent from the mobile application to the processing subsystem (105). The processing subsystem (105) responds to the mobile application with a mobile application signature. The processing subsystem (105) monitors for any possible interruption (225) in the mobile application at run-time. The mobile application then requests the server (108) to validate the trust. The server (108) responds as success or failure.
[0043] FIG. 3 is a schematic representation of an integration between a server, a mobile application and a processing subsystem of FIG. 1, in accordance with an embodiment of the present disclosure. In order to mitigate the chances of a client-side cyber-attack, a tightly coupled integration is established between the server (108), the mobile application (205) and the processing subsystem (105). As discussed earlier, the mobile application (205) communicates with the processing subsystem (105) by sending two types of requests. A request for initialization (310) starts up or configures the processing subsystem (105) to work with the mobile application (205) . Likewise, a request for trust (315) seeks to establish that the mobile application can be trusted and is not compromised. The processing subsystem (105) performs several checks to verify the integrity of the mobile application (205). The mobile application (205) integrity is verified over a trust validation by implementing anti-reverse engineering (320), anti-debugging controls (325) and runtime checksum with nonce validation (330). The anti-reverse engineering (320) is a technique to prevent an attacker from deconstructing the mobile application to understand its workings or exploit it. The anti-debugging controls (325) measures to detect and prevent debugging tools from analysing the mobile application. Debugging can be used to find vulnerabilities, so these controls help prevent such analysis. Further, the runtime checksum with nonce validation (330) is verified. The checksum is a value calculated from the mobile application’s code and data at runtime to detect changes or corruption. A nonce (a random value used only once) adds an additional layer of protection to ensure that the checksum is valid for the specific instance of the mobile application and not reused or spoofed.
[0044] After the completion of the checks, the processing subsystem (105) returns a mobile application signature to the mobile application (205). The mobile application (205) then sends a request to the server (108) for validation of the trust (340). The server (108) completes the integration by validating the nonce and static signature (345).
[0045] FIG. 4a and FIG. 4b is a schematic representation of communication for runtime integrity validation to detect tampering of a mobile application of FIG. 1, in accordance with an embodiment of the present disclosure. At the onset, the mobile application (205) sends a request for initialization to the processing subsystem (105). The mobile application (205) passes the nonce to the processing subsystem (105). The processing subsystem (105) validates various checksum (415) and appends the checksum with the nonce (420). A new checksum is created for the appended checksum (Part B) (425). Subsequently, the processing subsystem (105) applies RSA encryption with a public key to the appended checksum (Part A) (430). Part A and Part B are merged (435) and subsequently an AES encryption is applied to the merged parts (440). The processing subsystem (105) generates and returns the final trust to the mobile application (205) (445). The mobile application (205) then communicates to the server (108) by sending a trust (450). The server (108) then decrypts the merged A and B using AES encryption (455). Subsequently, RSA encryption is applied with a private key to decrypt Part A (460). The server (108) then validates the uniqueness of the nonce (465) and validates the decrypted appended nonce and checksum with Part B (470).
[0046] FIG. 5 is a block diagram of a computer or a server (108) in accordance with an embodiment of the present disclosure. The server (108) includes processor(s) (510), and memory (520) operatively coupled to the bus (530). The processor(s) (510), as used herein, means any type of computational circuit, such as, but not limited to, a microprocessor, a microcontroller, a complex instruction set computing microprocessor, a reduced instruction set computing microprocessor, a very long instruction word microprocessor, an explicitly parallel instruction computing microprocessor, a digital signal processor, or any other type of processing circuit, or a combination thereof.
[0047] The memory (520) includes several subsystems stored in the form of executable program which instructs the processor (510) to perform the method steps illustrated in FIG. 1. The memory (520) includes a processing subsystem (105) of FIG.1. The processing subsystem (105) includes a plurality of modules.
[0048] The plurality of modules includes a tampering detection module (120), a checksum verification module (125), an encryption module (130), a replay attack prevention module (135) and a processing module (140). The tampering detection module (120) is configured to constantly monitor the mobile application and one or more resources of the mobile application during runtime. The tampering detection module (120) is also configured to detect in real time a modification of at least one of the mobile application and the one or more resources of the mobile application and provide information of the modification. The checksum verification module (125) is operatively coupled to the tampering detection module (120) wherein the checksum verification module (125) is configured to share a checksum value pertaining to at least one of the mobile application and the one or more resources of the mobile application to a user. The checksum verification module (125) is also configured to verify the checksum value with a database to check the integrity of the at least one of the mobile application and the one or more resources of the mobile application. The encryption module (130) operatively coupled to the checksum verification module (125) wherein the encryption module (130) is configured to perform multiple encryptions on the checksum value with a public key. The encryption module (130) is also configured to decrypt the checksum value with a private key or a symmetric key to access the at least one of the mobile application and the one or more resources of the mobile application. The replay attack prevention module (135) is operatively coupled to the encryption module (130) wherein the replay attack prevention module (135) is configured to generate and amend a nonce value to the checksum in response to a request from the user for request of trust. Further, the processing module (140) is operatively coupled to the replay attack prevention module (135) wherein the processing module (140) is configured to generate a random number and return with mobile application static signature over the nonce value. The processing module (140) is also configured to transmit the mobile application static signature to the server to validate the trust and receive a response from the server upon validation, wherein the response implies a success or a failure of the modification.
[0049] The bus (230) as used herein refers to be internal memory channels or computer network that is used to connect computer components and transfer data between them. The bus (230) includes a serial bus or a parallel bus, wherein the serial bus transmits data in bit-serial format and the parallel bus transmits data across multiple wires. The bus (230) as used herein, may include but not limited to, a system bus, an internal bus, an external bus, an expansion bus, a frontside bus, a backside bus and the like.
[0050] FIG. 6a illustrates a flow chart representing the steps involved in a method for a runtime integrity validation to detect tampering of a mobile application in accordance with an embodiment of the present disclosure. FIG. 6b illustrates a flow chart illustrating continued steps of the method of FIG. 6(a) in accordance with an embodiment of the present disclosure.
[0051] The method (300) includes constantly monitoring, by a tampering detection module, the mobile application and one or more resources of the mobile application during runtime in step (305). This monitoring happens in real-time while the mobile application is running. Any attempts to alter, modify, or interfere with the mobile application's code or behaviour is detected to ensure the integrity of the mobile application while it is running. A "modification" could refer to anything from altering the code, changing configuration files, adjusting memory values, or interfering with network communications.
[0052] The method (300) includes detecting, by the tampering detection module, in real time a modification of at least one of the mobile application and the one or more resources of the mobile application in step (310). The one or more resources of the mobile application refers to various elements or assets used by the mobile application, such as memory, files, network connections, or other system resources that are critical to the mobile application's functioning. Further, the detection happens immediately as the mobile application is running, without delay. This ensures that any modifications are caught as soon as they occur, allowing for a quick response.
[0053] The method (300) includes providing, by the tampering detection module, information of the modification in step (315). After detecting a modification, the tampering detection module is responsible for reporting or sharing details about the modification. This involves generating and delivering information about what was changed, when, and possibly how or by whom. In other words, the information refers to the data or details related to the unauthorized change. Examples of the information includes but is not limited to, what part of the mobile application or resource was modified, the nature of the modification (for instance, code change, memory alteration, file tampering), the time at which the modification was detected, possibly other contextual information that might help in diagnosing or responding to the tampering.
[0054] The method (300) includes sharing, by a checksum verification module, a checksum value pertaining to at least one of the mobile application and the one or more resources of the mobile application to a user in step (320). A checksum is a unique value derived from the content of the mobile application or its resources. It is used to detect any unauthorized changes or corruption. The checksum is then shared to the user. This step involves making the checksum value accessible or visible to the user so they can verify the integrity of the mobile application or its resources. The user can use this value to independently verify that the mobile application or its resources have not been tampered.
[0055] The method (300) includes verifying, by the checksum verification module, the checksum value with a database to check the integrity of the at least one of the mobile application and the one or more resources of the mobile application in step (325). A checksum is a unique value calculated based on the content of the mobile application or its resources, used to detect any unauthorized changes or corruption. After generating the checksum, this value is checked against a trusted source to ensure that the mobile application or its resources have not been altered. This verification process is essential for confirming the integrity of the mobile application.
[0056] Further, the calculated checksum value is compared against a stored, trusted checksum value in a database. This database contains the correct or expected checksum values for the mobile application and its resources, serving as a reference for integrity checks. The purpose of this verification is to confirm that the mobile application and its resources are in their expected state and have not been tampered with. If the checksum matches the one in the database, it indicates that the mobile application or resource is intact and unaltered.
[0057] The method (300) includes performing, by an encryption module, multiple encryptions on the checksum value with a public key in step (330). The checksum value is encrypted more than once, using different layers or rounds of encryption. The purpose of multiple encryptions is to add additional security, making it significantly harder for an attacker to decipher the checksum value. In encryption, a public key is part of a pair of keys used in asymmetric cryptography. The public key is used to encrypt data, and the corresponding private key is used to decrypt it. This ensures that only someone with the private key (usually a trusted party) can access the original data.
[0058] The method (300) includes decrypting, by the encryption module, the checksum value with a private key or a symmetric key to access the at least one of the mobile application and the one or more resources of the mobile application in step (335). The encrypted checksum value is converted back into its original form. Decryption is the reverse of encryption and requires a specific key. In asymmetric encryption, a private key is paired with a public key. The public key is used for encryption, and the private key is used for decryption. The private key is kept secret and is known only to the intended recipient or owner. In symmetric encryption, the same key is used for both encryption and decryption. Unlike the public-private key pair, a symmetric key is shared secretly between the parties involved.
[0059] The method (300) includes generating, by a processing module, a random number and return with mobile application static signature over the nonce value in step (340).
[0060] In one embodiment, the processing module receives the nonce from the mobile application and subsequently performs a plurality of validation techniques. The plurality of validation techniques includes anti-reversing engineering, anti-debugging controls and runtime checksum with nonce validation. Anti-reverse engineering refers to techniques and practices designed to prevent or make it difficult for an attacker to analyse and understand the underlying code, algorithms, or data structures of a mobile application. Anti-debugging controls are mechanisms within a software mobile application that detect and prevent the use of debugging tools. Debuggers are often used by attackers to step through code and understand how it works or to modify it at runtime. Anti-debugging controls aim to stop or hinder this process, protecting the software from tampering or unauthorized analysis. Further, a runtime checksum with nonce validation is a security measure where a checksum (a calculated value representing the state of data) is computed during the execution of a program and validated using a nonce (a unique, one-time number). This ensures the integrity of the code or data during runtime, making it difficult for attackers to tamper with the program without being detected.
[0061] The method (300) includes transmitting, by the processing module, the mobile application static signature to the server to validate the trust in step (345). A static signature is a unique, fixed identifier that represents the mobile application in its original, unaltered state. This signature is typically generated using cryptographic techniques and remains consistent as long as the mobile application hasn't been changed or tampered with. The processing module sends (transmits) the mobile application’s static signature from the local system to a remote server. This transmission is typically done over a secure communication channel to prevent interception or tampering during transit. Once the server receives the static signature, it compares it with a known, trusted version of the signature stored in its database. If the signatures match, it confirms that the mobile application has not been tampered with and is trustworthy. This step is essential for establishing or maintaining trust between the mobile application and the server.
[0062] The method (300) includes receiving, by the processing module, a response from the server upon validation, wherein the response implies a success or a failure of the modification in step (350). After transmitting the mobile application’s static signature to the server (as described in the previous step), the processing module waits for a reply from the server. This response indicates the outcome of the server’s validation process. The server is the remote system that has received the static signature and performed the validation against its stored data. The server compares the received static signature with the trusted version stored in its database to check for consistency and integrity. If the server finds that the static signature matches its trusted record, it implies that the mobile application has not been tampered with, and it is considered trustworthy. The response will indicate success. Likewise, if the server finds discrepancies between the received static signature and the trusted record, it implies that the mobile application may have been altered or is not trustworthy. The response will indicate failure.
[0063] Various embodiments of the present disclosure for a runtime integrity validation to detect tampering of a mobile application enables several advantages. The constant monitoring of the mobile application’s code and resources at runtime by the tampering detection module (120) allows for immediate detection of tampering attempts. Further, the use of techniques like checksum validation, integrity checks and anti-debugging mechanisms by the processing module (140) enables dynamic adaptation to detect tampering of mobile applications. Furthermore, the tampering detection module (120) not only detects tampering attempts but also provides detailed information on the modified components thereby enabling targeted mitigation and forensic analysis. Moreover, the system (100) can be integrated with existing app security frameworks and techniques such as code signing, certificate pinning, and secure network communication protocols. This integration enhances overall app security and complements other security measures implemented by developers.
[0064] It will be understood by those skilled in the art that the foregoing general description and the following detailed description are exemplary and explanatory of the disclosure and are not intended to be restrictive thereof.
[0065] While specific language has been used to describe the disclosure, any limitations arising on account of the same are not intended. As would be apparent to a person skilled in the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein.
[0066] The figures and the foregoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, the order of processes described herein may be changed and are not limited to the manner described herein. Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts need to be necessarily performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples.
, Claims:1. A system (100) for runtime integrity validation to detect tampering of a mobile application comprising:
characterized in that,
a processing subsystem (105) hosted on a server (110), wherein the processing subsystem (105) is configured to execute on a network (145) to control bidirectional communications among a plurality of modules comprising:
a tampering detection module (120) configured to:
constantly monitor the mobile application and one or more resources of the mobile application during runtime;
detect in real time a modification of at least one of the mobile application and the one or more resources of the mobile application; and
provide information of the modification;
a checksum verification module (125) operatively coupled to the tampering detection module (120) wherein the checksum verification module (125) is configured to:
share a checksum value pertaining to at least one of the mobile application and the one or more resources of the mobile application to a user;
verify the checksum value with a database to check the integrity of the at least one of the mobile application and the one or more resources of the mobile application;
an encryption module (130) operatively coupled to the checksum verification module (125) wherein the encryption module (130) is configured to:
perform multiple encryptions on the checksum value with a public key;
decrypt the checksum value with a private key or a symmetric key to access the at least one of the mobile application and the one or more resources of the mobile application;
a replay attack prevention module (135) operatively coupled to the encryption module (130) wherein the replay attack prevention module (135) is configured to generate and amend a nonce value to the checksum in response to a request from the user for request of trust; and
a processing module (140) operatively coupled to the replay attack prevention module (135) wherein the processing module (140) is configured to:
generate a random number and return with mobile application static signature over the nonce value;
transmit the mobile application static signature to the server to validate the trust; and
receive a response from the server upon validation, wherein the response implies a success or a failure of the modification.
2. The system (100) as claimed in claim 1, wherein the processing module (140) is configured to:
receive the nonce value; and
perform a plurality of validation techniques.
3. The system (100) as claimed in claim 2, wherein the plurality of validation techniques comprises anti-reversing engineering, anti-debugging controls and runtime checksum with nonce validation.
4. The system (100) as claimed in claim 1, wherein the server stores the nonce value for a predetermined time.
5. The system (100) as claimed in claim 1, wherein the encryption module (130) is configured to perform encryption using Rivest-Shamir-Adleman and advanced encryption standard techniques.
6. The system (100) as claimed in claim 1, wherein the nonce value is a variable appended to the first checksum.
7. A method (300) for runtime integrity validation to detect tampering of a mobile application comprising:
constantly monitoring, by a tampering detection module, the mobile application and one or more resources of the mobile application during runtime; (305)
detecting, by the tampering detection module, in real time a modification of at least one of the mobile application and the one or more resources of the mobile application; (310)
providing, by the tampering detection module, information of the modification; (315)
sharing, by a checksum verification module, a checksum value pertaining to at least one of the mobile application and the one or more resources of the mobile application to a user; (320)
verifying, by the checksum verification module, the checksum value with a database to check the integrity of the at least one of the mobile application and the one or more resources of the mobile application; (325)
performing, by an encryption module, multiple encryptions on the checksum value with a public key; (330)
decrypting, by the encryption module, the checksum value with a private key or a symmetric key to access the at least one of the mobile application and the one or more resources of the mobile application; (335)
generating, by a processing module, a random number and return with mobile application static signature over the nonce value; (340)
transmitting, by the processing module, the mobile application static signature to the server to validate the trust; (345) and
receiving, by the processing module, a response from the server upon validation, wherein the response implies a success or a failure of the modification. (350)
Dated this 19th day of September 2024

Signature

Jinsu Abraham
Patent Agent (IN/PA-3267)
Agent for the Applicant