CN115378740B - 一种基于可信openssh双向认证登录的实现方法 - Google Patents

Abstract

本发明涉及一种基于可信openssh双向认证登录的实现方法，包括本地初始化、验证端初始化、可信接入发起、建立可信连接这些步骤。基于上述步骤，本方法将openssh命令重新封装为openpts命令，在保留单向通信连接与对关键目录验证的同时，加入双向验证关键目录PCR10的值的应用，并对上层系统调用底层系统的TPM2.0及以上芯片的机制也进行适配处理，使openpts命令能够适配TPM2.0及以上的芯片。本方法可以避免设备可能存在被篡改的情况，更能保障系统的安全性。

Description

一种基于可信openssh双向认证登录的实现方法

技术领域

本专利申请属于起重机设备技术领域，更具体地说，是涉及一种基于可信openssh双向认证登录的实现方法。

背景技术

SSH 为 Secure Shell 的缩写，由 IETF 的网络小组（Network Working Group）所制定；SSH 为建立在应用层基础上的安全协议。SSH 是较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。SSH最初是UNIX系统上的一个程序，后来又迅速扩展到其他操作平台。

OpenSSH 是 SSH （Secure SHell） 协议的免费开源实现。SSH协议族可以用来进行远程控制， 或在计算机之间传送文件。而实现此功能的传统方式，如telnet(终端仿真协议)、 rcp ftp、 rlogin、rsh都是极为不安全的，并且会使用明文传送密码。OpenSSH提供了服务端后台程序和客户端工具，用来加密远程控制和文件传输过程中的数据，并由此来代替原来的类似服务。

计算机信息的安全问题很难单靠软件解决，为了解决现有PC机的不安全问题，从根本上提高其可信性，可信计算平台联盟TCPA (后来更名为TCG)提出通过增强现有的终端体系结构的安全性来保证整个系统的安全，核心思想是在硬件平台上引入具有安全存储和加密功能的可信平台模块（又称为可信芯片）TPM。可信计算平台以TPM为信任根，借助其 他可信度量模块对系统平台配置进行度量，然后安全地将系统运行情况记录在TPM中的平 台配置寄存器（PCR)，同时在系统保存代表了被验证的可信平台的完整性度量历史的度量 存储日志SML (storage measurement log)。远程用户根据SML和相关PCR值来判断该运行 环境是否可信、某些环节是否出现安全问题，这一过程被称作远程证明。在TCG规范中，TPM 使用身份证明密钥AIK (attestation identity key)来证明自己的身份，凡是经过AIK签 名的实体，都表明已经经过TPM的处理。为了防止重放、篡改、假冒等攻击，远程证明要求被 验证的一方要使用AIK对数据进行签名。

目前存在一种基于SM2、SM4国密算法提升SSH协议安全性的方法；使用国密算法SM2、SM4替换SSH协议中的对称加密和非对称加密算法，提升SSH协议在涉密网络中的安全，规避SSH协议在涉密网络中的安全风险；包括以下步骤：在SSH连接过程中，将密钥认证的算法替换为SM2国密算法，在客户端到服务器通信阶段，将对称加密算法替换为SM4国密算法，实现了支持国密算法的SSH协议。

在两台设备互相通过openssh连接的过程中，如果设备本身的安全性已被破坏，则会在建立连接后，被入侵的设备能从内部篡改所有连入服务端设备的关键信息，导致整个可信系统会从内部被攻破。

发明内容

本发明需要解决的技术问题是提供一种基于可信openssh双向认证登录的实现方法，避免设备可能存在被篡改的情况。

为了解决上述问题，本发明所采用的技术方案是：

一种基于可信openssh双向认证登录的实现方法，基于国产自制操作系统，比如麒麟操作系统，将openssh命令重新封装为openpts命令，在本地用户和远程用户进行初始登录和/或鉴别时，针对连接双方分别进行关键位置信息的可信度量计算，确保双方系统在完整性验证无误的情况下，再进行可信连接。

