Deeply analyze the principle and practice of RSA key

Time:2021-5-13

1、 Preface

After experiencing many dark moments in life, when you read this article, you will regret and even be angry: why didn’t you write this article earlier?!

Your darkest moments include:

1. Your project needs to be connected with the bank, and the other party needs you to provide an encryption certificate. You have only one CET-6 certificate in hand, and you are not sure whether it meets the needs of the other party. Due to your delay in providing the correct certificate, the project is postponed, the salary increase plan fails, the monthly payment is broken, your girlfriend breaks up, and you feel that your life is over.

2. You have been working hard for two months and finally understand the. CRT format certificate. To join the new project, the project is in the process of certificate escrow transformation. Ha ha, I will upload the certificate file to the hosting system. You yell at the members of the project team, let go of those certificates and let me do it! Squeeze in and have a look. It’s an old project. There is no certificate at all. At that time, the public key and the private key were used. How can the public key and the private key be turned into a certificate? Because you can’t provide the correct certificate for a long time, the project is postponed, the salary increase plan fails, the monthly payment is cut off, and your girlfriend breaks up. You feel that your life is over.

3. After three months’ hard work, you have found out the origin and development of SSL certificate. When you want to join a new project, you tell the project manager about the history of blood and tears. After this battle, you have grown into an expert in safety certificate. The project manager was overjoyed. It happened that the project was carrying out data security transformation, and the database needed to enable SSL. It’s just the right time. Don’t worry. Just provide a few key files before work tomorrow. The more tomorrow, half an hour before work, you slowly walk to the project manager, “the goods you want have arrived”, and then three certificates will be issued. This is the key file, this is the public key file, and this is the certificate file. The project manager nodded and shook his head. What I want is JKS file. You say, tomorrow. Tomorrow, half an hour before work, you give the JKS format file to the project manager. The project manager nods and shakes his head. What’s the password? How can I do without a password? Due to your delay in providing the correct certificate, the project is postponed, the salary increase plan fails, the monthly payment is broken, your girlfriend breaks up, and you feel that your life is over.

This paper will reveal the little-known secret of RSA key file from the following parts:

  • Mathematical basis of RSA algorithm
  • Six layer model of RSA secret key system
  • RSA tools use
  • RSA key usage scenarios

Note: Although the key and certificate are not exactly the same in the strict sense, for the convenience of expression, the term “key” in this paper covers the concepts of public key, private key, certificate and so on.

2、 Mathematical basis of RSA algorithm

RSA algorithm is based on number theory. The complexity of RSA algorithm is based on the fact that the prime decomposition of a large number is a NP hard problem. Mathematical concepts related to RSA algorithm:

Deeply analyze the principle and practice of RSA key

For any number x, we can calculate Y:

Deeply analyze the principle and practice of RSA key

By Y, we can calculate X:

Deeply analyze the principle and practice of RSA key

That is to say, after X generates y by number pair (m, e), y can be reduced to X by number pair (m, d).

Here, we actually demonstrate the mathematical process of RSA encryption and decryption. Through formula (1), the process of calculating Y according to X is encryption, and through formula (2), the process of calculating x according to y is decryption.

In practical application, RSA algorithm encrypts by public key and decrypts by private key, so number pair (m, e) is public key and (m, d) is private key.

In fact, in order to improve the speed of private key decryption, the private key will save some intermediate results, such as P, Q, e, and so on.

So in practical application, public key can be derived from private key.

3   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 level defines its own responsibilities and boundaries. The lower the level, the more abstract and theoretical the content is; The higher the level is, the more practical the content is.

Deeply analyze the principle and practice of RSA key

  • Data:The data layer defines the mathematical concepts of RSA key (m, e, P, Q, etc.) or participating entities (subject, issuer, etc.).
  • Serialization:The serialization layer defines the method of serializing complex data structure.
  • Structure:The structure layer defines the data organization forms of RSA keys with different formats.
  • Text:The text layer defines the method of converting the binary key into text.
  • Presentation:The presentation layer defines the presentation of the text format key.
  • Application:In the application layer, various scenarios of RSA key usage are defined.

