CN109995534B

CN109995534B - Method and device for carrying out security authentication on application program

Info

Publication number: CN109995534B
Application number: CN201711476537.5A
Authority: CN
Inventors: 马德友
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Priority date: 2017-12-29
Filing date: 2017-12-29
Publication date: 2022-04-26
Anticipated expiration: 2037-12-29
Also published as: CN109995534A

Abstract

The invention discloses a method and a device for carrying out security authentication on an application program, and relates to the technical field of computers. One embodiment of the method comprises: acquiring dynamic attribute data of a master library, signing the dynamic attribute data, and generating a first dynamic signature; acquiring static attribute data of the main library stored in a dynamic library, signing the static attribute data, and generating a first static signature; and comparing whether the first dynamic signature and the first static signature are consistent or not to finish the safety certification of the master library. The embodiment can solve the problem that the APP faces multiple potential safety hazards.

Description

Method and device for carrying out security authentication on application program

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a method and an apparatus for performing security authentication on an application.

Background

Starting with the iOS 8 System (mobile Operating System developed by apple inc.), the Operating System allows APP (Application) with dynamic libraries to pass the audit. With the development of APP business, the amount of APP is larger and larger. Continued support of APP to iOS 7 faces a limitation: apple is limited to an executable file size under the iOS 7 framework within 60M. Therefore, a part of the service needs to be converted into a dynamic library, that is, a part of the executable file of the APP is converted into the dynamic library.

In the process of implementing the invention, the inventor finds that at least the following problems exist in the prior art: since the dynamic library is easily accessible in the resource (e.g., by decompressing the Ipa installation package) and is independently referenceable, APP running on iOS jail crossing devices faces many potential safety hazards. For example, the main library of the APP is easily subjected to hook (hook) or injection, re-signature packaging after the bound ID (APP unique identification) is changed, and the dynamic library of the APP is easily taken out for reference or replaced.

Disclosure of Invention

In view of this, embodiments of the present invention provide a method and an apparatus for performing security authentication on an application, which can solve the problem that an APP faces multiple potential safety hazards.

To achieve the above object, according to an aspect of an embodiment of the present invention, there is provided a method for performing security authentication on an application, including:

acquiring dynamic attribute data of a master library, signing the dynamic attribute data, and generating a first dynamic signature;

acquiring static attribute data of the main library stored in a dynamic library, signing the static attribute data, and generating a first static signature;

and comparing whether the first dynamic signature and the first static signature are consistent or not to finish the safety certification of the master library.

Optionally, the method further comprises:

acquiring dynamic attribute data of a dynamic library, signing the dynamic attribute data, and generating a second dynamic signature;

acquiring static attribute data of the dynamic library stored in a main library, signing the static attribute data, and generating a second static signature;

and comparing whether the second dynamic signature and the second static signature are consistent or not to finish the safety certification of the dynamic library.

Optionally, the dynamic attribute data comprises a dynamic value of an attribute, and the static attribute data comprises a static value of an attribute;

wherein the attribute comprises at least one of a unique identifier of the application program, a name of an application program installation package, a name displayed after the application program is installed, a name of a master library, a name of a dynamic library, a debugged identifier, an injected or hooked identifier, an jail crossing identifier and a resource identifier.

Optionally, respectively obtaining dynamic values of the attributes, splicing the dynamic values of the attributes into character strings according to a preset sequence, and encrypting the character strings to generate a dynamic signature; respectively obtaining the static values of the attributes, splicing the static values of the attributes into character strings according to a preset sequence, and encrypting the character strings to generate static signatures; and the dynamic signature and the static signature are generated in the same splicing sequence.

Optionally, a non-reversible encryption algorithm is used to sign the character strings spliced according to the preset sequence.

Optionally, the method further comprises:

encrypting the static attribute data of the main library, and storing the static attribute data in a dynamic library in a form of a ciphertext; and/or the presence of a gas in the gas,

encrypting the static attribute data of the dynamic library, and storing the static attribute data in a master library in a form of a ciphertext;

accordingly, the number of the first and second electrodes,

the obtaining the static attribute data of the master library stored in the dynamic library includes:

acquiring a ciphertext of the static attribute data stored in a dynamic library, and decrypting the ciphertext to obtain a plaintext of the static attribute data of the main library; and/or the presence of a gas in the gas,

the obtaining the static attribute data of the dynamic library stored in the master library includes:

and acquiring the ciphertext of the static attribute data stored in the main library, and decrypting the ciphertext to obtain the plaintext of the static attribute data of the dynamic library.

In addition, according to another aspect of the embodiments of the present invention, there is provided an apparatus for performing security authentication on an application, including:

the first signature module is used for acquiring dynamic attribute data of a master library, signing the dynamic attribute data and generating a first dynamic signature;

the second signature module is used for acquiring the static attribute data of the main library stored in the dynamic library, signing the static attribute data and generating a first static signature;

and the first comparison module is used for comparing whether the first dynamic signature and the first static signature are consistent or not so as to finish the security authentication of the master library.

Optionally, the apparatus further comprises:

the third signature module is used for acquiring the dynamic attribute data of the dynamic library, signing the dynamic attribute data and generating a second dynamic signature;

the fourth signature module is used for acquiring the static attribute data of the dynamic library stored in the master library, signing the static attribute data and generating a second static signature;

and the second comparison module is used for comparing whether the second dynamic signature and the second static signature are consistent or not so as to finish the safety certification of the dynamic library.

