METHOD AND DEVICE FOR PROVIDING VERIFYING APPLICATION INTEGRITY

Abstract

A device downloads and installs an APK file for the application, during which the code is modified. A checksum for the modified code is sent to a trusted entity that checks that the received checksum matches a stored checksum for the application. If so, the received checksum is signed and returned to the device where it is stored. The device can then check the integrity of the modified code by calculating a checksum for the modified code that is compared to the signed checksum. The solution is particularly suitable for devices using the Android OS since the DEX during installation is optimized to an ODEX for which there is no certified checksum.

Claims

1. A device for processing an application, the device comprising: a communications interface configured to receive the application; memory configured to store the application and a signed checksum; and a hardware processing unit configured to: modify the application to obtain a modified application; send a checksum generated for the modified application to a trusted entity; receive a signed checksum from the trusted entity, the signed checksum corresponding to the sent checksum; and store the signed checksum in the memory.

2. The device of claim 1, wherein the application is received with a first checksum and wherein the hardware processing unit is further configured to use the first checksum to verify the integrity of the application.

3. The device of claim 1, wherein the hardware processing unit is further configured to use the signed checksum to verify the integrity of the modified application at runtime of the modified application.

4. 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.

5. The device of claim 4, wherein the processing unit is configured to replace a checksum for the interpreted code with the signed checksum in a header for the interpreted code or the optimized interpreted code.

6. The device of claim 1, wherein the device is a smartphone or a tablet.

7. The device of claim 1, wherein the trusted entity is implemented in the device.

8. The device of claim 7, wherein the trusted entity is configured to store at least one checksum for the application, to verify that the checksum for the modified application matches a stored checksum for the application, and to use a signing key to sign the checksum for the modified application.

9. The device of claim 8, wherein the signing key is protected using software protection techniques.

10. The device of claim 1, wherein the trusted entity is a separate device and wherein the communications interface is further configured to receive the checksum for the modified application from the hardware processing unit and send the checksum for the modified application to the trusted entity, and to receive the signed checksum from the trusted entity and send the signed checksum to the hardware processing unit.

11. The device of claim 1, wherein the hardware processing unit is further configured to send an activation code for the application together with the checksum for the modified application.

12. The device of claim 1, wherein the hardware processing unit is configured to receive the signed checksum together with a signing certificate.

13. A method for processing an application comprising at a device: receiving by a communications interface the application; modifying by a hardware processor the application to obtain a modified application; sending by the hardware processor via the communications interface a checksum generated for the modified application to a trusted entity; receiving by the hardware processor via the communications interface a signed checksum from the trusted entity, the signed checksum corresponding to the sent checksum; and storing by the hardware processor the signed checksum in memory.

14. The method of claim 13, wherein receiving the application further comprises receiving a first checksum and wherein the method further comprises using by the hardware processor the first checksum to verify the integrity of the application.

15. The method of claim 13, further comprising using by the hardware processor the signed checksum to verify the integrity of the modified application at runtime of the modified application.

Description

BRIEF DESCRIPTION OF DRAWINGS

[0029] Preferred features of the present disclosure will now be described, by way of non-limiting example, with reference to the accompanying drawings, in which

[0030] FIG. 1 illustrates an exemplary system in which the disclosure is implemented; and

[0031] FIG. 2 illustrates a preferred embodiment of a method according to a preferred embodiment of the present disclosure.

DESCRIPTION OF EMBODIMENTS

[0032] FIG. 1 illustrates an exemplary system in which the disclosure is implemented. The system comprises a device 110, an application provider (application store) 120 and a trusted entity 130. The device 110 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”) 111, memory 112, a user interface 113 for interacting with a user, and a communications interface 114 for communication with the application provider 120 and the trusted entity 130 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.

[0033] The application provider 120 stores at least one application APK file 122 that can be downloaded by the device 110. The application provider 120 also comprises a hardware processor 124 configured to generate checksums for different ODEX or ELF files that correspond to the application DEX file. These checksums can be generated by installing the DEX file on different test or reference devices and calculate the checksum from the resulting ODEX or ELF files. The application provider 120 is also configured to send the checksums for the different ODEX or ELF files that correspond to the application DEX file to the trusted entity 130.

