Client self-identification national secret authentication method

Abstract

The invention discloses a client self-recognition national secret authentication method, and belongs to the technical field of computer communication. By adding support to a national secret algorithm SM2 / SM3 / SM4 in a TLS protocol, a client can support a national secret system and an international certificate system at the same time; comprising the following steps: automatic identification of national secret websites, TLS authentication and certificate verification. According to the method, the browser can automatically select the cryptographic algorithm used by the current server, and a user can realize a communication mode based on two cryptographic algorithms of national cryptographic algorithm and TLS encryption by one universal packet; on the premise that the user does not perceive, the communication mode is automatically switched to the national secret mode, and the safety of information communication is effectively guaranteed.

Description

Technical Field

[0001] The present invention relates to the field of computer communication technology, and in particular to a client self-identification national encryption authentication method. Background Art

[0002] The business system of B / S architecture covers most of the business operations, including various classified documents, 6+1 system and production scheduling information, etc. According to statistics, in recent years, attacks on terminal chips, operating system vulnerabilities and browsers accounted for more than 86%. Fixing vulnerabilities is an important part of the network security defense war, but the technologies based on chips, operating systems and browsers are all from foreign countries, and the prevention and control technology is subject to foreign forces, and the information security protection work is very passive. At present, the development of the national secret industry has been continuously advancing, and the support for national secrets still needs to be further improved. Summary of the invention

[0003] The purpose of the present invention is to provide a browser communication method that is adaptive and supports national encryption, and to propose a client self-identification national encryption authentication method.

[0004] In order to achieve the above object, the present invention adopts the following technical solutions:

[0005] A client self-identification national encryption authentication method, by adding support for the national encryption algorithm SM2 / SM3 / SM4 in the TLS protocol, enables the client to support both the national encryption and international certificate systems; comprising the following steps:

[0006] The client automatically identifies the national secret website;

[0007] The client performs TLS authentication;

[0008] The server performs certificate verification.

[0009] Furthermore, the client automatically identifies national secret websites, including:

[0010] A1. The client sends Client HelloA and Client HelloB in parallel. Both Client HelloA and Client HelloB are data packets, and Client HelloA comes with a cipher suite that supports national encryption, while Client HelloB does not have a cipher suite that supports national encryption.

[0011] A2. The server returns Server HelloA and Server HelloB accordingly. If the server supports national encryption, select the national encryption algorithm suite in Server HelloA; select the TLS encryption algorithm in Server HelloB.

[0012] Furthermore, the TLS protocol is divided into two layers: the record layer and the handshake layer. The handshake layer contains four sub-protocols: the handshake protocol, the encryption specification change protocol, the application data protocol, and the warning protocol. The record protocol of the record layer is responsible for recording all underlying messages exchanged on the transport connection, and encryption can be optionally configured. Each TLS record starts with a short header.

[0013] HTTPS only needs to configure browser and server related settings to enable TLS, which can achieve high decoupling of HTTPS and TLS, and cooperate with and be independent of the upper-level application layer protocols.

[0014] Furthermore, the client performs TLS authentication, which specifically includes the following process:

[0015] The TLS connection starts with a handshake. If the client has not established a session with the server before, a complete handshake process is performed to negotiate the TLS session.

[0016] During the handshake process, the client and server perform the following four steps:

[0017] S1. Exchange the functions they support and reach agreement on the required connection parameters;

[0018] S2. Verify the presented certificate or use other means to authenticate identity;

[0019] S3. Agree on a shared master key that will be used to protect the session.

[0020] S4. Verify that the handshake message has not been modified by a third party;

[0021] Among them, on the basis of TLS, the encryption algorithm negotiated in the handshake process and the encryption algorithm used for communication after the handshake are replaced with the national encryption SM2 / SM3 / SM4 algorithm respectively.

[0022] Furthermore, identity authentication in S2 includes: one-way authentication and two-way authentication;

[0023] One-way authentication is used in scenarios where one-to-many services are provided;