Optionally, the first signature module and the third signature module respectively obtain dynamic values of each attribute, then splice the dynamic values of each attribute into a character string according to a preset sequence, and then encrypt the character string to generate a dynamic signature;

the second signature module and the fourth signature module respectively acquire static values of the attributes, then splice the static values of the attributes into character strings according to a preset sequence, and then encrypt the character strings to generate static signatures;

and the dynamic signature and the static signature are generated in the same splicing sequence.

Optionally, the apparatus further comprises:

the first encryption module is used for encrypting the static attribute data of the main library and storing the static attribute data in the dynamic library in a ciphertext mode; and/or the presence of a gas in the gas,

the second encryption module is used for encrypting the static attribute data of the dynamic library and storing the static attribute data in the main library in a ciphertext mode;

accordingly, the number of the first and second electrodes,

the second signature module is configured to obtain a ciphertext of the static attribute data stored in the dynamic library, and decrypt the ciphertext to obtain a plaintext of the static attribute data of the master library; and/or the presence of a gas in the gas,

the fourth signature module is used for acquiring the ciphertext of the static attribute data stored in the master library, and decrypting the ciphertext to obtain the plaintext of the static attribute data of the dynamic library.

According to another aspect of the embodiments of the present invention, there is also provided an electronic device, including:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method of any of the embodiments described above.

According to another aspect of the embodiments of the present invention, there is also provided a computer readable medium, on which a computer program is stored, which when executed by a processor implements the method of any of the above embodiments.

One embodiment of the above invention has the following advantages or benefits: the method and the device have the advantages that the technical means of comparing whether the dynamic signature and the static signature corresponding to the main library are consistent or not is adopted, so that the technical problem that the APP faces multiple potential safety hazards is solved. Furthermore, the invention verifies whether the dynamic library is safe or not by comparing whether the dynamic signature and the static signature corresponding to the dynamic library are consistent or not, realizes the bidirectional authentication of the master library and the dynamic library, and improves the safety of the APP.

Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.

Drawings

The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:

FIG. 1 is a schematic diagram of the main flow of a method for secure authentication of an application according to an embodiment of the invention;

fig. 2 is a schematic diagram of a main flow of a method for performing security authentication on an application according to one referential embodiment of the present invention;

FIG. 3 is a schematic diagram of the main modules of an apparatus for securely authenticating an application according to an embodiment of the present invention;

FIG. 4 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;

fig. 5 is a schematic block diagram of a computer system suitable for use in implementing a terminal device or server of an embodiment of the invention.

Detailed Description

Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

Fig. 1 is a schematic diagram of a main flow of a method for performing secure authentication on an application according to an embodiment of the present invention. As one embodiment of the present invention. The execution main body of the method can be various terminals, such as a mobile phone, a tablet computer, a personal digital assistant, wearable equipment and the like. As shown in fig. 1, the method for securely authenticating an application may include:

step 101, acquiring dynamic attribute data of a master library, signing the dynamic attribute data, and generating a first dynamic signature.

It should be noted that the decompressed files of the application installation package generally include resource files, configuration files, a main library and a dynamic library, where the main library refers to a main executable file in the application, and the dynamic library (also referred to as a dynamic link library) refers to a file of a custom dynamic type in the application and a part of executable files except for the main library executable file.

The installation package of the application program in the android system is a file with a suffix name apk, and the installation package of the application program in ios is a file with a suffix name Ipa. Taking an Ipa installation package as an example, the Ipa installation package includes a resource file and a master library execution file, where a directory in the resource file stores a dynamic library, and the dynamic library serves as a directory and stores a dynamic library execution file and a dynamic library resource file (a picture, a text file, etc.).

Optionally, the dynamic attribute data includes dynamic values of attributes, wherein the attributes include attributes of the application and/or custom attributes. Optionally, the property of the application may include at least one of a unique identifier of the application, a name of an application installation package, a name displayed after the application is installed, a name of a master library, and a name of a dynamic library, and the customized property may include at least one of a debuggee identifier, an injected or hooked identifier, an jail crossing identifier, and a resource identifier.

These attributes and the corresponding effects are explained below:

(1) bound ID: the unique identifier of the APP, each different APP, the value is different. The value is added into the dynamic attribute data, and then the signature is generated, so that the occurrence of the APP self-identification version can be prevented.

(2) bundle name: the name of the APP installation package, each different APP installation package, is different. And adding the dynamic value of the attribute into the dynamic attribute data, and then generating a signature, so that the occurrence of the APP self-identification version can be prevented to a certain extent.

(3) bundle display name: the name that shows after the APP installation, the name that shows after every different APP installation is different. Adding the dynamic value of the attribute to the dynamic attribute data and then generating the signature can prohibit the name of the APP from being modified.

(4) Name of master library: the name of the master library executable. The name of the master library may be obtained by obtaining information of the class of executable files running in the master library. Adding the dynamic value of the attribute to the dynamic attribute data and then generating the signature can prevent the master library from being converted into the dynamically linked library.

(5) The debugged identification is as follows: and judging whether the APP is debugged or not by acquiring the debugging state value of the system. If the APP is being debugged, a debug identification (such as debug) is returned, and if the APP is not debugged, a normal identification (such as normal) is returned. The dynamic value of the attribute is added into the dynamic attribute data, and then a signature is generated, so that the APP can be prevented from being debugged, and some dynamic information (such as class information, a method operation result, service operation logic and the like) during the operation of the APP can be obtained.

