1. A third party countersignature method based on a V2 or V3 signature mechanism is characterized in that:

finding out a signature data block of V2 or V3 from the signature data blocks of the android application program, finding out a sequence of android native signer data blocks, finding out an additional attribute addtional attributes data block from each signer data block, inserting an ID into the additional attribute data block, wherein the value of the ID inserted into the additional attribute data block is countersignature data;

in the V2 signature data block, the ID is not 0x7109871 a; in the V3 signature data block, the ID is not 0x7109871a or 0xf05368c0 or 0x3ba06f8 c.

2. The third party countersignature method based on V2 or V3 signature mechanism as claimed in claim 1, wherein:

the countersignature takes the original signature value in the android V2 or V3 signature data block as the original text, and uses the private key of the third-party countersignature certificate to sign the original text.

3. The third party countersignature method based on the V2 or V3 signature mechanism as claimed in claim 1 or 2, specifically comprising the steps of:

s1, reading a native signature block of android application software, and acquiring V2 signature data from ID0x 7109871a or acquiring V3 signature data from ID0xf05368c 0;

s2, reading the data structure of the issuer;

s3, generating a countersignature data structure, wherein the countersignature data structure comprises a version number, a hash algorithm, an issuer subject item, an issuer certificate and a signature algorithm;

s4, using the original signature value as the original text of the countersignature, performing hash operation on the original text, and setting the hash value obtained by calculation into a credible attribute;

s5, using the countersignature credible attribute data as the original text and using the countersignature certificate private key to sign;

s6, add the countersignature to the value of the ID inserted in the extra attribute data block of the native signature.

4. The third party countersignature method based on V2 or V3 signature mechanism as claimed in claim 3, further comprising the following steps after S3:

and if the countersignature signature needs to be added into the trusted time, obtaining the trusted time from the trusted time source, and adding the trusted time attribute into the countersignature data format.

5. The third party countersignature method based on the V2 or V3 signature mechanism as claimed in claim 4, wherein:

if there is more than one issuer in the original signature, the data structure of each issuer is read out, and steps S3 to S6 are executed for the data structure of each issuer, and the signature is finished after the execution is finished.

6. The third party countersignature method based on the V2 or V3 signature mechanism as claimed in claim 3, wherein:

if there is more than one issuer in the original signature, the data structure of each issuer is read out, and steps S3 to S6 are executed for the data structure of each issuer, and the signature is finished after the execution is finished.

7. A third party countersignature verification method based on a V2 or V3 signature mechanism is characterized by comprising the following steps:

s11, reading a native signature block of the android application software, and acquiring V2 version signature data from ID0x 7109871a or acquiring signature data from ID0xf05368c 0;

s12, reading the data structure of the issuer and the data structure of the countersignature;

s13, acquiring a countersignature digital certificate from the countersignature data structure;

s14, verifying the validity of the digital certificate of the countersignature;

s15, after the validity of the countersignature certificate passes verification, judging whether the countersignature has the hash attribute, if not, the verification fails;

s16, hashing the original signature, comparing the calculated hash value with the hash value in the hash attribute, if different, the verification fails;

s17, taking the credible attribute data in the countersignature as the original text, and verifying the countersignature value by using the countersignature certificate; if the countersignature value verification is different, the verification fails.

8. The third party countersignature verification method based on the V2 or V3 signature mechanism as claimed in claim 7, wherein the method for verifying the validity of the digital certificate of the countersignature is as follows:

if the state of the digital certificate needs to be verified online, the digital certificate is verified through a trusted certificate service;

and if online verification is not required, locally verifying the certificate validity, verifying the certificate chain and verifying the black and white list.

9. The third party countersignature verification method based on the V2 or V3 signature mechanism as claimed in claim 7 or 8, wherein:

if more than one issuer exists in the primary signature, respectively reading the data structure of each issuer and the data structure of each countersignature signature of the data structure of each issuer;

s13 through S17 are performed for all countersignature signatures corresponding to each issuer.

