A third-party countersignature and verification method based on V2 or V3 signature mechanism

Abstract

The present invention discloses a third-party countersignature method based on a V2 or V3 signature mechanism. In an Android application signature data block, a V2 or V3 signature data block is found, an Android native signer data block sequence is found, an additional attribute data block is found in each signer data block, an ID is inserted into the additional attribute data block, and the value of the ID inserted into the additional attribute data block is the countersignature data; in the V2 signature data block, the ID is not 0x7109871a; in the V3 signature data block, the ID is not 0x7109871a or 0xf05368c0 or 0x3ba06f8c. The present invention also discloses a third-party countersignature verification method based on a V2 or V3 signature mechanism. The present invention is applicable to a third-party countersignature method under an Android system mobile application V2 or V3 signature mechanism, and realizes the signature tracing of various countersignature roles (application developers, testing agencies, application stores, etc.) under an Android system mobile application V2 or V3 signature mechanism, while not changing the original Android V2 or V3 signature verification mechanism.

Description

Technical Field

[0001] The present invention belongs to computer information security technology, and is used to provide a third-party countersignature method for the native V2 / V3 signature mechanism of Android application software. Background Art

[0002] The Android system requires that all applications must be signed before they can be installed, but there are no strict restrictions on signing certificates. Any self-signed certificate can be used for signing. Signing certificates are generally generated by developers themselves, and all developers can set the content of the certificate subject at will, making it easy to maliciously forge other developers' signing certificates. At the same time, signing certificates and private keys are generally stored in the form of ordinary data files, which may be copied, spread, and used maliciously. Once this happens, it becomes very difficult to trace the real developer of the Android application.

[0003] A countersignature is an additional signature on an already signed document as an endorsement and certification of the signed document. Its purpose is to prove that the data, actions or provisions in the document are approved by both the signer and the countersigner.

[0004] The third-party digital signature of an Android application is a counter-signature. The counter-signature is a signature issued by a third-party legitimate CA organization using a code signing certificate issued by the signature initiator (application developer, testing agency, application store, etc.). Without changing the original Android application packaging and signing process, the counter-signature is used to add a signature to the application that has been packaged and signed. The counter-signature can be one or more signatures.

[0005] Currently: Patent publication number CN106209379B, an Android APK countersignature and verification method proposes a countersignature method for an Android application for the native signature V1 version of the Android application.

[0006] In view of the continuous upgrade of the current Android system, the native signature V1 mechanism of Android applications has many shortcomings and security risks, such as:

[0007] Since the signature does not protect some parts of the APK, such as the ZIP metadata.

[0008] The APK verifier needs to process a large number of untrusted (not yet verified) data structures, and then discards data that is not protected by a signature. This results in a large attack surface.

[0009] APK Verifier must decompress all compressed entries, which takes more time and memory.

[0010] Due to these defects, Android application native signature V2 / V3 mechanisms are gradually replacing them, V2 solution (introduced from Android 7.0) and V3 solution (introduced from Android 9.0). However, there is currently no counter-signature mechanism under the V2 / V3 signature mechanism that is safe and reliable without affecting the native signature verification process. Summary of the invention

[0011] In view of the above technical problems, the present invention proposes a third-party counter-signature method based on the Android native signature V2 / V3 mechanism, which does not affect the original verification mechanism of the Android signature V2 / V3 version and can achieve the counter-signature effect.

[0012] To achieve the above-mentioned purpose, the technical solution adopted by the present invention is: a third-party counter-signature method based on the V2 or V3 signature mechanism, through which multiple counter-signatures can be added to the Android signature mechanism V2 or V3 version.

[0013] In the Android application signature data block, find the V2 or V3 signature data block, find the Android native signer data block sequence, find the additional attributes data block in each signer data block, insert the ID in the additional attributes data block, and the value of the ID inserted in the additional attributes data block is the countersignature data; in the V2 signature data block, the ID is not 0x7109871a; in the V3 signature data block, the ID is not 0x7109871a or 0xf05368c0 or 0x3ba06f8c.

[0014] Furthermore, the counter-signature is the original text with the signature value in the Signed data in the Signatures data structure in the Android V2 or V3 signature data block, and the original text is signed using the private key of the third-party counter-signature certificate. The counter-signature data format is not specifically restricted here, and the counter-signature data format can be PKCS#7, or other counter-signature formats. Since the Android native signature signs the hash of the Android data block ZIP path content block (Contents of ZIP Entries), ZIP central directory block (Central Directory), and the end of the central directory block (End of Central Directory), adding the counter-signature at this location does not affect the installation and upgrade of native Android applications.

