Provably Secure APK Redevelopment Authorization Scheme in the Standard Model

Daofeng Li , Mingxing Luo , Bowen Zhao and Xiangdong Che

Abstract: The secure issues of APK are very important in Android applications. In order to solve potential secure problems and copyrights issues in redevelopment of APK files,in this paper we propose a new APK redevelopment mechanism (APK-SAN). By exploring sanitizable signature technology, APK-SAN allows the original developer to authorize specified modifier who can redevelop the designated source code of APK files.Our scheme does not require interactions between the developer and modifiers. It can reduce the communication overhead and computational overhead for developers.Especially, the signature of redeveloped APK files is valid and maintains the copyrights.The proposed APK-SAN signature can effectively protect the security of the redeveloped APK files and copyrights of the developer and modifier.

Keywords: Sanitizable signature, APK signature mechanism, redevelopment, ID-based signature scheme.

1 Introduction

Due to the popularity and open source characteristics of Android system, various Android applications require to be redeveloped in different institutions, regional, and groups, such as alipay, health monitoring, weather forecast [Qin (2016); Enck, Damien and McDaniel(2011); Chen, Ying, Jiao et al. (2014); Qu, Keeney, Robitzsch et al. (2016)]. In these applications, one company Bob can require one developer Alice to redevelop his APP for special requirements. Alice authorizes Bob to redevelop specified part of APK files (one of Android files) [Park and Choi (2015); Jeon, Micinski and Vaughan (2012); Neidhardt(2011); Kim, Yoon, Yi et al. (2012); Karim, Kagdi and Penta (2016)]. In procedure of redeveloping, Bob should finish tasks accord to the authorization. If Alice’s authorization is not satisfied, the unspecified files of Bob are over-privileges [Toorani and Beheshti(2008); Silva, Amcrim and Ribeiro (2015); Pearce, Nunez and Wagner (2012); Choi,Sung, Choi et al. (2015); Barrera, Kayacik, van Oorschot et al. (2010); Blasing, Batyuk,

Schmidt et al. (2010); Felt, Wang, Moshchuk et al. (2011); Egele, Brumley, Fratantonio et al. (2013)]. This problem is very important and relates to copyrights protection.

The over-privilege is a serious problem in various mobile applications. It can be caused by malicious code embedding or data manipulating. It is an unavoidable problem derived from interactions in applications. In order to protect the legitimacy, copyrights and permission of Android APKs, there are various mechanisms deployed in Android system,such as signature [Toorani and Beheshti (2008); Egele, Brumley, Fratantonio et al. (2013);Shao (2014); Ma, Li and Deng (2016)], sandbox [Blasing, Batyuk, Schmidt et al. (2010)]and permission management [Karim, Kagdi and Penta (2016); Barrera, Kayacik, van Oorschot et al. (2010); Felt, Wang, Moshchuk et al. (2011)]. Signature is required by the APK developer to protect the integrity of APK before publishing APK application in APP store. Specifically, the developer uses the self-signed digital certificate for the compilation of packaging APK. The signature ensures the integrity, authenticity, nonrepudiation of APK, and the uniqueness of APK providers, further to protect the developer’s copyrights. Sandbox requires that all applications have to run on the Dalvik virtual machine. Sandbox and POSIX realize automatic management of Android applications that can ensure secure operations of APK. Copyrights management mainly protects commercial applications and Android system.

Authorization permissions of Android applications are divided into four levels: normal,dangerous, signature, and signature or system. These permissions are defined and declared in Android manifest file by the developer. However, it is coarse-grained and cannot protect users’ sensitive information for some Android applications [Silva, Amcrim and Ribeiro (2015); Choi, Sung, Choi et al. (2015)]. AdDroid is proposed [Pearce, Nunez and Wagner (2012)]. It is an Android advertising privilege separation mechanism, and used to protect the users’ privacy information. Meanwhile, a practical and efficient permission certification technique is explored [Dimitriadis, Efraimidis and Katos (2016)]by using the runtime information and static analysis to solve the problems of unauthorized APK.