[0024] Two-way authentication requires that both the server and the client have certificates, and the communication content between the two parties is encrypted data.

[0025] Furthermore, one-way authentication includes the following steps:

[0026] X1. The client sends ClientHello to the server.

[0027] X2, the server sends ServerHello, certificate authentication Certificate, key exchange ServerKeyExchange, and authentication ends ServerHelloDone;

[0028] X3, client verification certificate;

[0029] X4. After the client passes the verification, the client exchanges the key ClientKeyExchange, changes the cipher specification ChangeCipherSpec, and the handshake is completed Finished;

[0030] X5. The server calculates the secret key, verifies, changes the cipher specification ChangeCipherSpec, and the handshake is completed Finished;

[0031] X6, handshake ends;

[0032] X7. Encrypted communication.

[0033] Furthermore, in step X1:

[0034] ClientHello contains the following fields:

[0035] Version: protocol version indicates the protocol version supported by the client;

[0036] Random: A 32-byte data; 28 bytes are randomly generated; the remaining 4 bytes contain additional information related to the client clock;

[0037] During the handshake, both the client and the server provide a random number, which the client provides as random_C.

[0038] Session ID: During the first connection, the Session ID field is empty, indicating that the client does not wish to resume an existing session.

[0039] Cipher Suites: Cipher Suite is a list of all cipher suites supported by the client, arranged in order of priority;

[0040] Compression: The client can submit one or more methods that support compression; the default compression method is null, which means no compression;

[0041] Extensions: consists of any number of extensions;

[0042] Further, in step X2:

[0043] The server transmits the selected connection parameters back to the client via ServerHello;

[0044] The structure of ServerHello is similar to that of ClientHello, except that each field contains only one option. It contains the random_S parameter of the server. During the handshake, both the client and the server provide a random number, which is temporarily recorded as random_S on the server side. Clipper Suite is the encryption suite to be used for subsequent key negotiation and identity authentication.

[0045] In step X2:

[0046] Certificate is used to carry the server X.509 certificate chain;

[0047] Among them, the server must ensure that the certificate sent is consistent with the selected algorithm suite;

[0048] ServerKeyExchange carries additional data required for key exchange;

[0049] ServerHelloDone indicates that the server has sent all expected handshake messages; after this, the server will wait for the client to send messages.

[0050] Furthermore, two-way authentication includes the following steps:

[0051] Y1. The client sends ClientHello.

[0052] Y2. The server sends a CertificateRequest message to request authentication of the client.

[0053] Y3. The client sends its own Certificate_C message and attaches the certificate; then, it sends a CertificateVerify message to prove that it owns the corresponding private key;

[0054] In step Y2:

[0055] The server sends a CertificateRequest message to request the client to authenticate its identity while sending ServerHello, Certificate_S, and ServerKeyExchange. The message contains the public key and signature algorithm of the certificate it accepts.

[0056] In step Y3:

[0057] Sent during the ClientKeyExchange process, proving that the private key it possesses matches the public key in the client certificate sent previously; the message contains a signature of all handshake messages up to this step.

[0058] Compared with the prior art, the present invention provides a client self-identification national secret authentication method, which has the following beneficial effects.

[0059] 1. The present invention can enable the browser to automatically select the cryptographic algorithm used by the current server, so that users can use a universal package to solve the communication methods based on both national encryption and TLS encryption algorithms; it can flexibly determine whether the current server supports national encryption or TLS encryption algorithms.

[0060] 2. Based on TLS, the present invention replaces the encryption algorithm negotiated in the handshake phase and the encryption algorithm used in communication after the handshake is completed with the national encryption SM2 / SM3 / SM4 algorithm respectively, thereby realizing support for the national encryption.

[0061] 3. The present invention automatically detects whether the target website supports national encryption, and automatically switches the communication mode to national encryption without the user's perception, effectively ensuring the security of information communication.