本发明加入双向验证关键目录的PCR10的值的应用，通过连接时对目标设备进行加密验证来保证用户数据的完整性，并且在保留单向通信连接与对关键目录验证的同时，在进行openpts连接时会同时服务端与客户端下关键目录的PCR10的值，只要任意一方的关键目录被篡改，导致PCR10的值发生变动，此次连接就会失效，并将该事件记录到审计日志中。

具体实现方法包括如下步骤：

S1、本地初始化，包括客户端和服务端的双方系统在互相连接前需先各自进行本地初始化，在此过程中会读取各自的配置文件、获取各自的PCR10的值及初始化密钥工作；由于PCR10体现了操作系统重要文件系统中的文件完整性，所以获取PCR10的值。

在S1中，双方系统的本地初始化包括如下步骤，

S11、读取配置文件，设置默认信息；

S12、读取自身设备的TPM芯片；

S13、从TPM芯片中获取PCR10的值；

S14、调用系统函数uuid_create生成双方系统的通用唯一识别码，分别记为UUID和RM_UUID；其中，UUID表示发起接入端设备的通用唯一识别码，在本发明的场景应用中为真实的客户端主机；RM_UUID表示被接入端设备的通用唯一识别码，在本发明中为真实的服务端主机。客户端主机、服务端主机的身份一般不会变动。

S15、使用UUID和RM_UUID创建双方系统的公钥、私钥并固化。

S2、验证端初始化，双方系统（也就是接入双方）需分别作为信息发起方，向对端主机发起信息获取请求，在此连接过程中双方系统均会进行初始化，以根据相应主机的PCR10的值获取对应的PCR基准值，从而获取双方系统的PCR基准值。

S2中，在此连接过程中双方系统均会进行初始化，上述初始化包括enroll与verifier两部分，

S21、enroll，录入信息发起方信息，包括：

S211、获取信息发起方的通用唯一识别码，如信息发起方为客户端即为UUID，如信息发起方为服务端即为RM_UUID；

S212、获取公钥；

S22、verifier，验证，包括：

S221、获取对端主机的通用唯一识别码（为RM_UUID或UUID），验证对端主机的身份信息；

S222、对端主机根据获取的PCR基准值，对信息发起方进行内容验证。

S3、可信接入发起、并建立可信连接，由客户端发起接入请求，在接入发起后进行服务端与客户端的双向完整性验证（也就是完整性的双向认证），只有在双向完整性验证都有效的情况下才会建立可信接入通道，实现远程连接的需求，否则失败。可信通道建立成功后，基于客户端与服务端之间建立的可信通道，首先对客户端进行身份验证，身份验证成功后进行内容验证，最终形成完整性报告；然后服务端在接收到客户端的完整性报告后，先进行身份验证，身份验证成功后进行完整性验证，若一致，最终的验证结果通过；若不一致，最终的验证结果为完整性验证无效。

首先对客户端进行身份验证，身份验证成功后进行内容验证，最终形成完整性报告，是指，

首先对客户端进行身份验证，通过调用系统函数uuid_create获取客户端的当前UUID，利用一个有限状态机输入当前UUID，得到状态输出结果，将其与之前预存的RM_UUID的状态输出结果进行校验，校验成功后证明客户端的身份验证无误，接着进行内容验证；

客户端通过调用可信软件栈所提供的接口引用（TPM Quote）PCR10的值，并对PCR10的值进行哈希得到PCR10哈希值，再利用TPM芯片对该PCR10哈希值进行签名；由PCR10哈希值及其对应的签名数据、公钥组成了完整性报告；TPM芯片为TPM芯片2.0及以上版本。

服务端在接收到客户端的完整性报告后，进行的验证操作具体包括：

身份验证：利用PCR10哈希值、签名数据及公钥进行验签，以实现身份验证，若验证失败则完整性验证为无效状态，否则完整性验证为有效状态，进入步骤S44；

完整性验证：对PCR基准值进行哈希操作，并与完整性报告中的PCR10哈希值进行比对，若一致则最终的验证结果通过；若不一致则说明PCR10哈希值有所变化，代表重要文件系统的完整性存在风险，则最终的验证结果为完整性验证无效。

