Shulou(Shulou.com)06/01 Report--

Last year, when I was developing an Android Mini Game, I signed the apk package personally. At that time, I just followed the steps described in the book, and I didn't find out why. Recently, after a detailed understanding of the security mechanism of java, I found that there were so many problems with little knowledge.

Let's start with the public key and private key mechanisms of asymmetric encryption. The so-called asymmetry means that the content encrypted with the private key should be decrypted with the public key (conversely, the public key encryption must also be decrypted with the private key. Public and private are actually equal couples, not in terms of technology, but in terms of the scope of the release.

With the uniqueness of encryption and decryption, we can draw some conclusions: those encrypted with private / public keys can only be decrypted through the corresponding public / private keys, while those that can be unlocked with some public / private keys must be encrypted with their private keys / public keys. It's a little tongue-twisting, but it's not hard to understand. Using this feature, we can achieve some mutual verification purposes.

Then introduce the relevant operations. Let's start with the keystore:

A Keystore is a file that stores a collection of key pairs, so it is also called a KeyStore file (you didn't know you could store more than one). Using the jdk tool, it is generated as follows:

Keytool-genkey-alias mykey1-keypass-validity 1000-keystore xxx.keystore

If the xxx.keystore file does not already exist, a new one is generated and a password is required to read and write to the xxx.keystore file. This does not need to be the same as the password parameter after keypass.

Continue with one more:

Keytool-genkey-alias mykey2-keypass-validity 1000-keystore xxx.keystore

At this point, the xxx.keystore file already exists, so this command is appended to another key pair. So enter the read and write password set for the first time.

Literally, you would think that alias is an optional alias, but it is not, this parameter is required, it is the "official" name of a pair of keys. Even if we do not enter this parameter:-alias mykey1, the system will automatically generate a key pair name called mykey

If you do not have this parameter:-keypass, then you will be prompted for input. Of course, direct enter is set to be the same as the read and write password of the library file.

Now, in fact, two key pairs, mykey1 and mykey2, have been stored in xxx.keystore. You can use this command to see:

Keytool-list-keystore xxx.keystore, of course, you also need to enter a password to view it.

With these key pairs, you can sign the jar file. The command goes like this:

Jarsigner-keystore xxx.keystore-storepass-keypass xxx.jar mykey1

Similarly, if you do not have this parameter:-storepass, the system will require input. There is no such parameter:-keypass. In one case, if the password of mykey1 is the same as that of the library, the signature can be successful. If it is different, it will be wrong.

To export the public key to a certificate, the command is:

Keytool-export-file xxx.cer-keystore xxx.keystore-alias mykey1, after entering the library password, a certificate file for xxx.cer will be generated.

There can be multiple keys in a library, but there is only one public key in a certificate. View the certificate with the command keytool-printcert-file xxx.cer, and the result is one of the library keys in the list.

Private keys generally cannot be derived with commands (and there is no need to export them). But it can be exported by writing code.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.