TCP/IP协议基础之四（TCP/IP的安全性）

TCP/IP的层次不同供给的安全性也不同，例如，在网络层供给虚拟私用网络，在传输层供给安全套接服务。下面将分辨介绍TCP/IP不同层次的安全性和进步各层安全性的方法。

　　一、Internet层的安全性

　　对Internet层的安全协议进行标准化的想法早就有了。在过去十年里，已经提出 了一些方案。例如，“安全协议3号(SP3)”就是美国国家安全局以及标准技术协 会作为“安全数据网络系统(SDNS)”的一部分而制定的。“网络层安全协议(NLS P)”是由国际标准化组织为“无连接网络协议(CLNP)”制定的安全协议标准。 “集成化NLSP(I-NLSP)”是美国国家科技研究所提出的包含IP和CLNP在内的统一 安全机制。SwIPe是另一个Intenet层的安全协议，由Ioannidis和Blaze提出并实 现原型。所有这些提案的共同点多于不同点。事实上，他们用的都是IP封装技术。 其本质是，纯文本的包被加密，封装在外层的IP报头里，用来对加密的包进行In ternet上的路由选择。达到另一端时，外层的IP报头被拆开，报文被解密，然后 送到收报地点。

　　Internet工程特遣组(IETF)已经特许Internet协议安全协议(IPSEC)工作组对IP安 全协议(IPSP)和对应的Internet密钥管理协议(IKMP)进行标准化工作。IPSP的主 要目标是使需要安全措施的用户能够利用相应的加密安全部制。该体制不仅能在 目前通行的IP(IPv4)下工作，也能在IP的新版本(IPng或IPv6)下工作。该体制应 该是与算法无关的，即使加密算法调换了，也不对其他部分的实现产生影响。此 外，该体制必须能履行多种安全政策，但要避免给不利用该体制的人造成不利影 响。按照这些恳求，IPSEC工作组制定了一个规范：认证头(Authentication Hea der，AH)和封装安全有效负荷(Encapsulating Security Payload，ESP)。简言之， AH供给IP包的真实性和完整性，ESP供给机要内容。

　　IP AH指一段消息认证代码(Message Authentication Code，MAC)，在发送IP包之 前，它已经被事先计算好。发送方用一个加密密钥算出AH，吸收方用同一或另一 密钥对之进行验证。如果收发双方利用的是单钥体制，那它们就利用同一密钥； 如果收发双方利用的是公钥体制，那它们就利用不同的密钥。在后一种情况，AH 体制能额外地供给不可否定的服务。事实上，有些在传输中可变的域，如IPv4中 的time-to-live域或IPv6中的hop limit域，都是在AH的计算中必须疏忽不计的。 RFC 1828首次规定了加封状态下AH的计算和验证中要采用带密钥的MD5算法。而与 此同时，MD5和加封状态都被批评为加密强度太弱，并有调换的方案提出。

　　IP ESP的基础想法是全部IP包进行封装，或者只对ESP内上层协议的数据(运输状 态)进行封装，并对ESP的绝大部分数据进行加密。在管道状态下，为当前已加密 的ESP附加了一个新的IP头(纯文本)，它可以用来对IP包在Internet上作路由选择。 吸收方把这个IP头取掉，再对ESP进行解密，处理并取掉ESP头，再对本来的IP包 或更高层协议的数据就象普通的IP包那样进行处理。RFC 1827中对ESP的格式作了 规定，RFC 1829中规定了在密码块链接(CBC)状态下ESP加密和解密要利用数据加 密标准(DES)。虽然其他算法和状态也是可以利用的，但一些国家对此类产品的进 出口把持也是不能不考虑的因素。有些国家甚至连私用加密都要限制。

　　AH与ESP体制可以合用，也可以分用。不管怎么用，都逃不脱传输分析的攻击。人 们不太明确在Internet层上，是否真有经济有效的反抗传输分析的手段，但是在 Internet用户里，真正把传输分析当回事儿的也是寥寥无几。