In order to prevent embedded malicious code and copyrights issues, the third party needs to be authorized for modifying APK file. In this paper, we focus on licensing source codes for modifying. We propose a provably secure APK authorization scheme that is named as APK-SAN authorization mechanism in a standard model [Ateniese, Chou,DeMedeiros et al. (2005); Brzuska, Fischlin, Freudenreich et al. (2009)]. Our authorization has unique attribute, i.e. identity-based sanitizable signature. It allows APK developer to authorize the third party (the modifier) who can redevelop and modify APK licensing area or position. Moreover, the signature of new APK is still valid. The new mechanism is useful for protecting the copyrights of the modified APK, and can prevent from flooding malicious APK files. It does not require interacting with each other after authorizing the third party. This feature provides a fine-grained authorization. To sum up,APK-SAN authorization mechanism has the following improvements:

(1) Fine-grained authorization. When the third party applies for redeveloping a native APK, the developer authorizes he/she to modify files and position. The developer takes use of the identity-based sanitizable signature. If the third party complies with the permission license and redevelops the designated file or position, and the modified APK is legal and valid. Otherwise, the signature verification of the modified APK can detect an unauthorized redevelopment.

(2) Provable security. APK-SAN authorization mechanism mainly adopts the identitybased sanitizable signature to implement the access authorization. In this paper, we prove our scheme under a standard model.

The rest of the paper is organized as follows. In Section 2, we provide an overview of the An-droid signature mechanism, identity-based sanitizable signature scheme, and secure model. We present a protection mechanism using the identity-based sanitizable signature scheme and over-privileged applications in Section 3. In Section 4, we evaluate the security and performance of the proposed scheme while we conclude the paper in the last section.

2 Preliminaries

2.1 Android native signature mechanism

Unsigned APK usually makes up of res folder, lib folder, resources, files (rousouces.arsc,classes.dex and AndroidManifest.XML), as shown in Fig. 1.

Figure 1: Unsigned APK file format

When the third party redevelops APK, these files (folders) need to be modified. The developer of the original APK has to specify which files can be modified when he authorizes the redeveloper. The resources of each file (folders) are as follows:

(1) res folder: Deposits resource files, such as pictures, layout files, etc.;

(2) lib folder: Deposits.so dynamic link library, and .so dynamic link library are executable files, which are generated by the native code of JNI layer compiling and linking and performed by the Linux kernel. If there are no native codes in the source codes, no lib folder is included in APK;

(3) resources.arsc file. Compiled binary resource file;

(4) classes.dex file. Dalvik executable file, performed by Dalvik virtual machine. Android compiler compiles the project source codes;

(5) .class files. DX tool converts all .class files to executable classes.dex file;AndroidManifest.xml file: Global configuration file.

Android system specifies that all published APK files have to be signed by developers prior to install. By signing the compiled and packaged APK files, one can ensure the integrity of APK, authenticity and non-repudiation, while the rights and interests of developers.

APK signature is as follows:

(1) Generate MANIFEST.MF file. Traverse all files in APK file. Use SHA-1 hash algorithm to generate hash value of files, and encode each hash value with Base64 encoding. All of them are saved in MANIFEST.MF file.

(2) Generate CERT.SF file. Compute MANIFEST.MF file and its content hash value with SHA-1 hash algorithm. Encode each hash value with Base64 encoding, and then store them in CERT.SF file.

(3) Generate CERT.RSA file. Sign CERT.SF file and its contents with RSA signature algorithm and the developer’s private key. Create a CERT.RSA file including signature and self-signed public key certificate of the developer.

(4) Package all generated signature files. Package all files of MANIFEST.MF, CERT.SF and CERT.RSA in “/META-INF” directory.

2.2 Identity-based sanitizable signature scheme

In sanitizable signature scheme, the signer allows the specified modifier to modify the designated part without interacting with each other, where the modified signature is still valid. In this paper, we propose a new scheme consisting of the signer, sanitizer and verifier using the identity-based sanitizable signature scheme (IBSSS for short). New scheme is implemented as follows:

Let user’s identity beID= (ID1, ID2,…, IDn)∈{0,1}λand signature message beM=(M1, M2,…, Mn)∈{0,1}λ. Signer executes the following operations:

(1) Setup system parameters.Given a security parameterk, private key generator(PKG) generates system parametersparamsand master keymsk.paramsis published whilemskis kept confidentially.

(2) Create user keys.Given a user and its identityID, PKG calculates user’s private keydIDwith master keymsk.dIDis sent to a user via a secure channel.

(3) Sign.System parametersparams, signer’s identityID, messageMand signer’s private keydIDare input parameters of signature algorithm. Signer outputs signatureσand secret informationψ.

(4) Sanitize.System parametersparams, Sanitizer’s identityID′, secret informationψand signatureσof messageMare input parameters of sanitizable algorithm. The sanitizer outputs a new signatureσ′of messageM′.

(5) Verify.System parametersparams, signer’s identityIDi, messages/signatures(Mi′, σ ′i)and (Mi,σi)are input parameters of the verification algorithm. If the verification is valid, outputs "True". Otherwise, outputs "False".

2.3 Secure model

Diffie-Hellman ProblemLet G1be an additive group of orderq, and G2be a multiplicative groups,gbe a generator of G2. The map e: G1× G1→G2, possess the following properties:

(1) Bilinearity.For ?a, b∈Zq,P, Q∈G1, and e(P a, Qb) = e(P, Q)ab;

(2) Nondegeneracy.There existsP, Q∈G1, makes e(P, Q)≠1;

(3) Computability.There exists an efficient algorithm to compute e(P, Q) forP, Q∈G1.

Definition 1. Computational Diffie-Hellman (CDH) Problem. G1is a finite additive group.Giveng,ga, gb∈G1, for unknowna,b∈computegab.

Definition 2.The (ε, t)-CDH assumption. If there is not-time adversary who has at leastεsuccess probability of solving CDH problem for group G1, then the assumption of CDH problem is correct.

Obviously, if (ε, t)-CDH hypothesis is true, CDH problem is a mathematical puzzle[Brzuska, Fischlin, Freudenreich et al. (2009); Waters (2005)].

Combining with the secure model of sanitizable signature and secure mechanisms provided by APK-SAN authorization mechanism, we present two secure models with the unforgeable and immutable attributes.

Unforgeability:Signature generated by the signer and sanitizer cannot be forged in scheme.

Immutability:Sanitizer can only modify the designated part of files by the signer.

For the unforgeability and immutability, the interactive processes of challenger C and attacker A are as follows:

(1) Setup system parameters.

(2) Request private key.Attacker A specifies an identityIDfor APK developer.Challenger C executes the key generation algorithm to generate identityIDfor APK developer or private keydIDfor modifier, and sendsdIDto A;

(3) Request sign.Attacker A specifies an identity for the APK developer or modifier,signatures messagesMand signer’s private keydID. Challenger C executes the extraction key and signature algorithms to generate a signatureσof (ID, M), and sendsσto A;

(4) Forage and modify signature. Attacker A can successfully modify specifications of an APK developer with the identityIDor signature of the modifier if the following conditions are satisfied: (a) Attacker A does not specifies an APK developer with the identityID′or request to extract the modifier’s private key: (b)Attacker A does not request sign for developed APK (Unforgeability); (c) Attacker A can sign unspecified part of APK (allow to modify), and signatureσ′is still valid (Immutability).

If an attacker A successfully forges or modifies an APK signature, it is an instance solving CDH problem.

3 IBSSS based APK authorization mechanism

In order to facilitate the normal operation mechanism, we assume that the developer of a native APK file can authorize modifier to modify APK file if there is a modifier apply to redevelop. Meanwhile, in this paper, “redevelopment” is synonymous with “modification”,and the user represents modifier. The fine-grained authorization in APK-SAN is defined as follows:

Figure 2: The process of the redevelopment authorization request of APK file. There are five steps to complete a redevelopment. (1) The original developer publishes an APP in APP store. (2) A special user downloads APP and experiences servers. (3) The user or modifier applies a redevelopment of APP for some special goals. (4) The developer authorizes and specifies modifiable files or source codes of APP. (5) Modifier publishes the modified APP

Definition 3.Fine-grained authorization means that the developer of a native APK file has permissions to authorize the redevelopment or modify the designated APK file.In this section, combing with the identity-based sanitizable signature, we propose a finegrained APK redevelopment authorization mechanism (APK-SAN). APK redevelopment process is shown in Fig. 2. Specific steps are as follows:

(1) Publish applications.The developer publishes signed APK file in APP store;

(2) Users experience.The users download APK from APP market. According to special requirements, users can request to redevelop APK during the process of experiencing. For example, they find some bugs which may affect users’experience. So, it should be repaired. In another case, users need to add some business functions in the original APK to complete the customization;

(3) Request authorization.The user sends the redevelopment request of the native APK authorization;

(4) Authorization.The developer authorizes and specifies the user who can modify which files. In this step, we use the identity-based sanitizable signature to complete the authorization. Section 3.2 contributes specific implementation of this component;

(5) Publish modified applications.The user validates the developer’s authorization legitimacy and effectiveness. Section 3.3 explains the detailed implementation of this component. And then, according to the modifying authorization, user modifies the native APK file, and signs the modified APK file. Finally, user republishes it in APP store. The contents of the specific implementation are detailed in Section 3.4.

The operations of Steps (4) and (5) are used to complete the APK-SAN authorization mechanism that consists of four parts: key generation, APK redevelopment authorization,redevelopment process, and modified validation.

3.1 Key generation

Setup system parameters.Given a security parameterk, PKG chooses two cyclic groups G1and G2of prime orderq, a generatorgand an admissible bilinear pairing e:G1× G1→G2, PKG chooses a random integer α∈, computesg1=gα, and selectsg2∈G1. Furthermore, he choosesu′,m′∈G1and two vectors u = (u1,…,un),v=(v1,…, vn)of lengthn, whose entries are random elements in G1. The system parameters areparams=(G1,G2,e, q, g, g1, g2,u′,m′,u,v), and the master key is.

User’s private key.Each developer use identity informationIDi=Hash(Comi|| IDEi||ti) as its public key. Here,Comiis a formal data representation of company’s name;IDEiis unique identification number of the developer;tiis valid time of the developer’s public key.IDiis sent to PKG. PKG randomly picksrIDiand computes private keydIDias follows:

wherei= 1,2,..., n.

3.2 APK file generation and publishing

Before publishing APK, the authorization is that the developer specifies modifiable files(folders) and source codes.

(1) Setup APK file. After completing Android development, the developer packages Java files, resources XML file, Class files, and Dex file into APK file. And then,he/she computes hash values of res folder, lib folder, resources.arsc file,classes.dex file and An- droidManifest.xml file in APK, and encodes them with based64 encoding, which generates Manifest.MF and CERT.SF files as follows:

(2) Sign APK file. The developer randomly (uniform probability) picks, and signs APK file using Eq. (2), which generates CERT.SAN file:

(3) The developer packages Manifest.MF, CERT.SF and CERT.SAN files into APKSAN.SIG files that are stored in “/META-INF” directory, and publishes in APK file.

3.3 Redevelopment authorization

After publishing APK, if the developer receives the requirement of redevelopment from a user, he completes authorization operations as follows:

(1) The developer specifies modifiable files (folders) and programmable source codes.We assume that a modifiable folders’ seth′= {hi′} ,hi′includes the corresponding hash codes, andh′? {hi},i∈K={1,2,...,5}.

(2) LetK′={i∈K|hi=hi′} ,K′′= {i∈K|hi≠hi′}be an index set of the modifiable folders.K′′is an index set of the unmodifiable folders. The developer completes the authorization as follows:

whereh′′=Base6 4(Hashfori∈K′.is the authorization of a given modifier with the identityIDrevfor an indexi∈K′.is the immutable folder.

(3) The developer sends the authorized APK file, corresponding source codes and authorization informationh′, andσaut=to the modifier.

3.4 Redevelopment process

In the process of redevelopment, the modifier firstly verifies the authorization legitimacy and effectiveness. And then, he/she modifiesfiles according to the authorization information, and finally signs the modified APK. After receiving the authorized APK file and the corresponding source codes from the developer, the modifier retrieves secret authorization information and signature informationfrom APK AUTH.Sig in APK file “/META-INF” directory as follows:

(1) Verifying the effectiveness of the signatureσ. If the signature is efficient, the modifier executes the Step (2). Otherwise, terminates the protocol.

(2) Combing with the authorization informationh′, the modifier modifies the modifiable files and the corresponding source codes to generate a new APK file,and reintegrates a new APK file according to the format of Fig. 1 intonshares as

Here,=Base6 4(Hash(drev||file(i) ||IDrev))andfile(i) is the modifiedi-th file (folder).

(3) After completing the redevelopment, using Eq. (4) the modifier randomly chooses∈and calculates the signature of the modified files as:

where σiare defined asand

(4) Generating the signature file APKSAN.SIG and storing in the corresponding“/META- INF” directory. The modifier saves the signature (σ,σ)into the file, and repackages them to generate a new APK file.

4 Security analysis of APK-SAN

4.1 Validation

The verifier verifies the legitimacy of the signatureandσaut. In this section, we only show the verification ofandas follows:

4.2 Security analysis of the proposed scheme

Definition 4.An adversary A has attack abilityIn APK-SAN scheme, if A makesqeprivate key extraction queries andqssignature queries, the adversary with a nonnegligible advantageεcan successfully forge the original APK signature or the modifier’s signature with timet.

Definition 5. If APK-SAN authorization can resist the attack in Definition 4, it is secure for.

Theorem 1.If the assumption(ε′,t′)-CDH is true, APK-SAN authorization is secure for

Proof.Assume that there is an adversary A who is able to successfully attack APK-SAN authorization. It means that A can successfully forge the authorizationσof APK-SAN authorization. Namely, A makesqeprivate key extraction queries andqssignature queries,according to APK-SAN, it can successfully forge validly sanitizable signature with a nonnegligible advantageεand timet. Under these assumptions, given a group G1and its generatorg, there is an algorithm (Algorithm 1) with advantageε′, which can solve an instance of CDH problem with timet′. It means that after receivinggaandgb, A with Algorithm 1 can computegab,whereε′=1/( 16q(q+q)(n+1)2)andt′=t+O(5qe+(2n+4)qs)The length of APK file isnbits. It costs timetto execute the exponent arithmetic of the group G1.

When the attacker A can successfully attack APK-SAN authorization and forge an authorization (a signature), Algorithm 1 can solve a specific CDH problem instance which involves five steps of attack scenario as follows:

?

Note that the constructed private keysEq. (5) are valid because

?

and

To complete the proof, we need the following lemma:

Lemma 1.In order to ensure that there is at leastε′success probability to solve an instance of CDH problem, Algorithm B needs to satisfy the following three facts at the same time:

E1 When the adversary A requests the private key extraction, Algorithm 1 does not terminates, namely,F(ID* )≠0modru;

E2 The adversary A can generate authorization (signature) of the APK file generated by the developer/modifier with the identityID′, which requiresK(h* )≠0modrm;

E3 If the adversary A successfully forges the authorization (signature) of an APK file,which requires that they meet at the same timeF(ID′)=0 modqandK(h′)=0 modq,where 1 ≤i≤n;

Proof of Lemma 1.LetUibe the event ofF(ID* )≠0modru,U*be the event ofF(ID*)=0 modq, andVjbe the event ofF(ID* )≠0modqandK(h′)=0 modq. The success probability of Algorithm 1 is given by

where Eqs. (25) and (26) are obtained from the independence ofUi,U*,Vj,V*]. Here,Pr[U*]and Prare calculated as follows:

Hence,ε′is givenε′=ε/ (16qs(qe+qs)(n+1)2).

In the redevelopment and modification of APK, modifier can only modify the designated deposition or files of APK, as well as signs the modified APK files with the sanitizable signature. He cannot modify the unauthorized deposition or files of APK. Specifically, if adversary A can modify the unauthorized deposition or files of APK, namely those files encoded with base64, they have to meet timeK′′= {i∈K|hi≠hi′}, and generate a sanitizable signature. It means that the propose APK-SAN authorization mechanism is not unforgettable secure. So, we obtain that:

Theorem 2.Assume there is a polynomial bounded adversary A that is able to break the immutability of APK-SAN authorization with an advantageε′with timet, andqe′private key extraction queries andqs′signature queries. Then there exists an Algorithm 2 that can generate a valid signature with timet′′and advantageε′′.

Proof.The immutability of the authorized deposition of APK file means that: If advantage A deliberately or illegally modifies those files encoded with base64 and meets timeK′′= {i∈K|hi≠hi′}according to the signature verification we can discover the illegal modifications, and notice modified APK file is invalid. If adversary A is able to break the immutability of the authorized deposition of APK file, it means that Algorithm 2 is able to generate a valid signature. Algorithm 2 is defined as follows:

Algorithm 2 S1 Setup. Algorithm 2 interacts with the challenger C as follows:– Algorithm 2 submits a request to the challenger C, and C returns system parameters (G1, G2, e, q, g, g1, g2,u′, v′, u, v);– For be a system parameter;i K′∈, Algorithm 2 chooses *i q t∈Z, and lets i t i u=g be a system parameter.S2 Private key extraction query. When A issues a private key of the modifier with the identity extraction query, Algorithm 2 acts as follows:– For i K′∈, Algorithm 2 chooses *i q s∈Z, and lets i s i v=g– Issues a private key query of the modifier with the identity ID’, and gets the private key 11(1) (2)( , )i i ID ID d d??

Obviously, the premise that Algorithm 2 successfully forges a signature of the APK file is that A is able to alter the immutability of the APK-SAN authorization. Therefore,Algorithm 2 has the success probabilityε′′≥ε.

Meanwhile, the timet′′of Algorithm 2 is summation of A’s running timetand the time which is used to respond to′private key extraction queries and′signature queries.Each private key extraction query requires Algorithm 2 to performnexponentiation operations in G1. Each signature query requires Algorithm 2 to perform 2nexponentiation operations in G1. We assume that the exponentiation operation in G1takes timete, Hence, the total time is

?

5 Performances of the proposed scheme

In this section, we discuss the efficiency and security of the proposed scheme. For the cost of computation and storage, we only consider the following items: Signature overhead, verification overhead and increased size of the signature. For the computation complexity and memory space, we consider the computation costs of cryptographic operations involved in signature and verification schemes. For the space, we measure the memory cost, focus on the storage cost of key including the sizes of public key and private key.

5.1 The costs of computation and storage

Consider the scenario: After the developer accomplishes APK, a modifier applies for modifying the APK. The developer authorizes the modifier to improve or increase some functions in APK’s specified location. According to the requirements of Android signature, the modifier can carry out two operations as following:

(1) After completing the modification, the modifier sends the modified APK to the developer. The developer signs and releases it;

(2) The modifier directly signs and releases the modified APK.

Table 1: The comparing of the overhead costs. SO denotes the signature overhead. VO denotes the verification overhead. IS denotes the increased size which means the size of extra signature file. Rd denotes the decryption overhead of one time RSA algorithm. Re denotes the encryption overhead of one time RSA algorithm. T denotes the transmission overhead that an applicant returns to the designer. m denotes the number of APK files to modify. Ep denotes the exponentiation operation overhead. E denotes the logarithm operation overhead