由于采用了上述技术方案，本发明取得的有益效果是：

本发明基于国产自制操作系统，在本地用户和远程用户进行初始登录和/或鉴别时，针对连接双方分别进行关键位置信息的可信度量计算，确保双方系统在完整性无误的情况下，再进行可信连接。使用sm3加密算法实现可信信道的同时保证了通信双方的平台信息在网络传输过程中的秘密性。

该方法重新封装了一种名为openpts的命令，通过连接时对目标设备进行加密验证来保证用户数据的完整性。此方法比起通过普通openpts（也就是openpts用到了openssh的连接机制，但是功能上有区别）连接更能保障系统的安全性。并且在进行openpts连接时会同时服务端与客户端下关键目录的PCR10的值，只要任意一方的关键目录被篡改，导致PCR10的值发生变动，此次连接就会失效，并将该事件记录到审计日志中。

在客户端与服务端之间的通信层面，两者的交互过程中通过使用libtnc通信框架、采用TCG IF-M协议并利用SSH作为底层通信通道进行信息传递。

对于客户端而言，其通过可信软件栈（TSS）所提供的应用层接口（libtpsi）与核心服务进程（tcsd）、借助内核TPM驱动来使用TPM2.0可信芯片的基础功能，以实现在整个可信通道建立的初始化与双向认证过程中进行收集、处理与管理系统完整性信息的目标。

附图说明

图1为本发明完整性验证的流程图；

图2为本发明的双向网络可信接入的总体流程示意图；

图3为本发明客户端与服务端的系统架构图。

具体实施方式

下面结合实施例对本发明做进一步详细说明。

本发明公开了一种基于可信openssh双向认证登录的实现方法，在具体介绍本方法时，先介绍一些本行业的缩略语和关键术语定义：

PCR值：对需要度量的文件进行统一加密生成的一组数据。

openssh：通过加密远程控制来进行通信的一种方法。

openpts：根据openssh连接进行改造的一种通信方法。

sm3：一种国密加密算法。

双向认证：在远程加密连接时互相对各自关键信息进行验证的一种方法。

TPM芯片：一种符合可信赖平台模块的芯片，使储存在内的用户数据无法被破解。本发明侧重于使用TPM2.0及以上版本芯片。

可信软件栈：一套统一的执行和开发接口，让上层应用能够获取底层TPM芯片内数据的方法。

所以在本发明中，针对背景技术提到的设备可能存在被篡改的情况，基于国产自制操作系统，在本地用户和远程用户进行初始登录和/或鉴别时，针对连接双方分别进行关键位置信息的可信度量计算，确保双方系统在完整性无误的情况下，再进行可信连接，使用sm3加密算法实现可信信道的同时保证了通信双方的平台信息在网络传输过程中的秘密性，该方法重新封装了一种名为openpts的命令，通过连接时对目标设备进行加密验证来保证用户数据的完整性。此方法比起通过普通或常规的openpts连接更能保障系统的安全性。并且在进行openpts连接时会同时验证服务端与客户端下关键目录的PCR10的值，只要任意一方的关键目录被篡改，导致PCR10的值发生变动，此次连接就会失效，并将该事件记录到审计日志中。

关于本发明的一种基于可信openssh双向认证登录的实现方法，参见图1-图3，该方法的总体设计与实现过程为：基于国产自制操作系统，比如麒麟操作系统，将openssh命令重新封装为openpts命令，在本地用户和远程用户进行初始登录和/或鉴别时，针对连接双方分别进行关键位置信息的可信度量计算，确保双方系统在完整性验证无误的情况下，再进行可信连接。本发明主要是将openssh命令重新封装为openpts命令，在保留单向通信连接与对关键目录验证的同时，加入双向验证关键目录PCR10的值这一应用。

同时，对上层系统调用底层系统的TPM2.0及以上芯片的机制也进行适配处理，使openpts命令能够适配TPM2.0及以上的芯片。