(6) Injected or hooked identification: judging whether an executable file where n sensitive classes are located is consistent with an executable file of a main library or not by acquiring information of the n sensitive classes in the main library, judging whether the executable file where the n sensitive classes are located is the same as the executable file of a dynamic library or not if the n sensitive classes are not consistent with the executable file of the main library, if the n sensitive classes are not the same as the executable file of the dynamic library, judging that the sensitive classes are injected by hooks (hooks) or APPs, and returning injected or hook marks (such as hooks); otherwise, a normal flag (e.g., normal _ hook) is returned. And adding the dynamic value of the attribute into the dynamic attribute data, and then generating a signature, thereby further protecting the APP from being injected or hooked.

(7) Jail crossing identification: and judging whether the operating system is prison-crossed or not according to the effectiveness of the sandbox and the existence of the basic APP of the system prison-crossed. If the operating system is jailbreak, a jailbreak identification (jailbreak) is returned, and if the operating system is not jailbreak, a normal identification (such as no jaibreak) is returned. Dynamic attribute data is added to the dynamic value of the attribute, then a signature is generated, the APP can be guaranteed to be downloaded and operated in a normal channel, and the safety of the APP is guaranteed.

For a mobile operating system developed by apple, iOS Jailbreaking is a technical means for acquiring the highest authority of an iOS operating system, and a user can acquire the highest authority of the iOS operating system by using the technical means.

(8) Resource identification: several master library resource files are randomly identified. And returning the identification by judging whether the master library resource files exist. Return normal identity (resource) if both exist; if some do not exist, then an exception identification (resource _ failure) is returned. The dynamic value of the attribute is added into the dynamic attribute data, then the signature is generated, the resource file of the main library and the executable file of the main library can be bound, and the safety of the APP is further ensured.

It should be noted that, the resource files bound with the executable files of the master library are identified in advance, the identified number is not limited, and the greater the number is, the better the security of the APP is ensured.

Since the operating system splits the attribute and the attribute value of the object into key and value, the value of the attribute is acquired by the string key. Specifically, the encrypted key value of the character string is decrypted to obtain a key value of the plaintext, and the key value of the plaintext is adopted to read the attribute value of the APP.

After the APP is installed, the attribute values of the APP may be changed, and then the dynamically acquired attribute values may be changed. Because the main library and the dynamic library are mutually independent, whether the main library is safe or not is judged by judging the dynamic values of the attributes corresponding to the main library, and the APP is protected. Optionally, attribute values related to APP security check may be added to the dynamic attribute data, and are not limited to the attributes described in the present invention, so as to achieve the purpose of ensuring APP security from different angles.

As still another embodiment of the present invention, step 101 includes: and respectively acquiring dynamic values of the attributes corresponding to the master library, splicing the dynamic values of the attributes into character strings according to a preset sequence, and signing the character strings to generate a first dynamic signature.

Optionally, the string is signed using an irreversible encryption algorithm. Because the signature is irreversible, the original data can be effectively secured. For example, MD5, full name Message-Digest Algorithm 5 (information-Digest Algorithm), is an irreversible encryption Algorithm that has the following advantages: 1. compressibility: for data with any length, the calculated MD5 value length is fixed; 2. easy to calculate: the MD5 value is easy to calculate from the original data; 3. resistance to modification: the MD5 value obtained by modifying the original data by 1 byte is very different; 4. strong collision resistance: knowing the original data and its MD5 value, it is very difficult to find a data with the same MD5 value (i.e., counterfeit data).

Specifically, the dynamic values of the attributes corresponding to the master library may be obtained in a code calling manner. According to the obtained dynamic value, splicing into a character string according to a preset sequence, and then performing MD5 processing on the character string, wherein the processed result is the first dynamic signature.

As one embodiment of the invention, a request may be initiated by the dynamic library to the master library to obtain a first dynamic signature. Specifically, the dynamic library is spliced into a class name character string by n character strings, then converted into a class name by a transmitting mechanism, and then the method of the corresponding class in the master library is called, so that a return value (namely a first dynamic signature) is obtained, and the communication process of the dynamic library and the master library is completed. It should be noted that no other information is carried in the process of obtaining the signature. Optionally, the operation of requesting dynamic signature may occur in a C language constructor of the main library, where the C language constructor is automatically called after the APP is started, so that the method provided by the embodiment of the present invention may be enabled to function as soon as possible, thereby ensuring the security of the APP as soon as possible. Thus, in this embodiment, communication between the master library and the dynamic library is achieved by concatenating the strings, and then reflecting the classes. The main library and the dynamic library are both in an APP, and when the APP runs, the main library loads the dynamic library for execution. Because of these characteristics, the feasibility of this particular communication scheme is guaranteed. Furthermore, the transfer value between the dynamic library and the master library is just a transfer signature value, and has no other information.

As another embodiment of the present invention, a request may also be initiated by a separate hypervisor to the master library to obtain the first dynamic signature, and the same or similar technical effects as those in the foregoing solutions can also be achieved.

In the invention, the transmitted value can be only the signature value without any other information, and whether the master library is safe or not is authenticated by whether the signature value is correct or not, so that the safety of other communication data is not required to be ensured, and the authentication efficiency and the authentication reliability are greatly improved.

And 102, acquiring static attribute data of the main library stored in a dynamic library, signing the static attribute data, and generating a first static signature.

