Example analysis of the android signature mechanism
The article, which focuses on an illustrative analysis of the android signature mechanism, has some merit, and interested friends can refer to it in the hope that it will be of great benefit to you when you have finished reading it。
Android signing mechanism
What's an android signature
Students who are aware of https communications are aware of the need to address at least two issues in communications: first, to ensure the authenticity of the source, and second, to ensure that the information is not tampered with by third parties。
Similarly, in installing apk, there is also a need to ensure the authenticity of apk sources and that apk is not tampered with by third parties. In order to address this problem, android officially requires the developers to sign apk, which is the process of encrypting apk. Two basic concepts are needed to understand how to achieve a signature: a summary, a digital signature and a digital certificate。
Summary of information
Message digest, also known as digital digest or fingerprint. In short, the message summary is the execution of a one-way hash function on the message data to generate a fixed-length hash value, which is the message summary。
The encryption hash function mentioned above is the message summary algorithm. It has the following characteristics:
No matter how long the message is entered, the calculated summary is always fixed。
For example: 128 bits of messages applied to the md5 algorithm summary, and ultimately 160 bits of output using the sha-1 summary, and the variant of sha-1 can produce 192 bits and 256 bits of summaries. It is generally believed that the longer the final output of the summary, the safer the algorithm。
A summary of the news looks "random."。
These bits seem to be a mess. A large number of inputs can be used to test whether their output is the same, generally, different inputs will have different outputs, and the output summary message can be randomly tested. However, a summary is not truly random, since two summaries of the same message are obtained using the same algorithm, and the result is necessarily the same; if it is truly random, it cannot be repeated in any case. This post is part of our special coverage syria protests 2011。
The message summary function is a one-way function, i. E. Only a positive summary of the information cannot be recovered from the summary and no information related to the original information can be found at all。
Of course, the method of strong attack, i. E. Trying every possible information to calculate its summary to see if it is the same as the summary already in place, will eventually restore the message of the summary. In practice, however, the information to be obtained may be one of the endless ones, so such a strong attack is almost ineffective。
Good summary algorithm. No one can find a collision. In other words, it is not possible to find two messages, making them identical。
Although a "crash" is certain (as a long-term, explicitly short summary of hash is bound to produce a collision). In the case of a given summary, it is not possible to find a single information to make the summary properly given。
It is because of these characteristics that the summary algorithm is widely used in the field of "digital signatures" as an explicit summary algorithm. The well-known summary algorithms include the md5 and sha-1 algorithms of rsa and their large variations. Sha-256 is an upgraded version of sha-1, and the default algorithm used for android signatures has now been upgraded to sha-256。
It is precisely because of the nature of the summary that it is appropriate to validate the integrity of the data. For example, download a big file during a web transfer bigfile, we download bigfile and bigfile. Md5, bigfile. Md5 save bigfile's summary, we generate bigfile's summary locally and bigfile. Md5 compares, and if the content is the same, the download is correct。
Organisation
The role of digital signatures is to ensure the integrity of the transmission of information, the identification of the sender, and the prevention of a lie in a transaction. The digital signature technique is to encrypt summary information with the sender's private key and transmit it to the recipient with the original text. The recipient can decrypt encrypted summary information only with the sender's public key and then use the hash function to produce a summary information in the original language received, compared to the decrypted summary information. If the same is true, indicate that the information received is complete and has not been modified during the transmission, or that the information has been modified so that the digital signature can verify the integrity of the information。
If rsa is used as a digital signature program, it uses the following processes: such a signature is actually encrypted with the private key of the source, and the encrypted message is signed; and the corresponding public key is used to verify that if the message is the same as the original message, the message is complete or incomplete。
Rsa is the opposite of using public key passwords to keep information confidential. Because only the source has its own private key and no one else can re-encrypt the source message, even if the source message is intercepted and changed, the signature cannot be re-generated, because only the private key of the source can form the correct signature。
By the same token, if you verify that the message is declassified with the same public key as the message, you can know whether the message has been altered and whether the message is actually from the intended source, and the source cannot deny that it was sent. So this completes the digital signature function。
Such a programme, however, is too simple to guarantee the integrity of the information and its confidentiality. Moreover, this option requires all messages to be encrypted, which is very inefficient when the message is longer, mainly because of the inefficiency of the public key system's decryption process. Such programmes are therefore generally undesirable。
Almost all digital signature schemes are to be used together with fast and efficient summary algorithms (hash functions), which constitute an effective digital signature scheme when used in combination with summary algorithms。
Sign certificate
The problem of reliable communications could indeed be resolved through digital signature techniques. Once the signature has passed, the recipient is satisfied that the message was sent by the intended sender, and the sender cannot deny having sent it。
It has been noted that the digital signature method described above presupposes that the recipient of the message must obtain the correct public key in advance. If the public key is tampered with in the first place, the bad guy will be treated as a good person, and the real sender's message to you will be considered invalid. Moreover, information channels for prior communication of public keys are often not available。
How can public key security be assured? This will depend on digital certificates。
A digital certificate is a document containing information about the public key owner and the public key signed digitally at the centre of the certificate. The format of digital certificates is generally based on international standards x. 509 v3, and a standard x. 509 digital certificate typically contains the following:
Issuer, the issuing authority: which agency issued the certificate (ca centre)。
Validity: validity: the period of validity of the certificate, or the period of use. After that date, the certificate expired。
Certificate owner's public key (public-key): the certificate owner wants to publish the public key。
Name of the owner of the certificate (subject): to whom the certificate is issued, or owner of the certificate, typically the name of the person or company, the name of the institution, the website of the company, etc。
Signature algorithm: the encryption algorithm used for digital signatures of this number of certificates allows the fingerprint to be decrypted using the public key in the certificate of the certificate issuer。
The digital signature of the certificate by the issuer (thumbprint): the hash value (fingerprint) of the digital certificate is used to ensure the integrity of the digital certificate and that the certificate is not modified。
The rationale for digital certificates is that, at the time the certificate is issued, the ca agency calculates its hash value (fingerprint) on the basis of the signature algorithm (signature algorithm) for the certificate as a whole and puts it together with the certificate. When the user opens the certificate, the user also calculates the hash value (fingerprint) of the certificate on the basis of the signature algorithm, indicating that the certificate has not been modified if it is paired with the fingerprints recorded in the certificate。
As can be seen, the digital certificate itself uses digital signature techniques, except that the signature is the whole certificate (which contains the public key of the owner of the certificate, among others). Unlike a normal digital signature, the signatory of a digital certificate is not an ordinary institution, but a ca institution。
In summary, the general flow of digital signatures and signature authentication is illustrated in the following chart:
Android packs
The whole android packing process is as follows:
Compile packing steps:
1, pack resource files to generate r. Java files
The android packing tool (e:\d)Documents \android\sdk\build-tools5. 0. 0\aapt. Exe)。
During this process, the android manifest. Xml and layout files of the project are compiled and the corresponding r. Java is generated, and android manifest. Xml is compiled into binary。
Resources stored under the ap reis catalogue, which are mostly compiled and converted into binary files before the app packs, are given a source id for each file. For access to this type of resource, the application layer code is accessed through access id. Android uses the aapt tool to compile resource files and generate a resource. Arsc file, which is equivalent to a document index table, which records a great deal of resource-related information。
2. Processing of aidl files and generation of corresponding java files
The tool used in this process is aidl (android interface defense language), the android interface description language (e:\d){\chffffff}{\ch00ffff}。
Aidl tools resolve interface definition files and then generate the corresponding java code interface for program call. If the aidl file is not used on the project, you can skip this step。
3. Compile project source code and generate mass files
All java codes in the project, including r. Java and . Aidl files, are compiled by java compilers (javac) into. Class files, and the resulting class files are located in the project bin/classes directory。
Converts all class files to generate classes. Dex files
Dx tool to generate classes. Dex files for the android system dalvik virtual machine, in (e:\d))。
Any third party librries and . Class files are converted into . Dex files. The dx tool mainly works on converting java bytes into dalvik bytes, compressing constant pools, eliminating redundancy information, etc。
Packing to generate apk files
All resources that are not compiled, such as those under the images, asets catalogue (this type of document is an original file, which is not compiled by the ap when packaged, but is directly packaged into the app. For access to this type of resource file, the application layer code needs to be accessed by file name); the compiled resources and. Dex files are packaged into the final. Apk document by the ackbuilder tool。
Packing tool ackbuilder is in the "android-sdk/tools " directory. Apkbuilder is a script that is actually called (e:\d)Documents \android\sdk\tools\lib) document co. Android. Sdklib. Build. Apkbuildermain category。
6. Signing of apk documents
Once the apk file is generated, it must be signed before it can be installed on the device。
In the development process, two types of signatures were used primarily as a keepstore. One is debug. Keystore, which is used mainly for debugging, which is used when running directly on a mobile phone in eclipse or android studio。
The other is for the release of the official version。
7. Reprocessing of signed apk files
If you release apk as an official version, you have to match the apk, the tool used is zipalign (e:\d)\documents\android\sdk\build-tools5. 0. 0\zipalign. Exe)
The main process of alignment is to shift all resource files in the apk package from the start of the file to four-bytes multiple, so that the speed of access to apk files through memory mapping is faster. The effect of alignment is to reduce the use of running memory。
As can be seen from the figure above, the signature takes place in the penultimate step of the packing process, and the signature is directed at the already existing apk package and does not affect the code we write. It is true that android's signature is broadly based on the calculation of the hash of all the files in the unsigned apk, and then on the preservation of the hash (cert. Sf) in the calculation of the hash, and then on the calculation of the hash, which is then encrypted and preserved through the private keys in the keystore that we have generated above (cert. Rsa)。
Android signing program
From its inception to its present version 1. 0, the android system has undergone three generations of applied signature programmes, v1, v2 and v3。
Of these, v1 to v2 are subversive, mainly in order to solve the security problems of the jar signature program, while the v3 program has not been significantly restructured and can be understood as an upgraded version of the v2 signature program。
Upgrading the v1 to v2 programs has the greatest impact on developers and is the issue of channel signing. The signature of v2 is also intended to distinguish between the different channels, the installation packages on the market, and to carry the only sign of the channel, which is what we commonly call the channel packages. It was good to open up its own signature channel programmes at all major plants, such as walle (american) and vas dolly (tempo)。
V1 signature
Signing tool
Android applications have two signature tools: jarsigner and apksigner. Their signature algorithms do not make any difference, mainly because they use different documents. Their differences are as follows:
Jarsigner: jdk 's own signature tool, which allows jar to be signed. Other organiser the generated signature file is by default named by an alias of keystore。
Apsigner: signing tool for android applications provided by android sdk. Sign using pk8, x509. Pem files. Where pk8 is a private key file, x 509. Pem is a file containing a public key. The resulting signature file is jointly named after cert。
Now that both tools are signed for apk, is there any connection between the keystore file and pk8, x 509. Pem? The answer is yes, they can be converted between them, and there is no longer an analysis of how they are converted, and there are many examples online。
There is also a knowledge point that requires attention, if we look at the content of a keystore file, we find that it contains a md5 and sha1 summary, which is a summary of data on the private key in the keystore file, which is also the information that we need to fill in when applying for many development platform accounts。
Signing process
First of all, we pick up a signed apk (sample-release. Apk) for decompression and get the documents shown in the chart below。
You can find it in mThere are three documents in the eta-inf folder: manifest. Mf, certt. Sf, certt. Rsa. They are the documents generated during the signing process, and their effect is as follows。
Manifest. Mf
The file actually saves all entries in the aapk over time, skips the directory, and in the case of a file extracts a summary of the file using the sha1 (or sha256) message algorithm and then does bAfter ase64 is coded, the value that is the "sha1-digest" attribute is written in a block in the manifest. Mf file. This block has a "name" attribute, the value of which is the file 's path in the aapk package。
Open the manifest. Mf file, which is illustrated below:
Cert. Sf
Open the cert. Sf file, which reads as follows:
Cert. Rsa
The cert. Sf file that was previously generated is used to calculate the signature with the private key, and then the signature and the digital certificate containing the public key information are added to the cert. Rsa. It should be noted that the certt. Rsa certificate in android apk is self-signed and does not require a certificate issued or certified by a third party authority, and the user can generate the self-signed certificate on its own in the local machine. Android does not currently perform ca authentication of application certificates。
Open the cert. Rsa file as follows:
All you see here are binary files, because the rsa is encrypted, so we need to view them with an opensl command, as shown below。
Us$us$usl pkcs7-inform der-in/sample-release new/original/mEta-inf/cert. Rsa-text-noout-print certs
Following the above orders, the following figures were obtained:
As can be seen from the above, a complete signature process is as follows:
Sign verification
The signature authentication takes place during the installation of apk and is divided into three steps:
In conclusion, a complete signature validation process is as follows:
V2 signature
The apk signing program v2 is a full document signing program that can identify all changes to the protected parts of apk, thus helping to speed up authentication and enhance integrity assurance. From the previous analysis, two places can be found where the v1 signature can be improved:
Sign confirmation slow
A summary calculation of all the files in the apk is required during the validation process, and signing and checking on machines with high aapk resources and poor performance will take longer, resulting in slow installation。
Inadequate integrity guarantees
MThe eta-inf directory is used to store signatures. Naturally, the directory itself does not count for the signature verification process, and it can be randomly added to the directory, for example, some fast-track batch packing options choose to add channel files to the directory。
To solve these two problems, a new apk signature scheme v2 was introduced in android version 7. 0。
V2 improvements
As the v1 is verified only for a single zip entry, many changes can be made after the apk is signed - moving or even recompressing the file. In fact, this is how the zipalign tool to be used in the compilation process is used to adjust the zip entry to the correct byte limit to improve running time performance. And we can use this to modify m after packingThe contents below the eta-inf directory, or a modified zip comment, can be checked for multi-channel wrapping。
The v2 signature will verify all bytes in the archive, not individual zip entries, and therefore cannot run zipalign after signing (must be executed before signing). That is why now, in the process of compilation, google combines compression, adjustment and signature。
V2 signature
The v2 signature adds a new block (signature block) to the original aapk block that stores information on the signature, abstract, signature algorithm, certificate chain and additional properties, and this block has a specific format. The final apk signature is in fact four pieces: head file area, v2 signature block, central directory, tail. The figure below shows the composition of the v1 and v2 signatures。
The entire signing block is formatted as follows:
In multiple id-value pairs, the id of apk signing information is 0x7109871a, which contains the following:
Signer:
Summarizes: a signature block can contain multiple id-value signatures, and apk signature information will be stored in a key pair of ids 0x7109871a. He can contain signature information from multiple signatories, each of which contains signed data, signed data, public keys, of which signed data contains mainly summary series, certificate chain, additional attributes, signatureatures contains the signature values calculated by multiple signature algorithms, and public key indicates the signatory's public key, which is used to verify the signature。
Signing process
First, with reference to the aapk abstract calculation rules, for each summary algorithm, the results are as follows:
In short, the extracts of these subparagraphs are calculated separately by dividing the apk by 1m size, and finally, the extracts of these subparagraphs are calculated to be the final summary of apk. The aapk summary + digital certificate + other attribute generated signature data is then written to the aapk signing block。
Sign confirmation process
Let's look at the verification of the v2 signatures. The overall pattern is shown in the chart below。
Of these, the v2 signature mechanism was supported in android 7. 0 and above. Therefore, for android 7. 0 and above, if a v2 signature block is found during installation, the v2 signature mechanism must be followed and cannot be bypassed. Otherwise downgrade the v1 signature mechanism. V1 and v2 signature mechanisms can exist simultaneously, with v1 and v2 versions of m for bothAn x-android-apk-signed attribute is one of the . Sf file properties of eta inf。
X-android-apk-signed: 2
Before the channel package was generated by the mEta-inf adds an empty file to the directory, using the name of the empty file as the only identifier for the channel. But under the new application signature scheme mEta-inf has been included in the reserveEta-inf adds empty files to a scheme that affects blocks 1, 3 and 4. This issue can be summarized by reference to the multi-channel united states mission。
V3 signature
The new version of the v3 signature is based on the v2 basis and continues to be verified by checking the entire compressed package. The difference is that a new certificate (attr block) can be added to the signature section. In this new block, we record our previous signature information, as well as new signature information, to replace and upgrade signatures with a key rotation scheme. This means that as long as the old signature certificate is in hand, we can change the signature through it in the new apk file。
The v3 signature added new block (attr) stores all signature information by smaller level block in a chain table。
Each of these nodes contains the signature certificate used to apply the signature for the previous version, and the oldest signature certificate corresponds to the root point. The system will allow the certificate in each node to be signed as the next certificate in the list, thus providing evidence that each new key should be as credible as the old key。
Sign confirmation process
Android's signature programme, however upgraded, ensures downward compatibility. Therefore, with the introduction of the v3 scheme, android 9. 0 and higher versions can be used to try to verify apk in turn under the apk signing scheme, v3 - > v2 - > v1. The older platform will ignore the v3 signature and try the v2 signature, which will last to verify the v1 signature。
The entire validation process, as illustrated below:
It should be noted that, in the case of coverage, signature verification only supports upgrades and not demotion. This means that an aapk with a v1 signature is installed on the device and can be covered with an aapk with a v2 signature, which is not allowed。
