One, foreword
Based on the introduction of basic encryption algorithm knowledge combined with software authorization activation requirements, this paper proposes a design idea and sample code of offline software authorization activation code based on RSA+AES encryption algorithm. Even if you don’t have software licensing design requirements, you can use this article to deepen your understanding of the RSA+AES encryption algorithm.
Second, encryption algorithm basis
The foundation of software licensing mechanism is encryption algorithm. Encryption algorithms can be simply divided into symmetric encryption algorithm (encryption and decryption adopt the same key) and asymmetric encryption algorithm (encryption with public key, decryption with private key or signature with private key, public key check). The following describes the basic concepts of AES and RSA encryption algorithms to help you understand the design roadmap of software authorization licenses.
2.1. AES Encryption algorithm
Advanced Encryption Standard (AES) Encryption algorithm, also known as Rijndael Encryption algorithm in cryptography, is a block Encryption Standard algorithm. The AES encryption algorithm was published by the National Institute of Standards and Technology (NIST) on FIPS PUB 197 on 26 November 2001 and became a valid standard on 26 May 2002. Now AES encryption algorithm has become one of the most popular symmetric key encryption algorithms.
2.2 RSA encryption algorithm and its application mode
RSA (Ron Rivest, Adi Shamir, Leonard Adleman) is an asymmetric encryption algorithm (public-key encryption algorithm). The RSA encryption algorithm has a pair of keys, a public key and a private key. The public key is used for encryption and the private key is used for decryption. After using the public key to encrypt the ciphertext, only the corresponding private key can be used to decrypt and obtain the original plaintext.
The principles of RSA are based on a simple knowledge of number theory: it is difficult to factor the product of two mutually substantial large numbers. RSA encryption algorithm has two application modes: encryption and decryption mode and signature check mode.
2.2.1 RSA encryption and decryption mode
The RSA encryption and decryption mode uses the public key for encryption and the private key for decryption. It is used in scenarios where plaintext data needs to be encrypted and decrypted. The sender sends the ciphertext encrypted with the public key to the receiver. The receiver decrypts the ciphertext with the private key to obtain the plaintext.
2.2.2 RSA signature verification mode
The RSA signature verification mode is the so-called “private key encryption, public key decryption” logic common in network articles. In fact, it refers to the mode of using private key signature and public key check. Its application is: the scenario where a message needs to be signed. The sender sends the plaintext digest message signed by the plaintext and private key to the receiver. The receiver decrypts the plaintext digest message signed by the private key using the public key and compares the plaintext digest message sent by the sender. If the plaintext digest message is the same, the signature is successfully verified. Common digital signature algorithms include MD5withRSA, SHA1withRSA, and SHA256withRSA.
Generally speaking, the encryption and decryption speed of symmetric algorithms is much faster than that of asymmetric algorithms, and the encryption length of RSA encryption algorithm is effective. The maximum length of a single encryption is not greater than the key length. Therefore, RSA+AES is generally used in practice. This is why RSA algorithm is used to sign digest or encrypt AES key to improve efficiency and avoid encryption length limit.
For example, TLS (Transport Layer Security, formerly known as Secure Sockets Layer, abbreviated: SSL: Encrypts random numbers and conversation keys using the RSA algorithm during the handshake. After the handshake succeeds, the AES algorithm is used for symmetric encrypted communication.
Software authorization logic design
Based on the introduction of the basic knowledge of RSA+AES encryption algorithm, WE believe that you have a perceptual understanding of encryption. Next, we take the Android platform as an example to design a set of offline software License generation and verification scheme.
3.1 Software Authorization Information
The activation code contains some basic authorization information, such as the bound AppId, License issue time, License validity period, and customer information, based on actual requirements. Here we use json data format to represent authorization information.
Example Authorization information:
{
"appId": "cn.fdm.offlicensedemo"."issuedTime": 1595951714."notBefore": 1538671712."notAfter": 1640966400."customerInfo": Amazon.com inc.
}
Copy the code3.2 Generation of activation code
Next, how can authorization information be safely escorted to the App and not be tampered with by middlemen? Remember the RSA signature pattern we just studied? What? Tamper proof? This is how the RSA signature algorithm is used.
Without further ado, the (pseudo) code:
License = AesKey16 + AesEnc(data).length + AesEnc(data) + RsaSign(AesEnc(data));
Copy the codeLicense: is the final generated activation code string.
AesKey16: a randomly generated 16-bit AES key with a fixed length. Therefore, the AesKey length is not required.
AesEnc(data). Length: indicates the length of the encrypted authorization information. The length needs to be consigned to facilitate interception because authorization information may change.
AesEnc(data) : indicates the authorization information encrypted by AES.
RsaSign(AesEnc(data)) : indicates the encrypted authorization information after the RSA private key is signed.
Generation logic:
Firstly, a random AES key (16 bits) is generated to encrypt the authorization information and desensitize the plaintext information. Then the entire encrypted authorization information is signed with the private key, and the string generated by stitching is the final activation code.
See here, perhaps some people will say: if you this activation code generation rules are known, how to prevent others from cracking forged ah?
The answer is that even if someone knows the generation rules and does not know the private key, they cannot tamper with the authorization information to crack the forged activation code. Because our core is signature logic based on asymmetric encryption algorithms. The private key is used to sign the ciphertext authorization information. Once the authorization information changes, the ciphertext also changes. Therefore, the public key cannot be used to verify the signature. Therefore, this activation logic is relatively secure as long as the private key is never disclosed.
Example of activation code generation:
public static String getLic(licenseBean bean) {
String lic = "";
try {
String aesKey = MyUtil.getRandomString(16);
String encData = AesUtil.encrypt(aesKey, bean.toJson());
String encDataLength = Integer.toHexString(encData.length());
String sign = RSAUtil.sign(RSA_PRI_KEY, encData);
lic = aesKey + encDataLength + encData + sign;
Log.d("bruce", lic);
return lic;
} catch (Exception e) {
e.printStackTrace();
returnlic; }}Copy the codeAn example activation code:
11Tf2wg9JjXeuvKTd8m4QwVfLJczRej06EAVut7coeJf3iSBDAkEl3E6faNYnG3SwiRbNBtSTmW+oRJ0kLVZf8ZIWeDQecyUqfBMiCwkYkPK4PAsmCK+kWd/ aAZ+90t9QSZTq/qe4VQzkFuAk9a7D+vcF4e3BkVUovZuzB9XvmdIrNw8menjFLdWE+S0YD+VIs7AS8wUBBdA9+aH9/mZ8Oc53klslYT0mGGtTK0g==YRjmOK NaA5hA4hTAmHAK8LvRWjJqzKbGpxALd3V9dcX6Ln1ImKw0NhAVflAA5asyD4eaoafExlclCU+ayd2CyHpFmlIKTd4Uzh20y5Qke03WrGMWgSEaCgz+mZrihX 0nwoyg5GXuOI0/dqOplX7mf+mSd8wgk9d2paOBvm5+ea4=
3.3 Verification of activation code
Since we have generated the activation code, the verification is nothing more than reading the License and intercepting and verifying the License according to the rules of splicing when we designed the activation code.
Activation steps:
- Read the License activation code from the program.
- According to the generation rules, each section of information is segmented and intercepted.
- The RSA public key check algorithm is used to verify the AesEnc(data) and **RsaSign(AesEnc(data))**. If the check algorithm passes, the information is trusted.
- Then decrypt **AesEnc(data)** using AesKey16 captured in the activation code to obtain a trusted plaintext authorization message.
- Finally, the authorization is compared with the current environment using trusted plaintext authorization information, such as AppId and authorization time, to complete the activation process.
Sample code:
public static boolean checkLic(String lic) {
if (TextUtils.isEmpty(lic)) {
return false;
}
try {
String aesKey = lic.substring(0.16);
int encDataLength = Integer.parseInt(lic.substring(16.18), 16);
String encData = lic.substring(18.18 + encDataLength);
String sign = lic.substring(18 + encDataLength);
if(! RSAUtil.verifySign(RSA_PUB_KEY, encData, sign)) {return false;
}
String data = AesUtil.decrypt(aesKey, encData);
String appId = JsonUtil.getString(data, "appId");
long notBefore = JsonUtil.getLong(data, "notBefore");
long notAfter = JsonUtil.getLong(data, "notAfter");
String customerInfo = JsonUtil.getString(data, "customerInfo");
if(! MyUtil.getAppId(App.getContext()).equals(appId)) {return false;
}
long time = System.currentTimeMillis();
if (time < notBefore || time > notAfter) {
return false;
}
return true;
} catch (Exception e) {
e.printStackTrace();
return false; }}Copy the codeAt this point, a simple software activation code authorization License has been designed. See the link at the end of this article for the demo code.
Fourth, the enhancement of software authorization
4.1. Bind hardware serial number logic
In software authorization, it is common to run programs on the device first, extract relevant information, and generate activation codes. In fact, the extracted information is the unique information summary of the device, such as Mac address, serial number and other information that is uniquely associated with the hardware.
Therefore, if we want to prevent software authorization from being copied or transferred, we need to encrypt and authorize hardware information.
4.2 The calibration algorithm is placed in the Native layer
This article uses the Android code example, shows an authorization code generation and verification logic. However, because Java code is easy to be decomcompiled and cracked, the actual authorization activation scheme recommended that the verification logic and key business logic be placed in the Native layer. The C/C++ code of Native layer can directly read the authorization file, intercept and verify, which can increase the difficulty of cracking.
Five, the conclusion
This paper mainly introduces the basic knowledge of RSA+AES encryption algorithm, and designs a simple offline software authorization License scheme based on software authorization requirements, which provides an idea for software authorization activation design. In practical application, more details need to be taken into account, to increase the difficulty of cracking through a certain degree of improvement and evolution, and to hold the position in the link of attack and defense.
Some people may say: software authorization can be cracked, such as Microsoft is not not able to escape the software cracked? It is, but that doesn’t mean software licensing is useless. One of the value of software licensing mechanisms is the anxiety associated with using cracked versions, especially at the enterprise level, to ensure stable software licensing.
Finally, attached a complete Aandroid side example code: OffLicenseDemo. If this document is of any help or inspiration to your development, like/follow/share three links is the best incentive for the author to continue to create, thanks for your support!
Reference Documents:
AES encryption algorithm
Principle of RSA Algorithm (1)
Principle of RSA Algorithm (2)
Wikipedia: public-key encryption
RSA encryption algorithm
Copyright Notice:
This article first appeared in my column AndDev Android development welcome your attention.