安全外壳传输模型SSHTM构造及性能分析

黄晓巧 汪凯

许昌学院教育技术与信息部 河南 461000

0 前言

SNMP协议三个版本的安全特性：SNMPv1和SNMPv2都是基于团体名的安全检查措施，而团体名在网络中的传输是以明文形式出现的，其安全性根本无法保证；在SNMPv3中加入了基于用户的安全措施USM模型，但因为SNMPv3中的消息摘要算法HMAC-MD5原理已泄露，而且认证是单向的，加密算法DES的密钥长度太短，仅有56位，对于目前的攻击手段来说，完全可以破解，因此其安全性也受到威胁。而网络系统的安全管理又不能小视，所以有必要借助其他的安全协议来加强基于 SNMP网络安全管理。利用 SSH协议安全性加强基于SNMP网络安全管理就不失为一种好的解决办法。

利用SSH协议的安全特性，即它的三个协议：传输层协议、认证协议和连接层协议。传输层协议提供数据机密性、信息完整性等方面的保护；认证协议提供基于公钥的认证；连接协议建立隧道，使信息在隧道内进行安全传输。在SSH的基础上，构造安全外壳传输模型(the Secure Shell Security Model, SSHTM)。

1 建立SSHTM模型的目的

SSHTM利用SSH的安全基础设施，满足网络管理人员对网络安全管理和操作需要，在可操作的环境中最大化其可用性来获取高的成功配置，同时使执行和配置的费用最低，并且使配置的时间最少，保证网络系统正常高效运行。

SSH协议允许服务器与客户端进行双向认证，SNMP就可以利用已认证的标识符在授权策略范围内对数据进行访问。SSHTM利用SSH协议的客户端认证和密钥交换方法来支持不同的安全基础设施，并提供不同的安全属性。SSHTM使用的SSH用户认证方法包括：公钥、口令、基于主机、键盘交互、使用MIC的GSSAPI、密钥交换GSSAPI、GSSAPI、扩展密钥交换和不认证等等方法，其中不认证方法是不推荐使用的。通过使用公钥，或者基于主机认证，或者使用口令认证方法来支持本地账户，口令方式允许综合配置口令基础设施，例如作为AAA服务器使用RADIUS协议。SSHTM还为将来用户认证方法留有余地，这也是充分发挥SSH协议的安全特性。

现在有许多 Internet安全协议和机制在广泛地使用，它们中的大多数都试图为不同的应用层协议提供通用的基础设施，而SSHTM建立就是起一个杠杆的作用。SSHTM是对SNMPv3安全管理、命令行接口(Command Line Interface，CLI)和其它管理接口的统一。

2 SSHTM模型的构造

2.1 SNMP实体结构扩展

建立SSHTM模型不会对SSH和低层的协议有影响，它只是对 RFC3411框架的一个扩展，如图 1所示，对现有的SNMP协议也无影响。这种扩展允许通过SSHTM由扩展协议SSH连接到SNMP引擎提供安全服务。

本文由河南省教育厅自然科学基金(2010B520027)项目资助。

图1 扩展的SNMP实体

在图 1中，在原有的 SNMP实体的基础上，在 SNMP引擎部分新增加了传输子系统，在安全子系统中新增加了TMSM安全传输模型。RFC3417中定义的传输映射不提供低层的安全功能，也不提供特定的传输安全参数，本文通过定义扩展的SNMP实体框架修改了RFC3411和RFC3417，传输映射使用抽象服务接口(Abstract Service Interface, ASI)把特定传输安全参数传递给其它的子系统，包括特定的传输安全参数转换成独立于传输的安全名和安全级别。SSHTM 利用传输子系统。

2.2 SSHTM模型的构造

安全外壳安全传输模型SSHTM由两部分构造而成：传输映射安全处理器(the Transport Mapping Security Processor，TMSP)和安全模型安全处理器(the Security Model Security Processor, SMSP)构成(如图 2 所示)。

图2 SSHTM构成

TMSP是传输调度器的一部分，它负责执行实际的安全处理。

SMSP在安全处理子系统内，它负责识别需要的合适的安全模型。它还必须与TMSP交互合作，才能提供需要的安全服务。

传输映射安全处理器TMSP是从一个SNMP引擎调度器的传输映射起作用的过程到执行传输安全参数到/从独立安全模型参数转换的过程中被调用的。TMSP附加的安全功能执行是由安全模型安全处理器SMSP来完成。