[0062] Other advantages, objectives and features of the present invention will be described in part in the following description; and in part, will be apparent to those skilled in the art based on an examination of the following; or, may be taught from the practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] Figure 1 For TLS model;

[0064] Figure 2 This is a schematic diagram of HTTPS;

[0065] Figure 3 Flow chart for single certification;

[0066] Figure 4 A flowchart for dual certification;

[0067] Figure 5 Flowchart for verifying a certificate. DETAILED DESCRIPTION

[0068] The technical solutions in the embodiments of the present invention will be described clearly and completely below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments.

[0069] A client self-identification national encryption authentication method, by adding support for national encryption algorithms SM2 / SM3 / SM4 in the TLS protocol, enables the client to support both the national encryption and international certificate systems; the method includes the following steps: automatic identification of national encryption websites, TLS authentication, and certificate verification.

[0070] like Figure 1 As shown in the figure, the TLS protocol is divided into two layers: the record layer and the handshake layer. The handshake layer contains four sub-protocols: the handshake protocol, the encryption specification change protocol, the application data protocol, and the warning protocol. The record protocol of the record layer is responsible for recording all underlying messages exchanged on the transport connection, and encryption can be optionally configured. Each TLS record starts with a short header, such as Figure 1 shown.

[0071] like Figure 2 As shown in the figure, HTTPS (HTTP over TLS) only needs to configure the browser and server related settings to enable TLS, so that HTTPS and TLS can be highly decoupled, and can cooperate with and be independent of the upper-level application layer protocols.

[0072] The automatic identification of the national secret website allows the browser to automatically select the cryptographic algorithm used by the current server, so that the user can solve the communication mode based on the national secret and TLS encryption cryptographic algorithms with a common package; it includes the following steps:

[0073] A1. The client sends Client HelloA and Client HelloB in parallel. Among them, Client HelloA comes with a cipher suite that supports national encryption.

[0074] A2. The server responds with Server HelloA and Server HelloB.

[0075] A3. If the server supports national encryption, select the national encryption algorithm suite in Server HelloA;

[0076] Among them, if the national encryption is supported and has a high priority, the connection that supports the national encryption cipher suite will be used first, and the other TCP connection will be disconnected.

[0077] Through the above solution, we can flexibly determine whether the current server supports national encryption or TLS encryption algorithm; automatically detect whether the target website supports national encryption, and switch the communication mode to national encryption without the user's awareness, effectively ensuring the security of information communication.

[0078] Preferably, after testing once, the detection results are cached by host name to improve network utilization efficiency.

[0079] The TLS process consists of the following steps:

[0080] A TLS connection begins with a handshake; if the client has not previously established a session with the server, a full handshake process is performed to negotiate a TLS session.

[0081] During the handshake process, the client and server will go through the following four steps:

[0082] 1. Exchange the functions they support and reach agreement on the required connection parameters;

[0083] 2. Verify the presented certificate or use other means to authenticate identity;

[0084] 3. Agree on a shared master key that will be used to protect the session.

[0085] 4. Verify that the handshake message has not been modified by a third party.

[0086] Among them, on the basis of TLS, the encryption algorithm negotiated in the handshake process and the encryption algorithm used for communication after the handshake are replaced with the national encryption SM2 / SM3 / SM4 algorithm respectively.

[0087] The TLS authentication includes: one-way authentication and two-way authentication.

[0088] One-way authentication is used in scenarios where one-to-many services are provided to implement one-way authentication.

[0089] Two-way authentication requires that both the server and the client have certificates, and the communication between the two parties is encrypted data. If attacked, the third party will only get the encrypted data, and if they want to know the specific information, they need to decrypt it, which is a very cumbersome process. In addition, the encryption strength of two-way authentication is also higher than that of single authentication.

[0090] Currently, Web applications all use one-way authentication (because such authentication method is simple), which is suitable for a large number of users. However, HTTPS two-way authentication is more suitable for enterprise applications. When transmitting private enterprise information, using two-way authentication can ensure that the data is more secure and not easily intercepted or tampered by a third party, thus avoiding serious losses caused by data leakage.