[0015] Furthermore, the third-party countersignature method specifically includes the following steps:

[0016] S1. Read the native signature block of the Android application software, obtain the V2 signature data from ID 0x7109871a or obtain the V3 signature data from ID 0xf05368c0;

[0017] S2, read out the data structure of the issuer;

[0018] S3. Generate a counter-signature data structure, which includes a version number, a hash algorithm, an issuer subject item, an issuer certificate, a signature algorithm, etc.;

[0019] S4. Use the original signature value as the original text of the countersignature, perform a hash operation on it, and set the calculated hash value to the trusted attribute;

[0020] S5. Use the counter-signature trusted attribute data as the original text and sign it with the counter-signature certificate private key;

[0021] S6. Add the countersignature to the value of the ID inserted in the additional attribute data block of the original signature.

[0022] Finally, the signing is complete.

[0023] Preferably, S3 further includes the following steps: if the counter-signature needs to include a trusted time, the trusted time is obtained from a trusted time source, and the trusted time attribute is added to the counter-signature data format.

[0024] Furthermore, in the above method, if there is more than one issuer in the native signature, the data structure of each issuer is read out respectively, and steps S3 to S6 are executed for the data structure of each issuer. After the execution is completed, the signature is completed.

[0025] The present invention also discloses a third-party countersignature verification method based on a V2 or V3 signature mechanism, comprising the following steps:

[0026] S11. Read the native signature block of the Android application software, obtain the V2 version signature data from ID 0x7109871a or obtain the signature data from ID 0xf05368c0;

[0027] S12, read out the data structure of the issuer and the data structure of the countersignature;

[0028] S13, obtaining the digital certificate of the counter-signature from the counter-signature data structure;

[0029] S14. If the status of the digital certificate needs to be verified online, it is verified through a trusted certificate service.

[0030] If online verification is not required, verify the validity of the certificate locally, verify the certificate chain, and verify the blacklist and whitelist.

[0031] S15. After the counter-signature certificate is verified, it is determined whether the counter-signature has a hash attribute. If not, the verification fails.

[0032] S16. Hash the original signature and compare the calculated hash value with the hash value in the hash attribute. If they are different, verification fails.

[0033] S17. Take the trusted attribute data in the counter-signature as the original text and use the counter-signature certificate to verify the counter-signature value; if the counter-signature value verification is different, the verification fails. Use cryptographic related operations to verify, and successful verification proves the non-repudiation of the signature made by the private key corresponding to this certificate.

[0034] S18. If there is a countersignature, jump to step 3.

[0035] S21. If there is a native signature, jump to 2.

[0036] Furthermore, if there is more than one issuer in the original signature, the data structure of each issuer and the data structure of each counter-signature of each issuer's data structure are read out respectively; S13 to S17 are executed for all counter-signatures corresponding to each issuer.

[0037] The present invention has the following beneficial effects:

[0038] The present invention is applicable to a third-party counter-signature method under the Android system mobile application V2 or V3 signature mechanism, and realizes the signature tracing of various counter-signature roles (application developers, testing agencies, application stores, etc.) under the Android system mobile application V2 or V3 signature mechanism, while not changing the original Android V2 or V3 signature verification mechanism.

[0039] The application counter-signature uses a code signing digital certificate issued by a third-party legitimate CA organization, and the identity of the counter-signer is strictly reviewed and verified by the third-party CA organization. After the application is counter-signed with a code signing digital certificate, under the protection of the "Electronic Signature Law of the People's Republic of China", there are the following advantages:

[0040] The countersigner's identity must be authenticated and legal liability can be pursued.

[0041] After the application is countersigned, each countersignature link can be traced.

[0042] The counter-signature is completed by a code signing digital certificate issued by a third-party CA organization, which is more credible and easier to promote.

[0043] The countersignature can prove the developer's ownership of the application, and will provide strong evidence for the application developer when the application is pirated or infringed. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1It is the overall data structure under the Android application V2 and V3 signature mechanisms.

[0045] Figure 2 Signature data structure for Android application V2 version.

[0046] Figure 3 This is the data format of the counter-signature under the V2 signature mechanism of an embodiment of the present invention.