TMSP与SMSP之间必须进行信息的交换，在TMSP和SMSP之间使用缓存，在缓存中传递信息，修改MIB模块。这种方式是处理速度快，简单，也是最有效的方式。TMSP与 SMSP之间进行信息传递的主要部分是传输映射状态参考tmStateReference，与RFC3412中定义的securityStateReference相似。TMSP为SSHTM模型提供部分安全功能，而另一部安全功能由SMSP来完成，TMSP与SMSP之间要进行协调。例如，TMSP提供加密、数据完整性、认证以及授权策略的找回，或者是这些属性的子集，这些都依赖于传输机制中可用的属性。

3 SSHTM模型安全功能

3.1 SSHTM模型提供的安全保护

SSHTM针对RFC3411中定义的主要威胁和次要威胁，提供如下的安全保护：

（1）消息流修改：SSH确保每个接收到的消息在网络中传输未被修改，由SSH加密隧道完成。

（2）信息修改：SSH确保每个接收到消息的内容在网络传输过程中未被修改，数据在没有被授权的情况下遭到篡改或破坏，与不是故意修改的情况相比，数据序列号在很大程度上不会被改变。由SSH加密隧道完成。

（3）假冒：SSH提供SSH服务器身份的确认以及SSH客户端身份的确认，确保客户端发出的信息是由自己产生的，而不会抵赖。SSH服务器身份确认是通过SSH传输层协议服务器认证来完成的。

（4）用户身份的确认对使用SNMP访问控制子系统来说是很重要的，以确保只有授权的用户才能访问敏感数据。SSH用户身份被映射到一个SNMP模型独立的安全名上。

（5）SSH服务器与客户端相互认证确保真实的SNMP引擎提供MIB数据，无论这个SNMP引擎是驻留在服务器端或是客户端。操作者或管理应用程序要对接收到的数据进行处理(例如，对一个操作者升起一个警告，对发送Trap操作的设备进行配置修改，修改网络中其它设备的配置等等)，对MIB数据的提供者是经过认证的，这一点很重要。

（6）泄露：SSHTM模型提供对接收到SNMP消息的内容不被泄露给未授权用户的保护。

（7）重放：SSH确保SSH会话开始创建的与SSH会话状态中存储的加密密钥对于每一个会话都产生新的会话密钥，密钥不会重复，这是由SSH中Diffie-Hellman密钥算法来实现的。这些密钥是用来认证和加密数据用的，以防止会话中遭遇重放攻击。另外，在一次会话中，SSH使用序列号信息来阻止重放和消息重组攻击。

除了以上的保护外，SSHTM 还提供数据完整性检查，防止SNMP消息延迟和重定向。另外，SSH本身还能堤防中间人攻击、IP连接劫持等，SSHTM模型同样具有这样的防范能力。

3.2 消息认证安全

RFC3411体系结构定义了SNMP可以识别的三种安全级别：不认证不加密(noAuthNoPriv)、认证但不加密(authNoPriv)和认证且加密(authPriv)。SSH协议提供对加密和数据完整性的支持，而技术上可能支持不认证不加密，但在SSHTM模型中不推荐使用。

SSHTM模型从SSH_MSG_USERAUTH_SUCCESS数据包中获得已认证的用户身份，以及与SNMP引擎接收到消息相关联的消息类型和传输地址，它还将这些信息提供给SNMP引擎请求的消息。SSHTM模型充分信任低层的SSH连接已经正确配置以支持authPriv特性。SSHTM传输模型对算法或者打开SSH会话匹配不同安全级别选项不了解，为了信任间相互可操作，就假定在 SNMP引擎之间，一个 SSH传输模型兼容执行必须使用SSH连接提供认证、数据完整性和加密服务，以此达到SNMP安全的最高级别authPriv。对于由SNMP应用程序请求发送出去的消息，如果指定的安全级别是noAuthNoPriv或者是authNoPriv，则SSHTM传输模型就会以SNMP最高级别authPriv对待。

3.3 认证协议安全

SSHTM传输模型支持任何的服务器或客户端认证机制，这种机制是由SSH支持提供的，包括认证方法有：公钥、口令、基于主机和键盘交互。

基于口令认证机制为了完整性允许使用配置口令基础设施，可以把一个口令交给一个提供认证服务的服务器，如RADIUS，Diameter，以得到认证，这种认证也是使用用户名和用户口令属性得到的。也可以使用不同的口令确认协议，如CHAP或者消息摘要认证，与RADIUS或Diameter结合提供身份认证。不过，这些机制要求的口令都是明文进行传输的，其安全性得不到保证。

通用安全服务(Generic Security Service, GSS)密钥交换为附加客户端认证机制提供了一种框架，以支持不同的安全基础设施，并提供不同的安全属性，附加的认证机制如支持X.509认证证书，此项已添加到SSH2中。

