SSH bidirectional authentication method, apparatus and device, and storage medium
By integrating a Trusted Cryptographic Module (TCM) into the SSH protocol, hardware-level platform integrity verification is achieved, solving the problems of low security and efficiency in traditional SSH authentication. It provides two-way trusted authentication, reduces deployment costs, and improves security and user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-30
- Publication Date
- 2026-03-10
AI Technical Summary
Traditional SSH authentication lacks hardware-level security guarantees, cannot verify the integrity of the node platform, is susceptible to man-in-the-middle attacks and malware impersonation, and is low in cost and efficiency.
The Trusted Cryptography Module (TCM) is integrated into the OpenSSH architecture to verify platform integrity information by exchanging identity credentials and session keys, thereby achieving two-way trusted authentication.
It provides hardware-level platform integrity verification, prevents tampering risks, reduces costs, improves security and efficiency, and reduces authentication delays.
Smart Images
Figure CN121644077A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of computer network security, and in particular to an SSH bidirectional authentication method, device, equipment and storage medium. BACKGROUND
[0002] SSH (Secure Shell, Secure Shell) is a common network protocol that provides secure remote login, command execution and file transfer services in an insecure network. The traditional OpenSSH implementation mainly uses password authentication or public key authentication based on the Public Key Infrastructure (PKI, Public Key Infrastructure). For SSH authentication based on PKI, the client and the server verify each other's identity by exchanging public keys. For example, OpenSSH uses RSA or ECDSA (Elliptic Curve Digital Signature Algorithm, Elliptic Curve Digital Signature Algorithm) asymmetric encryption algorithm to generate key pairs by default, and verifies the identity of the other party through the known_hosts file (used to store the public key fingerprint of the remote server) or the Certificate Authority (CA, Certificate Authority). In addition, some enhanced schemes introduce multi-factor authentication or hardware tokens, but all lack verification of the hardware-level trustworthiness of both nodes. The existing SSH authentication process only focuses on verifying the authenticity of the other party, and does not involve checking the integrity of the node platform (such as system state, hardware trustworthiness). This may lead to the fact that in the case where the node is infected with malicious software or the hardware is tampered with, the authentication process can still pass, thereby bringing security risks. The core defects are reflected in:
[0003] (1) Technical aspect: Traditional SSH authentication mainly relies on key exchange and verification at the software level, lacking hardware-level security guarantees. Nodes may be attacked by man-in-the-middle, tampered with by malicious software or rootkits, resulting in authentication key leakage or impersonation. In addition, the scheme usually only implements one-way authentication (such as server verifying client) or two-way authentication, but does not involve platform integrity verification, and cannot ensure that the node is running in a trusted state;
[0004] (2) Cost: The introduction of external hardware security modules (such as smart cards or special HSMs) will increase deployment and maintenance costs, and additional hardware devices and integration work are required. The traditional OpenSSH scheme has a lower cost, but the security level is limited and cannot meet the high security demand scenario;
[0005] (3) Efficiency: Multi-factor authentication or complex PKI systems based on software may increase authentication delay and computational overhead, affecting user experience and system performance. For example, certificate chain verification or frequent key updates can cause connection establishment time to be prolonged.
[0006] Therefore, how to provide a solution to the above-mentioned technical problems is a problem that needs to be solved by those skilled in the art. Summary of the Invention
[0007] In view of this, the purpose of this invention is to provide a method, apparatus, device, and storage medium for two-way SSH authentication, which can ensure the platform integrity of both nodes (client and server) during the SSH authentication process and prevent security risks caused by hardware or software tampering; achieve two-way trusted authentication without significantly increasing cost and complexity, thereby enhancing the overall security of the SSH protocol; optimize the authentication process, reduce additional overhead, and improve authentication efficiency and user experience. The specific solution is as follows:
[0008] Firstly, this application discloses an SSH two-way authentication method applied to an SSH client, including:
[0009] During the SSH protocol negotiation phase, the respective trusted cryptographic modules exchange identity credentials with the SSH server, and based on the identity credentials, they interact with the SSH server to negotiate a first session key and a second session key for encrypting platform integrity information.
[0010] Using the first session key, the integrity information of the client platform is encrypted to generate a first integrity evidence, which is then sent to the SSH server so that the SSH server can verify the first integrity evidence.
[0011] If the first integrity evidence is verified, the second integrity evidence, generated by encrypting with the second session key, is received from the SSH server, and the server platform integrity information contained in the second integrity evidence is verified.
[0012] Once the second integrity evidence is verified, the two-way trust verification is deemed successful.
[0013] Optionally, the exchange of identity credentials between the respective trusted cryptographic modules and the SSH server includes:
[0014] Initialize the trusted cryptography module to generate the endorsement key and identity key for the SSH client;
[0015] Obtain the endorsement key certificate issued by the certificate authority for the endorsement key, and pre-set the first trust metric benchmark value of the SSH client, the second trust metric benchmark value of the SSH server, and the certificate public key;
[0016] Send a first identity credential to the SSH server; the first identity credential includes the endorsement key certificate and identity key of the trusted cryptographic module of the SSH client;
[0017] Receive a second identity credential from the SSH server; the second identity credential includes the endorsement key certificate and identity key of the trusted cryptographic module of the SSH server.
[0018] Optionally, based on the identity credentials, interaction is performed with the SSH server to negotiate a first session key and a second session key for encrypting platform integrity information, including:
[0019] Receive first verification data from the SSH server; the first verification data is data generated by encrypting a first random number using the SSH client's endorsement key and identity key through the SSH server; the first random number is a random number generated by verifying the SSH client's endorsement key certificate in the first identity credential using a preset certificate public key through the SSH server.
[0020] The first random number obtained after decrypting the first verification data is used as the first session key;
[0021] The endorsement key certificate of the SSH server in the second identity credential is verified using the certificate public key pre-installed in the SSH client, and a second random number is generated after successful verification;
[0022] The second random number is encrypted using the endorsement key and identity key of the trusted cryptographic module of the SSH server to generate second verification data, which is then sent to the SSH server. The SSH server then uses the second random number obtained after decrypting the second verification data as the second session key.
[0023] Optionally, a first integrity evidence is generated and sent to the SSH server so that the SSH server can verify the first integrity evidence, including:
[0024] A first integrity evidence is generated and sent to the SSH server so that the SSH server can decrypt the first integrity evidence to obtain the integrity information of the target client platform, and verify the integrity information of the target client platform using the first trust metric benchmark value of the SSH client that is preset locally.
[0025] Accordingly, if the integrity information of the target client platform is determined to be accurate based on the first trust metric benchmark, then the first integrity evidence verification is deemed successful.
[0026] Optionally, receiving a second integrity certificate generated using the second session key from the SSH server, and verifying the server platform integrity information contained in the second integrity certificate, including:
[0027] Receive the second integrity evidence generated by encrypting the second session key from the SSH server, and decrypt the second integrity evidence to obtain the integrity information of the target server platform;
[0028] The integrity information of the target server platform is verified using the second trusted benchmark value of the SSH server that is pre-configured locally.
[0029] Accordingly, if the integrity information of the target server platform is determined to be accurate based on the second trust metric benchmark, then the second integrity evidence verification is deemed successful.
[0030] Optionally, before exchanging identity credentials of their respective trusted cryptographic modules with the SSH server during the SSH protocol negotiation phase, the process further includes:
[0031] When the SSH client starts, it collects system startup status data through a local trusted cryptography module to generate metric logs and hash values;
[0032] The hash value is stored in the platform configuration register of the trusted cryptographic module and used to determine the client platform integrity information with the metric log.
[0033] Secondly, this application discloses an SSH two-way authentication method, applied to an SSH server, including:
[0034] During the SSH protocol negotiation phase, the respective trusted cryptographic modules exchange identity credentials with the SSH client, and based on the identity credentials, interact with the SSH client to negotiate a first session key and a second session key for encrypting platform integrity information;
[0035] Receive the first integrity evidence sent by the SSH client, and use the first session key to decrypt and verify the client platform integrity information contained in the first integrity evidence;
[0036] If the first integrity evidence is verified, the second session key is used to encrypt the integrity information of the server platform to generate a second integrity evidence, which is then sent to the SSH client so that the SSH client can verify the second integrity evidence.
[0037] Once the second integrity evidence is verified, the two-way trust verification is deemed successful.
[0038] Thirdly, this application discloses an SSH two-way authentication device for use in SSH clients, comprising:
[0039] The identity credential exchange module is used to exchange identity credentials of their respective trusted cryptographic modules with the SSH server during the SSH protocol negotiation phase.
[0040] The session key negotiation module is used to interact with the SSH server based on the identity credentials to negotiate a first session key and a second session key for encrypting platform integrity information;
[0041] The first verification module is used to encrypt the integrity information of the client platform using the first session key to generate a first integrity evidence, and send it to the SSH server so that the SSH server can verify the first integrity evidence.
[0042] The second verification module is used to receive a second integrity certificate generated by encrypting the first integrity certificate using the second session key from the SSH server if the first integrity certificate verification is successful, and to verify the server platform integrity information contained in the second integrity certificate; when the second integrity certificate verification is successful, the two-way trusted verification is determined to be successful.
[0043] Fourthly, this application discloses an electronic device including a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the SSH two-way authentication method as described above.
[0044] Fifthly, this application discloses a computer-readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the SSH two-way authentication method as described above.
[0045] The beneficial effects of this application are as follows:
[0046] (1) Security: Traditional SSH authentication only verifies the identity of the key holder and cannot verify whether that identity is being used on an untrusted platform that has been tampered with by rootkits, Trojans, or malicious firmware. This invention relies on a trusted cryptographic module to exchange and verify platform integrity information protected or signed by the trusted cryptographic module, expanding the authentication dimension from "who you are" to "whether you are operating in a trusted environment". This makes it impossible for attackers to pass verification on compromised platforms (whose integrity information is bound to be abnormal) even if they steal legitimate keys, thereby effectively preventing man-in-the-middle attacks, hardware tampering, and malware impersonation, and providing a higher level of platform integrity assurance;
[0047] (2) Cost and practicality: Current enhancement solutions introduce dedicated hardware, which increases costs. This invention uses a widely deployed standard trusted cryptographic module, which does not require additional dedicated equipment. Moreover, the authentication process is integrated into the SSH protocol negotiation stage, which is compatible with the traditional OpenSSH architecture, reducing deployment and maintenance costs, while improving applicability and scalability.
[0048] (3) Efficiency: Complex PKI systems or multi-factor authentication will increase latency; This invention uses a lightweight process based on identity credentials, certificate verification, session key encryption, and evidence ciphertext interaction. The authentication process is optimized, the trusted cryptographic module operates efficiently, reduces redundant calculations and data transmission, and is compatible with the traditional SSH protocol. It avoids complex certificate management and reduces authentication latency and resource overhead.
[0049] In addition, the SSH two-way authentication device, equipment and storage medium provided in this application correspond to the above-mentioned SSH two-way authentication method and have the same effect. Attached Figure Description
[0050] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0051] Figure 1 This is a flowchart of an SSH two-way authentication method disclosed in this application;
[0052] Figure 2 This is a schematic diagram of one of the scheme architectures disclosed in this application;
[0053] Figure 3 This is a schematic diagram of a trusted access authentication process disclosed in this application;
[0054] Figure 4 This is a flowchart of an SSH two-way authentication method disclosed in this application;
[0055] Figure 5 This is a schematic diagram of the structure of an SSH two-way authentication device disclosed in this application;
[0056] Figure 6 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation
[0057] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0058] The SSH protocol is used for secure remote login services on insecure networks. Traditional OpenSSH relies on password or public key authentication, and enhanced solutions lack node-level hardware trust verification. Currently, only identity verification is performed, without verifying platform integrity (system status, hardware trust), posing security risks. Its disadvantages include: reliance on software keys, lack of hardware guarantees, vulnerability to attacks and tampering, and unverified platform for one-way / two-way authentication; high cost (external hardware modules); and low efficiency (multi-factor / PKI-increased latency overhead).
[0059] To address this, this application provides an SSH two-way authentication scheme, offering a hardware-level trusted verification mechanism to ensure the platform integrity of both nodes (client and server) during SSH authentication, preventing security risks caused by hardware or software tampering. It achieves two-way trusted authentication without significantly increasing cost and complexity, enhancing the overall security of the SSH protocol. Furthermore, it optimizes the authentication process, reduces additional overhead, and improves authentication efficiency and user experience.
[0060] This invention discloses an SSH two-way authentication method, see [link to relevant documentation]. Figure 1 As shown, applied to SSH clients, this method includes:
[0061] Step S11: During the SSH protocol negotiation phase, exchange identity credentials of their respective trusted cryptographic modules with the SSH server, and interact with the SSH server based on the identity credentials to negotiate a first session key and a second session key for encrypting platform integrity information.
[0062] Current SSH authentication primarily relies on software-level key exchange and verification, lacking hardware-level security guarantees. Therefore, this application provides a hardware-level trusted verification mechanism that innovatively utilizes the Trusted Cryptographic Module (TCM) chip on the computer motherboard. By integrating the TCM trusted identity authentication and integrity verification process into the OpenSSH architecture, it achieves bidirectional trusted verification between nodes. This mechanism is applicable to devices equipped with a TCM 2.0 standard trusted cryptographic module.
[0063] In this embodiment, the TCM hardware module is seamlessly integrated with the OpenSSH software layer. By modifying the SSH protocol stack, the trusted authentication process is deeply embedded and reused in the SSH protocol negotiation phase, instead of initiating separate remote attestation sessions before and after the SSH connection is established. In this way, the TCM-based remote attestation function verifies not only the other party's public key but also the integrity of the other party's platform during the SSH authentication phase. This avoids additional network round trips and connection latency, significantly enhancing security while ensuring good compatibility and efficiency.
[0064] During the SSH protocol negotiation phase, the core process is trusted access authentication, while the remaining processes follow the standard OpenSSH negotiation procedure. Trusted access authentication involves a total of four interaction requests. The first interaction involves exchanging identity credentials for each client's Trusted Cryptography Module (TCM). Specifically, the client sends its locally generated Endorsement Key Certificate (EK certificate) and Identity Key (AK) as the first identity credential to the SSH server. Correspondingly, upon receiving this credential, the SSH server replies to the client in the same manner, using its own TCM's EK certificate and Identity Key as the second identity credential. This includes the following steps:
[0065] Initialize the trusted cryptography module to generate the endorsement key and identity key for the SSH client; obtain the endorsement key certificate issued by the certificate authority for the endorsement key, and pre-set the first trusted benchmark value of the SSH client, the second trusted benchmark value of the SSH server, and the certificate public key; send the first identity credential to the SSH server, the first identity credential including the endorsement key certificate and identity key of the trusted cryptography module of the SSH client; receive the second identity credential from the SSH server, the second identity credential including the endorsement key certificate and identity key of the trusted cryptography module of the SSH server.
[0066] In this embodiment, the endorsement key certificate is a digital certificate issued by a trusted Certificate Authority (CA) for the unique endorsement key of the TCM, used to prove the legitimacy and authenticity of the TCM and its platform. The identity key is an asymmetric key pair generated internally by the TCM, specifically used for encryption and signing operations in this and subsequent trusted interactions. By exchanging these two sets of credentials, both communicating parties not only obtain each other's keys but also obtain a CA-endorsed, hardware-bound identity assertion, laying the foundation for building a bidirectional trusted chain.
[0067] It should be noted that during the initialization phase, both the client and server initialize their respective TCMs. The TCM is used to generate and store asymmetric key pairs, including the endorsement key EK and the identity key AK. An EK certificate is issued through a CA, and trust measurement benchmark values are pre-set for both the local and remote devices. The trust measurement benchmark value is integrity reference data under normal platform operation; it is benchmark data obtained by performing integrity measurements (such as calculating hash values) on entities (e.g., programs, configuration files) under trusted system conditions, and serves as a reference standard for subsequent integrity verification. As the benchmark for integrity verification, the consistency between the current measurement value and the benchmark value determines whether the entity has been tampered with.
[0068] Furthermore, after successful authentication, a second interaction is conducted: negotiating a first session key and a second session key for encrypting platform integrity information. It should be noted that platform integrity information refers to structured data characterizing the trustworthiness of the system's hardware and software operating status. In one feasible implementation, platform integrity information includes platform configuration register values measured by a local trusted cryptographic module and corresponding measurement logs. For SSH clients: when the SSH client starts, system startup status data is collected through the local trusted cryptographic module to generate measurement logs and hash values; the hash values are stored in the platform configuration registers (PCRs) of the trusted cryptographic module and used to determine the client's platform integrity information along with the measurement logs.
[0069] During the second interaction, after receiving the first identity credential sent by the client, the server uses a pre-set CA public key to verify the client's EK certificate within the first identity credential. Upon successful verification, the server creates a first random number, which becomes the first session key used by the client subsequently. After generating the first random number, the server uses the client's EK public key and AK public key to create a "server-protected credential" for this random number, obtaining the first verification data. The server then sends its own server-side EK certificate, server-side AK public key, and the first verification data to the client.
[0070] Specifically, the system receives first verification data from the SSH server; the first verification data is generated by encrypting a first random number using the SSH client's endorsement key and identity key through the SSH server; the first random number is generated by verifying the SSH client's endorsement key certificate in the first identity credential using a preset certificate public key through the SSH server; and the first random number obtained after decrypting the first verification data is used as the first session key.
[0071] Upon receiving the second identity credential and the first verification data from the SSH server, the client first verifies the server's EK certificate in the second identity credential using its locally pre-configured CA public key. After successful verification, the client creates a second random number, which becomes the second session key used by the server subsequently. After generating the second random number, the client uses the server's EK and AK public keys to create a "client protection credential" for this random number, obtaining the second verification data. In this way, after the client sends the second verification data to the server, the server can decrypt the second verification data to obtain the second random number, which is then used as the second session key to encrypt its own server platform integrity information.
[0072] Specifically, the SSH client uses its pre-installed certificate public key to verify the SSH server's endorsement key certificate in the second identity credential, and generates a second random number after successful verification. The second random number is then encrypted using the endorsement key and identity key of the SSH server's trusted cryptographic module to generate second verification data, which is then sent to the SSH server. The SSH server uses the second random number obtained after decrypting the second verification data as the second session key.
[0073] Step S12: Using the first session key, encrypt the integrity information of the client platform to generate the first integrity evidence, and send it to the SSH server so that the SSH server can verify the first integrity evidence.
[0074] In this step, a third interaction occurs: the client uses a first random number recovered from the server and derived from the first verification data as the first session key to encrypt its own platform integrity information, generating the first integrity evidence. It should be noted that the client's device version information is also encrypted using the first session key during this process. Therefore, the first integrity evidence also includes data encrypted with the first session key to encrypt the client's device version information. The third interaction sends the first integrity evidence and the second verification data to the server together.
[0075] Upon receiving the data, the server verifies the platform integrity report signed by the TCM to ensure that all client platforms are in a trusted state. Specifically, the SSH server decrypts the first integrity evidence to obtain the target client platform integrity information, which also includes client device version information. The server retrieves the corresponding benchmark value from the database and uses the locally preset first trusted benchmark value of the SSH client to verify the target client platform integrity information.
[0076] Accordingly, if the integrity information of the target client platform is determined to be accurate based on the first trust metric benchmark, then the first integrity evidence verification is deemed successful.
[0077] Step S13: If the first integrity evidence is verified, the second integrity evidence generated by encrypting the second session key from the SSH server is received, and the server platform integrity information contained in the second integrity evidence is verified.
[0078] In this step, the fourth interaction process is performed: the server uses the second random number recovered from the second verification data, obtained from the client, as the second session key to encrypt the server platform integrity information, generating the second integrity evidence. Similarly, in this process, the server device version information is encrypted using the second session key. Therefore, the second integrity evidence also includes data encrypted with the second session key. The fourth interaction process sends the second integrity evidence to the client.
[0079] After receiving data from the server, the client verifies the platform integrity report signed by the TCM to ensure that the server platform is in a trusted state. Specifically, it receives a second integrity certificate generated using the second session key from the SSH server and decrypts it to obtain the target server platform integrity information, which also includes server device version information. The client retrieves the corresponding metric value from the database and verifies the target server platform integrity information using the locally preset second trusted metric value of the SSH server.
[0080] Accordingly, if the integrity information of the target server platform is determined to be accurate based on the second trust metric benchmark, then the second integrity evidence verification is deemed successful.
[0081] Step S14: Once the second integrity evidence is verified, the two-way trust verification is deemed successful.
[0082] In summary, the complete trusted access authentication process is achieved through the following four consecutive message interactions: In the first interaction, the client sends the first identity credential to the server; in the second interaction, the server sends the second identity credential and the first verification data generated based on the first random number to the client; in the third interaction, the client sends the second verification data generated based on the second random number and the first integrity evidence generated by encryption using the first random number to the server; in the fourth interaction, the server sends the second integrity evidence generated by encryption using the second random number to the client.
[0083] In this embodiment, if both the client and server pass the two-way certificate verification and the integrity information verification, the SSH two-way trusted authentication is completed and a secure communication connection is established; if either verification fails, the authentication process is terminated.
[0084] The beneficial effects of this application are as follows:
[0085] (1) Security: Traditional SSH authentication only verifies the identity of the key holder and cannot verify whether that identity is being used on an untrusted platform that has been tampered with by rootkits, Trojans, or malicious firmware. This invention relies on a trusted cryptographic module to exchange and verify platform integrity information protected or signed by the trusted cryptographic module, expanding the authentication dimension from "who you are" to "whether you are operating in a trusted environment". This makes it impossible for attackers to pass verification on compromised platforms (whose integrity information is bound to be abnormal) even if they steal legitimate keys, thereby effectively preventing man-in-the-middle attacks, hardware tampering, and malware impersonation, and providing a higher level of platform integrity assurance;
[0086] (2) Cost and practicality: Current enhancement solutions introduce dedicated hardware, which increases costs. This invention uses a widely deployed standard trusted cryptographic module, which does not require additional dedicated equipment. Moreover, the authentication process is integrated into the SSH protocol negotiation stage, which is compatible with the traditional OpenSSH architecture, reducing deployment and maintenance costs, while improving applicability and scalability.
[0087] (3) Efficiency: Complex PKI systems or multi-factor authentication will increase latency; This invention uses a lightweight process based on identity credentials, certificate verification, session key encryption, and evidence ciphertext interaction. The authentication process is optimized, the trusted cryptographic module operates efficiently, reduces redundant calculations and data transmission, and is compatible with the traditional SSH protocol. It avoids complex certificate management and reduces authentication latency and resource overhead.
[0088] like Figure 2 The diagram illustrates an architecture based on the aforementioned embodiments. The system includes an SSH client, an SSH server, and their respective TCM hardware modules. The TCM is used to generate and store asymmetric key pairs, including an endorsement key EK and an identity key AK, and to perform platform integrity measurements, recording the system startup state via the PCR register. The OpenSSH software layer is modified to support TCM trusted access interaction, including the addition of a TCM driver and authentication plugins.
[0089] like Figure 3 As shown, the trusted access authentication process includes the following steps:
[0090] 1. Initialization phase: The client and server initialize their respective TCMs and generate endorsement keys EK (client EKc, server EKs); issue EK certificates through the CA (client cert (EKc), server cert (EKs)), and pre-set the trusted measurement benchmark information of this device and the peer device.
[0091] 2. Platform startup phase: TCM collects platform integrity data, records the metric log (System MetricsLog), and stores the metric hash information in the TCM's PCR register.
[0092] 3. Negotiation Phase: The core process in the negotiation phase is trusted access authentication; the remaining processes follow the standard OpenSSH negotiation procedure. Trusted access authentication involves a total of four interaction requests, with the specific interaction content and authentication actions as follows:
[0093] first step:
[0094] Message direction: Client → Server;
[0095] Message content: Client EK certificate (cert(EKc)), client AK public key (AKc);
[0096] Authentication steps: ① The client retrieves the "Client EK Certificate" and "Client AK Public Key" and sends them to the server;
[0097] Step Two:
[0098] Message direction: Server → Client;
[0099] Message content: server EK certificate (cert(EKs)), server AK public key (AKs), server protection credentials (i.e., the aforementioned first verification data);
[0100] Authentication steps: ① The server uses a pre-configured CA public key to verify the "client EK certificate". If correct, proceed to the next step; ② The server creates a random number (Ss) and uses the client's EK public key and AK public key to create a "server protection credential (EKcAKc_cred(Ss))" for the random number; ③ The server retrieves the "server EK certificate", "server AK public key", and "server protection credential" and sends them to the client together.
[0101] Step 3:
[0102] Message direction: Client → Server;
[0103] Message content: Client protection credentials (i.e., the aforementioned second verification data), client evidence ciphertext (i.e., the aforementioned first integrity evidence);
[0104] Authentication steps: ① The client uses a pre-configured CA public key to verify the "server EK certificate". If correct, proceed to the next step; ② The client creates a random number (Sc) and uses the server's EK and AK public keys to create a "client protection credential (EKsAKs_cred(Sc))" for this random number; ③ The client obtains the "client integrity information (PCRc, SMLc)" and uses the random number (Ss) recovered from the server's "server protection credential" as the encryption key to encrypt the "client integrity information" and "client device version information (DEVc, VERc)" to obtain the "client evidence ciphertext"; ④ The client sends the "client protection credential" and "client evidence ciphertext" to the server.
[0105] Step 4:
[0106] Message direction: Server → Client;
[0107] Message content: Server-side encrypted evidence (i.e., the aforementioned second integrity evidence);
[0108] Authentication steps: ① The server decrypts the "client evidence ciphertext" to obtain the "client integrity information" and "client device version information," retrieves the corresponding benchmark value from the database, and verifies the correctness of the peer's information. If correct, proceed to the next step; ② The server obtains the "server integrity information," uses a random number recovered from the client's "client protection credentials" as the encryption key, and encrypts the "server integrity information" and "server device version information" to obtain the "server evidence ciphertext"; ③ The server sends the "server protection credentials" and "server evidence ciphertext" to the client; ④ The client decrypts the "server evidence ciphertext" to obtain the "server integrity information" and "server device version information," retrieves the corresponding benchmark value from the database, and verifies the correctness of the peer's information. If correct, the trusted access authentication is successful.
[0109] By employing the above methods, hardware-level two-way trusted authentication is added to traditional OpenSSH authentication, effectively enhancing security. It is evident that the remote authentication function based on TCM is directly applied to the identity authentication process between SSH clients and servers. During the SSH authentication phase, it not only verifies the other party's public key but also verifies the integrity of the other party's platform, improving the security and reliability of authentication through the integration of a Trusted Cryptographic Module (TCM). Specifically, during key exchange, both nodes exchange authentication messages containing the TCM identity public key certificate and a platform integrity report using temporary and permanent keys generated by the TCM. The integrity report is signed by the TCM to ensure its immutability. This approach is suitable for network environments requiring high security levels, such as financial, government, and critical infrastructure systems.
[0110] This application discloses an SSH two-way authentication method. See [link to relevant documentation] Figure 4 As shown, this method, applied to the SSH server, includes:
[0111] Step S21: During the SSH protocol negotiation phase, exchange identity credentials of their respective trusted cryptographic modules with the SSH client, and interact with the SSH client based on the identity credentials to negotiate a first session key and a second session key for encrypting platform integrity information.
[0112] During the SSH protocol negotiation phase, similar to the client, the server sends its locally generated endorsement key certificate (EK certificate) and identity key (AK) as secondary identity credentials to the SSH client.
[0113] During the initialization of the trusted cryptography module, the server generates the SSH server's endorsement key and identity key; obtains the endorsement key certificate issued by the certificate authority for the endorsement key; and pre-sets the first trusted benchmark value for the SSH client, the second trusted benchmark value for the SSH server, and the certificate public key.
[0114] Step S22: Receive the first integrity evidence sent by the SSH client, and use the first session key to decrypt and verify the client platform integrity information contained in the first integrity evidence.
[0115] During the interaction, the first integrity evidence is data obtained by encrypting the client platform integrity information using a first random number generated by the server as the first session key. Therefore, after receiving the first integrity evidence, the server decrypts it using the first session key to verify the correctness of the client platform integrity information and client device version information. If correct, it proceeds to the next step.
[0116] Step S23: If the first integrity evidence is verified, the second session key is used to encrypt the integrity information of the server platform to generate a second integrity evidence, which is then sent to the SSH client so that the SSH client can verify the second integrity evidence.
[0117] When the first integrity evidence verification passes, it proves that the client platform is in a trusted state. At this time, the server uses the second random number generated by the client as the second session key to encrypt the integrity information of the server platform, generating a second integrity evidence which is then sent to the client.
[0118] Step S24: Once the second integrity evidence is verified, the two-way trust verification is deemed successful.
[0119] Once the client successfully verifies the server platform integrity information and server device version information in the second integrity evidence using the same method, it proves that the server platform is also in a trusted state. In this way, both platforms are in a trusted state, allowing the subsequent SSH connection establishment process to continue. Therefore, this invention implements a lightweight authentication process, reducing authentication latency and maintaining compatibility with traditional SSH by optimizing TCM information interaction and message format.
[0120] For more detailed processing procedures regarding the above steps, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.
[0121] Accordingly, this application also discloses an SSH two-way authentication device for use in SSH clients, see [link to relevant documentation]. Figure 5 As shown, the device includes:
[0122] The identity credential exchange module 11 is used to exchange identity credentials of their respective trusted cryptographic modules with the SSH server during the SSH protocol negotiation phase.
[0123] The session key negotiation module 12 is used to interact with the SSH server based on the identity credentials to negotiate a first session key and a second session key for encrypting platform integrity information.
[0124] The first verification module 13 is used to encrypt the integrity information of the client platform using the first session key to generate a first integrity evidence, and send it to the SSH server so that the SSH server can verify the first integrity evidence.
[0125] The second verification module 14 is used to receive the second integrity evidence generated by encrypting the second session key from the SSH server if the first integrity evidence verification is successful, and to verify the server platform integrity information contained in the second integrity evidence; when the second integrity evidence verification is successful, the two-way trusted verification is determined to be successful.
[0126] For more detailed information on the working process of each of the above modules, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.
[0127] Therefore, through the above scheme of this embodiment, (1) in terms of security: traditional SSH authentication only verifies the identity of the key owner, and cannot identify whether the identity is used on an untrusted platform that has been tampered with by rootkits, Trojans or malicious firmware. The present invention relies on a trusted cryptographic module to exchange and verify the platform integrity information protected or signed by the trusted cryptographic module, and expands the authentication dimension from "who you are" to "whether you are running in a trusted environment". This makes it impossible for attackers to pass verification on compromised platforms (whose integrity information is bound to be abnormal) even if they steal legitimate keys, thus effectively preventing man-in-the-middle attacks, hardware tampering, and malware impersonation, and providing higher platform integrity guarantees; (2) Cost and practicality: Current enhancement schemes introduce dedicated hardware, which increases costs. This invention uses a widely deployed standard trusted cryptographic module, which does not require additional dedicated equipment. Moreover, the authentication process is integrated into the SSH protocol negotiation stage, which is compatible with the traditional OpenSSH architecture, reducing deployment and maintenance costs, while improving applicability and scalability; (3) Efficiency: Complex PKI systems or multi-factor authentication increase latency. This invention uses a lightweight process based on identity credentials certificate verification + session key encryption + evidence ciphertext interaction. The authentication process is optimized, the trusted cryptographic module operates efficiently, reduces redundant calculations and data transmission, and is compatible with the traditional SSH protocol, avoiding complex certificate management and reducing authentication latency and resource overhead.
[0128] Furthermore, embodiments of this application also disclose an electronic device, Figure 6 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.
[0129] Figure 6 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the SSH two-way authentication method disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be a computer.
[0130] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.
[0131] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored on it can include an operating system 221, computer programs 222, and data 223, etc. The data 223 can include various types of data. The storage method can be temporary storage or permanent storage.
[0132] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the SSH two-way authentication method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.
[0133] Furthermore, this application also discloses a computer-readable storage medium, which includes random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, magnetic disks, optical disks, or any other form of storage medium known in the art. The computer program, when executed by a processor, implements the aforementioned SSH two-way authentication method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.
[0134] Furthermore, embodiments of this application also provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements any of the above-described implementations of the SSH two-way authentication method.
[0135] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.
[0136] The steps of the SSH two-way authentication method or algorithm described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.
[0137] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0138] The foregoing has provided a detailed description of the SSH two-way authentication method, apparatus, device, and storage medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only intended to help understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.
Claims
1. A method for SSH two-way authentication, characterized in that, The application is applied to an SSH client, and includes: In an SSH protocol negotiation stage, identity credentials of respective trusted password modules are exchanged with an SSH server, and based on the identity credentials, interaction is performed with the SSH server to negotiate first and second session keys for encrypting platform integrity information; Client platform integrity information is encrypted by using the first session key to generate first integrity evidence, which is sent to the SSH server to be verified by the SSH server; If the first integrity evidence is verified, second integrity evidence encrypted by using the second session key is received from the SSH server, and server platform integrity information contained in the second integrity evidence is verified; After the second integrity evidence is verified, it is determined that two-way trusted verification is successful.
2. The SSH two-way authentication method of claim 1, wherein, The identity credentials of respective trusted password modules are exchanged with the SSH server, and include: A trusted password module is initialized to generate an endorsement key and an identity key of the SSH client; An endorsement key certificate issued by a certificate authority to the endorsement key is obtained, and a first trusted measurement reference value of the SSH client, a second trusted measurement reference value of the SSH server, and a certificate public key are preset; The first identity credential is sent to the SSH server; the first identity credential includes the endorsement key certificate and the identity key of the trusted password module of the SSH client; The second identity credential is received from the SSH server; the second identity credential includes the endorsement key certificate and the identity key of the trusted password module of the SSH server.
3. The SSH two-way authentication method of claim 2, wherein, Based on the identity credentials, interaction is performed with the SSH server to negotiate first and second session keys for encrypting platform integrity information, and includes: First verification data is received from the SSH server; the first verification data is data generated by encrypting a first random number by using the endorsement key and the identity key of the SSH client by the SSH server; the first random number is a random number generated by verifying the endorsement key certificate of the SSH client in the first identity credential by using the preset certificate public key by the SSH server; The first random number obtained by decrypting the first verification data is used as the first session key; The endorsement key certificate of the SSH server in the second identity credential is verified by using the certificate public key preset by the SSH client, and a second random number is generated after the verification is passed; The second random number is encrypted by using the endorsement key and the identity key of the trusted password module of the SSH server to generate second verification data and send to the SSH server, so that the second random number obtained by decrypting the second verification data by the SSH server is used as the second session key.
4. The SSH two-way authentication method of claim 2, wherein, The first integrity evidence is generated and sent to the SSH server to be verified by the SSH server, and includes: generating a first integrity evidence and sending it to the SSH server, so that the SSH server decrypts the first integrity evidence to obtain target client platform integrity information, and verifies the target client platform integrity information by using a first trusted measurement baseline value of the SSH client pre-stored locally; Correspondingly, if the target client platform integrity information is determined to be accurate according to the first trusted measurement baseline value, it is determined that the first integrity evidence is verified.
5. The SSH two-way authentication method of claim 2, wherein, receiving a second integrity evidence encrypted by the second session key from the SSH server, and verifying server platform integrity information contained in the second integrity evidence, including: receiving a second integrity evidence encrypted by the second session key from the SSH server, and decrypting the second integrity evidence to obtain target server platform integrity information; verifying the target server platform integrity information by using a second trusted measurement baseline value of the SSH server pre-stored locally; Correspondingly, if the target server platform integrity information is determined to be accurate according to the second trusted measurement baseline value, it is determined that the second integrity evidence is verified.
6. The SSH two-way authentication method according to any one of claims 1 to 5, characterized in that, Before exchanging identity credentials of respective trusted password modules with the SSH server in the SSH protocol negotiation phase, the method further includes: collecting system startup state data by a local trusted password module when the SSH client starts, to generate a measurement log and a hash value; storing the hash value to a platform configuration register of the trusted password module, and determining the client platform integrity information together with the measurement log.
7. A method for SSH two-way authentication, characterized by, Applied to an SSH server, the method includes: exchanging identity credentials of respective trusted password modules with an SSH client in an SSH protocol negotiation phase, and interacting with the SSH client based on the identity credentials to negotiate a first session key and a second session key for encrypting platform integrity information; receiving a first integrity evidence sent by the SSH client, and decrypting and verifying client platform integrity information contained in the first integrity evidence by using the first session key; if the first integrity evidence is verified, encrypting server platform integrity information by using the second session key to generate a second integrity evidence, and sending it to the SSH client, so that the SSH client verifies the second integrity evidence; when the second integrity evidence is verified, it is determined that the bidirectional trusted verification is successful.
8. An apparatus for SSH two-way authentication, characterized by, Applied to an SSH client, the method includes: an identity credential exchange module configured to exchange identity credentials of respective trusted password modules with an SSH server in an SSH protocol negotiation phase; a session key negotiation module configured to interact with the SSH server based on the identity credentials to negotiate a first session key and a second session key for encrypting platform integrity information; The first verification module is configured to encrypt the client platform integrity information by using the first session key to generate a first integrity evidence and send the first integrity evidence to the SSH server, so that the SSH server verifies the first integrity evidence. The second verification module is configured to receive a second integrity evidence encrypted by using the second session key from the SSH server if the first integrity evidence is verified, and verify the server platform integrity information contained in the second integrity evidence; and determine that the two-way trusted verification is successful when the second integrity evidence is verified.
9. An electronic device, comprising: The electronic device comprises a processor and a memory; wherein the memory is configured to store a computer program, and the computer program is loaded and executed by the processor to implement the SSH two-way authentication method according to any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, A computer program is stored; wherein the computer program is executed by a processor to implement the SSH two-way authentication method according to any one of claims 1 to 7.