In the step, the static values of the attributes corresponding to the master library are respectively obtained, then the static values of the attributes are spliced into character strings according to a preset sequence, and then the character strings are encrypted to generate a first static signature. The static values may be stored in a dynamic library in advance. Optionally, the static attribute data includes static values of attributes, wherein the attributes include attributes of the application and/or custom attributes.

It should be noted that in step 102, the attribute used in the concatenation string is the same as the attribute used in step 101, except that in step 102, a static value of the attribute is used, and in step 101, a dynamic value of the attribute is used. Also, in step 102, the order of the concatenated string is the same as the order of the concatenated string in step 101.

The splicing sequence of the character strings may be preset, and the obtained attributes may also be preset, so that the attribute values are obtained according to the same attributes in step 101 and step 102, and the attribute values are spliced according to the same sequence. Therefore, it is also necessary to encrypt the character string by the same method, for example, by using MD5, and the result of the encryption is the first static signature, so that the first dynamic signature and the first static signature have comparability.

Taking the property of the application (e.g. bound ID, bound name, bound display name, name of the main library, and name of the dynamic library) as an example, the static value is the unmodified APP property value. Taking the self-defined attribute as an example, the static value of the self-defined attribute is at least one of an un-debugged identifier (such as normal), an un-injected or hooked identifier (such as normal _ hook), an un-jailbreak identifier (such as no _ jaibreak), and a resource identifier (such as resource).

It should be noted that step 101 may be executed first, and then step 102 is executed; step 102 may be executed first, and then step 101 is executed; step 101 and step 102 may also be performed simultaneously. Fig. 1 is a flowchart illustrating the steps 101 and 102 are performed first, and the present invention is not limited to the flowchart.

And 103, comparing whether the first dynamic signature and the first static signature are consistent or not to finish the safety certification of the master library.

The purpose of the static signature is to verify the value of the dynamic signature, which can verify whether the value of the dynamic signature is normal. If the values of the first dynamic signature and the first static signature are not consistent, the master library is no longer secure. If the values of the first dynamic signature and the first static signature are consistent, the master library is still safe.

In this step, it is compared whether the values of the first dynamic signature and the first static signature are consistent. If not, performing exception handling on the comparison result (such as quitting the APP, throwing the exception, reporting the server and the like); and if the two are consistent, ending the process, thereby completing the safety authentication of the master library. Therefore, continuous execution of behavior of destroying APP is prevented, and the safety of the APP can be comprehensively ensured by the method provided by the embodiment of the invention.

According to the various embodiments, it can be seen that the problem that the APP faces multiple potential safety hazards is solved by adopting a technical means of comparing whether the dynamic signature and the static signature corresponding to the master library are consistent or not. That is to say, in the prior art, the master library of the APP is easily hook-injected or changed in APP attribute values, which causes the APP to face multiple potential safety hazards, but the invention verifies whether the master library is safe by comparing whether the dynamic signature and the static signature corresponding to the master library are consistent, thereby ensuring the safety of the APP.

Because the executable file of the main library and the executable file of the dynamic library are separated and exist equivalently in the APP, the executable files of the APP are formed together. The authentication process in the above embodiment may be reversed. But the purpose of the two is not the same: the authentication main library is used for protecting the security of the main library and the APP, and the authentication dynamic library is used for ensuring the security of the dynamic library and the APP. They complement each other, jointly maintaining the safety of the APP.

For convenience of description, in the present invention, the method of authenticating the security of the master library is made a forward authentication process, and the method of authenticating the security of the dynamic library is made a forward authentication process. As a further embodiment of the invention, the dynamic library can be further subjected to reverse authentication, so that bidirectional authentication is realized, and the safety of APP is improved.

Fig. 2 is a schematic diagram of a main flow of a method for performing security authentication on an application according to one referential embodiment of the present invention. As another embodiment of the present invention, the method for securely authenticating an application may include:

step 201, acquiring dynamic attribute data of a master library, signing the dynamic attribute data, and generating a first dynamic signature;

step 202, obtaining static attribute data of the main library stored in a dynamic library, signing the static attribute data, and generating a first static signature;

step 203, comparing whether the first dynamic signature and the first static signature are consistent or not to finish the safety certification of the master library;

step 204, acquiring dynamic attribute data of a dynamic library, signing the dynamic attribute data, and generating a second dynamic signature;

step 205, acquiring static attribute data of the dynamic library stored in a master library, signing the static attribute data, and generating a second static signature;

and step 206, comparing whether the second dynamic signature and the second static signature are consistent or not to finish the safety certification of the dynamic library.

It should be noted that steps 201, 202, and 203 are forward authentication processes, and steps 204, 205, and 206 are forward authentication processes. As another embodiment of the present invention, the forward authentication process may be performed first, and then the reverse authentication process may be performed; the technical effect of the invention can be achieved by executing the reverse authentication process first and then executing the forward authentication process.

Because the positions of the main library and the dynamic library in the APP are different, the existence modes are different, the reference modes are different, the code amount of the libraries is different, and the like, the safety problems of the main library and the dynamic library are different, and the contents protected in the reverse authentication process are different.

The execution of step 204, step 205 and step 206 is explained in detail below.

And 204, acquiring dynamic attribute data of the dynamic library, signing the dynamic attribute data, and generating a second dynamic signature.

Optionally, the dynamic attribute data includes dynamic values of attributes, wherein the attributes include attributes of the application and/or custom attributes. Optionally, the property of the application may include a bound ID and/or a name of a dynamic library, and the customized property may include at least one of an injected or hooked identifier and/or a resource identifier.

