EP3224722A1 - Method and device for providing verifying application integrity - Google Patents
Method and device for providing verifying application integrityInfo
- Publication number
- EP3224722A1 EP3224722A1 EP15804363.8A EP15804363A EP3224722A1 EP 3224722 A1 EP3224722 A1 EP 3224722A1 EP 15804363 A EP15804363 A EP 15804363A EP 3224722 A1 EP3224722 A1 EP 3224722A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- application
- code
- checksums
- signature
- checksum
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
- G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
- G06F11/1004—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
- G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
Definitions
- the present disclosure relates generally to computer systems and in particular to integrity of software code in such systems.
- checksum-based protection is CRC32 for the Portable Executable (PE) format used in the Windows operating system.
- PE Portable Executable
- a PE header contains a CRC32 field that gives the checksum of the corresponding code section.
- CRC32 field gives the checksum of the corresponding code section.
- an attacker first modifies the code section and then replaces the original checksum with a new value computed over the modified code section. This type of attack is possible since the attacker does not need any secret to update checksums of modified code sections.
- cryptographic signatures are a preferred solution. The generation of the signature is performed before the code release and uses a private (and thus secret) key. The associated public key is appended to the code and later used to check the code integrity at installation of the code or at runtime. An attacker can still modify the code, but since a correct signature for the code cannot be generated without the private key, the attack fails.
- Native code is a set of assembler instructions directly executable by the processor. The set of instructions does not change after installation, which means that a program integrity value remains the same before and after installation (i.e. remains constant over time). In this case, the signature can be generated beforehand and delivered with the application package.
- interpreted code - such as code written in Java, Android DEX code, etc. - comprise intermediate instructions that must be passed through an interpreter before it is executed.
- interpreted code can be modified after installation time for optimization purposes. The code modification is generally very dependent on the target platform and is thus not necessarily predictable. If the code is modified, a signature generated upon the interpreted code cannot be used to check code integrity and authenticity dynamically at runtime.
- APK - Android Application PacKage - To distribute and install application software onto the previously mentioned Android operating system a file format called APK - Android Application PacKage - is used.
- APK file a program for Android is first compiled to an intermediate language, and then its parts are packaged into a compressed archive file (ZIP format).
- the archive file contains the entire program code in a single DEX (Dalvik Executable code) file, various resources (e.g. image files), and the manifest of the APK file.
- the archive file comprises two additional files: CERT.SF and CERT.RSA. CERT.SF contains cryptographic hashes of all other archive files; CERT.RSA contains the public key used for signature verification. Only CERT.SF is signed with the RSA private key.
- the RSA signature for the CERT.SF enables validation of the entire content of the APK file during installation. Indeed, all the files mentioned in the CERT.SF file are indirectly signed because CERT.SF contains their hashes. Altering any file before installation would cause an error because the software would detect that a file digest does not match the hash in the CERT.SF file. Alternatively, modifying a cryptographic hash value inside the CERT.SF file (as in the attack against checksum-based verification already described) would lead to an error during the signature verification.
- a DEX file header also contains a global checksum for the contents of the DEX file.
- the Android system uses an optimizer which modifies a DEX interpreted byte code into an optimized machine- instructions sequence called ODEX (Optimized DEX) just in time before execution.
- ODEX Optimized DEX
- the optimizer also updates the checksum.
- the ODEX file is then stored in a specific repository within the Android file system for future use.
- the ODEX file then becomes the reference for the application software and, when it is present, the original DEX file is not used anymore.
- the system may verify the integrity of the application using the ODEX checksum.
- ODEX checksum This option is not set by default in the Android operating system and the Dalvik machine, which is used to execute ODEX code, does not always check ODEX checksums, since checksum verification has a non-negligible impact on execution performance and boot time.
- an APK even when not signed by a central authority, can be installed on an Android device if the user allows installation of application coming from untrusted sources.
- the application developers use then their own self-signed certificates that are not linked to any trusted authority. In that case tampered applications can be resigned and reinstalled by any hacker on the Android device unbeknownst to its owner.
- DEX interpreter portable format
- This portable format can execute on a large set of devices with different architectures and characteristics: ARM, x86, MIPS, Little/Big Endian etc.
- the DEX code is modified at installation time or at the first use of the application to produce the ODEX or the ELF binary that is optimized for the target device.
- OAT compilation various things can be modified in the code: instructions can be replaced by others, the alignment of instructions may be changed, the byte order can be swapped, and so on.
- the system is thus vulnerable to at least two classes of attacks: the remote attack and the root attack.
- the remote attack a downloaded malicious application elevates its privileges and gains system permissions.
- the malicious application may then tamper with ODEX and ELF files stored on the cache repository of the internal storage.
- the root attack the attacker obtains an Android device, for example by purloining the device or by accessing the device when the owner is absent without locking the device session.
- the attacker can retrieve installed application from the device's internal storage through a USB link, modify the application, and then push the modified application back onto the internal storage.
- the device must be "rooted” (i.e. "root access” is required to take control of the device's Android system).
- the trust in Android application integrity can thus be broken during the application's life cycle. It is possible to trust what is installed on an Android system, but not necessarily what is running.
- the disclosure is directed to a device for processing a modified application.
- the device comprises memory configured to store the application that has been obtained through modification of an original application and a plurality of different valid checksums, each valid checksum corresponding to an application obtained through a different modification of the original application, and a processing unit configured to, during execution of the application, generate a checksum for the application, and determine that the integrity of the application is valid in case the generated checksum matches one of the plurality of different valid checksums.
- the memory is further configured to store a signature for the plurality of different valid checksums and a corresponding certificate and that the processing unit is further configured to verify the validity of the signature and the validity of the certificate.
- the application is implemented as interpreted code and the modified application is implemented as an optimized interpreted code or as a native code.
- the disclosure is directed to a method for processing an application.
- a device During execution of the application a device generates a checksum for the application and determines that the integrity of the application is valid in case the generated checksum matches one of the plurality of different valid checksums.
- the device further verifies the validity of the signature using a certificate and verifies the validity of the certificate.
- the disclosure is directed to a computer executable program comprising instructions that, when executed by a processor, cause the processor to perform the method of the second aspect.
- the disclosure is directed to a device for generating an application package.
- the device comprises memory configured to store a signing key and a certificate for the signing key, and a processing unit configured to generate a plurality of checksums, each checksum corresponding to a modified application code resulting from a particular modification to an unmodified application code, sign the plurality of checksums using the signing key to obtain a signature, and store the unmodified application code, the plurality of checksums, the signature and the certificate for the signing key in the application package.
- the processor is further configured to output the application package.
- the disclosure is directed to a method for generating an application package.
- a device storing a signing key and a certificate for the signing key generates a plurality of checksums, each checksum corresponding to a modified application code resulting from a particular modification to an unmodified application code, signs the plurality of checksums using the signing key to obtain a signature, stores the unmodified application code, the plurality of checksums, the signature and the certificate for the signing key in the application package, and outputs the application package.
- Figure 1 illustrates an exemplary system in which the disclosure is implemented
- Figure 2 illustrates functional aspects of the exemplary system
- Figure 3 illustrates a preferred embodiment of a method according to a preferred embodiment of the present disclosure.
- a plurality of ODEX or ELF file checksums each checksum corresponding to a specific, possible ODEX or set of ELF files, are delivered with the DEX.
- the integrity of the ODEX or ELF files is then verified by comparing a generated checksum against the plurality of ODEX or ELF file checksums.
- FIG. 1 illustrates an exemplary system in which the disclosure is implemented.
- the system comprises a device 1 10 and an application provider (preferably the creator of the application, but it may also be an application store) 120.
- the device 1 10 can be any kind of suitable device running an Android OS, such as a smartphone or a tablet, and it comprises at least one hardware processing unit (“processor") 1 1 1 , memory 1 12, a user interface 1 13 for interacting with a user, and a communications interface 1 14 for communication with the application provider 120 over a connection 140 such as the Internet.
- processor hardware processing unit
- memory 1 12 for interacting with a user
- a communications interface 1 14 for communication with the application provider 120 over a connection 140 such as the Internet.
- connection 140 such as the Internet
- the application provider 120 comprises a processing unit (“processor") 124 and a trusted entity 126 that is configured to store a signing key and a corresponding certificate 128.
- the processing unit 124 is configured to perform a plurality of optimizations on a DEX to obtain a plurality of ODEX files or sets of ELF files and to calculate checksums for each of the plurality of ODEX files or sets of ELF files.
- the trusted entity 126 which can be implemented in the processing unit 124, is configured to generate a signature for the plurality of checksums for the plurality of ODEX files or sets of ELF files.
- the processing unit 124 is further configured to generate an APK file 122 comprising the DEX, the plurality of checksums, the signature and the certificate 128, and to output the generated APK file 122.
- the different ODEX files or sets of ELF files and corresponding checksums are for different optimizations of the DEX, for example depending on processor architecture (e.g. single core or multi-core), processor endianess, and version of the Android OS.
- FIG. 2 illustrates functional aspects of the application in the APK file 122.
- the application 220 comprises the APK certificate 222 signed by a signatory entity, application code 224 (DEX before installation and ODEX or ELF files after installation), and signed ODEX or ELF file checksums (CS) 226.
- the application 200 further comprises a library 230 comprising a source acquisition module 232 and an integrity verification module 234 having access to the certificate 128.
- the source acquisition module 232 and the integrity verification module 234 are comprised in the native library of the APK that is packaged with the application and has access to the extended JNI library that among other things allows signature verification.
- the source acquisition module 232 is configured to extract the plurality of ODEX or ELF file checksums 226 and the certificate 228.
- the integrity verification module 234 is configured to generate a checksum for the ODEX or ELF files 224, to compare the generated checksum with the plurality of ODEX or ELF file checksums 226. In case the generated checksum does not match any of the plurality of ODEX or ELF file checksums, it is determined that the integrity of the ODEX or ELF files is not valid. In case the generated checksum matches one of the plurality of ODEX or ELF file checksums 226, the signature is verified using the public key in the certificate 228. If successfully verified, the certificate 228 is verified as is well known in the art. If the certificate is successfully verified, it is determined that the integrity of the ODEX or ELF files is valid.
- FIG. 3 illustrates a flowchart of a method according to a preferred embodiment.
- the device 1 10 executes the ODEX or ELF files, i.e. the modified code, obtained by modification of a DEX, i.e. the unmodified code.
- step S304 the device 1 10 generates an ODEX or ELF file checksum for the ODEX or ELF files 224 and, in step S306, checks whether the generated ODEX or ELF file checksum matches one of the plurality of stored ODEX or ELF file checksums 226.
- the device 1 10 verifies the signature on the plurality of stored ODEX or ELF file checksums 226 in step S308, and, if successfully verified, verifies the validity of the certificate in step S310.
- the integrity of the ODEX or ELF files is determined to have been verified in case of positive verification of the certificate since this is done in the instance where the signature is valid and where the generated ODEX or ELF file checksum matches one of the plurality of stored ODEX or ELF file checksums.
- the integrity may be checked a plurality of times during the execution of the application.
- checksum' is intended to cover a value that enables verification of whether or not the data for which it was generated has been modified after generation of the checksum.
- a checksum may thus for example also be a hash value, a Cyclic Redundancy Check (CRC) value or other kind of digest; it is preferred that it is computationally infeasible to obtain the code from the checksum.
- CRC Cyclic Redundancy Check
- the signature may be any suitable cryptographic signature such as a Hash-based Message Authentication Code (HMAC) or a signature based on for example RSA, Digital Signature Algorithm (DSA) or Elliptic Curve Digital Signature Algorithm (ECDSA).
- HMAC Hash-based Message Authentication Code
- DSA Digital Signature Algorithm
- EDSA Elliptic Curve Digital Signature Algorithm
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Stored Programmes (AREA)
- Detection And Correction Of Errors (AREA)
Abstract
During execution of modified code (S302), a device (110) generates (S304) a checksum for the modified code, and checks (S306) whether the generated checksum matches one of a plurality of stored possible checksums for the modified code (226), each possible checksum corresponding to a possible code obtained by modification of an original code that was modified to obtain the modified code. In case of a match, the device (110) verifies (S308) a signature on the plurality of stored possible checksums (226), and, if successfully verified, verifies (S310) the validity of a certificate for the signing key. The solution is particularly suitable for devices using the Android OS since the DEX during installation is optimized to an ODEX or OAT complied to ELF files for which there is no certified checksum.
Description
METHOD AND DEVICE FOR PROVIDING VERIFYING APPLICATION
INTEGRITY
TECHNICAL FIELD
The present disclosure relates generally to computer systems and in particular to integrity of software code in such systems.
BACKGROUND
This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present disclosure that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present disclosure. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art. It is, for various reasons, often desirable to ensure that processing devices execute software that has not been tampered with. To this end, different techniques can be used to protect a software image against tampering attacks. The most common technique is to compute a signature or a checksum over code segments and then verify the signature or checksums at a later stage. Checksums are generally computed and verified without any secret while the generation of a cryptographic signature requires a private key and verification of the signature the corresponding public key.
An example of checksum-based protection is CRC32 for the Portable Executable (PE) format used in the Windows operating system. A PE header contains a CRC32 field that gives the checksum of the corresponding code section. To bypass the protection successfully, an attacker first modifies the code section and then replaces the original checksum with a new value computed over the modified code section. This type of attack is possible since the attacker does not need any secret to update checksums of modified code sections.
Given the weakness of checksums, cryptographic signatures are a preferred solution. The generation of the signature is performed before the code release and uses a private (and thus secret) key. The associated public key is appended to the code and later used to check the code integrity at installation of the code or at runtime. An attacker can still modify the code, but since a correct signature for the code cannot be generated without the private key, the attack fails.
Many solutions exist for checking the integrity of applications delivered and executed in native code, such as the solutions provided by Arxan (GuardIT™), Metaforic (Metafortress™), etc. Native code is a set of assembler instructions directly executable by the processor. The set of instructions does not change after installation, which means that a program integrity value remains the same before and after installation (i.e. remains constant over time). In this case, the signature can be generated beforehand and delivered with the application package.
On the other hand, applications distributed in the form of interpreted code - such as code written in Java, Android DEX code, etc. - comprise intermediate instructions that must be passed through an interpreter before it is executed. Unlike native code, interpreted code can be modified after installation time for optimization purposes. The code modification is generally very dependent on the target platform and is thus not necessarily predictable. If the code is modified, a signature generated upon the interpreted code cannot be used to check code integrity and authenticity dynamically at runtime.
To distribute and install application software onto the previously mentioned Android operating system a file format called APK - Android Application PacKage - is used. To make an APK file, a program for Android is first compiled to an intermediate language, and then its parts are packaged into a compressed archive file (ZIP format). The archive file contains the entire program code in a single DEX (Dalvik Executable code) file, various resources (e.g. image files), and the manifest of the APK file. The archive file comprises two additional files: CERT.SF and CERT.RSA. CERT.SF contains cryptographic
hashes of all other archive files; CERT.RSA contains the public key used for signature verification. Only CERT.SF is signed with the RSA private key. The RSA signature for the CERT.SF enables validation of the entire content of the APK file during installation. Indeed, all the files mentioned in the CERT.SF file are indirectly signed because CERT.SF contains their hashes. Altering any file before installation would cause an error because the software would detect that a file digest does not match the hash in the CERT.SF file. Alternatively, modifying a cryptographic hash value inside the CERT.SF file (as in the attack against checksum-based verification already described) would lead to an error during the signature verification.
A DEX file header also contains a global checksum for the contents of the DEX file. At the first execution of the application, the Android system uses an optimizer which modifies a DEX interpreted byte code into an optimized machine- instructions sequence called ODEX (Optimized DEX) just in time before execution. The optimizer also updates the checksum. The ODEX file is then stored in a specific repository within the Android file system for future use. The ODEX file then becomes the reference for the application software and, when it is present, the original DEX file is not used anymore.
At runtime, the system may verify the integrity of the application using the ODEX checksum. However this option is not set by default in the Android operating system and the Dalvik machine, which is used to execute ODEX code, does not always check ODEX checksums, since checksum verification has a non-negligible impact on execution performance and boot time.
Android version 5.0 and higher introduced the Android Runtime (ART) which replaces the Dalvik machine. The application are still deployed in DEX code, but at installation time, the DEX code is compiled to native code using the ahead-of-time compilation (AOT) feature. The AOT compilation on a DEX file results in a binary Executable Linkable Format (ELF) file. The DEX code of the application is then compiled once and then the ELF code is afterward launched each time the application is executed. As ART runs native code directly (ELF code), it brings faster execution of applications and improves the overall power
consumption. Thus it can be seen that in an Android system, the APK signature is verified only at installation time. Furthermore, an APK, even when not signed by a central authority, can be installed on an Android device if the user allows installation of application coming from untrusted sources. The application developers use then their own self-signed certificates that are not linked to any trusted authority. In that case tampered applications can be resigned and reinstalled by any hacker on the Android device unbeknownst to its owner.
As already mentioned, Android applications use an interpreter portable format (DEX). This portable format can execute on a large set of devices with different architectures and characteristics: ARM, x86, MIPS, Little/Big Endian etc. In order to improve performance, the DEX code is modified at installation time or at the first use of the application to produce the ODEX or the ELF binary that is optimized for the target device. During optimization or OAT compilation, various things can be modified in the code: instructions can be replaced by others, the alignment of instructions may be changed, the byte order can be swapped, and so on.
The optimization and OAT compilation then raise a security issue. While the signature of the DEX file can still be verified using the CERT.SF and CERT.RSA, this is not the case for the ODEX and ELF files since they have been modified and their integrity is no more linked to the original DEX signature. In other words, integrity and authenticity can only be verified at installation, but not at runtime since an attacker is able to modify the ODEX and ELF code and update the eventual checksum in the header accordingly.
The system is thus vulnerable to at least two classes of attacks: the remote attack and the root attack. In the remote attack, a downloaded malicious application elevates its privileges and gains system permissions. The malicious application may then tamper with ODEX and ELF files stored on the cache repository of the internal storage. In the root attack, the attacker obtains an Android device, for example by purloining the device or by accessing the device when the owner is absent without locking the device session. The attacker can retrieve installed application from the device's internal storage through a USB
link, modify the application, and then push the modified application back onto the internal storage. For the latter attack to be successful, the device must be "rooted" (i.e. "root access" is required to take control of the device's Android system). The trust in Android application integrity can thus be broken during the application's life cycle. It is possible to trust what is installed on an Android system, but not necessarily what is running.
It will be appreciated that it is desired to have a solution that overcomes at least part of the problems related to the integrity and authenticity of interpreted code applications. The present disclosure provides such a solution.
SUMMARY OF DISCLOSURE
In a first aspect, the disclosure is directed to a device for processing a modified application. The device comprises memory configured to store the application that has been obtained through modification of an original application and a plurality of different valid checksums, each valid checksum corresponding to an application obtained through a different modification of the original application, and a processing unit configured to, during execution of the application, generate a checksum for the application, and determine that the integrity of the application is valid in case the generated checksum matches one of the plurality of different valid checksums.
Various embodiments of the first aspect include:
That the memory is further configured to store a signature for the plurality of different valid checksums and a corresponding certificate and that the processing unit is further configured to verify the validity of the signature and the validity of the certificate.
That the application is implemented as interpreted code and the modified application is implemented as an optimized interpreted code or as a native code.
That the device is a smartphone or a tablet.
In a second aspect, the disclosure is directed to a method for processing an application. During execution of the application a device generates a checksum for the application and determines that the integrity of the application is valid in case the generated checksum matches one of the plurality of different valid checksums.
In an embodiment of the second aspect there is a signature for the plurality of different valid checksums and the device further verifies the validity of the signature using a certificate and verifies the validity of the certificate.
In a third aspect, the disclosure is directed to a computer executable program comprising instructions that, when executed by a processor, cause the processor to perform the method of the second aspect.
In a fourth aspect, the disclosure is directed to a device for generating an application package. The device comprises memory configured to store a signing key and a certificate for the signing key, and a processing unit configured to generate a plurality of checksums, each checksum corresponding to a modified application code resulting from a particular modification to an unmodified application code, sign the plurality of checksums using the signing key to obtain a signature, and store the unmodified application code, the plurality of checksums, the signature and the certificate for the signing key in the application package.
In an embodiment of the fourth aspect, the processor is further configured to output the application package.
In a fifth aspect, the disclosure is directed to a method for generating an application package. A device storing a signing key and a certificate for the signing key generates a plurality of checksums, each checksum corresponding to a modified application code resulting from a particular modification to an unmodified application code, signs the plurality of checksums using the signing key to obtain a signature, stores the unmodified application code, the plurality of
checksums, the signature and the certificate for the signing key in the application package, and outputs the application package.
BRIEF DESCRIPTION OF DRAWINGS
Preferred features of the present disclosure will now be described, by way of non-limiting example, with reference to the accompanying drawings, in which Figure 1 illustrates an exemplary system in which the disclosure is implemented; Figure 2 illustrates functional aspects of the exemplary system; and Figure 3 illustrates a preferred embodiment of a method according to a preferred embodiment of the present disclosure. DESCRIPTION OF EMBODIMENTS
According to the present disclosure, a plurality of ODEX or ELF file checksums, each checksum corresponding to a specific, possible ODEX or set of ELF files, are delivered with the DEX. The integrity of the ODEX or ELF files is then verified by comparing a generated checksum against the plurality of ODEX or ELF file checksums.
Figure 1 illustrates an exemplary system in which the disclosure is implemented. The system comprises a device 1 10 and an application provider (preferably the creator of the application, but it may also be an application store) 120. The device 1 10 can be any kind of suitable device running an Android OS, such as a smartphone or a tablet, and it comprises at least one hardware processing unit ("processor") 1 1 1 , memory 1 12, a user interface 1 13 for interacting with a user, and a communications interface 1 14 for communication with the application provider 120 over a connection 140 such as the Internet. The skilled person will appreciate that the illustrated device is very simplified for reasons of clarity and that real devices in addition would comprise features such as power supplies and persistent storage.
The application provider 120 comprises a processing unit ("processor") 124 and a trusted entity 126 that is configured to store a signing key and a corresponding certificate 128. The processing unit 124 is configured to perform a plurality of optimizations on a DEX to obtain a plurality of ODEX files or sets of
ELF files and to calculate checksums for each of the plurality of ODEX files or sets of ELF files. The trusted entity 126, which can be implemented in the processing unit 124, is configured to generate a signature for the plurality of checksums for the plurality of ODEX files or sets of ELF files. The processing unit 124 is further configured to generate an APK file 122 comprising the DEX, the plurality of checksums, the signature and the certificate 128, and to output the generated APK file 122.
The different ODEX files or sets of ELF files and corresponding checksums are for different optimizations of the DEX, for example depending on processor architecture (e.g. single core or multi-core), processor endianess, and version of the Android OS.
Figure 2 illustrates functional aspects of the application in the APK file 122. The application 220 comprises the APK certificate 222 signed by a signatory entity, application code 224 (DEX before installation and ODEX or ELF files after installation), and signed ODEX or ELF file checksums (CS) 226. The application 200 further comprises a library 230 comprising a source acquisition module 232 and an integrity verification module 234 having access to the certificate 128.
The source acquisition module 232 and the integrity verification module 234 are comprised in the native library of the APK that is packaged with the application and has access to the extended JNI library that among other things allows signature verification.
The source acquisition module 232 is configured to extract the plurality of ODEX or ELF file checksums 226 and the certificate 228. The integrity verification module 234 is configured to generate a checksum for the ODEX or ELF files 224, to compare the generated checksum with the plurality of ODEX or ELF file checksums 226. In case the generated checksum does not match any of the plurality of ODEX or ELF file checksums, it is determined that the integrity of the ODEX or ELF files is not valid.
In case the generated checksum matches one of the plurality of ODEX or ELF file checksums 226, the signature is verified using the public key in the certificate 228. If successfully verified, the certificate 228 is verified as is well known in the art. If the certificate is successfully verified, it is determined that the integrity of the ODEX or ELF files is valid.
It will be appreciated that suitable measures may be taken in the instance that the integrity is not valid.
Figure 3 illustrates a flowchart of a method according to a preferred embodiment. In step S302, the device 1 10 executes the ODEX or ELF files, i.e. the modified code, obtained by modification of a DEX, i.e. the unmodified code.
In step S304, the device 1 10 generates an ODEX or ELF file checksum for the ODEX or ELF files 224 and, in step S306, checks whether the generated ODEX or ELF file checksum matches one of the plurality of stored ODEX or ELF file checksums 226.
In the instance of a match in step S306, the device 1 10 verifies the signature on the plurality of stored ODEX or ELF file checksums 226 in step S308, and, if successfully verified, verifies the validity of the certificate in step S310. The integrity of the ODEX or ELF files is determined to have been verified in case of positive verification of the certificate since this is done in the instance where the signature is valid and where the generated ODEX or ELF file checksum matches one of the plurality of stored ODEX or ELF file checksums.
The integrity may be checked a plurality of times during the execution of the application.
It is noted that the solution does not require any modification to currently deployed Android systems.
In the present description, the term 'checksum' is intended to cover a value that enables verification of whether or not the data for which it was generated has been modified after generation of the checksum. A checksum may thus for example also be a hash value, a Cyclic Redundancy Check (CRC) value or other kind of digest; it is preferred that it is computationally infeasible to obtain the code from the checksum. In addition, while a single checksum has been used for clarity, a plurality of checksums may be used, wherein a checksum may be generated for a distinct part of the code (wherein the different parts may overlap), and that a plurality of checksums for different parts of the code are used to generate a single, global checksum that is used for the comparison. The signature may be any suitable cryptographic signature such as a Hash-based Message Authentication Code (HMAC) or a signature based on for example RSA, Digital Signature Algorithm (DSA) or Elliptic Curve Digital Signature Algorithm (ECDSA). It will be appreciated that the present solution can counter both root attacks and remote attacks successfully.
While the present solution has been described in an Android environment, it can be adapted to other operating systems that modify the code during installation without enabling secure integrity verification of the installed application at runtime.
It will thus be appreciated that the present disclosure provides a solution that can enable runtime integrity of applications on Android devices.
Each feature disclosed in the description and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination. Features described as being implemented in hardware may also be implemented in software, and vice versa. Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.
Claims
1 . A device (1 10) for processing an application (224), the device comprising: memory (1 12) configured to store the application (224) that has been obtained through modification of an original application and a plurality of different valid checksums (226), each valid checksum corresponding to an application obtained through a different modification of the original application; and
a processing unit (1 1 1 ) configured to, during execution of the application (224):
- generate a checksum for the application (224); and
- determine that the integrity of the application is valid in case the generated checksum matches one of the plurality of different valid checksums (226).
2. The device of claim 1 , wherein the memory is further configured to store a signature for the plurality of different valid checksums (226) and a corresponding certificate (228) and wherein the processing unit (1 1 1 ) is further configured to verify the validity of the signature and the validity of the certificate.
3. The device of claim 1 , wherein the application is implemented as interpreted code and the modified application is implemented as an optimized interpreted code or as a native code.
4. The device of claim 1 , wherein the device is a smartphone or a tablet.
5. A method for processing an application comprising at a device (1 10) during execution (S302) of the application:
- generating (S304) a checksum for the application; and
- determining (S306) that the integrity of the application is valid in case the generated checksum matches one of the plurality of different valid checksums (226).
6. The method of claim 5, wherein there is a signature for the plurality of different valid checksums (226), the method further comprising:
- verifying (S308) the validity of the signature using a certificate (228); and
- verifying (S310) the validity of the certificate.
7. A computer executable program (220) comprising instructions that, when executed by a processor (1 10), cause the processor to perform the method of claim 5.
8. A device (120) for generating an application package (122; 220), the device comprising:
memory configured to store a signing key and a certificate for the signing key (128); and
a processing unit (124) configured to:
- generate a plurality of checksums, each checksum corresponding to a modified application code resulting from a particular modification to an unmodified application code;
- sign the plurality of checksums using the signing key to obtain a signature; and
- store the unmodified application code, the plurality of checksums, the signature and the certificate for the signing key (128) in the application package.
9. The device of claim 8, wherein the processor is further configured to output the application package (122; 200).
10. A method for generating an application package (122; 220), the method comprising, in a device (120) comprising a processing unit (124) and memory storing a signing key and a certificate for the signing key (128):
- generating a plurality of checksums, each checksum corresponding to a modified application code resulting from a particular modification to an unmodified application code;
- signing the plurality of checksums using the signing key to obtain a signature;
- storing the unmodified application code, the plurality of checksums, the signature and the certificate for the signing key (128) in the application package; and
- outputting the application package (122; 200).
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP14306921.9A EP3026560A1 (en) | 2014-11-28 | 2014-11-28 | Method and device for providing verifying application integrity |
PCT/EP2015/077837 WO2016083542A1 (en) | 2014-11-28 | 2015-11-26 | Method and device for providing verifying application integrity |
Publications (1)
Publication Number | Publication Date |
---|---|
EP3224722A1 true EP3224722A1 (en) | 2017-10-04 |
Family
ID=52023432
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP14306921.9A Withdrawn EP3026560A1 (en) | 2014-11-28 | 2014-11-28 | Method and device for providing verifying application integrity |
EP15804363.8A Withdrawn EP3224722A1 (en) | 2014-11-28 | 2015-11-26 | Method and device for providing verifying application integrity |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP14306921.9A Withdrawn EP3026560A1 (en) | 2014-11-28 | 2014-11-28 | Method and device for providing verifying application integrity |
Country Status (3)
Country | Link |
---|---|
US (1) | US20170262657A1 (en) |
EP (2) | EP3026560A1 (en) |
WO (1) | WO2016083542A1 (en) |
Families Citing this family (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9058483B2 (en) | 2008-05-08 | 2015-06-16 | Google Inc. | Method for validating an untrusted native code module |
US9176754B2 (en) * | 2008-07-16 | 2015-11-03 | Google Inc. | Method and system for executing applications using native code modules |
US10642971B2 (en) * | 2017-09-04 | 2020-05-05 | Cisco Technology, Inc. | Methods and systems for ensuring program code flow integrity |
CN107729198B (en) * | 2017-10-18 | 2020-04-21 | 深圳合纵富科技有限公司 | Android system firmware verification method and device |
CN113645230B (en) * | 2018-06-06 | 2023-04-28 | 北京八分量信息科技有限公司 | System and method for analyzing credibility value of node |
FR3083343B1 (en) * | 2018-06-29 | 2023-05-26 | Ingenico Group | METHOD FOR DETERMINING THE VALIDITY OF A CORRESPONDING APPLICATION CODE, DEVICE AND COMPUTER PROGRAM PRODUCT. |
US10776094B2 (en) * | 2018-07-29 | 2020-09-15 | ColorTokens, Inc. | Computer implemented system and method for encoding configuration information in a filename |
US11886390B2 (en) | 2019-04-30 | 2024-01-30 | JFrog Ltd. | Data file partition and replication |
US11340894B2 (en) | 2019-04-30 | 2022-05-24 | JFrog, Ltd. | Data file partition and replication |
US11386233B2 (en) | 2019-04-30 | 2022-07-12 | JFrog, Ltd. | Data bundle generation and deployment |
US11106554B2 (en) | 2019-04-30 | 2021-08-31 | JFrog, Ltd. | Active-active environment control |
FR3105484B1 (en) * | 2019-12-19 | 2021-12-10 | Commissariat Energie Atomique | METHOD OF DYNAMIC VERIFICATION OF THE INTEGRITY OF A MACHINE CODE |
US11695829B2 (en) | 2020-01-09 | 2023-07-04 | JFrog Ltd. | Peer-to-peer (P2P) downloading |
US11860680B2 (en) | 2020-11-24 | 2024-01-02 | JFrog Ltd. | Software pipeline and release validation |
US12061889B2 (en) | 2021-10-29 | 2024-08-13 | JFrog Ltd. | Software release distribution across a hierarchical network |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2362314A1 (en) * | 2010-02-18 | 2011-08-31 | Thomson Licensing | Method and apparatus for verifying the integrity of software code during execution and apparatus for generating such software code |
US8650439B2 (en) * | 2010-12-07 | 2014-02-11 | Samsung Electronics Co., Ltd. | Apparatus and method for fault tolerant FOTA update |
WO2012109640A2 (en) * | 2011-02-11 | 2012-08-16 | Siemens Healthcare Diagnostics Inc. | System and method for secure software update |
KR101299099B1 (en) * | 2011-09-07 | 2013-09-16 | 주식회사 팬택 | Apparatus and method for management of optimized virtualization module in embedded system |
US9715591B2 (en) * | 2012-07-30 | 2017-07-25 | Hewlett-Packard Development Company, L.P. | Code validation |
-
2014
- 2014-11-28 EP EP14306921.9A patent/EP3026560A1/en not_active Withdrawn
-
2015
- 2015-11-26 EP EP15804363.8A patent/EP3224722A1/en not_active Withdrawn
- 2015-11-26 US US15/531,440 patent/US20170262657A1/en not_active Abandoned
- 2015-11-26 WO PCT/EP2015/077837 patent/WO2016083542A1/en active Application Filing
Non-Patent Citations (2)
Title |
---|
None * |
See also references of WO2016083542A1 * |
Also Published As
Publication number | Publication date |
---|---|
US20170262657A1 (en) | 2017-09-14 |
WO2016083542A1 (en) | 2016-06-02 |
EP3026560A1 (en) | 2016-06-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20170262657A1 (en) | Method and device for providing verifying application integrity | |
US20170262656A1 (en) | Method and device for providing verifying application integrity | |
US20170270319A1 (en) | Method and device for providing verifying application integrity | |
US20170262658A1 (en) | Method and device for providing verifying application integrity | |
US7577848B2 (en) | Systems and methods for validating executable file integrity using partial image hashes | |
US10992482B2 (en) | Verified boot and key rotation | |
CN112507328B (en) | File signature method, computing device and storage medium | |
JP6332970B2 (en) | System and method for secure software update | |
US7739516B2 (en) | Import address table verification | |
EP3343424B1 (en) | Control board secure start method, and software package upgrade method and device | |
CN105426750A (en) | Startup method of embedded system, and embedded device | |
CN112511306A (en) | Safe operation environment construction method based on mixed trust model | |
CN117556430B (en) | Safe starting method, device, equipment and storage medium | |
JP2024528585A (en) | Secure execution of software based on cryptographically verified instructions | |
Athalye et al. | Package manager security | |
WO2023136829A1 (en) | Firmware authentication | |
CN112257033A (en) | Application packaging method, device and equipment | |
CN116049781A (en) | Method for determining authenticity of binary image |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20170522 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) | ||
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20190601 |