[0047] Figure 4 Signature data structure for Android application V3 version.

[0048] Figure 5 This is the data format of the counter-signature under the V3 signature mechanism of an embodiment of the present invention.

[0049] Figure 6 This is a flow chart of a countersignature method under a V2 or V3 signature mechanism according to an embodiment of the present invention.

[0050] Figure 7 Flow chart of the counter-signature verification method under the V2 or V3 signature mechanism of an embodiment of the present invention. DETAILED DESCRIPTION

[0051] To facilitate understanding by those skilled in the art, the present invention is further described below in conjunction with embodiments and drawings.

[0052] like Figure 1 As shown in the figure, unlike the overall data structure of the native signature V1 of the Android application, V2 / V3 adds an APK Signature Block on the basis of the original mobile application data block, forming four data blocks including the Contents of ZIP Entries, APK Signature Block, ZIP Central Directory, and End of Central Directory. There is an ID-VALUE paired data structure in the signature block, where ID 0x7109871a represents the V2 signature, and ID 0xf05368c0 represents the V3 signature.

[0053] The Android application native signature V2 and V3 schemes do not have a counter-signature mechanism based on the Android native signature verification without changing the Android native signature verification. The method of this embodiment mainly solves the counter-signature mechanism under the Android native signature V2 and V3 schemes.

[0054] Example 1: Figure 2 As shown, the Android V2 signature block, ID is 0x7109871a, the format is as follows:

[0055] ·Length-prefixed signer (length-prefixed) sequence:

[0056] Signed data with length prefix:

[0057] A sequence of length-prefixed digests:

[0058] ·signature algorithm ID(uint32)

[0059] (length-prefixed) digest - see integrity-protected content

[0060] A sequence of length-prefixed X.509 certificates:

[0061] X.509 certificate with length prefix (ASN.1DER format)

[0062] A length-prefixed sequence of additional attributes:

[0063] ID (uint32)

[0064] value (variable length: length of additional attributes - 4 bytes)

[0065] ·Sequence of length-prefixed signatures:

[0066] ·signature algorithm ID(uint32)

[0067] · Signature with length prefix on signed data

[0068] Length-prefixed public key (SubjectPublicKeyInfo, ASN.1DER format)

[0069] This embodiment is based on the V2 signature block and realizes that multiple counter-signatures can be added to the Android signature mechanism V2 version without affecting the original verification mechanism of the Android signature V2 version. It can be installed and upgraded normally and can achieve the counter-signature effect.

[0070] like Figure 3As shown, the specific operation is to find the V2 signature data block (ID is 0x7109871a) in the Android application signature data block, find the Android native signer (Signer) data block sequence, find the additional attributes data block in each signer data block, insert any ID with an ID other than 0x7109871a into this data block, and the value of the ID is the counter-signature data. The counter-signature is based on the signature value in the Signed data in the Signatures in the Android V2 signature block as the original text, and the original text is signed using the private key of the third-party counter-signature certificate. However, the counter-signature data format is not specifically restricted here. The counter-signature data format can be PKCS#7, or as follows Figure 3 The three columns on the left side show the countersignature data format, as well as other countersignature formats. If placed in this position, it is within the scope of protection of the present invention. Since the Android native signature is a hash of the Android data block ZIP path content block (Contents of ZIP Entries), ZIP central directory block (Central Directory), and the end of the central directory block (End of Central Directory), adding the countersignature in this position does not affect the installation and upgrade of the native Android application.

[0071] Example 2: Figure 4 As shown, the Android V3 signature block, ID is 0xf05368c0, the format is as follows:

[0072] ·Length-prefixed signer (length-prefixed) sequence:

[0073] Signed data with length prefix:

[0074] A sequence of length-prefixed digests:

[0075] Signature algorithm ID (4 bytes)

[0076] digest (with length prefix)

[0077] A sequence of length-prefixed X.509 certificates:

[0078] X.509 certificate with length prefix (ASN.1DER format)

[0079] minSDK (uint32) – If the platform version is lower than this number, this signer should be ignored.

[0080] maxSDK (uint32) – If the platform version is higher than this number, this signer should be ignored.

[0081] A length-prefixed sequence of additional attributes:

[0082] ID (uint32)

[0083] value (variable length: length of additional attributes - 4 bytes)

[0084] ID-0x3ba06f8c

[0085] Value-Proof-of-Rotation Structure