The operations in Scheme 1 [Neidhardt (2011)] belong to the first operation type, which are used to protect the integrity of APK file based on RSA algorithm. The operations in APKSAN scheme belong to the second operation type. In this paper, we attempt to provide a scheme that the modifier is able to directly sign and release the modified APK. Meanwhile,one can verify the copyrights of APK. We assume that the Android signature is based on RSA algorithm, known as Scheme 1 [Neidhardt (2011)]. Their computation and storage costs are shown in Tab. 1. Here, each APK containsnfiles.Pis a large prime integer used in this paper. Obviously,m

From Tab. 1, the signature overhead of Scheme 1 [Neidhardt (2011)] isnRd+T, and its verification overhead isnRe.Tdenotes the time to finish the sending and receiving processes. The transmission overhead is much higher than these of RSA encryption and decryption. The overhead of APK-SAN scheme comes from the pairing operations that depend on the number of the modified APK. If the 1024bits-RSA is adopted in Scheme 1[Neidhardt (2011)], it costs 50 ms to finish a signature and 2.5 ms for verifying.Nevertheless, it only costs 43 ms to carry out the pairing operation in the finite field F97.Obviously, APK-SAN scheme has less time overhead than that in Scheme 1. In the worst case, i.e.m= 5, the time overhead of APK-SAN scheme approximately equals to 430 ms in the signature phase and verification phase, respectively. These time costs are durable for smart mobile phones. On the other hand, a new signature file is generated because one needs sign APK files in Scheme 1 [Neidhardt (2011)]. The size of the signature is |N|,where |N|is the digit of the modular numberN. In APK-SAN scheme, the size of the signature is 3 |G1|, where |G1| is the order of the finite group G1. At the same time,Scheme 1 requires the certificate that increases the storage overhead. APK-SAN scheme is based on the user’s identity without user’s certificate.

5.2 Security

A fine-grained authorization means that the modifier can only modify the specified APK.Authentication means a scheme is able to verify the copyrights of the designer and the validity of the designer’s and modifier’s signatures. The over-privilege detection means that whether one scheme provides the over-privilege detection function or not. The copyrights protection means that whether one scheme has the ability to protect the copyrights after completing the modification.

As shown in Tab. 2, Scheme 1 [Neidhardt (2011)] only provides authentication for the developer, and needs the certificate which increases the storage overhead. Scheme 1 cannot provide a fine-grained authorization and Copyrights protection. The proposed APK-SAN scheme can provide all of these securities. In APK-SAN scheme, the developer authorizes a modifier, and specifies APK’s files and their sub files that are allowed to be modified.Accordingly, it can restrict modifier’s modification permissions, which prevent malicious codes from embedding in APK, and protect Copyrights of developer. If modifier violates the authorization regulations to modify the unauthorized APK’s files, the modified APK’s signature is invalid. Therefore, we can fulfill the over-privilege detection.

Table 2: The comparing of the security. FA denotes fine-grained authorization. OPD denotes the over-privilege detection. CP denotes the copyrights protection after modification

6 Conclusion

In this paper, we design a new APK signature APK-SAN with the unique properties of the sanitizable signature. New scheme allows developers of Android applications to authorize specified modifiers to modify designated source codes of APK file, and sign the modified APK file. The signature of new APK file is still valid. APK-SAN signature is designed to ensure the integrity, authenticity and non-repudiation of APK files, while can reduce the communication time and computational overhead of developers. It also can maintain the legitimate rights and interests of developers and modifiers. Therefore, the proposed mechanism is able to solve the difficult problem that verifies the validity of the original designer’s signature of APK and copyrights of APK when the authorization has completed.

Acknowledgement:This work was supported by the National Natural Science Foundation of China (No. 61662004, 61772437, 61702427), National Natural Science Foundation of Guangxi (No. 2016GXNSFAA380215), Sichuan Youth Science and Technique Foundation(No. 2017JQ0048), and EU ICT COST CryptoAction (No. IC1306).