TCP/IP完整的一套基础介绍(三)
TCP/IP完整的一套基础介绍(三)
三、应用层的安全性
必须牢记(且须仔细品味): 网络层(传输层)的安全协议允许为主机(进程)之间的数据通道增加安全属性。本质上，这意味着真正的(或许再加上机密的)数据通道还是建立在主机(或进程)之间，但却不可能区分在同一通道上传输的一个具体文件的安全性要求。比如说，如果一个主机与另一个主机之间建立起一条安全的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和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系统平台上的免费版本，也有由Data Fellows公司包装上市的商品化版本。
把SSH的思路再往前推进一步，就到了认证和密钥分配系统。本质上，认证和密钥分配系统提供的是一个应用编程界面(API)，它可以用来为任何网络应用程序提供安全服务，例如: 认证、数据机密性和完整性、访问控制以及非否认服务。目前已经有一些实用的认证和密钥分配系统，如: MIT的Kerberos(V4与V5)，IBM的CryptoKnight和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更高的层次，使同网络安全性有关的编程更加方便了。
三、应用层的安全性
必须牢记(且须仔细品味): 网络层(传输层)的安全协议允许为主机(进程)之间的数据通道增加安全属性。本质上，这意味着真正的(或许再加上机密的)数据通道还是建立在主机(或进程)之间，但却不可能区分在同一通道上传输的一个具体文件的安全性要求。比如说，如果一个主机与另一个主机之间建立起一条安全的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和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系统平台上的免费版本，也有由Data Fellows公司包装上市的商品化版本。
把SSH的思路再往前推进一步，就到了认证和密钥分配系统。本质上，认证和密钥分配系统提供的是一个应用编程界面(API)，它可以用来为任何网络应用程序提供安全服务，例如: 认证、数据机密性和完整性、访问控制以及非否认服务。目前已经有一些实用的认证和密钥分配系统，如: MIT的Kerberos(V4与V5)，IBM的CryptoKnight和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更高的层次，使同网络安全性有关的编程更加方便了。