Background

The android system requires that all application programs can be installed after being signed, but the signing certificate is not strictly limited, any self-signing certificate can be used for signing, the signing certificate is generally generated by developers, all developers can freely set the subject item content of the certificate, and the signing certificates of other developers can be easily forged maliciously. Meanwhile, the signature certificate and the private key are generally stored in a common data file form and may be copied, spread and used maliciously, and once the signature certificate and the private key are generated, it is very difficult for a real developer of Android application to trace back.

Countersignature is the addition of a signature to a signed document as a certification and attestation of the signed document, the purpose of which is to attest to the data, actions or provision in the document for the signer and the countersignature signer to approve.

The third-party digital signature of the android application is a countersignature, and a signature initiator (an application developer, a detection mechanism, an application store and the like) uses a code signing certificate issued by a third-party legal CA mechanism to attach a signature to an application which is packaged and signed under the condition of not changing the packaging signature flow of the original android application. The countersignature signature may be one or more signatures.

At present: patent publication No. CN106209379B, an Android APK countersignature and verification method, which provides a countersignature method for an Android application program aiming at the native signature V1 version of the Android application program.

Aiming at the continuous upgrade of the existing android system, the native signature V1 mechanism of the android application program has many defects and potential safety hazards, such as:

since the signature does not protect certain parts of the APK, such as the ZIP metadata.

The APK verifier needs to handle a large number of untrusted (not yet verified) data structures and then discard the data that is not protected by the signature. This results in a rather large attack surface.

The APK authentication program must decompress all the compressed entries, which takes more time and memory.

Based on these drawbacks, the V2 scheme (introduced from android 7.0), and the V3 scheme (introduced from android 9.0) are currently being gradually replaced by the android application native signature V2/V3 mechanism. However, the countersignature method under the current V2/V3 signature mechanism does not have a safe and reliable countersignature mechanism without affecting the original signature verification process.

Disclosure of Invention

Aiming at the technical problems, the invention provides a third party countersignature method based on the android native signature V2/V3 mechanism, which does not influence the original verification mechanism of the android signature V2/V3 version and can achieve countersignature effect.

In order to achieve the purpose, the invention adopts the technical scheme that: a third party countersignature method based on a V2 or V3 signature mechanism can add a plurality of countersignature signatures on the version V2 or V3 of the android signature mechanism.

Finding out a signature data block of V2 or V3 from the signature data blocks of the android application program, finding out a sequence of android native signer data blocks, finding out an additional attribute addtional attributes data block from each signer data block, inserting an ID into the additional attribute data block, wherein the value of the ID inserted into the additional attribute data block is countersignature data; in the V2 signature data block, the ID is not 0x7109871 a; in the V3 signature data block, the ID is not 0x7109871a or 0xf05368c0 or 0x3ba06f8 c.

Further, the countersignature takes the signature value in the Signed data in the signature data structure in the android V2 or V3 signature data block as the original text, and uses the private key of the third party countersignature certificate to sign the original text. The countersignature data format is not particularly restricted here, and may be PKCS #7, or other countersignature format. Since the android native signature is a signature of a hash of the content block (Contents of ZIP Entries), the ZIP Central Directory block (Central Directory), and the Central Directory End block (End of Central Directory) of the ZIP stripe of the android data block, adding the countersignature at this location does not affect the installation and upgrade of native android applications.

Further, the third party countersignature method specifically includes the following steps:

s1, reading a native signature block of android application software, and acquiring V2 signature data from ID0x 7109871a or acquiring V3 signature data from ID0xf05368c 0;

s2, reading the data structure of the issuer;

s3, generating a countersignature data structure, wherein the countersignature data structure comprises a version number, a hash algorithm, an issuer topic item, an issuer certificate, a signature algorithm and the like;

s4, using the original signature value as the original text of the countersignature, performing hash operation on the original text, and setting the hash value obtained by calculation into a credible attribute;

s5, using the countersignature credible attribute data as the original text and using the countersignature certificate private key to sign;