[0091] The single authentication does not require verification of the client identity, but requires a handshake to verify the server identity;

[0092] Single certification includes the following steps (please refer to Figure 3 ):

[0093] X1. The client sends ClientHello to the server.

[0094] X2. The server sends ServerHello, Certificate, ServerKeyExchange, and ServerHelloDone.

[0095] X3, client verification certificate (Verify Certificate);

[0096] X4. After the client passes the verification, the client exchanges keys (ClientKeyExchange), changes the cipher specification (ChangeCipherSpec), and completes the handshake (Finished(Encrypted Handshake Message)).

[0097] X5. The server calculates the secret key, verifies, changes the cipher specification (ChangeCipherSpec), and the handshake is completed (Finished (Encrypted Handshake Message)).

[0098] X6, handshake ends;

[0099] X7. Encrypted communication.

[0100] Wherein, in step X1:

[0101] ClientHello contains the following fields.

[0102] Version: The protocol version indicates the protocol version supported by the client.

[0103] Random: A 32-byte data; 28 bytes are randomly generated ( Figure 3 The remaining 4 bytes contain additional information related to the client clock (e.g., Figure 3 GMT Unix Time is used in the

[0104] During the handshake, both the client and the server provide a random number, the client's temporary record is random_C (used for subsequent key generation); this randomness is unique for each handshake and plays a vital role in identity authentication.

[0105] Session ID: During the first connection, the session ID field is empty, indicating that the client does not wish to resume an existing session. A typical session ID contains 32 bytes of randomly generated data, which is usually generated by the server and returned to the client via ServerHello.

[0106] Cipher Suites: The Cipher Suite block is a list of all cipher suites supported by the client, arranged in order of priority.

[0107] Compression: The client can submit one or more methods that support compression; the default compression method is null, which means no compression.

[0108] Extensions: An Extension block consists of any number of extensions; these extensions carry additional data.

[0109] In step X2:

[0110] The server passes the selected connection parameters back to the client via ServerHello.

[0111] The structure of ServerHello is similar to that of ClientHello, except that each field contains only one option. It includes the server's random_S parameter (used for subsequent key negotiation). During the handshake, both the client and the server provide a random number, which is temporarily recorded as random_S on the server side. Clipper Suite is the encryption suite to be used for subsequent key negotiation and identity authentication.

[0112] It should be noted that the server does not need to support the best version supported by the client; if the server does not support the same version as the client, it can provide some other version in the hope that the client can accept it.

[0113] In step X2:

[0114] Certificate is used to carry the server X.509 certificate chain.

[0115] Among them, the server must ensure that the certificate sent is consistent with the selected algorithm suite. In addition, some key exchange algorithms rely on specific data embedded in the certificate and require that the certificate must be signed with an algorithm supported by the client; all of these indicate that the server needs to configure multiple certificates (each certificate may be equipped with a different certificate chain).

[0116] It is important to note that Certificate is optional because not all suites use authentication, and not all authentication methods require certificates. Furthermore, although messages use X.509 certificates by default, they can also carry other forms of tokens.

[0117] In step X2:

[0118] ServerKeyExchange carries additional data required for key exchange.

[0119] It should be noted that it is optional and the message content may differ for different negotiation algorithm suites.

[0120] In some scenarios, such as when using the RSA algorithm, the server does not need to send this message; ServerKeyExchange is sent by the server only when the server certificate message (that is, the Certificate message mentioned above) does not contain enough data to allow the client to exchange the premaster secret.

[0121] In step X2:

[0122] ServerHelloDone indicates that the server has sent all expected handshake messages; after this, the server will wait for the client to send messages.

[0123] In step X3:

[0124] The client verifies the legitimacy of the certificate. If the verification is successful, subsequent communication will be carried out. Otherwise, prompts and operations will be given according to the error situation. The legitimacy verification content includes the following:

[0125] Trusted certificate path of the certificate chain;

[0126] There are two ways to revocation a certificate: offline CRL and online OCSP. Different clients have different behaviors.

[0127] Expiry date: whether the certificate is within the valid time range;

[0128] Domain name domain, check whether the certificate domain name matches the current access domain name.

[0129] The certificate signature sent by the server is encrypted with the CA (Certificate Authority) private key; after receiving the certificate, first read the relevant plaintext information in the certificate, and use the same hash function to calculate the information summary; then, use the corresponding CA public key to decrypt the signature data and compare the certificate information summary; if they are consistent, the legitimacy of the certificate can be confirmed; then, check the revocation status of the certificate, etc.

[0130] In step X4:

[0131] After the legitimacy verification is passed, the client calculates a random digital pre-master key (Pre-master), encrypts it with the certificate public key, and sends it to the server, carrying all the information provided by the client for key exchange.

[0132] This message is affected by the negotiated cipher suite, and the content varies with different negotiated cipher suites.

[0133] At this point, the client has obtained all the information needed to calculate the negotiation key: two plaintext random numbers random_C and random_S and the Pre-master calculated by itself, and then obtained the negotiation key (for subsequent message encryption).

[0134] In step X4:

[0135] ChangeCipherSpec notifies the server that all subsequent communications will be encrypted using the negotiated communication key and encryption algorithm.

[0136] In step X4:

[0137] The Finished message means that the handshake has been completed; the message contents are encrypted so that both parties can securely exchange the data needed to verify the integrity of the entire handshake.

[0138] This message contains a verify_data field, which is a hash of all the messages sent during the handshake. These messages are arranged in the order they were seen by both ends of the connection and hashed using the negotiated master key (enc_key). This is done using a pseudorandom function (PRF) that can generate any amount of pseudorandom data. The calculations are the same on both ends, but they use different labels (finished_label): the client uses clientfinished, and the server uses server finished.

[0139] Because Finished messages are encrypted and their integrity is guaranteed by the negotiated MAC algorithm, an active network attacker cannot alter the handshake messages and spoof the value of verify_data.

[0140] In step X5:

[0141] The server uses the private key to decrypt the encrypted Pre-master data. Based on the two plaintext random numbers random_C and random_S exchanged previously, the server also calculates the negotiated key: enc_key. It also calculates the hash value of all previously sent and received information, and then uses the negotiated key to decrypt verify_data_C sent by the client to verify the correctness of the message.

[0142] In step X5:

[0143] After the server passes the authentication, the server also sends ChangeCipherSpec to inform the client that subsequent communications will use the negotiated key and algorithm for encrypted communications.

[0144] In step X5:

[0145] The server also generates a piece of data (verify_data_S) based on all current communication parameter information and encrypts it using the negotiated key session secret (enc_key) and algorithm and sends it to the client.

[0146] In step X6:

[0147] The client calculates the hash value of all received information and uses the negotiated key to decrypt verify_data_S to verify the data and key sent by the server. If the verification is successful, the handshake is completed.

[0148] In step X7:

[0149] Start encrypted communication using the negotiated key and algorithm.

[0150] In addition to the client needing to authenticate the server, the two-way authentication also adds the server's authentication of the client (see Figure 4 ); in contrast, the server requests authentication of the client by sending a CertificateRequest message; the message lists all acceptable client certificates; in response, the client sends its own Certificate message (using the same format as the server sent the certificate) and attaches its certificate; thereafter, the client sends a CertificateVerify message to prove that it owns the corresponding private key.

[0151] The following steps are involved:

[0152] Y1. The client sends ClientHello.

[0153] Y2. The server sends a CertificateRequest message to request authentication of the client;

[0154] Y3. The client sends its own Certificate_C message (using the same format as the certificate sent by the server) and attaches the certificate; then, it sends a CertificateVerify message to prove that it owns the corresponding private key.

[0155] In step Y2:

[0156] The server sends a CertificateRequest message to request the client to authenticate its identity while sending ServerHello, Certificate_S, and ServerKeyExchange. The message contains the public key and signature algorithm of the certificate it accepts.

[0157] In step Y3:

[0158] Sent during the ClientKeyExchange process, proving that the private key it possesses matches the public key in the client certificate sent previously; the message contains a signature of all handshake messages up to this step.

[0159] The certificate exists in the form of a certificate chain:

[0160] 1) The top layer is root, commonly known as CA, which is used to issue certificates;

[0161] 2) The bottom layer is end-user, which corresponds to the certificates purchased and used by each website;