(1) bound ID: the bound ID of the dynamic library is determined at the same time of generating the dynamic library, and may be the same as or different from the bound ID of the master library.

(2) Name of dynamic library: the name of the executable file of the dynamic library can be obtained by acquiring the information running in the executable file class of the dynamic library.

(3) Injected or hooked marks; judging whether an executable file where n sensitive classes are located is consistent with an executable file of a dynamic library or not by acquiring information of the n sensitive classes in a main library, judging whether the executable file where the n sensitive classes are located is the same as the executable file of the dynamic library or not if the n sensitive classes are not consistent with the executable file of the dynamic library, if the n sensitive classes are not the same as the executable file of the main library, judging that the sensitive classes are injected by a hook (hook) or an APP, and returning an injected or hooked identifier (such as hook); otherwise, a normal flag (e.g., normal _ hook) is returned.

(4) Resource identification: and judging whether the dynamic library resource files exist or not by randomly identifying a plurality of dynamic library resource files. Return normal identity (resource) if both exist; if some do not exist, then an exception identification (resource _ failure) is returned. The purpose of doing so is to bind the resource file of the dynamic library and the executable file of the dynamic library together, and ensure the security of the dynamic library, thereby ensuring the security of the APP.

It should be noted that the splicing order of the character strings may be preset, and the acquired attribute may also be preset. In addition, the dynamic attribute information of more dynamic libraries can be acquired according to different requirements, so that the safety of the APP and the dynamic libraries can be ensured in more aspects.

As still another embodiment of the present invention, step 204 comprises: and respectively acquiring the dynamic values of the attributes corresponding to the dynamic library, splicing the dynamic values of the attributes into character strings according to a preset sequence, and signing the character strings to generate a second dynamic signature.

It is noted that the order of the concatenation property values in step 204 may be the same as the order in step 101, except that a different concatenation string value needs to be used. Of course, the order of the concatenation attribute values in step 204 may or may not be the same as the order in step 101.

Optionally, the string is signed using an irreversible encryption algorithm. Specifically, the dynamic values of the attributes corresponding to the dynamic library may be obtained in a code calling manner. And splicing the obtained dynamic values into a character string according to a preset sequence, and then performing MD5 processing on the character string, wherein the processed result is the second dynamic signature.

As one embodiment of the invention, a request may be initiated by the master library to the dynamic library to obtain the second dynamic signature. The request method is similar to the method described in step 101, and is not described in detail. Alternatively, the operation of requesting dynamic signing can occur within the C language constructor of the dynamic library. As another embodiment of the present invention, a separate management program may also initiate a request to the dynamic library to obtain the second dynamic signature, and the same or similar technical effects as those in the foregoing solutions can also be achieved.

Step 205, obtaining the static attribute data of the dynamic library stored in the master library, signing the static attribute data, and generating a second static signature.

In the step, the static values of the attributes corresponding to the dynamic library are respectively obtained, then the static values of the attributes are spliced into character strings according to a preset sequence, and then the character strings are encrypted to generate a second static signature. The static value may be stored in the master library in advance.

It should be noted that in step 205, the attribute used for splicing the string is the same as the attribute used in step 204, except that in step 205, a static value of the attribute is used, and in step 204, a dynamic value of the attribute is used. Also, in step 205, the order of the concatenated string is the same as the order of the concatenated string in step 204. The splicing order of the character strings may be preset, and the obtained attributes may also be preset, so that the step 204 and the step 205 both obtain attribute values according to the same attribute and splice the attribute values according to the same order. Therefore, it is also necessary to encrypt the character string by the same method, for example, by using MD5, and the result of the encryption is the first static signature, so that the second dynamic signature and the second static signature are comparable.

It should be noted that step 204 may be executed first, and then step 205 may be executed; step 204 may be performed first, and then step 205 may be performed; step 204 and step 205 may also be performed simultaneously.

And if the values of the second dynamic signature and the second static signature are inconsistent, the dynamic library is not safe any more. If the values of the second dynamic signature and the second static signature are consistent, the dynamic library is still safe.

In this step, the values of the second dynamic signature and the second static signature are compared for consistency. If not, performing exception handling on the comparison result (such as quitting the APP, throwing the exception, reporting the server and the like); and if the two are consistent, ending the process, thereby finishing the safety authentication of the dynamic library. Therefore, continuous execution of behavior of destroying APP is prevented, and the safety of the APP can be comprehensively ensured by the method provided by the embodiment of the invention.

Therefore, the method provided by the embodiment of the invention can realize the signature authentication process from the executable file of the APP main library to the dynamic library and the signature authentication process from the APP dynamic library to the executable file of the main library, thereby ensuring the safety of the APP.

Therefore, the method provided by the embodiment of the invention can bind the main library, the dynamic library and the resource file together, reinforce the APP, improve the safety level of the APP, improve the threshold of the reverse APP, and enable the APP to run on the terminal more safely and healthily. The method has a remarkable effect on preventing APP from being hook, being injected, dynamic library being changed and replaced or being singly referenced, and the like.

As yet another embodiment of the present invention, the method further comprises: and encrypting the static attribute data of the main library, and storing the static attribute data in the dynamic library in a ciphertext mode.

Specifically, the character string is encrypted, and the ciphertext is stored in a dynamic library in a character string constant form for use. Alternatively, the concatenated string may be encrypted and then concatenated after decryption. Alternatively, the un-concatenated strings (i.e. the static values of the respective attributes) may be encrypted separately, and then after decryption, the concatenated strings are required.