本发明的具体实现方法包括如下步骤，

S1、本地初始化，包括客户端和服务端的双方系统在互相连接前需先各自进行本地初始化，在此过程中会读取配置文件、获取所需采集的PCR10的值及初始化密钥工作。由于PCR10体现了操作系统重要文件系统中的文件完整性，所以获取PCR10的值。

S2、验证端初始化，双方系统（也就是接入双方）需分别作为信息发起方，向对端主机发起远程连接以实施信息获取请求，在该远程连接过程中双方系统均会进行初始化工作，以根据相应主机的PCR10的值获取对应的PCR基准值，从而可以获取双方系统的PCR基准值，以备后续操作；

S3、可信接入发起、并建立可信连接，由客户端发起接入请求，在接入发起后将进行服务端与客户端的双向完整性验证，只有在双向完整性验证都有效的情况下才会建立可信接入通道，实现远程连接的需求，否则失败。

下面将各个步骤逐一介绍。

S1中，双方系统的本地初始化包括如下步骤，

S11、读取配置文件设置默认信息；

S12、读取自身设备的TPM芯片；

S13、从TPM芯片中获取PCR10的值；

S14、调用系统函数uuid_create生成双方系统的通用唯一识别码，分别记为UUID和RM_UUID；其中，UUID表示客户端主机的通用唯一识别码，RM_UUID表示服务端主机的通用唯一识别码。如果客户端和服务端可以正常通信连接，则UUID和RM_UUID的内容是可以对应的。

在本文件中，由于双方系统需要发送信息再验证，角色不停变更，因此进行如下定义：客户端、服务端指向固定的某台设备，比如客户端一直为1号设备，其通用唯一识别码为UUID。服务端一直是2号设备，其通用唯一识别码为RM_UUID；而信息发起方指向任一台设备，比如信息发起方可以是1号设备，也可以是2号设备。

S15、使用UUID和RM_UUID创建双方系统的公钥、私钥并固化。

S2中，在此连接过程中双方系统均会进行初始化，如图2所示，上述初始化包括enroll与verifier两部分，

S21、enroll，录入信息发起方的信息，包括：

S211、获取信息发起方的通用唯一识别码；如果信息发起方是客户端，则获取的通用唯一识别码为UUID，反之如果信息发起方是服务端，则获取的通用唯一识别码为RM_UUID；

S212、获取公钥；

S22、verifier，验证，包括：

S221、获取对端主机（也就是信息接收方）的通用唯一识别码，验证对端主机（也就是信息接收方）的身份信息；与步骤S211相应的，该步骤获取的通用唯一识别码为RM_UUID或UUID；

S222、对端主机（也就是信息接收方）根据获取的信息发起方的PCR基准值，对信息发起方进行内容验证。

本发明中，客户端的身份验证一般是通过通用唯一识别码来进行的，通过特征比对来判定是不是本设备；但是服务端的身份验证却不同，需要将PCR10哈希值和PCR基准值对比。内容验证主要是当前PCR10哈希值和PCR基准值对比，用以判断关键文件是否有篡改。完整性验证是内容验证+包括度量日志在内的整体验证。

当接收方是客户端时，步骤S222也需要执行，双向验证必须保证密码和完整性度量报告都要双方全部验证通过才能进行连接。

双方的基准值是之前在初始化时就已经互相收到了。然后进行连接时就会对比最新的完整性报告和基准值是否一致，如果全部一致就能符合连接的条件。

图2中的IR为信息传输管道，VR为信息回传管道。IR传输的信息是最新的完整性度量值，S2初始化的结果就是完整性度量的基准值。

S3中，由客户端发起接入请求包括如下步骤，当然也可以是服务端发起接入请求，流程相似，以客户端发起接入请求为例来说明：

S311、首先对需要连接的客户端数据进行完整性验证，验证通过后，执行步骤S312；

S312、然后再对服务端的数据进行完整性验证；

S313、只有在双方系统完整性验证都有效的情况下才会建立可信通道，否则可信通道接入失败；

