One, foreword
After many of the darkest moments of your life, you read this article with regret and anger: Why didn’t you write it sooner? !
Your darkest moments include:
1. The project you are in needs to be connected to the bank, and the bank needs you to provide an encryption certificate. You have only one CET-6 certificate in hand. I’m not sure if this will meet their needs. Projects are delayed, raises go up in smoke, your mortgage is cut off, your girlfriend breaks up and you feel like your life is over because you haven’t been able to provide the right credentials.
2. You’ve been an active follower for 2 months, and you finally understand the. CRT certificate. Join a new project that is undergoing a certificate hosting transformation. Ha ha, I can do this problem, is to upload the certificate file to the hosting system. You shout at the project team members, let go of the certificates and let me do it! Squeeze in a look, it is an old project, there is no certificate, at that time use public key and private key, how public key and private key into a certificate… Because you can not provide the correct certificate, the project is postponed, the salary plan is ruined, the monthly payment is cut off, the girlfriend broke up, you feel that life is over.
3. You endured hardships for 3 months and found out the ins and outs of SSL certificates. When you join a new project, you tell the project manager your story and become an expert in safety certification. The project manager was overjoyed. It happened that the project was undergoing data security transformation, and the database needed to enable SSL. It came at the right time. The next day, half an hour before work, you slowly walk to the project manager, “the goods you want have arrived”, you will produce three certificates, this is the key file, this is the public key file, this is the certificate file. The project manager nodded and shook his head. I wanted JKS files. You said it would be provided tomorrow. The next day, half an hour before leaving work, you hand the JKS file to the project manager, who nods and shakes his head. Where is the password? How can we do without a password? Projects are delayed, raises go up in smoke, your mortgage is cut off, your girlfriend breaks up and you feel like your life is over because you haven’t been able to provide the right credentials.
This article will reveal the secrets of RSA key files in the following sections:
- Mathematical basis of RSA algorithm
- Six layer model of RSA secret key system
- Using the RSA Tool
- RSA key usage scenarios
Note: Although the key is not the same as the certificate strictly, the term key in this article covers public key, private key, certificate and other concepts unless specifically specified.
Second, the mathematical basis of RSA algorithm
RSA algorithm is based on number theory, the complexity of RSA algorithm is based on a large number of prime decomposition is NP difficult, very difficult to crack. Mathematical concepts related to RSA algorithm:
For any number x, we can calculate y:
From y, x can be calculated:
In other words, after x generates y from the number pairs (m,e), y can be restored to x by the number pairs (m, d).
Here, we actually demonstrate the mathematical process of RSA encryption and decryption. According to Formula (1), the process of calculating y based on x is encryption, and the process of calculating X based on Y is decryption.
In practice, the RSA algorithm uses the public key to encrypt and the private key to decrypt. Therefore, the number pair (m,e) is the public key and (m, d) is the private key.
In fact, to improve the decryption speed of the private key, the private key stores some intermediate results, such as p, q, e, etc.
Therefore, you can use the private key to export the public key in practical applications.
Three, RSA secret key six layer model
In order to understand the principle of RSA key, I creatively invented the concept of RSA key six-layer model. Each layer defines its own responsibilities and boundaries, and the lower it is, the more abstract and theoretical it represents; The higher the level, the more practical the content is.
- **Data: **Data layer, which defines the mathematical concepts of RSA keys (m, E, P,q, etc.) or participating entities (subject, issuer, etc.).
- **Serialization: **Serialization layer, which defines methods for serializing complex data structures.
- **Structure: The **Structure layer, which defines the data organization of RSA keys in different formats.
- **Text: ** The Text layer, which defines methods for converting binary keys into Text.
- **Presentation: **Presentation layer, which defines the representation of the text format key.
- **Application: **Application layer, which defines various scenarios for using RSA keys.
Each layer is explained in detail below.
3.2 the data layer
As you can see from above, a secret key is a data structure, each containing two or more members (the public key contains M and E, the private key contains M, D, e, and some other intermediate results). To keep these data structures in a file, you need to define some format to serialize the secret keys.
3.3 Serialization Layer
Common formats for defining data structures today include text formats such as JSON and XML.
For example, we could theoretically define a public key as a JSON:
Json-formatted key
{
"m":"15",
"e":"3"
}
Copy the code
<? xml> <key> <module>15</module> <e>3</e> <d>3</d> <p>3</p> <q>5</q> <key>Copy the code
3.3.1 the ASN. 1
Asn.1 stands for Abstract Syntax Notation dot one (1st edition). The number 1 is added after ASN by ISO to keep ASN open, so that ASN with more powerful functions can be named ASN.2, etc., but it has not appeared yet.
Asn.1 describes a data format for representing, encoding, transmitting, and decoding data. It provides a formal set of formats for describing the structure of an object, regardless of how it is executed in the language, how the data is referred to, or what the application is.
3.3.2 ASN.1 Encoding rules
Specific asn.1 syntax (zh.wikipedia.org/wiki/ASN.1), you can refer to wikipedia only briefly go over here.
Data type in ASN.1 is in the form of T-L-V: the first two bytes represent the data type, the next two bytes represent the length of bytes, and V represents the specific value. Common basic types of values include Integer and UTF8String, and complex structures include SEQUENCE and SET. The key and certificate are of SEQUENCE type, and the SEQUENCE type is 0x30 and the length is greater than 127, so the second byte is 0x82. Asn.1 encoded data is binary data. After being encoded in BASE64, 0x3082 is the character string MI. Therefore, the first two characters of the secret keys stored in all PEM files are MI.
BER, CER, DER are ASN.1 encoding rules. Among them, Distinguish Encode Rules (DER) are unambiguous coding Rules to ensure the same serialization results generated by the same data structure.
Asn.1 only defines the serialization of abstract data, but the specific encoding needs to be further defined.
Strictly speaking, ASN.1 is not yet a format for defining data, but a syntactical standard according to which a variety of formats can be formulated.
3.4 structure layer
According to the purpose of the key file, the following standards define different structures for ASN.1 encoding of the key data. In general, different formats of keys imply different structures.
- Pkcs# 1 is used to define the RSA public and private key structures
- Pkcs# 7 is used to define the certificate chain
- Pkcs# 8 is used to define the public and private keys of any algorithm
- Pkcs# 12 is used to define the private key certificate
- X.509 Defines public key certificates
See 3.5.2 below for a detailed comparison of the differences between these formats
3.5 the presentation layer
Asn.1 and its encoding rules (BER, CER, DER) define binary rules and are saved in binary format in files. Since the E-mail standards of the time did not support the transfer of binary content, if the secret key file was transferred via E-mail, the binary file needed to be converted to text. This is where privacy-enhanced Mail (PEM) comes in. Therefore, the key content stored in the PEM file is the binary content generated by ASN.1 encoding and base64 encoding text.
In addition, in order to facilitate the user to identify which format is added at the beginning and end of the file in the identity of the text. PEM files generally contain three parts: the first line label, BASE64 encoded text data, and the last line label.
-----BEGIN <label>-----
<BASE64 ENCODED DATA>
-----END <label>-----
Copy the code
3.5.2 PEM File Format Summary
3.6 the application layer
In actual use, the public and private keys are not only used to encrypt and decrypt data, but also key distribution and authentication according to different application scenarios. Section 5 lists some common usage scenarios for RSA keys.
Four, tools,
4.1 the openssl
Note: The -rsapublickey_in and -rsapublickey_out options in the following commands must be supported by OpenSSL 1.0 or later. If an error occurs, please check the OpenSSL version.
4.1.1 Creating a Key File
Openssl rsa in private.pem -out openssl genrsa in private.pem -out Pem -pubout openssl rsa -in private.pem -out public.pem -rsapublickey_outCopy the code4.1.2 Key File Format Conversion
Pem -out public-pkcs8.pem -rsapublickey_in #pkcs#8 converts the public key to pkcs#1 Pem -out public-pkcs1.pem -pubin-rsapublickey_out #pkcs#1 converts the private key to openssl pkcs8 Pem -topk8 #pkcs#8 converts the private key to pkcs#1 openssl rsa -in private-pkcs8.pem -out private-pkcs1.pemCopy the code4.1.3 Viewing Key File Information
Pem -pubin -text -noout openssl rsa -in private.pem -text -nooutCopy the code4.1.4 certificate
RSA certificate
Pem -out request. CSR -new # Create a certificate from the existing CSR file and private key, valid for 365 days openssl x509 -req -in Request. CSR -signkey private.pem -out cert. CRT -days 365 # Generate a new certificate and private key openssl req -nodes -newkey rsa:2048 -keyout root.key CRT -x509 -days 365 # Sign other CSR files with existing certificate and private key openssl x509 -req in child. CSR -days 365 CRT -ca root. CRT -cakey root.key -set_serial 01 -out child. CRT # Query certificate information openssl x509 -in child. CRT -text -noout # Extract public key from certificate openssl x509 -pubkey -noout -in child.crt > public.pemCopy the code4.1.5 JKS
Keytool -importcert -alias Cacert -file ca. CRT -keystore truststoremysql. JKS -storepass password123 CRT -inkey client.key -name "mysqlclient" -passout openssl pkCS12 -export -in client. CRT -inkey client.key -name "mysqlclient" -passout Pass :mypassword -out client-keystore.p12 # convert PKCS#12 format to JKS format keytool -importkeystore -srckeystore client-keystore.p12 -srcstoretype pkcs12 -srcstorepass mypassword -destkeystore clientstore.jks -deststoretype JKS -deststorepass password456Copy the code5. RSA Key Usage Scenarios
5.1 HTTPS Unidirectional Authentication
HTTP is transmitted in plaintext. To prevent HTTP packets from being leaked or tampered with, HTTPS encrypts and decrypts HTTP packets using SSL or TLS.
To put it simply, the HTTPS protocol requires the client and server to exchange the session key and then use the session key to encrypt and decrypt communication packets. The whole communication process is as follows:
- On the server, create the RSA certificate server. CRT and private key server.key as shown in 4.1.4, and configure them on the WEB server.
- The client establishes a connection with the server, and the server sends the server.crt certificate to the client.
- The client verifies the server certificate, randomly generates a session key, encrypts the session key using the server certificate, and sends the session key to the server.
- The server decrypts the encrypted session key using server.key to obtain the original session key.
- The client encrypts HTTP packets using the session key and sends them to the server.
- The server decrypts HTTP encrypted packets using the session key to obtain the original HTTP packets.
- The server encrypts HTTP response packets using the session key and returns them to the client.
- The client decrypts the HTTP response packet using the session key and obtains the original HTTP response packet.
(Figure 1. HTTPS unidirectional authentication)
5.2 HTTPS Bidirectional Authentication
The HTTPS scenario described in Section 5.1 is a common scenario in which only the client authenticates the server. That is, after receiving the certificate from the server, the client verifies the validity of the certificate, for example, whether it is ca-signed and whether the certificate is still valid. This one-way validation is fine in scenarios such as browser access, because the service is designed to serve tens of thousands of users. However, in some scenarios, such as providing services only to specific enterprises and merchants, the server needs to authenticate the client, so that the trusted client that passes the authentication can be normal.
HTTPS bidirectional authentication is required to access the server.
HTTPS bidirectional authentication is to enhance the authentication between the server and the client based on HTTPS unidirectional authentication. The solution is that the client saves the client certificate client. CRT, but the client certificate is not signed by the client itself or CA, but is signed by root.key on the server. During HTTPS bidirectional authentication, the client needs to send the client certificate client. CRT to the server. The server uses root.key to verify the certificate correctly before communicating with the client. Otherwise, the client is not a trusted client and the server refuses to provide subsequent services.
The specific communication process is as follows:
- On the server, create the RSA certificate server. CRT and private key server.key as shown in 4.1.4, and configure them on the WEB server.
- The client establishes a connection with the server, and the server sends the server.crt certificate to the client.
- The client verifies the server certificate and continues the subsequent process after the verification succeeds. If the verification fails, the connection is disconnected and the process ends.
- The server sends a packet to the client to request the client to send the client certificate.
- The client sends the client certificate to the server.
- The server authenticates the client certificate using root.key and proceeds with the subsequent process. Otherwise, disconnect and the process ends.
- The client randomly generates a session key, encrypts the session key using the server certificate, and sends the session key to the server.
- The server decrypts the encrypted session key using server.key to obtain the original session key.
- The client encrypts HTTP packets using the session key and sends them to the server.
- The server decrypts HTTP encrypted packets using the session key to obtain the original HTTP packets.
- The server encrypts HTTP response packets using the session key and returns them to the client.
- The client decrypts the HTTP response packet using the session key and obtains the original HTTP response packet.
After the client authenticates the server certificate and before sending the encrypted session key to the server, the client sends the client certificate client. CRT to the server and the server authenticates the certificate.
(Figure 2. HTTPS bidirectional authentication)
5.3 MySQL Enable SSL
The principle of SSL provided by MySQL is similar to THAT provided by HTTPS. The difference is that the service provided by MySQL does not target tens of thousands of ordinary users, so CA is not in high demand.
Therefore, the actual CA certificate is usually generated by the server itself.
Similar to HTTPS, MySQL provides two types of SSL authentication mechanisms: one-way authentication and two-way authentication.
5.3.1 ONE-WAY SSL Authentication for MySQL
(1) Server configuration files: ca. CRT, server. CRT, and server.key. Server. CRT is generated by ca. CRT signature.
(2) The client configuration file is ca. CRT. Ca. CRT is the same as that on the server.
(3) The client generates JKS files
keytool -importcert -alias Cacert -file ca.crt -keystore truststoremysql.jks -storepass password123
Copy the code
verifyServerCertificate=true&useSSL=true&requireSSL=true&trustCertificateKeyStoreUrl=file:./truststoremysql.jks&trustCer tificateKeyStorePassword=password123Copy the code5.3.2 SSL Bidirectional Authentication for MySQL
(1) Server configuration files: ca. CRT, server. CRT, and server.key. Server. CRT is generated by ca. CRT signature.
(2) Client configuration files: ca. CRT, client. CRT, and client.key. Ca. CRT is the same as ca. CRT on the server.
(3) The client generates the trustKeyStore file
keytool -importcert -alias Cacert -file ca.crt -keystore truststore.jks -storepass password123
Copy the code
keytool -importcert -alias Cacert -file ca.crt -keystore clientstore.jks -storepass password456
Copy the code
verifyServerCertificate=true&useSSL=true&requireSSL=true&trustCertificateKeyStoreUrl=file:./truststore.jks&trustCertific ateKeyStorePassword=password123&clientCertificateKeyStoreUrl=file:./clientstore.jks&clientCertificateKeyStorePassword=pa ssword456Copy the codeFor more details about MySQL SSL authentication, see:
- www.howtoforge.com/tutorial/ho…
- www.cnblogs.com/ccgood/p/13…
Appendix A Different formats of ASN.1 encodings
A.1 pkcs#1
A. 1.1 public key
RSAPublicKey ::= SEQUENCE {
modulus INTEGER , -- n
publicExponent INTEGER -- e
}
Copy the code
RSAPrivateKey ::= SEQUENCE {
version Version ,
modulus INTEGER , -- n
publicExponent INTEGER , -- e
privateExponent INTEGER , -- d
prime1 INTEGER , -- p
prime2 INTEGER , -- q
exponent1 INTEGER , -- d mod (p-1)
exponent2 INTEGER , -- d mod (q-1)
coefficient INTEGER , -- (inverse of q) mod p
otherPrimeInfos OtherPrimeInfos OPTIONAL
}
Copy the code
A. 2.1 PKCS # 8 public key
PublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier ,
PublicKey BIT STRING
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER ,
parameters ANY DEFINED BY algorithm OPTIONAL
}
Copy the code
OneAsymmetricKey ::= SEQUENCE { version Version , privateKeyAlgorithm PrivateKeyAlgorithmIdentifier , privateKey PrivateKey , attributes [0] Attributes OPTIONAL , ... , [[2: publicKey [1] PublicKey OPTIONAL ]], ... } PrivateKey ::= OCTET STRING -- Content varies based on type of key. The -- algorithm identifier dictates the format of -- the key.Copy the codeA.3 X.509
A. 3.1 x. 509 certificate
Certificate ::= SEQUENCE { tbsCertificate TBSCertificate , signatureAlgorithm AlgorithmIdentifier , signatureValue BIT STRING } TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber , signature AlgorithmIdentifier , issuer Name, validity Validity , subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo , issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL , -- If present , version MUST be v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL , -- If present , version MUST be v2 or v3 extensions [3] EXPLICIT Extensions OPTIONAL -- If present , version MUST be v3 } Version ::= INTEGER { v1(0), v2(1), v3(2) } CertificateSerialNumber ::= INTEGER Validity ::= SEQUENCE { notBefore Time, notAfter Time } Time ::= CHOICE { utcTime UTCTime , generalTime GeneralizedTime } UniqueIdentifier ::= BIT STRING SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier , subjectPublicKey BIT STRING } Extensions ::= SEQUENCE SIZE (1.. MAX) OF Extension Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER , critical BOOLEAN DEFAULT FALSE , extnValue OCTET STRING -- contains the DER encoding of an ASN.1 value -- corresponding to the extension type identified -- by extnID }Copy the codeAuthor: Zhu Ran, From Vivo Internet Technology team