s6, add the countersignature to the value of the ID inserted in the extra attribute data block of the native signature.

Finally, the signature ends.

Preferably, the method further comprises the following step after S3: and if the countersignature signature needs to be added into the trusted time, obtaining the trusted time from the trusted time source, and adding the trusted time attribute into the countersignature data format.

Further, in the above method, if there is more than one issuer in the original signature, the data structure of each issuer is read out, and steps S3 to S6 are executed for the data structure of each issuer, and the signature ends after the execution is finished.

The invention also discloses a third party countersignature verification method based on the V2 or V3 signature mechanism, which comprises the following steps:

s11, reading a native signature block of the android application software, and acquiring V2 version signature data from ID0x 7109871a or acquiring signature data from ID0xf05368c 0;

s12, reading the data structure of the issuer and the data structure of the countersignature;

s13, acquiring a countersignature digital certificate from the countersignature data structure;

and S14, if the digital certificate state needs to be verified online, verifying through the trusted certificate service.

And if online verification is not required, locally verifying the validity of the certificate, verifying the certificate chain and verifying the black and white list.

S15, after the countersignature certificate passes the verification, judging whether the countersignature has the hash attribute, if not, the verification fails;

s16, hashing the original signature, comparing the calculated hash value with the hash value in the hash attribute, if different, the verification fails;

s17, taking the credible attribute data in the countersignature as the original text, and verifying the countersignature value by using the countersignature certificate; if the countersignature value verification is different, the verification fails. And verifying by adopting relevant operation of cryptography, and proving the non-repudiation of the signature made by the private key corresponding to the certificate if the verification succeeds.

S18, if there is any countersignature, jumping to step 3.

S21, jump to 2 if there is a native signature.

Further, if more than one issuer exists in the primary signature, reading the data structure of each issuer and the data structure of each countersignature signature of the data structure of each issuer respectively; s13 through S17 are performed for all countersignature signatures corresponding to each issuer.

The invention has the following beneficial effects:

the method is suitable for the third party countersignature method under the android system mobile application program V2 or V3 signature mechanism, realizes signature tracing of various countersignature roles (application developers, detection mechanisms, application stores and the like) under the android system mobile application program V2 or V3 signature mechanism, and does not change the original android V2 or V3 signature verification mechanism.

The application countersignature uses a code-signed digital certificate issued by a third party legitimate CA authority, and the identity of the countersignature signer is strictly reviewed and verified by the third party CA authority. After the application program is signed by using the code signing digital certificate, under the protection of the electronic signature law of the people's republic of China, the following advantages are provided:

the identity real-name authentication of the signer is countersigned, so that the legal responsibility can be followed.

After the application counterdeploys the signature, each counterdeployment link can be traced.

The countersignature is completed by a code signature digital certificate issued by a third-party CA organization, so that the credibility is higher, and the popularization is facilitated.

Countersigning the signature can prove the ownership of the application program by the developer, and can provide strong evidence for the application program developer when the application program is pirated, infringed and the like.

Drawings

Fig. 1 shows an overall data structure of an android application program V2 and a V3 signature mechanism.

Fig. 2 is a signature data structure under the V2 version of the android application.

Fig. 3 is a data format of a countersignature under the V2 signature mechanism according to an embodiment of the present invention.

Fig. 4 is a signature data structure under the V3 version of the android application.

Fig. 5 is a data format of a countersignature under the V3 signature mechanism according to an embodiment of the present invention.

Fig. 6 is a flowchart of a countersignature method under the V2 or V3 signature mechanism according to an embodiment of the present invention.

Fig. 7 is a flowchart of a countersignature verification method under the V2 or V3 signature mechanism according to an embodiment of the present invention.

Detailed Description

In order to facilitate understanding of those skilled in the art, the present invention will be further described with reference to the following embodiments and the accompanying drawings.

