发明名称 一种可扩展的可信SSH的实现方法
摘要 本发明涉及一种可扩展的可信SSH的实现方法。本方法要求服务器端和客户端都配有可信安全芯片,并且安装了度量模块和可信操作系统,能够对各自平台状态进行度量。本方法通过在SSH传输子协议层定义三个新消息编码,并将SSH传输子协议层中密钥交换算法所计算的会话密钥作为可信计算远程证明的参数,来实现可信SSH通道。本方法实现的可信通道具有以下两个特性,一个是远程证明过程对密钥交换算法的透明性,另一个是通信双方的平台信息在网络传输过程中的秘密性。
申请公布号 CN101888383B 申请公布日期 2013.07.31
申请号 CN201010222556.7 申请日期 2010.06.30
申请人 北京交通大学 发明人 常晓林;王绍创;藤莎;左向晖;韩臻;刘吉强
分类号 H04L29/06(2006.01)I;H04L9/32(2006.01)I 主分类号 H04L29/06(2006.01)I
代理机构 北京正理专利代理有限公司 11257 代理人 张文祎
主权项 1.一种可扩展的可信SSH的实现方法,其特征在于:在SSH传输子协议层定义三个新消息编码:SSH_MSG_RA_INIT、SSH_MSG_RA_OK和SSH_MSG_RA_ERROR,并将SSH传输子协议层中密钥交换算法所计算的会话密钥作为可信计算远程证明的参数,方法的具体步骤如下:步骤1,客户端首先生成一个Diffie-Hellman算法参数,记作e,然后客户端向服务器端发送一个带有SSH_MSG_KEXDH_INIT消息编码的消息,该消息只包含e;其中SSH_MSG_KEXDH_INIT是RFC 4253中定义的消息编码;步骤2,服务器端接到客户端的SSH_MSG_KEXDH_INIT消息后,首先生成一个Diffie-Hellman算法参数,记作f;然后服务器端根据e和f生成会话密钥,记作Skey;最后发送带有SSH_MSG_KEXDH_REPLY消息编码的消息给客户端并进入步骤3,该消息包含f和服务器端的签名信息;其中SSH_MSG_KEXDH_REPLY是RFC 4253中定义的消息编码;步骤3,服务器端对Skey进行SHA-1哈希运算,结果记为h_Skey,然后利用安全芯片(TPM)中的<img file="FSB00001013699500011.GIF" wi="153" he="79" />对字符串PCR<sup>s</sup>||h_Skey进行签名,签名结果记作sign<sup>s</sup>,并用Skey作为对称加密密钥,对SML<sup>s</sup>加密,结果记为Senc;最后发送带有SSH_MSG_RA_INIT消息编码的消息给客户端,该消息包含Senc、sign<sup>s</sup>、<img file="FSB00001013699500012.GIF" wi="237" he="120" />其中PCR<sup>s</sup>是安全芯片TPM中代表服务器端平台信息的平台配置寄存器(PCR)内容,||代表将两个字符串连接起来,<img file="FSB00001013699500013.GIF" wi="169" he="120" />和<img file="FSB00001013699500014.GIF" wi="266" he="166" />分别为服务器端身份证明密钥(AIK)的私钥和公钥证书,SML<sup>s</sup>表示服务器端平台的度量存储日志;步骤4,客户端收到服务器端的SSH_MSG_KEXDH_REPLY消息后,首先验证消息中的签名,如果签名不正确,则终止与服务器端通信;否则客户端也根据e和f生成了会话密钥,记作Ckey;进入步骤5;步骤5,客户端收到服务器端的SSH_MSG_RA_INIT消息后,首先验证<img file="FSB00001013699500021.GIF" wi="227" he="155" />的有效性和合法性,如果验证没通过,则进入步骤6;如果验证通过,则利用<img file="FSB00001013699500022.GIF" wi="181" he="79" />中的公钥<img file="FSB00001013699500023.GIF" wi="194" he="79" />从sign<sup>s</sup>中获得步骤3中的h_Skey和PCR<sup>s</sup>;然后对Ckey进行SHA-1哈希运算,结果记为h_Ckey,并判断h_Ckey和h_Skey是否匹配,如果不匹配,则进入步骤6;如果匹配,则利用Ckey解密Senc得到步骤3中的SML<sup>s</sup>,根据SML<sup>s</sup>重构服务器端的整个完整性度量过程,计算并得到最终值c_PCR<sup>s</sup>,并判断c_PCR<sup>s</sup>与PCR<sup>s</sup>是否匹配,如果不匹配,则进入步骤6;如果匹配,则进入步骤7;其中<img file="FSB00001013699500024.GIF" wi="196" he="85" />为服务器端AIK的公钥;步骤6,客户端发送带有SSH_MSG_RA_ERROR消息编码的消息给服务器端并终止与服务器端通信;步骤7,客户端利用TPM中的<img file="FSB00001013699500025.GIF" wi="152" he="79" />对PCR<sup>c</sup>||h_Ckey进行签名,签名结果记作sign<sup>c</sup>;然后用Ckey作为对称加密密钥,对SML<sup>c</sup>加密,结果记为Cenc;最后发送带有SSH_MSG_RA_INIT消息编码的消息给服务器端,该消息包含Cenc、sign<sup>c</sup>、<img file="FSB00001013699500026.GIF" wi="213" he="80" />其中PCR<sup>c</sup>是安全芯片TPM中代表客户端平台信息的PCR内容,<img file="FSB00001013699500027.GIF" wi="153" he="127" />和<img file="FSB00001013699500028.GIF" wi="183" he="81" />分别为客户端AIK的私钥和公钥证书,SML<sup>c</sup>表示客户端平台的度量存储日志;步骤8,服务器端如果接到客户端带有SSH_MSG_RA_ERROR消息编码的消息,则结束运行;步骤9,服务器端收到客户端的SSH_MSG_RA_INIT消息后,首先验证<img file="FSB00001013699500031.GIF" wi="181" he="104" />的有效性和合法性,如果验证没通过,则进入步骤10,如果验证通过,则利用<img file="FSB00001013699500032.GIF" wi="187" he="143" />中的公钥<img file="FSB00001013699500033.GIF" wi="194" he="112" />从sign<sup>c</sup>中获得步骤7中的h_Ckey和PCR<sup>c</sup>;然后检查h_Ckey和h_Skey是否匹配,如果不匹配,则进入步骤10;如果匹配,则利用Skey解密Cenc得到步骤7中的SML<sup>c</sup>,根据SML<sup>c</sup>重构客户端的整个完整性度量过程,计算并得到最终值c_PCR<sup>c</sup>,并判断c_PCR<sup>c</sup>与PCR<sup>c</sup>是否匹配,如果不匹配,则进入步骤10;如果匹配,则发送带有SSH_MSG_RA_OK消息编码的消息和带有SSH_MSG_NEWKEYS消息编码的消息给客户端,并进入步骤11;其中<img file="FSB00001013699500034.GIF" wi="195" he="105" />为客户端AIK的公钥,SSH_MSG_NEWKEYS是RFC 4253中定义的消息编码;步骤10,服务器端发送带有SSH_MSG_RA_ERROR消息编码的消息给客户端并终止与客户端通信;步骤11,客户端如果接到服务器端带有SSH_MSG_RA_ERROR消息编码的消息后,则结束运行;客户端如果接到服务器端带有SSH_MSG_RA_OK消息编码的消息,则发送带有SSH_MSG_NEWKEYS消息编码的信息给服务器端;步骤12,服务器端和客户端都接收到带有SSH_MSG_NEWKEYS消息编码的消息后,密钥交换过程结束。
地址 100044 北京市海淀区上园村3号