这个可信通道对应的就是图2最下端的SSH，也是图3中的SSH Tunnel，由于IR传输的信息就是完整性度量报告，VR传输的信息是之前IR完整性度量报告的验证结果。只有收到VR传输的验证结果证明完整性报告无误后，才会继续之后的流程。

“验证”这个步骤主要是设备密码的正确性验证；“verifier”这个步骤主要是完整性度量报告的正确性验证。这两步也都是要保证正确才能继续完成可信连接。

S314、可信通道建立成功后，基于客户端与服务端之间建立的可信通道，如图1所示，首先对客户端进行身份验证，身份验证成功后进行内容验证，最终形成完整性报告；然后服务端在接收到客户端的完整性报告后，先进行身份验证，身份验证成功后进行完整性验证，若完整性验证一致，最终的验证结果通过；若不一致，最终的验证结果为完整性验证无效。这里，与后续操作相对应，也就是：若经过哈希操作的PCR基准值和完整性报告中的对应值一致，验证结果通过；若不一致，验证结果为完整性验证无效。

步骤S311和步骤S312进行完整性验证的步骤相同，均包含如下步骤：

1）、检测是否已对客户端、服务端进行过步骤S2的验证端初始化的工作，若未进行过，则验证不通过；

2）、借助底层芯片（TPM2.0及以上版本芯片）、可信软件栈，对端主机生成完整性报告，当前主机对该完整性报告进行完整性验证，若完整性验证无效，则无法建立可信通道。

S314中，见图1，首先对客户端进行身份验证，身份验证成功后进行内容验证，最终形成完整性报告，是指，

首先对客户端进行身份验证，通过调用系统函数uuid_create获取客户端的当前UUID，利用一个有限状态机输入当前UUID，得到状态输出结果，将其与之前预存的RM_UUID的状态输出结果进行校验，校验成功后证明客户端的身份验证无误，接着进行内容验证；

客户端通过调用可信软件栈所提供的接口引用（TPM Quote）PCR10的值，并对PCR10的值进行哈希得到PCR10哈希值，再利用TPM2.0及以上版本芯片对该PCR10哈希值进行签名，得到签名数据；由PCR10哈希值及其对应的签名数据、公钥组成了完整性报告；

见图1，服务端在接收到客户端的完整性报告后，进行的验证操作具体包括：

身份验证：利用PCR10哈希值、签名数据及公钥进行验签，以实现身份验证，若验证失败则完整性验证为无效状态，否则完整性验证为有效状态，进入步骤S44；图1中，TPMQuote：是TPM接口提供的进行签名的命令，使用该命令可以针对PCR10文件的内容生成签名数据，之后的身份验证就会用到该签名数据进行验证。

完整性验证：对PCR基准值进行哈希操作，并与完整性报告中的PCR10哈希值进行比对，若一致则最终的验证结果通过；若不一致则说明PCR10哈希值有所变化，代表重要文件系统的完整性存在风险，则最终的验证结果为完整性验证无效。

本发明中，哈希值就是判断数据内容是否出错的凭据；PCR哈希值指的是将哈希值储存于TPM芯片中，这样代表比储存于系统软件内的哈希值更安全。

PCR10哈希值代表需要度量的文件哈希值的总和，这次需要度量的文件只是boot目录下的部分关键文件，这部分文件的哈希值就称为PCR10哈希值。

PCR基准值是判断用户数据是否出错的精准参数，如果当前系统的PCR10的值与之前记录的PCR基准值不一致，则会拒绝连接。

如图3所示，在客户端（PTS collector）与服务端（PTS verifier）之间的通信层面，两者的交互过程中通过使用libtnc通信框架、采用TCG IF-M协议并利用SSH作为底层通信通道进行信息传递。

对于客户端（PTS collector）而言，其通过可信软件栈（TSS）所提供的应用层接口（libtpsi）与核心服务进程TSS（tcsd）、借助内核TPM驱动来使用TPM2.0可信芯片的基础功能，以实现在整个可信通道建立的初始化与双向认证过程中进行收集、处理与管理系统完整性信息的目标。上述系统架构可见图3所示。

