荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: michaelx (我这样可以吗？--睡觉), 信区: Security
标 题: TCP/IP各层的安全性和提高各层安全性的方法
发信站: 荔园晨风BBS站 (Sat Sep 8 14:41:57 2001), 转信
◆ TCP/IP各层的安全性和提高各层安全性的方法
日期：2001-8-13
作者：<>
来源：chinaren
TCP/IP的层次不同提供的安全性也不同，例如，在网络层提供虚拟私用网络，在传输层
提供安全套接服务。下面将分别介绍TCP/IP不同层次的安全性和提高各层安全性的方法
。
一、Internet层的安全性
对Internet层的安全协议进行标准化的想法早就有了。在过去十年里，已经提出了一些
方案。例如，“安全协议3号(SP3)”就是美国国家安全局以及标准技术协会作为“安全
数据网络系统(SDNS)”的一部分而制定的。“网络层安全协议(NLSP)”是由国际标准化
组织为“无连接网络协议(CLNP)”制定的安全协议标准。“集成化NLSP(I-NLSP)”是美
国国家科技研究所提出的包括IP和CLNP在内的统一安全机制。SwIPe是另一个Intenet层
的安全协议，由Ioannidis和Blaze提出并实现原型。所有这些提案的共同点多于不同点
。事实上，他们用的都是IP封装技术。其本质是，纯文本的包被加密，封装在外层的IP
报头里，用来对加密的包进行Internet上的路由选择。到达另一端时，外层的IP报头被
拆开，报文被解密，然后送到收报地点。
Internet工程特遣组(IETF)已经特许Internet协议安全协议(IPSEC)工作组对IP安全协议
(IPSP)和对应的Internet密钥管理协议(IKMP)进行标准化工作。IPSP的主要目的是使需
要安全措施的用户能够使用相应的加密安全体制。该体制不仅能在目前通行的IP(IPv4)
下工作，也能在IP的新版本(IPng或IPv6)下工作。该体制应该是与算法无关的，即使加
密算法替换了，也不对其他部分的实现产生影响。此外，该体制必须能实行多种安全政
策，但要避免给不使用该体制的人造成不利影响。按照这些要求，IPSEC工作组制订了一
个规范：认证头(Authentication Header，AH)和封装安全有效负荷(Encapsulating Se
curity 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)，可能是事先手工发布的。SKIP要求Diffie-Hellm
an证书，其他协议则要求RSA证书。
1996年9月，IPSEC决定采用OAKLEY作为ISAKMP框架下强制推行的密钥管理手段，采用SK
IP作为IPv4和IPv6实现时的优先选择。目前已经有一些厂商实现了合成的 ISAKMP/OAKL
EY方案。Photuris以及类Photuris的协议的基本想法是对每一个会话密钥都采用Diffie
-Hellman密钥交换机制，并随后采用签名交换来确认Diffie--Hellman参数，确保没有“
中间人”进行攻击。这种组合最初是由Diffie、Ooschot和Wiener在一个“站对站(STS)
”的协议中提出的。Photuris里面又添加了一种所谓的“cookie”交换，它可以提供“
清障(anti-logging)”功能，即防范对服务攻击的否认。
Photuris以及类Photuris的协议由于对每一个会话密钥都采用Diffie-Hellman密钥交换
机制，故可提供回传保护(back-traffic protection，BTP)和完整转发安全性(perfect
-forward secrecy，PFS)。实质上，这意味着一旦某个攻击者破解了长效私钥，比如Ph
oturis中的RSA密钥或SKIP中的Diffie-Hellman密钥，所有其他攻击者就可以冒充被破解
的密码的拥有者。但是，攻击者却不一定有本事破解该拥有者过去或未来收发的信息。
值得注意的是，SKIP并不提供BTP和PFS。尽管它采用Diffie-Hellman密钥交换机制，但
交换的进行是隐含的，也就是说，两个实体以证书形式彼此知道对方长效Diffie--Hell
man 公钥，从而隐含地共享一个主密钥。该主密钥可以导出对分组密钥进行加密的密钥
，而分组密钥才真正用来对IP包加密。一旦长效Diffie-Hellman密钥泄露，，则任何在
该密钥保护下的密钥所保护的相应通信都将被破解。而且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或W
indows版本。而在这些系统上实现Internet层安全协议所直接面临的一个问题就是，PC
上相应的实现TCP/IP的公共源码资源什么也没有。为克服这一困难，Wagner和Bellovin
实现了一个IPSEC模块，它象一个设备驱动程序一样工作，完全处于IP层以下。
Internet层安全性的主要优点是它的透明性，也就是说，安全服务的提供不需要应用程
序、其他通信层次和网络部件做任何改动。它的最主要的缺点是: Internet层一般对属
于不同进程和相应条例的包不作区别。对所有去往同一地址的包，它将按照同样的加密
密钥和访问控制策略来处理。这可能导致提供不了所需的功能，也会导致性能下降。针
对面向主机的密钥分配的这些问题，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 Sockets等，
具体做法包括双端实体的认证，数据加密密钥的交换等。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 chi
p上的密钥交换机制的支持。
Netscape通信公司已经向公众推出了SSL的参考实现(称为SSLref)。另一免费的SSL实现
叫做SSLeay。SSLref和SSLeay均可给任何TCP/IP应用提供SSL功能。Internet号码分配当
局(IANA)已经为具备SSL功能的应用分配了固定端口号，例如，带SSL的 HTTP(https)被
分配的端口号为443，带SSL的SMTP(ssmtp)被分配的端口号为465，带SSL的NNTP(snntp)
被分配的端口号为563。
微软推出了SSL2的改进版本称为PCT(私人通信技术)。至少从它使用的记录格式来看，S
SL和PCT是十分相似的。它们的主要差别是它们在版本号字段的最显著位(The Most Sig
nificant 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也是一个政治性的过程，因为它需要多方在一个共同点上达
成信任。不幸的是，历史表明，政治性的过程总是需要时间的，作为一个中间步骤，Ph
il 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和DSS。
目前还没有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国际和微软已经同意联手推出Internet上的安全信用卡交易
服务。他们发布了相应的安全电子交易(SET)协议，其中规定了信用卡持卡人用其信用卡
通过Internet进行付费的方法。这套机制的后台有一个证书颁发的基础结构，提供对X.
509证书的支持。
上面提到的所有这些加安全功能的应用都会面临一个主要的问题，就是每个这样的应用
都要单独进行相应的修改。因此，如果能有一个统一的修改手段，那就好多了。通往这
个方向的一个步骤就是赫尔辛基大学的Tatu Yloenen开发的安全shell(SSH)。SSH允许其
用户安全地登录到远程主机上，执行命令，传输文件。它实现了一个密钥交换协议，以
及主机及客户端认证协议。SSH有当今流行的多种Unix系统平台上的免费版本，也有由D
ata Fellows公司包装上市的商品化版本。
把SSH的思路再往前推进一步，就到了认证和密钥分配系统。本质上，认证和密钥分配系
统提供的是一个应用编程界面(API)，它可以用来为任何网络应用程序提供安全服务，例
如: 认证、数据机密性和完整性、访问控制以及非否认服务。目前已经有一些实用的认
证和密钥分配系统，如: MIT的Kerberos(V4与V5)，IBM的CryptoKnight和Netwrok Secu
rity Program，DEC的SPX，Karlsruhe大学的指数安全系统(TESS)等，都是得到广泛采用
的实例。甚至可以见到对有些认证和密钥分配系统的修改和扩充。例如，SESAME和OSF
DCE对Kerberos V5作了增加访问控制服务的扩充，Yaksha对Kerberos V5作了增加非否认
服务的扩充。
关于认证和密钥分配系统的一个经常遇到的问题是关于它们在Internet上所受到的冷遇
。一个原因是它仍要求对应用本身做出改动。考虑到这一点，对一个认证和密钥分配系
统来说，提供一个标准化的安全API就显得格外重要。能做到这一点，开发人员就不必再
为增加很少的安全功能而对整个应用程序大动手术了。因此，认证系统设计领域内最主
要的进展之一就是制定了标准化的安全API，即通用安全服务API(GSS-API)。GSS-API(v
1及v2)对于一个非安全专家的编程人员来说可能仍显得过于技术化了些，但德州Austin
大学的研究者们开发的安全网络编程(SNP)，把界面做到了比GSS-API更高的层次，使同
网络安全性有关的编程更加方便了。
--
※ 来源:·荔园晨风BBS站 bbs.szu.edu.cn·[FROM: 203.93.19.1]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店