　　1995年8月，Internet工程领导小组(IESG)批准了有关IPSP的RFC作为Internet标 准系列的推荐标准。除RFC 1828和RFC 1829外，还有两个实验性的RFC文件，规定 了在AH和ESP体制中，用安全散列算法(SHA)来代替MD5(RFC 1852)和用三元DES代 替DES(RFC 1851)。

　　在最简略的情况下，IPSP用手工来配置密钥。然而，当IPSP大规模发展的时候，就需要在Internet上建立标准化的密钥管理协议。这个密钥管理协议按照IPSP安全条例的恳求，指定管理密钥的方法。
　　因此，IPSEC工作组也负责进行Internet密钥管理协议(IKMP)，其他若干协议的标准化工作也已经提上日程。其中最重要的有：

IBM 提出的“标准密钥管理协议(MKMP)”
SUN 提出的“Internet协议的简略密钥管理(SKIP)”
Phil Karn 提出的“Photuris密钥管理协议”
Hugo Krawczik 提出的“安全密钥交换机制(SKEME)”
NSA 提出的“Internet安全条例及密钥管理协议”
Hilarie Orman 提出的“OAKLEY密钥决定协议”

　　在这里需要再次强调指出，这些协议草案的类似点多于不同点。除MKMP外，它们都恳求一个既存的、完整可操作的公钥基础设施(PKI)。MKMP没有这个恳求，因为它假定双方已经共同知道一个主密钥(Master Key)，可能是事先手工发布的。SK IP恳求Diffie-Hellman证书，其他协议则恳求RSA证书。

　　1996年9月，IPSEC决定采用OAKLEY作为ISAKMP框架下强制推行的密钥管理手段， 采用SKIP作为IPv4和IPv6实现时的优先选择。目前已经有一些厂商实现了合成的 ISAKMP/OAKLEY方案。

　　Photuris以及类Photuris的协议的基础想法是对每一个会 话密钥都采用Diffie-Hellman密钥交换机制，并随后采用签名交换来确认Diffie --Hellman参数，确保没有“中间人”进行攻击。这种组合最初是由Diffie、Oos chot和Wiener在一个“站对站(STS)”的协议中提出的。Photuris里面又添加了一 种所谓的“cookie”交换，它可以供给“清障(anti-logging)”功效，即戒备对 服务攻击的否定。 Photuris以及类Photuris的协议由于对每一个会话密钥都采用Diffie-Hellman密 钥交换机制，故可供给回传掩护(back-traffic protection，BTP)和完整转发安 全性(perfect-forward secrecy，PFS)。本质上，这意味着一旦某个攻击者破解 了长效私钥，比如Photuris中的RSA密钥或SKIP中的Diffie-Hellman密钥，所有其 他攻击者就可以冒充被破解的密码的拥有者。但是，攻击者却不必定有本事破解 该拥有者过去或未来收发的信息。

　　值得注意的是，SKIP并不供给BTP和PFS。尽管它采用Diffie-Hellman密钥交换机 制，但交换的进行是隐含的，也就是说，两个实体以证书情势彼此知道对方长效 Diffie--Hellman 公钥，从而隐含地共享一个主密钥。该主密钥可以导出对分组 密钥进行加密的密钥，而分组密钥才真正用来对IP包加密。一旦长效Diffie-Hel lman密钥泄漏，，则任何在该密钥掩护下的密钥所掩护的相应通信都将被破解。 而且SKIP是无状态的，它不以安全条例为基础。每个IP包可能是个别地进行加密 和解密的，归根到底用的是不同的密钥。

　　SKIP不供给BTP和PFS这件事曾经引起IPSEC工作组内部的批评，该协议也曾进行过 扩充，试图供给BTP和PFS。但是，扩充后的SKIP协议版本其实是在BTP和PFS功效 的供给该协议的无状态性之间的某种折衷。实际上，增长了BTP和PFS功效的SKIP 非常类似于Photuris以及类Photuris的协议，唯一的重要差别是SKIP(仍然)需要 本来的Diffie-Hellman证书。这一点必须注意:目前在Internet上，RSA证书比其 他证书更容易实现和开展业务。