本发明方法主要是实现了openpts命令的双向验证功能，以及进行了openpts命令与TPM2.0及以上版本芯片的适配应用。

为使本技术方案的流程更加清楚明白，以下结合具体实施例，在openpts连接时展示双向认证登录的具体过程进行说明。

以下实施例中，设备ip为10.3.20.69

1.先对设备进行初始化，ptsc -i，代码如下：

[root@localhost 桌面]# ptsc –i

Sign key location: SYSTEM

Generate uuid: 08b0893e-24ef-11ec-b0a3-02423ff7b093

Generate UUID(for RM): 0e4f364c-24ef-11ec-b0a3-02423ff7b093

Level 0 Reference Manifest:

/var/lib/openpts//0e4f364c-24ef-11ec-b0a3-02423ff7b093/rm0.xml

ptsc has successfully initialized!

[root@localhost 桌面] #

2.设备进行初始PCR10的值的设置，openpts -i 10.3.20.69此处因为需要先进行设备的连接然后进行PCR验证，所以需要输入2次密码，代码如下：

3.建立可信连接，设备使用命令，openpts -u 10.3.20.69，因为此处是连接设备自身，所以输入的是此设备的ip，如果需要连接其它设备则输入对应其它设备的ip即可，需要注意的是其它设备必须也要完成openpts的初始化工作才可正常进行连接。

连接步骤：第一次输入密码客户端的PCR有效性，第二次输入密码完成客户端可信连接，第三次输入密码服务端的PCR有效性，第四次输入密码完成服务端验证，至此服务端才有权限登录客户端，如下所示的代码：

[root@localhost 桌面]# openpts –u 10.3.20.69

Authorized users only. All activities may be monitored and reported.

root@10.3.20.69’s password:

integrity: valid

Authorized users only. All activities may be monitored and reported.

root@10.3.20.69’s password:

Authorized users only. All activities may be monitored and reported.

root@10.3.20.69’s password:

integrity: valid

connection to 10.3.20.69 closed.

Two-way integrity:valid

Authorized users only. All activities may be monitored and reported.

root@10.3.20.69’s password:

Last login: Wed 0ct 6 09:45:25 CST 2021 from 10.3.20.69 on ssh

Authorized users only. All activities may be monitored and reported.

Web console: https://localhost:9090/

Last login: Wed 0ct 6 09:45:41 2021 from 10.3.20.69

最近一次密码修改时间：9月30日，2021

密码过期时间：从不

密码失效时间：从不

账户过期时间：从不

两次改变密码之间相距的最小天数：0

两次改变密码之间相距的最大天数：99999

在密码过期之前警告的天数：7天

[root@localhost~]#

4.如果此时修改客户端或服务端的PCR10的值，如修改/boot目录下的grub.cfg文件，由于该文件属于重要配置文件，修改该文件会导致PCR10的值发生变化，此时服务端再次使用openpts -u 10.3.20.69命令进行连接就没有权限登录客户端，如下所示的代码：

[root @localhost 桌面]# openpts –u 10.3.20.69

Authorized users only. All activities may be monitored and reported.

root@10.3.20.69’s password:

integrity: valid

Authorized users only. All activities may be monitored and reported.

root@10.3.20.69’s password:

Authorized users only. All activities may be monitored and reported.

root@10.3.20.69’s password:

integrity: valid

connection to 10.3.20.69 closed.

two-way integrity: valid

Authorized users only. All activities may be monitored and reported.

root@10.3.20.69’s password:

5.此次连接失败之后，相关日志会被保存到/var/log/audit/audit.log下，审计用户能够查看到此次登录失败的相关信息。

6.此时root用户认可通过重新度量PCR10的值的方法使openpts连接重新恢复，保证功能的完整性。

Claims (4)

1.一种基于可信openssh双向认证登录的实现方法，其特征在于：具体实现方法包括如下步骤：