As still another embodiment of the present invention, the encryption method includes: and encrypting the static attribute data in a form of a symmetric encryption algorithm and a random character string. Alternatively, the symmetric encryption algorithm may be a triple data encryption algorithm, and a random string is added before and after the ciphertext, and the number of characters of the random string is not limited. Optionally, the plaintext is encrypted by using a standard 3DES (Triple Data Encryption Algorithm), and six random character strings are added before and after the encrypted ciphertext character string to obtain a final Encryption result. The purpose of adding the random character string is to avoid directly exposing the ciphertext to hackers and improve the security of the static attribute data.

Encryption and decryption key: since symmetric encryption is employed, the decryption key is the same as the encryption key. The encryption and decryption keys are stored in the executable file of the dynamic library in a plaintext form, and are directly transmitted to the encryption algorithm after being loaded into the memory.

Encryption and decryption offset: for security of encryption and decryption, an offset is set. The encryption offset and the decryption offset are the same, the encryption offset and the decryption offset are stored in an executable file of the dynamic library in a plain text mode, and are directly transmitted to an encryption algorithm after being loaded into a memory.

Six-bit random string: consists of 0-9, a-Z, ═ q, etc. Firstly, a digit is randomly generated by adopting a systematic method, then the digit is divided by 64 to obtain a remainder, when the result is less than 10, the result is divided by 10 to obtain the remainder, and then the process can obtain a random digit with 0-9. Similarly, if the result of the first remainder is 10-36, 37-62, 63-64, the characters of a-Z, (/) are returned, respectively. The process is circulated for six times, and a six-bit random character string can be obtained.

Accordingly, in step 102, the obtaining the static attribute data of the master library stored in the dynamic library includes: the method comprises the steps of firstly obtaining a ciphertext of the static attribute data stored in a dynamic library, and then decrypting the ciphertext to obtain a plaintext of the static attribute data of the main library.

Optionally, the step of decrypting the ciphertext includes: the random character strings before and after the ciphertext are removed, then the decryption key and the decryption offset are obtained, and the corresponding decryption method is adopted to decrypt the ciphertext, so that the plaintext is obtained.

Since the decryption key is issued with the APP and is easily exposed to hackers, it is securely processed. Reading a simple picture in the APP resource file, converting the read data into a character string, and performing MD5 encryption on the character string to obtain a decryption key.

As a further embodiment of the invention, more complex encryption algorithms may also be employed, such as: 1) the Encryption method is combined by adopting a 3DES (Advanced Encryption Standard) Encryption method and an AES (Advanced Encryption Standard, also called Rijndael Encryption method). The plaintext to be encrypted is divided into two parts according to a certain proportion, one part adopts 3DES encryption, and the other part adopts AES encryption. And then the ciphertext is spliced into a character string. More encryption algorithm concatenations may also be employed. 2) Each character of the ciphertext is followed by a random character. The method of generating the character is similar to the method of generating the random string described above. More random string combinations are also possible. 3) And carrying out encryption by adopting a white-box encryption technology.

As yet another embodiment of the present invention, the method further comprises: and encrypting the static attribute data of the dynamic library, and storing the static attribute data in the main library in a ciphertext mode. Accordingly, in step 205, the obtaining the static attribute data of the dynamic library stored in the master library includes: and firstly, acquiring the ciphertext of the static attribute data stored in the main library, and then decrypting the ciphertext to obtain the plaintext of the static attribute data of the dynamic library.

It should be noted that the method for encrypting and decrypting the static attribute data of the dynamic library is similar to the method for encrypting and decrypting the static attribute data of the master library, and therefore the repeated content will not be described again.

Alternatively, a call implementation separation method is used to hide all function calls, and then when a decompilation tool is used for static analysis, which function is called can not be found. Specifically, with a function pointer as a parameter, in the implementation of a function, a function pointed by the function pointer is called, the result of the execution of the function is returned, and some obfuscated codes are added into the function.

Fig. 3 is a device for securely authenticating an application according to an embodiment of the present invention, and as shown in fig. 3, the device 300 for securely authenticating an application includes a first signature module 301, a second signature module 302, and a first comparison module 303. The first signature module 301 obtains dynamic attribute data of a master library, signs the dynamic attribute data, and generates a first dynamic signature; the second signature module 302 obtains the static attribute data of the master library stored in the dynamic library, signs the static attribute data, and generates a first static signature; the first comparison module 303 compares whether the first dynamic signature and the first static signature are consistent to complete the security authentication of the master library.

Optionally, the dynamic attribute data comprises a dynamic value of an attribute and the static attribute data comprises a static value of an attribute. Wherein the attribute comprises the attribute of the application program and/or the self-defined attribute. Optionally, the property of the application may include at least one of a unique identifier of the application, a name of an application installation package, a name displayed after the application is installed, a name of a master library, and a name of a dynamic library, and the customized property may include at least one of a debuggee identifier, an injected or hooked identifier, an jail crossing identifier, and a resource identifier.

The first signature module 301 obtains the dynamic values of the attributes corresponding to the master library, splices the dynamic values of the attributes into a character string according to a preset sequence, and signs the character string to generate a first dynamic signature. Optionally, the string is signed using an irreversible encryption algorithm.

The second signature module 302 obtains the static values of the attributes corresponding to the master library, splices the static values of the attributes into a character string according to a preset sequence, and encrypts the character string to generate the first static signature. The static values may be stored in a dynamic library in advance. Optionally, a non-reversible encryption algorithm is used to sign the character strings spliced according to the preset sequence.