[0162] 3) The middle layer is intermediates, which is the secondary CA. This layer can be further divided into multiple layers to help the root issue certificates to the end-user, so that the root only needs to issue certificates to the intermediates.

[0163] The current certificate is considered legitimate only when all certificates in the entire certificate chain are valid.

[0164] For each certificate, there is a pair of public and private keys; the private key is kept confidential by the certificate owner, and the public key is publicly available. In addition, each certificate also contains a lot of information, such as the issuing authority, validity period, etc. The most important one is the signature. Signature means using the private key of the upper-level certificate to encrypt some meta information, including basic information, public key, domain name for which the certificate is valid, etc.

[0165] The certificate verification includes:

[0166] After receiving the signed certificate, decompress it to obtain the "metadata" and "signature ciphertext" respectively; then, apply the hash algorithm specified by the CA to the "metadata" to obtain summary A, decrypt the "signature ciphertext" using the CA's public key to obtain summary B, and compare summary A and summary B; if they match, it means that this certificate is a legitimate certificate verified by the CA (please refer to Figure 5 ).

[0167] Each certificate guarantees the legitimacy of the certificate at the next level. The root certificate is a self-signed certificate. Some certificates are pre-installed in the browser or operating system. These certificates are the root certificates. For these certificates, they are directly trusted during the certificate verification process.