　　大多数IPSP及其相应的密钥管理协议的实现均基于Unix系统。任何IPSP的实现都 必须跟对应协议栈的源码纠缠在一起，而这源码又能在Unix系统上利用，其原因 大概就在于此。但是，如果要想在Internet上更广泛地利用和采用安全协议，就 必须有相应的DOS或Windows版本。而在这些系统上实现Internet层安全协议所直 接面临的一个问题就是，PC上相应的实现TCP/IP的公共源码资源什么也没有。为 克服这一艰苦，Wagner和Bellovin实现了一个IPSEC模块，它象一个设备驱动程序 一样工作，完整处于IP层以下。

　　Internet层安全性的重要优点是它的透明性，也就是说，安全服务的供给不需要 利用程序、其他通信层次和网络部件做任何修正。它的最重要的弊病是: Intern et层一般对属于不同过程和相应条例的包不作差别。对所有去往同一地址的包， 它将按照同样的加密密钥和访问把持策略来处理。这可能导致供给不了所需的功 能，也会导致性能降落。针对面向主机的密钥分配的这些问题，RFC 1825容许(甚 至可以说是推荐) 利用面向用户的密钥分配，其中，不同的连接会得到不同的加 密密钥。但是，面向用户的密钥分配需要对相应的操作系统内核作比较大的修正。

　　虽然IPSP的规范已经基础制定完毕，但密钥管理的情况千变万化，要做的工作还 很多。尚未引起足够器重的一个重要的问题是在多播 (multicast)环境下的密钥 分配问题，例如，在Internet多播骨干网(MBone)或IPv6网中的密钥分配问题。

　　简而言之，Internet层是非常合适供给基于主机对主机的安全服务的。相应的安 全协议可以用来在Internet上建立安全的IP通道和虚拟私有网。例如，利用它对 IP包的加密和解密功效，可以简捷地强化防火墙系统的防卫能力。事实上，许多厂商已经这样做了。RSA数据安全公司已经发起了一个倡议，来推动多家防火墙和 TCP/IP软件厂商联合开发虚拟私有网。该倡议被称为S-WAN(安全广域网)倡议。其 目标是制定和推荐Internet层的安全协议标准。

　　二、传输层的安全性

　　在Internet利用编程序中，通常利用广义的过程间通信(IPC)机制来与不同层次的 安全协议打交道。比较风行的两个IPC编程界面是BSD Sockets和传输层界面(TLI)， 在Unix系统V命令里可以找到。

　　在Internet中供给安全服务的首先一个想法便是强化它的IPC界面，如BSD Socke ts等，具体做法包含双端实体的认证，数据加密密钥的交换等。Netscape通信公 司遵守了这个思路，制定了建立在可靠的传输服务(如TCP/IP所供给)基础上的安 全套接层协议(SSL)。SSL版本3(SSL v3)于1995年12月制定。它重要包含以下两个 协议：

　　SSL记载协议 它涉及利用程序供给的信息的分段、压缩、数据认证和加密。SSL v3供给对数据认证用的MD5和SHA以及数据加密用的R4和DES等的支撑，用来对数据 进行认证和加密的密钥可以通过SSL的握手协议来协商。

　　SSL握手协议 用来交换版本号、加密算法、(相互)身份认证并交换密钥。SSL v3 供给对Deffie-Hellman密钥交换算法、基于RSA的密钥交换机制和另一种实现在 Fortezza chip上的密钥交换机制的支撑。

　　Netscape通信公司已经向大众,推出了SSL的参考实现(称为SSLref)。另一免费的S SL实现叫做SSLeay。SSLref和SSLeay均可给任何TCP/IP利用供给SSL功效。Inter net号码分配当局(IANA)已经为具备SSL功效的利用分配了固定端口号，例如，带 SSL的 HTTP(https)被分配的端口号为443，带SSL的SMTP(ssmtp)被分配的端口号 为465，带SSL的NNTP(snntp)被分配的端口号为563。