[0086] minSDK (uint32) - A copy of the minSDK value in the Signature Data section - used to skip verification of this signature if the current platform is not in the corresponding range. Must match the Signature Data value.

[0087] maxSDK (uint32) - A copy of the maxSDK value in the Signature Data section - used to skip verification of this signature if the current platform is not in the corresponding range. Must match the Signature Data value.

[0088] ·Sequence of length-prefixed signatures:

[0089] ·signature algorithm ID(uint32)

[0090] · Signature with length prefix on signed data

[0091] Length-prefixed public key (SubjectPublicKeyInfo, ASN.1DER format)

[0092] This embodiment is based on the native signature V3 version mechanism of Android applications, and invents a method for placing a third-party digital certificate counter-signature. Through this method, multiple counter-signatures can be added to the native signature mechanism V3 version of the Android application without affecting the verification mechanism of the Android application V3 version itself. It can be installed and upgraded normally and can achieve the effect of counter-signature.

[0093] like Figure 5As shown, the specific operation is to find the V3 signature data block (ID is 0xf05368c0) in the Android application signature data block, find the Android native signer (Signer) data block sequence, find the additional attributes data block in each signer's data block, insert any ID with an ID other than 0x7109871a, 0xf05368c0, and 0x3ba06f8c into this data block, and the VALUE of the ID is the counter-signature data. The counter-signature is based on the signature value in the Signed data in the Signatures in the Android V3 signature block as the original text, and the original text is signed using the private key of the third-party counter-signature certificate. However, the counter-signature data format is not specifically restricted here. The counter-signature data format can be PKCS#7, or as follows Figure 5 The three columns on the left show the countersignature data format, as well as other countersignature formats. Since the Android native signature is a hash of the Android data block ZIP path content block (Contents of ZIP Entries), ZIP Central Directory block (CentralDirectory), and the end of the central directory block (End of Central Directory), adding a countersignature to the location does not affect the installation and upgrade of native Android applications.

[0094] More specifically, Figure 6 The third-party countersignature process based on the V2 or V3 signature mechanism is shown as follows:

[0095] 1. Read the Android application software native signature block (APK Signature Block), obtain the V2 version signature data from ID 0x7109871a or obtain the signature data from ID0xf05368c0.

[0096] 2. Read out the data structure of each issuer separately.

[0097] 3. Generate a countersignature data structure (this structure is not limited to PKCS#7, as well as Figure 3 or Figure 5 The counter-signature data format can also be any counter-signature format), including version number, hash algorithm, issuer subject item, issuer certificate, signature algorithm, etc.

[0098] 4. If the counter-signature needs to include trusted time, obtain the trusted time from the trusted time source and add the trusted time attribute to the counter-signature data format.

[0099] 5. Use the native 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), perform a hash operation on it, and set the calculated hash value to the trusted attribute.

[0100] 6. Use the counter-signature trusted attribute data as the original text and sign it using the counter-signature certificate private key.

[0101] 7. Add the countersignature to the ID-VALUE pair in the additional attributes of the original signature (the ID can be any ID other than 0x7109871a, 0xf05368c0, and 0x3ba06f8c).

[0102] 8. If there is an issuer in the original signature, jump to step 2.

[0103] 9. Signature completed.

[0104] More specifically, Figure 7 The third-party countersignature verification process based on the V2 or V3 signature mechanism is shown below:

[0105] 1. Read the Android application software native signature block (APK Signature Block), obtain the V2 version signature data from ID 0x7109871a or obtain the signature data from ID0xf05368c0.

[0106] 2. Read out the data structure of each issuer separately.

[0107] 3. Read out the data structure of each countersignature separately.

[0108] 4. Obtain the digital certificate of the counter-signature from the counter-signature data structure.

[0109] 5. If you need to verify the certificate status online, verify it through a trusted certificate service.

[0110] 6. If not required, verify the validity of the certificate locally, verify the certificate chain, and verify the blacklist and whitelist.

[0111] 7. Does the counter-signature have a hash attribute? If not, verification fails.

[0112] 8. Get the hash attribute, hash the native signature, and compare the calculated hash value with the hash value in the hash attribute. If they are different, verification fails.

[0113] 9. Take the trusted attribute data in the counter-signature as the original text and use the counter-signature certificate to verify the counter-signature value. If the verification fails, the verification fails.

[0114] 10. If there is a countersignature, jump to step 3.

[0115] 11. If there is a native signature, jump to 2.