4 SSHTM模型的性能

4.1 会话建立

表1给出了在不同的传输层协议 TCP和 UDP上执行snmpget请求操作的结果。从该表中可以看出SSH会话的建立需要的花费(时间、数据大小和数据包数量)是很大的，这是因为SSH协议在进行认证和SSH连接建立之前建立会话密钥要用到 Diffie-Hellman算法进行密钥交换。因为加密操作是CPU绑定的，因此会话建立所花费的时间在CPU速度比较慢的机器上增长更快。

表1 snmpget操作数据表

表1同样也反映出在不同的传输层，数据大小和数据包数量有明显的不同：在TCP上使用的数据量普遍比UDP高很多。这是因为TCP连接的使用需要花销，连接建立和拆卸都需要额外的网络流量，而且，在下面的操作系统网络层还要保持开放的连接绑定资源。不过，对于网络带宽日益增加的前提下，这样的花销也就算不了什么，而且这种开始建立会话的花销还可以由后继的SNMP安全操作来抵消。

4.2 SSHTM安全模型的安全性能

SSHTM模型的安全性是通过与SNMPv3/USM安全性进行比较得到的。

（1）短操作安全性

短操作主要是通过 snmpget操作进行的。snmpget操作在不同安全级别下时间表如2所示，单位：ms。

表2 snmpget操作时间表

（2）长操作安全性

长操作安全性是通过snmpwalk操作进行的。snmpwalk操作在不同安全级别下时间对比如表3所示，单位：ms。

从表2的snmpget操作时间与表3 snmpwalk操作时间来看，无论安全级别是noAhthnoPriv，或是AuthNoPriv，或还是AuthPriv，TCP协议下的操作时间都要大于UDP，这是因为TCP数据包的包头比UDP数据报的包头要大，这就造成了 SNMP实体在处理 SNMP消息时花费的时间就长。而SSHTM模型下的SNMP操作，即snmpv2c/SSH，snmpv3/SSH操作在没有安全级别时(noAuthnoPriv)，所要用到的时间比snmpv3/UDP/USM snmpv3/TCP/USM都大，这是因为SSH会话建立要进行密钥交换造成的，但随着安全级别的增强，SSHTM模型下的SNMP消息所需要的操作时间明显降低了，其优点显现出来了。这是因为SSH协议数据包头增加了一个很小的头部，这个很小的头部相对SNMPv3/USM的头部所占用的空间要小得多。因此可以说，在相同的安全级别下，SSHTM模型比SNMPv3/USM的安全性能要好一些。

5 总结

通过构造安全外壳传输模型 SSHTM，增强了网络管理安全性，对安全模型SSHTM的性能分析得知，SSHTM模型在会话建立阶段因为要进行密钥交换用时相对来说要长一些，但随着时间的推移这种时间上的多余可以由后面的操作来弥补。SSHTM模型比SNMPv3/USM的安全性能要好一些，对于目前安全性要求较高的网络管理来说无疑是一种好的解决办法。

[1]M. Schoffstall, J. Davin Simple Network Management Protocol(SNMP)[S].RFC1157.1990.

[2]M. Rose, S. Waldbusser Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)[S].RFC1905.1996.

[3]Presuhn.R McCloghrie.K User-based Security Model (USM)for version 3 of the Simple Network Management Protocol(SNMPv3) [S].RFC3414.2002.

[4]Krawczyk,H.,Bellare,M.,and R.Canetti,HMAC:Keyed-Hashing for Message Authentication[S].RFC2104.1997.

[5]冯登国,裴定一.密码学导引[M].北京:科学出版社.1999.

[6]Ylonen, T. and C. Lonvick, Ed. The Secure Shell (SSH) Protocol Architecture[S].RFC4251.2006.

[7]C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol[S],RFC4253.2006.

[8]C. Lonvick,The Secure Shell (SSH) Authentication Protocol[S].RFC4252.2006.

[9]C. Lonvick, The Secure Shell (SSH) Connection Protocol[S].RFC4254.2006.

[10]http://www.ietf.org/ietf/1id-abstracts.txt.

[11]J. Salowey, J. Galbraith, V. Welch Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol[S].RFC4462.2006.

[12]W.Simpson,S.Willens,Remote Authentication Dial In User Service(RADIUS) [S].RFC2138.1997.

[13]Pat R.Calhoun,John Loughney,Jari Arkko,Erik Guttman,Glen Zorn Diameter Base Protocol[S].RFC3588.2003.

[14]J. Hutzelman, Generic Security Service Application[S].RFC4462.2006.