　　微软推出了SSL2的改良版本称为PCT(私人通信技术)。至少从它利用的记载格式来 看，SSL和PCT是十分类似的。它们的重要差别是它们在版本号字段的最明显位(T he Most Significant Bit)上的取值有所不同: SSL该位取0，PCT该位取1。这样 区分之后，就可以对这两个协议都给以支撑。

　　1996年4月，IETF授权一个传输层安全(TLS)工作组着手制定一个传输层安全协议 (TLSP)，以便作为标准提案向IESG正式提交。TLSP将会在许多处所酷似SSL。 前面已介绍Internet层安全机制的重要优点是它的透明性，即安全服务的供给不 恳求利用层做任何转变。这对传输层来说是做不到的。原则上，任何TCP/IP利用， 只要利用传输层安全协议，比如说SSL或PCT，就必定要进行若干修正以增长相应 的功效，并利用(稍微)不同的IPC界面。于是，传输层安全机制的重要弊病就是要 对传输层IPC界面和利用程序两端都进行修正。可是，比起Internet层和利用层的 安全机制来，这里的修正还是相当小的。另一个弊病是，基于UDP的通信很难在传 输层建立起安全机制来。同网络层安全机制相比，传输层安全机制的重要优点是 它供给基于过程对过程的(而不是主机对主机的)安全服务。这一成绩如果再加上 利用级的安全服务，就可以再向前跨越一大步了。

　　三、利用层的安全性

　　必须牢记(且须仔细品味): 网络层(传输层)的安全协议容许为主机(过程)之间的 数据通道增长安全属性。本质上，这意味着真正的(或许再加上机密的)数据通道 还是建立在主机(或过程)之间，但却不可能区分在同一通道上传输的一个具体文 件的安全性恳求。比如说，如果一个主机与另一个主机之间建立起一条安全的IP 通道，那么所有在这条通道上传输的IP包就都要主动地被加密。同样，如果一个 过程和另一个过程之间通过传输层安全协议建立起了一条安全的数据通道，那么 两个过程间传输的所有消息就都要主动地被加密。

　　如果确实想要区分一个具体文件的不同的安全性恳求，那就必须借助于利用层的 安全性。供给给用层的安全服务实际上是最机动的处理单个文件安全性的手段。 例如一个电子邮件系统可能需要对要发出的信件的个别段落履行数据签名。较低 层的协议供给的安全功效一般不会知道任何要发出的信件的段落结构，从而不可 能知道该对哪一部分进行签名。只有利用层是唯一能够供给这种安全服务的层次。

　　一般来说，在利用层供给安全服务有几种可能的做法，第一个想到的做法大概就 是对每个利用(及利用协议)分辨进行修正。一些重要的TCP/IP利用已经这样做了。 在RFC 1421至1424中，IETF规定了私用强化邮件(PEM)来为基于SMTP的电子邮件系 统供给安全服务。由于种种理由，Internet业界采用PEM的步子还是太慢，一个主 要的原因是PEM依附于一个既存的、完整可操作的PKI(公钥基础结构)。PEM PKI是 按层次组织的，由下述三个层次构成:

　　顶层为Internet安全政策登记机构(IPRA)
　　次层为安全政策证书颁发机构(PCA)
　　底层为证书颁发机构(CA)

　　建立一个符合PEM规范的PKI也是一个政治性的过程，因为它需要多方在一个共同 点上达成信任。不幸的是，历史表明，政治性的过程总是需要时间的，作为一个 中间步骤，Phil Zimmermann开发了一个软件包，叫做PGP(pretty Good Privacy)。 PGP符合PEM的绝大多数规范，但不必恳求PKI的存在。相反，它采用了散布式的信 任模型，即由每个用户自己决定该信任哪些其他用户。因此，PGP不是去推广一个 全局的PKI，而是让用户自己建立自己的信任之网。这就立刻产生一个问题，就是 散布式的信任模型下，密钥破除了怎么办。