Each layer is described in detail below.

3.2 data layer

As can be seen from the above, the secret key is a data structure, each structure contains two or more members (the public key contains M and E, the private key contains M, D, e and some other intermediate results). In order to save these data structures in a file, we need to define a format to serialize the secret key.

3.3 serialization layer

At present, the common formats of defining data structure include JSON, XML and other text formats.

For example, in theory, we can define a public key as a JSON:

JSON format key

{
    "m":"15",
    "e":"3"
}

Alternatively, you can define the private key as an XML:

<?xml>
<key>
    <module>15</module>
    <e>3</e>
    <d>3</d>
    <p>3</p>
    <q>5</q>
<key>

But when RSA was invented, neither format existed. So scientists chose ASN. 1, the popular grammar format at that time.

3.3.1 ASN.1

The full name of ASN. 1 is abstract syntax notation dot one. The number 1 is added after ASN by ISO in order to keep the openness of ASN, which can make the more powerful ASN named ASN. 2, but it has not appeared so far.

ASN. 1 describes a data format that represents, encodes, transmits, and decodes data. It provides a set of formal formats for describing the structure of objects, regardless of how the language is executed and the specific reference of these data, and regardless of what kind of application it is.

3.3.2 ASN. 1 coding rules

The specific syntax of ASN. 1 can be found in Wikipedia(https://zh.wikipedia.org/wiki/ASN.1)For brief explanation only.

In ASN. 1, the data type representation is in the form of t-l-v: the first two bytes represent the data type, the next two bytes represent the byte length, and V represents the specific value. Common values of basic types include integer, utf8string, and composite structures include sequence, set. Both secret key and certificate are of sequence type, while the type of sequence is 0x30, and the length is greater than 127, so the second byte is 0x82. The data encoded by ASN. 1 is binary data, which is usually converted into string and stored in PEM file through Base64, After Base64 encoding, 0x3082 is the string MI, so the first two characters of the secret key stored in all PEM files are mi.

BER, CER and Der are ASN. 1 coding rules. Der (distinct encode rules) is an unambiguous encoding rule, which ensures that the same data structure produces the same serialization result.

ASN. 1 only defines the serialization method of abstract data, but the specific coding needs to be further defined.

Strictly speaking, ASN. 1 is not a format for defining data, but a syntax standard, according to which various formats can be formulated.

3.4 structural layer

According to the different uses of secret key files, the following standards define different structures for ASN. 1 encoding of secret key data. Generally speaking, different formats of secret keys imply different structures.

  • pkcs#1 Used to define RSA public key and private key structure
  • pkcs#7  Used to define the certificate chain
  • pkcs#8 Used to define public and private keys for any algorithm
  • pkcs#12 Used to define the private key certificate
  • X.509  Define public key certificate

See 3.5.2 below for the specific differences between these formats

3.5 performance layer

As you can see, ASN. 1 and its coding rules (BER, CER, DER) define binary rules, which are stored in a file in binary format. Because the e-mail standard at that time did not support the transmission of binary content, if the secret key file was transmitted by e-mail, it was necessary to convert the binary file into a text file. This is the origin of PEM (Privacy enhanced mail). Therefore, the content of the secret key stored in the PEM file is the binary content generated by ASN. 1 encoding, and then the text encoded by Base64.

In addition, in order to facilitate the user to identify what format, a line of identity text is added at the beginning and end of the file. PEM file generally consists of three parts: first line label, Base64 encoded text data and last line label.

-----BEGIN <label>-----
<BASE64 ENCODED DATA>
-----END <label>-----

For different formats, < label > values are different.

3.5.2 summary of PEM file format

Deeply analyze the principle and practice of RSA key

3.6 application layer

In practical use, not only need to use public and private keys to encrypt and decrypt data, but also need to solve the key distribution and verification according to different use scenarios. Section 5 lists some common use scenarios of RSA keys.

4、 Tools

4.1 openssl

Note: in the following command – rsapublickey\_ in, -RSAPublicKey\_ The out option needs to be supported by OpenSSL version 1.0 or above. If an error is reported, please check the OpenSSL version.

4.1.1 create secret key file

#Generating 2048 bit private key in pkcs#1 format
openssl genrsa -out private.pem 2048
 
#Extracting pkcs#8 format public key from private key
openssl rsa -in private.pem -out public.pem -pubout
 
#Extracting pkcs#1 format public key from private key
openssl rsa -in private.pem -out public.pem -RSAPublicKey_out

4.1.2 format conversion of secret key file

#Pkcs#1 public key converted to pkcs#8 public key
openssl rsa -in public.pem -out public-pkcs8.pem -RSAPublicKey_in
 
#PKCs × 8 public key converted to PKCs × 1 public key
openssl rsa -in public-pkcs8.pem -out public-pkcs1.pem -pubin -RSAPublicKey_out
 
#PKCs ා 1 private key converted to PKCs ා 8 private key
openssl pkcs8 -in private.pem -out private-pkcs8.pem -topk8
 
#PKCs × 8 private key is converted to PKCs × 1 private key
openssl rsa -in private-pkcs8.pem -out private-pkcs1.pem

4.1.3 view secret key file information

#View public key information
openssl rsa -in public.pem -pubin -text -noout
 
#View private key information
openssl rsa -in private.pem -text -noout

4.1.4 certificate

RSA certificate

#Create CSR file from existing private key
openssl req -key private.pem -out request.csr -new
 
#Create a certificate from an 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 new certificate and private key
openssl req -nodes -newkey rsa:2048 -keyout root.key -out root.crt -x509 -days 365
 
#Sign other CSR files with existing certificate and private key (as CA)
openssl x509 -req -in child.csr -days 365 -CA root.crt -CAkey root.key -set_serial 01 -out child.crt
 
#View certificate information
openssl x509 -in child.crt -text -noout
 
 
#Extract public key from certificate
openssl x509 -pubkey -noout -in child.crt  > public.pem

4.1.5 JKS

#Convert CA certificate to JKS format
keytool -importcert -alias Cacert -file ca.crt  -keystore truststoremysql.jks -storepass password123
 
#Convert client.crt and client.key to PKCs ා 12 format
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 password456

5、 RSA key usage scenarios

5.1 one way authentication of HTTPS

Because the HTTP protocol is plaintext transmission, in order to ensure that the HTTP message is not leaked and tampered with, HTTPS encrypts and decrypts the HTTP message through SSL / TLS protocol.

In short, in the process of establishing a connection between the client and the server, the HTTPS protocol requires the exchange of session key first, and then uses the session key to encrypt and decrypt the communication message. The whole communication process is as follows:

  1. The server creates RSA certificate server.crt and private key server.key through the method shown in 4.1.4, and configures them in the web server.
  2. The client establishes a connection with the server, and the server sends the certificate server.crt to the client.
  3. The client checks the server certificate, generates the session key randomly, encrypts the session key through the server certificate, and transmits it to the server.
  4. The server decrypts the encrypted session key through server.key to obtain the original session key.
  5. The client encrypts the HTTP message through the session key and transmits it to the server.
  6. The server decrypts the HTTP encrypted message through the session key to obtain the original HTTP message.
  7. The server encrypts the HTTP response message with the session key and returns it to the client.
  8. The client decrypts the HTTP response message through the session key to obtain the original HTTP response message.

Deeply analyze the principle and practice of RSA key

(Figure 1. One way authentication of HTTPS)

5.2 two way authentication of HTTPS

The HTTPS scenario described in Section 5.1 is a general scenario. In the whole process, only the client verifies the server, that is, after the client gets the certificate of the server, it will verify the validity of the certificate, such as whether it is signed by Ca, whether it is still in the valid period, etc. This one-way verification has no problem in browser access scenarios, because this service is designed to provide services to tens of thousands of users. However, in some scenarios, such as only providing services to specific enterprises and merchants, the server needs to verify the client, and the trusted client that passes the verification can work normally.

When accessing the server, we need to use the two-way authentication of HTTPS.

The process of two-way authentication of HTTPS is to enhance the authentication of server to client on the basis of one-way authentication of HTTPS. The idea of the solution is that the client saves the client certificate client.crt, but the client certificate is not signed by the client or Ca, but signed by the root.key of the server. In the process of two-way authentication of HTTPS, the client needs to send the client certificate client.crt to the server, and the server uses root.key to verify the correctness before subsequent communication; Otherwise, the client is not a trusted client, and the server refuses to provide follow-up services.

The specific communication process is as follows:

  1. The server creates RSA certificate server.crt and private key server.key through the method shown in 4.1.4, and configures them in the web server.
  2. The client establishes a connection with the server, and the server sends the certificate server.crt to the client.
  3. The client verifies the server certificate and continues the follow-up process after passing the verification; If the verification fails, the connection is disconnected and the process ends.
  4. The server sends a message to the client and requests the client to send the client certificate.
  5. The client sends the client certificate to the server.
  6. The server verifies the client certificate through root.key, and the follow-up process is carried out; Otherwise, the connection is disconnected and the process ends.
  7. The client generates the session key randomly, encrypts the session key through the server certificate, and transmits it to the server.
  8. The server decrypts the encrypted session key through server.key to obtain the original session key.
  9. The client encrypts the HTTP message through the session key and transmits it to the server.
  10. The server decrypts the HTTP encrypted message through the session key to obtain the original HTTP message.
  11. The server encrypts the HTTP response message with the session key and returns it to the client.
  12. The client decrypts the HTTP response message through the session key to obtain the original HTTP response message.

It can be seen that compared with the one-way authentication process of HTTPS, after the client verifies the server certificate, before sending the encrypted session key to the server, the client sends the client certificate client.crt to the server, and the server verifies the certificate.

Deeply analyze the principle and practice of RSA key

(Figure 2. Two way authentication of HTTPS)

5.3 enable SSL in MySQL

The principle of SSL provided by MySQL is similar to that of HTTPS. The difference is that the service object provided by MySQL will not be thousands of ordinary users, so the demand for CA is not high.

Therefore, the actual CA certificate is usually generated by the server itself.

Similar to HTTPS, MySQL provides two forms of SSL authentication mechanism: one-way authentication and two-way authentication.

5.3.1 SSL one way authentication of MySQL

(1) Server configuration files: ca.crt, server.crt, server.key, where server.crt is generated by ca.crt signature.

(2) Client configuration file: ca.crt, ca.crt is the same as that of server.

(3) Client generates JKS file

keytool -importcert -alias Cacert -file ca.crt -keystore truststoremysql.jks -storepass password123

(4) Configure SSL option and JKS file through JDBC string

verifyServerCertificate=true&useSSL=true&requireSSL=true&trustCertificateKeyStoreUrl=file:./truststoremysql.jks&trustCertificateKeyStorePassword=password123

5.3.2 SSL mutual authentication of MySQL

(1) Server configuration files: ca.crt, server.crt, server.key, where server.crt is generated by ca.crt signature.

(2) Client configuration files: ca.crt, client.crt, client.key, where ca.crt is the same as ca.crt of server, and client.crt is generated by ca.crt signature.

(3) Client generates trustkeystore file

keytool -importcert -alias Cacert -file ca.crt -keystore truststore.jks -storepass password123

(4) Client generates clientkeystore file

keytool -importcert -alias Cacert -file ca.crt -keystore clientstore.jks -storepass password456

(5) Configure SSL option and JKS file through JDBC string

verifyServerCertificate=true&useSSL=true&requireSSL=true&trustCertificateKeyStoreUrl=file:./truststore.jks&trustCertificateKeyStorePassword=password123&clientCertificateKeyStoreUrl=file:./clientstore.jks&clientCertificateKeyStorePassword=password456

For more details about SSL authentication of MySQL, please refer to:

Appendix A   ASN. 1 coding of different formats

A.1 pkcs#1

A. 1.1 public key

RSAPublicKey ::= SEQUENCE {
    modulus INTEGER , -- n
    publicExponent INTEGER -- e
}

A. 1.2 private key

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
}

A.2 pkcs#8

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
}

A. 2.2 PKCs × 8 private key

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.

A.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
}

Author: Zhu ran, from vivo Internet technology team