It should be noted that the attribute used by the second signature module 302 to splice the character string is the same as the attribute used by the first signature module 301, except that the second signature module 302 uses a static value of the attribute, and the first signature module 301 uses a dynamic value of the attribute. Also, the order in which the second signature module 302 splices the character strings is the same as the order in which the first signature module 301 splices the character strings.

The splicing order of the character strings may be preset, and the obtained attributes may also be preset, so that the first signature module 301 and the second signature module 302 both obtain attribute values according to the same attribute, and splice the attribute values according to the same order. Therefore, it is also necessary to encrypt the character string in the same way, for example, in MD5, so that the first dynamic signature is comparable to the first static signature.

The first comparison module 303 compares whether the values of the first dynamic signature and the first static signature are consistent. If not, performing exception handling on the comparison result (such as quitting the APP, throwing the exception, reporting the server and the like); and if the two are consistent, ending the process, thereby completing the safety authentication of the master library. Therefore, the continuous execution of the behavior of destroying the APP is prevented, and the safety of the APP can be comprehensively ensured by the device provided by the embodiment of the invention.

Optionally, the device further includes a third signature module, a fourth signature module, and a second comparison module, where the third signature module obtains dynamic attribute data of the dynamic library, signs the dynamic attribute data, and generates a second dynamic signature, the fourth signature module obtains static attribute data of the dynamic library stored in the master library, signs the static attribute data, and generates a second static signature, and the second comparison module compares whether the second dynamic signature and the second static signature are consistent, so as to complete security authentication of the dynamic library.

Optionally, the dynamic attribute data comprises a dynamic value of an attribute and the static attribute data comprises a static value of an attribute. Wherein the attribute comprises the attribute of the application program and/or the self-defined attribute. Optionally, the property of the application may include a unique identifier of the application and/or a name of the dynamic library, and the customized property may include at least one of an injected or hooked identifier and/or a resource identifier.

And the third signature module respectively acquires the dynamic values of the attributes corresponding to the dynamic library, then splices the dynamic values of the attributes into character strings according to a preset sequence, and then signs the character strings to generate a second dynamic signature. And the fourth signature module respectively acquires the static values of the attributes corresponding to the dynamic library, then splices the static values of the attributes into character strings according to a preset sequence, and then encrypts the character strings to generate a second static signature. The static value may be stored in the master library in advance. Optionally, a non-reversible encryption algorithm is used to sign the character strings spliced according to the preset sequence.

It should be noted that the attribute used by the fourth signature module to splice the character string is the same as the attribute used by the third signature module, except that the attribute is a static value used by the fourth signature module, and the attribute is a dynamic value used by the third signature module. And the order of the fourth signature module splicing character strings is the same as the order of the third signature module splicing character strings.

The splicing sequence of the character strings can be preset, and the acquired attributes can also be preset, so that the third signature module and the fourth signature module can acquire attribute values according to the same attributes and splice the attribute values according to the same sequence. Therefore, it is also necessary to encrypt the character string in the same way, for example, in MD5, so that the second dynamic signature is comparable to the second static signature.

The second comparison module compares whether values of the second dynamic signature and the second static signature are consistent. If not, performing exception handling on the comparison result (such as quitting the APP, throwing the exception, reporting the server and the like); and if the two are consistent, ending the process, thereby finishing the safety authentication of the dynamic library. Therefore, continuous execution of behavior of destroying APP is prevented, and the safety of the APP can be comprehensively ensured by the method provided by the embodiment of the invention.

Optionally, the apparatus further includes a first encryption module and/or a second encryption module, where the first encryption module encrypts the static attribute data of the master library and stores the encrypted static attribute data in the dynamic library in the form of a ciphertext, and the second encryption module encrypts the static attribute data of the dynamic library and stores the encrypted static attribute data in the master library in the form of the ciphertext.

Correspondingly, in this embodiment, the second signature module 302 obtains the ciphertext of the static attribute data stored in the dynamic library, and decrypts the ciphertext to obtain the plaintext of the static attribute data of the master library; and the fourth signature module acquires the ciphertext of the static attribute data stored in the master library, and decrypts the ciphertext to obtain the plaintext of the static attribute data of the dynamic library.

Specifically, the first encryption module and/or the second encryption module encrypt the character string, and store the ciphertext in the dynamic library and/or the main library in the form of a character string constant for use. Alternatively, the concatenated string may be encrypted and then concatenated after decryption. Alternatively, the strings that are not spliced may be encrypted separately, and then after decryption, the strings need to be spliced.

As still another embodiment of the present invention, the encryption method includes: and encrypting the static attribute data in a form of a symmetric encryption algorithm and a random character string. Alternatively, the symmetric encryption algorithm may be a triple data encryption algorithm, and a random string is added before and after the ciphertext, and the number of characters of the random string is not limited. Optionally, the plaintext is encrypted by using standard 3DES, and a six-bit random character string is added before and after the ciphertext character string after the password to obtain a final encryption result, so as to improve the security of the static attribute data.

According to the various embodiments described above, it can be seen that the technical means for comparing whether the dynamic signature and the static signature corresponding to the master library are consistent is adopted, so that the technical problem that the APP faces multiple potential safety hazards is solved. Furthermore, the invention verifies whether the dynamic library is safe or not by comparing whether the dynamic signature and the static signature corresponding to the dynamic library are consistent or not, realizes the bidirectional authentication of the master library and the dynamic library, and improves the safety of the APP.