　　S-HTTP是Web上利用的超文本传输协议(HTTP)的安全加强版本，由企业集成技术公 司设计。S-HTTP供给了文件级的安全机制，因此每个文件都可以被设成私人/签字 状态。用作加密及签名的算法可以由参与通信的收发双方协商。S-HTTP供给了对 多种单向散列(Hash)函数的支撑，如: MD2，MD5及SHA; 对多种单钥体制的支撑， 如：DES，三元DES，RC2，RC4，以及CDMF; 对数字签名体制的支撑，如: RSA和D SS。

　　目前还没有Web安全性的公认标准。这样的标准只能由WWW Consortium，IETF或其 他有关的标准化组织来制定。而正式的标准化过程是漫长的，可能要拖上好几年， 直到所有的标准化组织都充分认识到Web安全的重要性。S-HTTP和SSL是从不同角 度供给Web的安全性的。S-HTTP对单个文件作“私人/签字”之区分，而SSL则把参 与通信的相应过程之间的数据通道按“私用”和“已认证”进行监管。Terisa公 司的SecureWeb工具软件包可以用来为任何Web利用供给安全功效。该工具软件包 供给有 RSA数据安全公司的加密算法库，并供给对SSL和S-HTTP的全面支撑。

　　另一个重要的利用是电子商务，尤其是信用卡交易。为使Internet上的信用卡交 易安全起见，MasterCard公司(同IBM，Netscape，GTE和Cybercash一道) 制定了 安全电子付费协议(SEPP)，Visa国际公司和微软(和其他一些公司一道)制定了安 全交易技术(STT)协议。同时，MasterCard，Visa国际和微软已经批准联手推出I nternet上的安全信用卡交易服务。他们发布了相应的安全电子交易(SET)协议， 其中规定了信用卡持卡人用其信用卡通过Internet进行付费的方法。这套机制的 后台有一个证书颁发的基础结构，供给对X.509证书的支撑。

　　上面提到的所有这些加安全功效的利用都会见临一个重要的问题，就是每个这样 的利用都要单独进行相应的修正。因此，如果能有一个统一的修正手段，那就好 多了。通往这个方向的一个步骤就是赫尔辛基大学的Tatu Yloenen开发的安全sh ell(SSH)。SSH容许其用户安全地登录到远程主机上，履行命令，传输文件。它实 现了一个密钥交换协议，以及主机及客户端认证协议。SSH有当今风行的多种Uni x系统平台上的免费版本，也有由Data Fellows公司包装上市的商品化版本。

　　把SSH的思路再往前推动一步，就到了认证和密钥分配系统。本质上，认证和密钥 分配系统供给的是一个利用编程界面(API)，它可以用来为任何网络利用程序供给 安全服务，例如: 认证、数据机密性和完整性、访问把持以及非否定服务。目前 已经有一些实用的认证和密钥分配系统，如: MIT的Kerberos(V4与V5)，IBM的Cr yptoKnight和Netwrok Security Program，DEC的SPX，Karlsruhe大学的指数安全 系统(TESS)等，都是得到广泛采用的实例。甚至可以见到对有些认证和密钥分配 系统的修正和扩充。例如，SESAME和OSF DCE对Kerberos V5作了增长访问把持服 务的扩充，Yaksha对Kerberos V5作了增长非否定服务的扩充。

　　关于认证和密钥分配系统的一个经常遇到的问题是关于它们在Internet上所受到 的冷遇。一个原因是它仍恳求对利用本身做出修正。考虑到这一点，对一个认证 和密钥分配系统来说，供给一个标准化的安全API就显得格外重要。能做到这一点， 开发人员就不必再为增长很少的安全功效而对全部利用程序大动手术了。因此， 认证系统设计领域内最重要的进展之一就是制定了标准化的安全API，即通用安全 服务API(GSS-API)。GSS-API(v1及v2)对于一个非安全专家的编程人员来说可能仍 显得过于技术化了些，但德州Austin大学的研究者们开发的安全网络编程(SNP)， 把界面做到了比GSS-API更高的层次，使同网络安全性有关的编程更加方便了。