[0168] In the present invention, on the basis of TLS, the encryption algorithm negotiated in the handshake phase and the encryption algorithm used in the communication after the handshake are replaced with the national encryption SM2 / SM3 / SM4 algorithm respectively, so as to realize the support for the national encryption; the browser can automatically select the encryption algorithm used by the current server, so that the user can solve the communication mode based on the two encryption algorithms of the national encryption and TLS encryption with a universal package; it can flexibly obtain whether the current server supports the national encryption or the TLS encryption algorithm; realize automatic detection of whether the target website supports the national encryption, and automatically switch the communication mode to the national encryption without the user's perception, so as to effectively ensure the security of information communication.

Claims

1. A client self-identification national secret authentication method, characterized in that: By adding support for the national encryption algorithm SM2 / SM3 / SM4 in the TLS protocol, the client can support both the national encryption and international certificate systems; the following steps are included: The client automatically identifies the national secret website; The client performs TLS authentication; The server performs certificate verification.

2. According to claim 1, a client self-identification national secret authentication method is characterized in that: The client automatically identifies national secret websites, including: A1. The client sends Client HelloA and Client HelloB in parallel. Both Client HelloA and Client HelloB are data packets, and Client HelloA comes with a cipher suite that supports national encryption, while Client HelloB does not have a cipher suite that supports national encryption. A2. The server returns Server HelloA and Server HelloB accordingly. If the server supports national encryption, select the national encryption algorithm suite in Server HelloA; select the TLS encryption algorithm in Server HelloB.

3. According to claim 1, a client self-identification national secret authentication method is characterized in that: The TLS protocol is divided into two layers: the record layer and the handshake layer. The handshake layer contains four sub-protocols: the handshake protocol, the encryption specification change protocol, the application data protocol, and the warning protocol. The record protocol of the record layer is responsible for recording all underlying messages exchanged on the transport connection, and encryption can be optionally configured. Each TLS record starts with a short header. HTTPS only needs to configure browser and server related settings to enable TLS, which can achieve high decoupling of HTTPS and TLS, and cooperate with and be independent of the upper-level application layer protocols.