As shown in fig. 1, unlike the overall data structure of the native Signature V1 of the android application, V2/V3 adds an APK Signature Block (APK Signature Block) to the original mobile application data Block to form a four-part data Block including a content Block of ZIP Entries (APK Signature Block), an APK Signature Block (APK Signature Block), a ZIP Central Directory Block (Central Directory), and an End of Central Directory Block (End of Central Directory), where there is a data structure of ID-VALUE pairs, where the data structure of ID is 0x7109871a for V2 Signature and 0xf05368c0 for V3 Signature.

The Android application native signature V2 and V3 schemes do not have a countersignature mechanism on the basis of not changing the Android native signature verification, and the method of the embodiment mainly solves the countersignature mechanism under the Android native signature V2 and V3 schemes.

Example 1: as shown in FIG. 2, android V2 is signed in blocks with an ID of 0x7109871a, in the format:

a length-prefixed signer (length-prefixed) sequence:

signed data with length prefix:

digests (with length prefix) sequence with length prefix:

·signature algorithm ID(uint32)

digest (with length prefix) -please refer to integrity protected content

X.509certificates sequence with length prefix:

x.509certificate (ASN.1DER format) with length prefix

An additional entries (with length prefix) sequence with length prefix:

·ID(uint32)

value (variable length: length of additional Properties-4 bytes)

A length-prefixed signatures (length-prefixed) sequence:

·signature algorithm ID(uint32)

signature with length prefix on signed data

Public key with length prefix (SubjectPublicKeyInfo, ASN.1DER form)

In this embodiment, on the basis of the V2 signature block, multiple countersignature signatures can be added to the version V2 of the android signature mechanism without affecting the original verification mechanism of the version V2 of the android signature mechanism, and the countersignature can be normally installed and upgraded, and the countersignature effect can be achieved.

As shown in fig. 3, the specific operation is to find out, in the android application signature data block, a V2 signature data block (ID is 0x7109871a), find out a sequence of data blocks of android native Signer (Signer), find an addtional attributes data block in each Signer data block, insert an arbitrary ID with ID other than 0x7109871a into the data block, the value of the ID is countersignature data, the countersignature is an original text with a signature value in Signed data in Signatures in the signature block of the android V2, sign the original text with a private key of a third party countersignature certificate, but the countersignature data format is not specifically restricted here, and may be PKCS #7, or the countersignature data format as shown in column 3 on the left side of fig. 3, and other countersignature formats. If the location is within the protection scope of the present invention, since the android native signature is a signature of a hash of a content block (Contents of ZIP Entries), a ZIP Central Directory block (Central Directory), and a Central Directory End block (End of Central Directory) of a ZIP bar of the android data block, adding the countersignature at the location does not affect the installation and upgrade of the native android application.

Example 2: as shown in fig. 4, android V3 signs the block with an ID of 0xf05368c0 in the format:

a length-prefixed signer (length-prefixed) sequence:

signed data with length prefix:

digests (with length prefix) sequence with length prefix:

signature algorithmID (4 bytes)

Digest (with length prefix)

X.509certificates sequence with length prefix:

x.509certificate (ASN.1DER form) with length prefix

minSDK (agent 32) -if the platform version is below this number, the signer should be ignored.

MaxSDK (agent 32) -if the platform version is higher than this number, the signer should be ignored.

An additional entries (with length prefix) sequence with length prefix:

·ID(uint32)

value (variable length: length of additional Properties-4 bytes)

·ID-0x3ba06f8c

value-Proof-of-rotation Structure

minSDK (agent 32) -copy of the minSDK value in the signature data section-to skip verification of this signature when the current platform is not within the corresponding range. Must match the signature data value.

maxSDK (uint32) -copy of maxSDK value in signature data section-to skip verification of this signature when the current platform is not in the corresponding range. Must match the signature data value.

A length-prefixed signatures (length-prefixed) sequence:

·signature algorithm ID(uint32)

signature with length prefix on signed data

Public key with length prefix (SubjectPublicKeyInfo, ASN.1DER form)