[0034] The trusted entity 130 can be implemented inside the Android OS or on an independent device. The trusted entity 130 comprises memory for storing ODEX or ELF checksums for an application, an interface for receiving an ODEX or ELF checksum from the Android OS on the device 110, a processing unit for verifying that the received ODEX or ELF checksum for an application matches a stored ODEX or ELF checksum for the application, a private signing key 132 to be used for signing ODEX or ELF checksums and an interface for sending a signed ODEX or ELF checksum to the device 110. In case the trusted entity 130 is implemented inside the Android OS, the private signing key is preferably protected using software protection techniques, such as code obfuscation and white-box cryptography, or through the use of specific hardware such as a key-store or a crypto engine.

[0035] FIG. 2 illustrates a flowchart of a method according to a preferred embodiment. In step S202, the application provider 120 sends to the trusted entity 130 a number of ODEX or ELF checksums for an application it offers to Android devices. In step S204, the device 110 downloads and installs the APK file for the application. As already mentioned, during installation, the device 110 optimizes or OAT compiles the DEX in the APK file, obtains an ODEX or ELF and adds to the DEX header the checksum for the ODEX or the ELF code. It should be noted that the hash in the CERT.SF file enables the device 110 to verify the integrity of the DEX.

[0036] When the application is to be executed for the first time, a Source Acquisition module reads the content of the ODEX or ELF file into the memory 112, reads the ODEX or ELF checksum (CS) from the DEX header and transmits it, in step S206, to the trusted entity 130. The ODEX or ELF checksum is preferably sent over a protected connection such as a Secure Authenticated Channel. The Source Acquisition module is included in a native library of the application (part of Android application can be developed using code other than Java such as C/C++ language). The Java Native Interface (JNI) enables JAVA code running in a Dalvik Machine to call native libraries delivered with the application.

[0037] In case the application requires an activation code to be entered, the checksum could be sent to the remote trusted entity 130 together with the activation code.

[0038] The trusted entity 130 preferably checks, in step S208, that the received ODEX or ELF checksum corresponds to one of the stored ODEX or ELF checksums for the application. If this is the case, in step S210 the trusted entity 130 signs the received ODEX or ELF checksum using the private signing key and returns, in step S212, the signed ODEX or ELF checksum to the device 110. The trusted entity 130 can also send a signing certificate comprising a corresponding public key together with the signed ODEX or ELF checksum.

[0039] In step S214, the Source Acquisition module receives and stores the signed ODEX or ELF checksum (and, if available and needed, the signing certificate).

[0040] The application or the Android OS, having access to a public key corresponding to the private signing key, can then check the integrity of the ODEX or ELF, in step S216, by calculating a checksum for the ODEX or ELF and comparing it to the signed ODEX or ELF checksum. The integrity of the signing certificate can also be verified through the use of a trusted root certificate installed on the device or through the use of a chain of certificates eventually leading to the trusted root certificate.

[0041] At subsequent executions of the application or at any time during the current execution of the application, the integrity of the application may be verified the same way as in step S216, i.e. by calculating a checksum for the ODEX or ELF and compare it to the signed ODEX or ELF checksum. To this end, it is advantageous that the option to check the integrity of the ODEX or ELF is set in the Android operating system.

[0042] It is noted that the solution is compatible with currently deployed Android systems since the code necessary for runtime integrity verification is either part of the existing Android OS or part of the delivered APK package for the application.

[0043] 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).

[0044] It will be appreciated that the present solution can counter remote attacks successfully.

[0045] Root attacks can also be countered if the trusted entity checks that the received ODEX or ELF checksum corresponds to a ‘legitimate’ code. This is to verify that the received ODEX checksum is not the checksum of an APK comprising modified code (which may be the case if the attacker modifies the code after download from the application provider). For this reason is it preferable for the application provider 120 to send the possible ODEX or ELF checksums to the trusted entity 130; in a variant, it is the trusted entity 130 that generates the different ODEX or ELF checksums by OAT compiling or optimizing for a given target device the DEX code of the application. It is noted that the number of potential checksums depends on a limited set of device hardware parameters (CPU endianness, CPU Symmetric MultiProcessing (SMP) mode, etc.) and thus the number of parameter combinations is limited. For instance, only the SMP mode differs for DEX optimization between a Nexus 7 and a Samsung galaxy tab P5100.

[0046] 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.

[0047] It will thus be appreciated that the present disclosure provides a solution that can enable runtime integrity of applications on Android devices.

[0048] 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.