S1、本地初始化，包括客户端和服务端的双方系统在互相连接前需先各自进行本地初始化，在此过程中会读取各自的配置文件、获取各自的PCR10的值及初始化密钥工作；

S2、验证端初始化，双方系统需分别作为信息发起方，向对端主机发起信息获取请求，在此连接过程中双方系统均会进行初始化，以根据相应主机的PCR10的值获取对应的PCR基准值，从而获取双方系统的PCR基准值；

S3、可信接入发起、并建立可信连接，由客户端发起接入请求，在接入发起后进行服务端与客户端的双向完整性验证，只有在双向完整性验证都有效的情况下才会建立可信接入通道，实现远程连接的需求，否则失败；

S1中，双方系统的本地初始化包括如下步骤，

S11、读取配置文件，设置默认信息；

S12、读取自身设备的TPM芯片；

S13、从TPM芯片中获取PCR10的值；

S14、调用系统函数uuid_create生成双方系统的通用唯一识别码，分别记为UUID和RM_UUID；其中，UUID表示客户端主机的通用唯一识别码，RM_UUID表示服务端主机的通用唯一识别码；

S15、使用UUID和RM_UUID创建双方系统的公钥、私钥并固化；

S2中，在此连接过程中双方系统均会进行初始化，上述初始化包括enroll与verifier两部分，

S21、enroll，录入信息发起方信息，包括：

S211、获取信息发起方的通用唯一识别码；

S212、获取公钥；

S22、verifier，验证，包括：

S221、获取对端主机的通用唯一识别码，验证对端主机的身份信息；

S222、对端主机根据PCR基准值，对信息发起方进行内容验证；

S3中，由客户端发起接入请求，在接入发起后进行服务端与客户端的双向完整性验证，包括如下步骤：

S311、先对需要连接的客户端数据进行完整性验证，验证通过后，执行步骤S312；

S312、再对服务端的数据进行完整性验证；

S313、只有在双方系统的完整性验证都有效的情况下才会建立可信通道，否则通道接入失败；

S314、可信通道建立成功后，基于客户端与服务端之间建立的可信通道，首先对客户端进行身份验证，身份验证成功后进行内容验证，最终形成完整性报告；然后服务端在接收到客户端的完整性报告后，先进行身份验证，身份验证成功后进行完整性验证，若一致，最终的验证结果通过；若不一致，最终的验证结果为完整性验证无效。

2.根据权利要求1所述的一种基于可信openssh双向认证登录的实现方法，其特征在于：S314中，首先对客户端进行身份验证，身份验证成功后进行内容验证，最终形成完整性报告，是指，

首先对客户端进行身份验证，通过调用系统函数uuid_create获取客户端的当前UUID，利用一个有限状态机输入当前UUID，得到状态输出结果，将其与之前预存的RM_UUID的状态输出结果进行校验，校验成功后证明客户端的身份验证无误，接着进行内容验证；

客户端通过调用可信软件栈所提供的接口引用PCR10的值，并对PCR10的值进行哈希得到PCR10哈希值，再利用TPM芯片对该PCR10哈希值进行签名；由PCR10哈希值及其对应的签名数据、公钥组成了完整性报告。

3.根据权利要求2所述的一种基于可信openssh双向认证登录的实现方法，其特征在于：S314中，服务端在接收到客户端的完整性报告后，进行的验证操作具体包括：

身份验证：利用PCR10哈希值、签名数据及公钥进行验签，以实现身份验证，若验证失败则完整性验证为无效状态，否则完整性验证为有效状态，进入步骤S44；

完整性验证：对PCR基准值进行哈希操作，并与完整性报告中的PCR10哈希值进行比对，若一致则最终的验证结果通过；若不一致则说明PCR10哈希值有所变化，代表重要文件系统的完整性存在风险，则最终的验证结果为完整性验证无效。

4.根据权利要求2所述的一种基于可信openssh双向认证登录的实现方法，其特征在于：TPM芯片为TPM2.0及以上版本的芯片。

Images