The embodiment discloses a method for placing third-party digital certificate countersignature signatures on the basis of an android application native signature V3 version mechanism, and by the method, a plurality of countersignature signatures can be added to the android application native signature mechanism V3 version without influencing the verification mechanism of the android application V3 version, so that normal installation and upgrading can be realized, and the countersignature effect can be achieved.

As shown in fig. 5, the specific operation is to find out, in the android application signature data block, a V3 signature data block (ID is 0xf05368c0), find out a sequence of data blocks of android native Signer (Signer), find addtion attribute data blocks in the data block of each Signer, insert any ID of ID other than 0x7109871a, 0xf05368c0 and 0x3ba06f8c into the data block, whose VALUE is countersignature data, and sign the original text with the signature VALUE in Signed data in Signatures in the signature block of the android V3 signature, and sign the original text with the private key of the third party countersignature certificate, but the format of the countersignature data is not specifically restricted here, and the format of the countersignature data may be PKCS #7, or the format of the signature data as shown in column 3 on the left side of fig. 5, and other formats of the countersignature. Since the android native signature is a signature of a hash of the content block (Contents of ZIP Entries), the ZIP Central Directory block (Central Directory), and the Central Directory End block (End of Central Directory) of the ZIP data block, adding the countersignature in a location does not affect the installation and upgrade of the native android application.

More specifically, the third party countersignature flow based on the V2 or V3 signature mechanism as shown in fig. 6 is:

1. and reading an android application software native Signature Block (APK Signature Block), and acquiring V2 version Signature data from ID0x 7109871a or acquiring Signature data from ID0xf05368c 0.

2. The data structure of each issuer is read separately.

3. A countersignature data structure (this structure is not limited to PKCS #7, and the countersignature data format as in fig. 3 or fig. 5, but may be any countersignature format) is generated, including a version number, a hash algorithm, an issuer subject item, an issuer certificate, a signature algorithm, and the like.

4. And if the countersignature signature needs to be added into the trusted time, obtaining the trusted time from the trusted time source, and adding the trusted time attribute into the countersignature data format.

5. And (3) using the original signature value as the original text of the attached signature (the signature value in the Signed data in the Signatures data structure is the original text), carrying out hash operation on the original text, and setting the calculated hash value into the credible attribute.

6. The trusted attribute data is signed using the countersignature certificate private key as the original text.

7. The countersignature signature is added to the ID-VALUE pair (ID can be any ID other than 0x7109871a and 0xf05368c0 and 0x3ba06f8 c) in the additional attributes of the native signature.

8. If there is also an issuer in the native signature, jump to step 2 if there is one.

9. And finishing the signature.

More specifically, the third party countersignature verification flow based on the V2 or V3 signature mechanism as shown in fig. 7:

1. and reading an android application software native Signature Block (APK Signature Block), and acquiring V2 version Signature data from ID0x 7109871a or acquiring Signature data from ID0xf05368c 0.

2. The data structure of each issuer is read separately.

3. The data structure of each countersignature signature is read out separately.

4. A countersignature signed digital certificate is obtained from the countersignature signature data structure.

5. If online verification of certificate status is required, verification is performed by the trusted certificate service.

6. If not, the certificate validity is verified locally, the certificate chain is verified, and the black and white list is verified.

7. And whether the countersignature has the hash attribute or not, and if not, the verification fails.

8. And acquiring a hash attribute, hashing the original signature, comparing the calculated hash value with the hash value in the hash attribute, and if the calculated hash value is different from the hash value in the hash attribute, failing to verify.

9. And taking the credible attribute data in the countersignature as an original text, verifying the countersignature value by using the countersignature certificate, and failing verification if the verification fails.

10. If there are countersignature signatures, jump to step 3.

11. Jump 2 if there is also a native signature.

12. And the verification is successful.

The above embodiments are only for illustrating the technical idea of the present invention, and the protection scope of the present invention is not limited thereby, and any modification made on the basis of the technical scheme according to the technical idea of the present invention falls within the protection scope of the present invention.