4. According to claim 1, a client self-identification national secret authentication method is characterized in that: The client performs TLS authentication, which includes the following process: The TLS connection starts with a handshake. If the client has not established a session with the server before, a complete handshake process is performed to negotiate the TLS session. During the handshake process, the client and server perform the following four steps: S1. Exchange the functions they support and reach agreement on the required connection parameters; S2. Verify the presented certificate or use other means to authenticate identity; S3. Agree on a shared master key that will be used to protect the session. S4. Verify that the handshake message has not been modified by a third party; Among them, on the basis of TLS, the encryption algorithm negotiated in the handshake process and the encryption algorithm used for communication after the handshake are replaced with the national encryption SM2 / SM3 / SM4 algorithm respectively.

5. A client self-identification national secret authentication method according to claim 4, characterized in that: Authentication in S2 includes: one-way authentication and two-way authentication; One-way authentication is used in scenarios where one-to-many services are provided; Two-way authentication requires that both the server and the client have certificates, and the communication content between the two parties is encrypted data.

6. A client self-identification national secret authentication method according to claim 5, characterized in that: One-way authentication includes the following steps: X1. The client sends ClientHello to the server. X2, the server sends ServerHello, certificate authentication Certificate, key exchange ServerKeyExchange, and authentication ends ServerHelloDone; X3, client verification certificate; X4. After the client passes the verification, the client exchanges the key ClientKeyExchange, changes the cipher specification ChangeCipherSpec, and the handshake is completed Finished; X5. The server calculates the secret key, verifies, changes the cipher specification ChangeCipherSpec, and the handshake is completed Finished; X6, handshake ends; X7. Encrypted communication.

7. A client self-identification national secret authentication method according to claim 6, characterized in that: In step X1: ClientHello contains the following fields: Version: protocol version, indicating the protocol version supported by the client; Random: A 32-byte data; 28 bytes are randomly generated; the remaining 4 bytes contain additional information related to the client clock; During the handshake, both the client and the server provide a random number, which the client provides as random_C. Session ID: During the first connection, the Session ID field is empty, indicating that the client does not wish to resume an existing session. Cipher Suites: Cipher Suite is a list of all cipher suites supported by the client, arranged in order of priority; Compression: The client can submit one or more methods that support compression; the default compression method is null, which means no compression; Extensions: Consists of any number of extensions.

8. A client self-identification national secret authentication method according to claim 6, characterized in that: In step X2: The server transmits the selected connection parameters back to the client via ServerHello; The structure of ServerHello is similar to that of ClientHello, except that each field contains only one option. It contains the random_S parameter of the server. During the handshake, both the client and the server provide a random number, which is temporarily recorded as random_S on the server side. Clipper Suite is the encryption suite to be used for subsequent key negotiation and identity authentication. In step X2: Certificate is used to carry the server X.509 certificate chain; Among them, the server must ensure that the certificate sent is consistent with the selected algorithm suite; ServerKeyExchange carries additional data required for key exchange; ServerHelloDone indicates that the server has sent all expected handshake messages; after this, the server will wait for the client to send messages.

9. A client self-identification national secret authentication method according to claim 8, characterized in that: Two-way authentication includes the following steps: Y1. The client sends ClientHello. Y2. The server sends a CertificateRequest message to request authentication of the client. Y3. The client sends its own Certificate_C message and attaches the certificate; then, it sends a CertificateVerify message to prove that it owns the corresponding private key; In step Y2: The server sends a CertificateRequest message to request the client to authenticate its identity while sending ServerHello, Certificate_S, and ServerKeyExchange. The message contains the public key and signature algorithm of the certificate it accepts. In step Y3: Sent during the ClientKeyExchange process, proving that the private key it possesses matches the public key in the client certificate sent previously; the message contains a signature of all handshake messages up to this step.

Images