[0116] 12. Verification successful.

[0117] The above embodiments are only for illustrating the technical idea of ​​the present invention, and cannot be used to limit the protection scope of the present invention. Any changes made on the basis of the technical solution in accordance with the technical idea proposed by the present invention shall fall within the protection scope of the present invention.

Claims

1. A third-party countersignature method based on V2 or V3 signature mechanism, characterized by: In an Android application based on the V2 or V3 signature mechanism, find the V2 or V3 Android native signer data block sequence, find the additional attribute data block in each signer data block, and insert the ID-value pair in the additional attribute data block; In the V2 signature data block, the ID is not 0x7109871a; in the V3 signature data block, the ID is not 0x7109871a, 0xf05368c0, or 0x3ba06f8c; the value of the ID inserted in the additional attribute data block is the countersignature data; The counter-signature is to use the original signature value in the Android V2 or V3 signature data block as the original text, and use the private key of the third-party counter-signature certificate to sign the original text; The countersignature data structure includes version number, hash algorithm, issuer subject item, issuer certificate, and signature algorithm; Use the original signature value as the original text of the counter-signature, perform a hash operation on it, and set the calculated hash value to the trusted attribute of the counter-signature.

2. The third-party countersignature method based on the V2 or V3 signature mechanism according to claim 1, characterized in that: The specific steps include: S1. Read the native signer data block of the Android application software based on the V2 or V3 signature mechanism, obtain the V2 signature data from ID 0x7109871a or obtain the V3 signature data from ID 0xf05368c0; S2, read out the data structure of the issuer's signature data; S3. Generate a countersignature data structure; S4. Use the original signature value as the original text of the counter-signature, perform a hash operation on it, and set the calculated hash value to the trusted attribute of the counter-signature; S5. Use the counter-signature trusted attribute data as the original text and sign it with the counter-signature certificate private key; S6. Add the countersignature to the value of the ID inserted in the additional attribute data block of the original signature.

3. The third-party countersignature method based on the V2 or V3 signature mechanism according to claim 2, characterized in that: S3 further includes the following steps: If the counter-signature needs to include trusted time, obtain the trusted time from the trusted time source and add the trusted time attribute to the counter-signature data structure.

4. The third-party countersignature method based on the V2 or V3 signature mechanism according to claim 3, characterized in that: If there is more than one issuer in the native signature, the data structure of the signature data of each issuer is read out respectively, and steps S3 to S6 are executed for the data structure of the signature data of each issuer. After the execution is completed, the signature is completed.

5. The third-party countersignature method based on the V2 or V3 signature mechanism according to claim 2, characterized in that: If there is more than one issuer in the native signature, the data structure of the signature data of each issuer is read out respectively, and steps S3 to S6 are executed for the data structure of the signature data of each issuer. After the execution is completed, the signature is completed.

6. A third-party countersignature verification method based on V2 or V3 signature mechanism, characterized in that: The following steps are involved: S11. Read the Android application based on the V2 or V3 signature mechanism, obtain the V2 version signature data from ID 0x7109871a or obtain the V3 signature data from ID 0xf05368c0; S12, read out the data structure of the issuer's signature data and the data structure of the countersignature; S13, obtaining the digital certificate of the counter-signature from the counter-signature data structure; S14. Verify the validity of the counter-signed digital certificate; S15. After the validity verification of the counter-signature certificate is passed, it is determined whether the counter-signature has a hash attribute. If not, the verification fails. S16. Hash the original signature and compare the calculated hash value with the hash value in the hash attribute. If they are different, verification fails. S17. Take the trusted attribute data in the counter-signature as the original text and use the counter-signature certificate to verify the counter-signature value; if the counter-signature value verification is different, the verification fails.

7. The third-party countersignature verification method based on the V2 or V3 signature mechanism according to claim 6 is characterized in that: The method for verifying the validity of the countersigned digital certificate is: If the digital certificate status needs to be verified online, it is verified through a trusted certificate service; If online verification is not required, verify the certificate validity, certificate chain, and blacklist and whitelist locally.

8. The third-party countersignature verification method based on the V2 or V3 signature mechanism according to claim 6 or 7, characterized in that: If there is more than one issuer in the original signature, read out the data structure of each issuer's signature data and the data structure of each countersignature of each issuer's signature data data structure respectively; S13 to S17 are executed for all countersignatures corresponding to each issuer.

Images