It should be noted that, in the implementation of the apparatus for performing security authentication on an application according to the present invention, the above-mentioned method for performing security authentication on an application has been described in detail, and therefore, the repeated description is omitted here.

Fig. 4 illustrates an exemplary system architecture 400 for a method of securely authenticating an application or a device for securely authenticating an application to which embodiments of the present invention may be applied.

As shown in fig. 4, the system architecture 400 may include

terminal devices

401, 402, 403, a network 404, and a server 405. The network 404 serves as a medium for providing communication links between the

terminal devices

401, 402, 403 and the server 405. Network 404 may include various types of connections, such as wire, wireless communication links, or fiber optic cables, to name a few.

A user may use

terminal devices

401, 402, 403 to interact with a server 405 over a network 404 to receive or send messages or the like. The

terminal devices

401, 402, 403 may have installed thereon various communication client applications, such as shopping-like applications, web browser applications, search-like applications, instant messaging tools, mailbox clients, social platform software, etc. (by way of example only).

The

terminal devices

401, 402, 403 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.

The server 405 may be a server providing various services, such as a background management server (for example only) providing support for shopping websites browsed by users using the

terminal devices

401, 402, 403. The background management server may analyze and process the received data such as the product information query request, and feed back a processing result (for example, target push information and product information — only an example) to the terminal device.

It should be noted that the method for performing security authentication on an application provided in the embodiment of the present invention is generally executed on the

terminal devices

401, 402, and 403 in a public place, and accordingly, the apparatus for performing security authentication on an application is generally disposed in the

terminal devices

401, 402, and 403 in a public place.

It should be understood that the number of terminal devices, networks, and servers in fig. 4 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Referring now to FIG. 5, shown is a block diagram of a computer system 500 suitable for use with a terminal device implementing an embodiment of the present invention. The terminal device shown in fig. 5 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present invention.

As shown in fig. 5, the computer system 500 includes a Central Processing Unit (CPU)501 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)502 or a program loaded from a storage section 508 into a Random Access Memory (RAM) 503. In the RAM503, various programs and data necessary for the operation of the system 500 are also stored. The CPU 501, ROM 502, and RAM503 are connected to each other via a bus 504. An input/output (I/O) interface 505 is also connected to bus 504.

The following components are connected to the I/O interface 505: an input portion 506 including a keyboard, a mouse, and the like; an output portion 507 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 508 including a hard disk and the like; and a communication section 509 including a network interface card such as a LAN card, a modem, or the like. The communication section 509 performs communication processing via a network such as the internet. The driver 510 is also connected to the I/O interface 505 as necessary. A removable medium 511 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 510 as necessary, so that a computer program read out therefrom is mounted into the storage section 508 as necessary.

In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 509, and/or installed from the removable medium 511. The computer program performs the above-described functions defined in the system of the present invention when executed by the Central Processing Unit (CPU) 501.

It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present invention, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor includes a first signature module, a second signature module, and a first comparison module, wherein the names of the modules do not in some cases constitute a limitation on the modules themselves.

As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise: acquiring dynamic attribute data of a master library, signing the dynamic attribute data, and generating a first dynamic signature; acquiring static attribute data of the main library stored in a dynamic library, signing the static attribute data, and generating a first static signature; and comparing whether the first dynamic signature and the first static signature are consistent or not to finish the safety certification of the master library.

According to the technical scheme of the embodiment of the invention, because the technical means of comparing whether the dynamic signature and the static signature corresponding to the main library are consistent is adopted, the technical problem that the APP faces many potential safety hazards is solved. Furthermore, the invention verifies whether the dynamic library is safe or not by comparing whether the dynamic signature and the static signature corresponding to the dynamic library are consistent or not, realizes the bidirectional authentication of the master library and the dynamic library, and improves the safety of the APP.

The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for securely authenticating an application, comprising:

comparing whether the first dynamic signature and the first static signature are consistent or not to finish the safety certification of the master library;

further comprising:

2. The method of claim 1, wherein the dynamic attribute data comprises dynamic values of attributes, and wherein the static attribute data comprises static values of attributes;

3. The method of claim 2,

respectively acquiring dynamic values of the attributes, splicing the dynamic values of the attributes into character strings according to a preset sequence, and encrypting the character strings to generate dynamic signatures;

respectively obtaining the static values of the attributes, splicing the static values of the attributes into character strings according to a preset sequence, and encrypting the character strings to generate static signatures;

4. The method of claim 3, wherein the string concatenated in the predetermined order is signed using an irreversible encryption algorithm.

5. The method of claim 1, further comprising:

accordingly, the number of the first and second electrodes,

6. An apparatus for securely authenticating an application, comprising:

the first comparison module is used for comparing whether the first dynamic signature and the first static signature are consistent or not so as to complete the safety certification of the master library;

further comprising:

7. The apparatus of claim 6, wherein the dynamic attribute data comprises dynamic values of attributes, and wherein the static attribute data comprises static values of attributes;

8. The device according to claim 7, wherein the first signature module and the third signature module respectively obtain dynamic values of the attributes, then splice the dynamic values of the attributes into a character string according to a preset sequence, and then encrypt the character string to generate the dynamic signature;

9. The apparatus of claim 8, wherein the string concatenated in the predetermined order is signed using an irreversible encryption algorithm.

10. The apparatus of claim 6, further comprising:

accordingly, the number of the first and second electrodes,

11. An electronic device, comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-5.

12. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-5.