《网络信息安全》课件第4章

第4章密码技术应用4.1IPSec4.2SSL4.3S-HTTP4.4SMIME4.5SET

4.6PGP习题

4.1IPSec

1.IPSec概述传统的TCP/IP协议，IP数据包在传输过程中并没有过多的安全需求，人们很容易伪造IP地址，篡改数据包内容，重放以前的包并在传输途中截获并查看包内信息。因此不能保证自己收到的数据包来自正确的发送端，不能肯定数据是发送端的原始数据，也不能防止原始数据在传输过程中未被窃听，所以本质上说这种协议是不安全的。为了有效保护IP数据包的安全，IPSec应运而生，它随着Ipv6的制定而产生，鉴于Ipv4应用的广泛性，IPSec也提供对Ipv4的支持，不过在Ipv6中它是必须支持的，而在Ipv4中是可选的。

图4-1IPSec结构框架

2．IPSec的结构

(1)AH为IP数据包提供3种服务，即无连接的数据完整性验证、数据源身份认证和防重放攻击。数据完整性验证通过哈希函数产生的校验来保证；数据源身份认证通过在计算验证码时加入一个共享密钥来实现；AH报头中的序列号可以防止重放攻击。

(2)ESP除了为IP数据包提供AH已有的3种服务外，还提供另外两种服务，即数据包加密、数据流加密。加密是ESP的基本功能，而数据源身份认证、数据完整性验证以及防重放攻击都是可选的。数据包加密是指对一个IP包进行加密，可以是对整个IP包，也可以只加密IP包的负荷部分，一般用于客户端计算机；数据源加密一般用于支持IPSec的路由器，源端路由器并不关心IP包的内容，对整个IP包进行加密后传输，目的端路由器将该包解密后把原始包继续转发。在实际进行IP通信中，可以根据实际安全需求同时使用这两种协议或选择其中的一种。AH和ESP都可以提供验证服务，不过，AH提供的验证服务要强于ESP。

(3)IKE协议负责密钥管理，定义了通信实体间进行身份认证、协商加密算法以及生成共享的会话密钥的方法。IKE将密钥协商的结果保留在安全联盟(SA)中，供AH和ESP以后通信时使用。最后，解释域(DOI)为使用IKE进行协商SA的协议统一分配标识符。共享一个DOI的协议从一个共同的命名空间中选择安全协议和变换、共享密码以及交互协议的标识等，DOI将IPSec的这些RFC文档联系到一起。

3．IPSec的运行模式

IPSec有两种运行模式，即传输模式(TransportMode)和隧道模式(TunnelMode)。这两种模式的主要区别是它们所保护的内容不同，传输模式保护的只是IP的有效负载，而隧道模式保护的是整个IP数据包。AH和ESP都支持这两种模式，共存在四种形式，即AH传输模式、ESP传输模式、AH隧道模式、ESP隧道模式。这些传输模式如图4-2所示。

图4-2IPSec传输模式(a)AH传输模式；(b)AH隧道模式；(c)ESP传输模式；(d)ESP隧道模式

1)AH传输模式在该模式中，AH被插入到IP头部之后，在传输层协议(如TCP、UDP)或者其他IPSec协议之前。因为AH验证的区域覆盖整个IP包，包括IP包头部，所以源/目的IP地址是不能修改的，否则会被检测出来。如果数据包在传送过程中经过网络地址转换(NAT，NetworkAddressTranslation)网关，其源/目的IP地址将发生改变，会造成到达目的地址后的完整性验证识别失败。因此，AH在传输模式下和NAT是冲突的，不能同时使用。或者说AH不能穿越NAT。

2)AH隧道模式在该模式中，AH插入到原始IP头部字段之前，再在AH之前增加一个新的IP头部。在隧道模式下，AH验证的区域也将覆盖整个IP包，所以也存在AH与NAT的冲突。

3)ESP传输模式在该模式中，ESP插入到IP头部之后，

ESP头部包含SPI和序列号字段，ESP尾部包含填充、填充长度和下一个头字段。在接收端，SPI字段用于和源IP地址、IPSec协议一起组成一个三元组来惟一确定一个SA，并利用该SA进行验证、解密，然后等待后续处理，所以SPI不能被加密。其次，序列号字段用于判断包是否重复，从而防止重发攻击。序列号不会泄漏明文中的任何机密，所以也没有必要进行加密。其尾部使用了ESP验证，因为SA需要ESP的验证服务，接收端会在任何后续处理(如检查重放、解密)之前进行验证。数据包只有经过验证该包没有经过任何修改，才会被确认为可信任的，才会进行候选处理。

4)ESP隧道模式在该模式中，ESP插入到IP头部之前，在ESP之前再插入新的IP头部。与传输模式一样，ESP头部含有SPI和序列号字段，ESP尾部包含填充、填充长度和下一个头字段。如果选用了验证，ESP的验证数据字段中包含了验证数据。同样ESP头部和ESP验证数据字段不会被加密。内部的IP头部被加密和验证，而外部的IP头部既没有被加密也没有被验证，不被加密是因为路由器需要这些信息为其寻找路由，不被验证是为了能适应NAT等情形。

4.2SSL

1．SSL概述

SSL(SecureSocketLayer)是由Netscape公司开发的，用于提供Internet通信的安全协议，目前已经广泛用于Web浏览器与服务器之间的身份认证和加密数据传输。SSL协议位于网络层协议(如TCP/IP)与各种应用层协议(如HTTP等)之间，如图4-3所示。在发送端，SSL层接收应用层的数据，然后将加了密的数据发往TCP端口。在接收端，SSL从TCP端口读取数据，解密后将数据交给应用层。所以它为客户端与服务器之间提供安全通信，允许双方相互认证、通过加密提供消息保密。

图4-3SSL在TCP/IP协议栈中的位置

2．SSL的结构

SSL被设计成使用TCP来提供一种可靠的端到端的安全服务。SSL由多个协议组成，并采用两层体系结构，如图4-4所示。

图4-4SSL协议体系结构

SSL中有两个重要的概念(SSL连接和SSL会话)，具体定义如下：

(1)SSL连接：连接是提供恰当类型服务的传输。SSL是一种点对点连接，每次连接与一个会话相联系。

(2)SSL会话：SSL会话是客户与服务器之间的关联，会话通过握手协议来创建。会话定义了一组被多个连接共享的加密安全参数集。会话可以用来避免为每个连接进行昂贵的新安全参数的协商。

3．SSL协议

1)SSL记录协议

SSL协议的底层是记录协议层，SSL记录协议在客户机和服务器之间传输应用数据和SSL控制数据，期间有可能需要进行分段或把多个高层协议数据组合成单个数据单元。图4-5描述了SSL记录协议操作的整个过程。

图4-5SSL记录协议

(1)分段：其中每个分片报文最大不能超过16KB。

(2)压缩：该操作是可选的。目前的版本还没有指定压缩算法，默认的缺省算法为空。压缩必须是无损的，而且增加的内容长度不会超过1024B。

(3)计算MAC码：这一步需要用到客户机与服务器共享的密钥。

(4)加密：使用加密算法对压缩报文和MAC码进行加密。加密对内容长度的增加不可超过1024B。

(5)增加记录协议头部，该头部包含以下几个部分：

*内容类型(8bit)：所封装分段的高层协议类型。*主版本(8bit)：使用SSL协议的主要版本号，对SSLv3值为3。*次版本(8bit)：使用SSL协议的次要版本号，对SSLv3值为0。*压缩长度(16bit)：分段的字节长度，不超过16KB＋2KB。图4-6描述了SSL记录头部格式。

图4-6SSL记录头部格式

2)SSL修改密码规格协议

SSL修改密码规格协议是SSL协议体系中最简单的一个，它由单个报文构成，该报文由值为1的单个字节组成。这个报文的惟一目的是使得未决状态被复制为当前状态，从而改变这个连接将要使用的密码规格。

3)SSL告警协议告警协议通过SSL记录协议把有关警告传送到各个实体。它由两个字节组成，分别表示告警级别和告警信息。其中告警级别有两个：第一是代表警告，表明是一个一般警告信息；第二是代表致命错误，它将终止当前链接，同一个会话的其他链接也许可以继续，但肯定不会再生成新的连接。告警信息则相对较多，它用告警代码标识。例如，0代表close_notify，表示通知接收方发送方已经关闭本链接，不再发任何信息；10代表unexpected_message，表示接收到不合适的报文。

4)SSL握手协议握手协议是SSL中最复杂的部分。这个协议使得服务器与客户机能相互鉴别对方的身份、协商加密和MAC算法以及保护SSL记录中发送数据的加密密钥等。在传输任何应用数据前，都必须使用握手协议。握手协议由一系列在客户端与服务器之间交换的报文组成。所有这些报文具有三个字段：类型(指示10种报文中的一个)、长度(以字节为单位的报文长度)、内容(和这个报文有关的参数)。

SSL握手协议包含两个阶段：第一个阶段用于建立私密性通信信道；第二个阶段用于客户认证。

第一阶段是通信的初始化阶段，通信双方都发出HELLO消息。当双方都接收到HELLO消息时，就有足够的信息确定是否需要一个新的密钥。若不需要新的密钥，双方立即进入握手协议的第二阶段。否则，此时服务器方的SERVER-HELLO消息将包含足够的信息使客户方产生一个新的密钥。这些信息包括服务器所持有的证书、加密规约和连接标识。若密钥产生成功，客户方发出CLIENT-MASTER-KEY消息，否则发出错误消息。最终当密钥确定以后，服务器方向客户方发出SERVER-VERIFY消息。因为只有拥有合适的公钥的服务器才能解开密钥。需要注意的一点是，每一通信方向上都需要一对密钥，所以一个连接需要四个密钥，分别为客户方的读密钥、客户方的写密钥、服务器方的读密钥、服务器方的写密钥。

第二阶段的主要任务是对客户进行认证，此时服务器已经被认证了。服务器方向客户发出认证请求消息：REQUEST-CERTIFICATE。当客户收到服务器方的认证请求消息时，发出自己的证书，并且监听对方回送的认证结果。而当服务器收到客户的认证时，若认证成功，则返回SERVER-FINISH消息，否则返回错误消息。到此为止，握手协议全部结束。

4．OpenSSL的安装与应用

1)OpenSSL简介

OpenSSL是基于SSLeay库的软件包，它是由EricA.Young和TimJ.Hudson于1995年共同开发成功的。其OpenSSL工具箱是经过Apache型认证认可的，也就是说，这是一个没有太多限制的开放源代码的软件包。到目前为止，用户已经可以从免费下载OpenSSL0.9.7g及其补丁程序。

OpenSSL采用C语言作为开发语言，这使得OpenSSL具有优秀的跨平台性能，这对于广大技术人员来说是一件非常美妙的事情，可以在不同的平台使用同样熟悉的东西。OpenSSL支持Linux、Windows、BSD、Mac、VMS等平台，这使得OpenSSL具有广泛的适用性。OpenSSL的算法已经非常完善，提供对SSL2.0、SSL3.0以及TLS1.0的支持。

OpenSSL整个软件包大概可以分成三个主要的功能部分：密码算法库、SSL协议库以及应用程序。

2)OpenSSL安装下载OpenSSL免费软件经解压缩，安装方法可以参考INSTALL.*文件。OpenSSL是支持跨平台的，它支持UNIX、DOS、Windows、OpenVMS和MacOS各类操作系统，具体安装手册可以分别查阅INSTALL、INSTALL.DJGPP、INSTALL.W32、INSTALL.VMS和INSTALL.MacOS文件。这里只讲述基于UNIX和Windows下的OpenSSL安装工作。

(1)在UNIX平台安装OpenSSL。在安装OpenSSL前必须具备以下工具：make，Perl5，ANSIC编译器，类库和C头文件开发环境，可支持UNIX操作系统。安装过程比较简单，可以在控制台输入以下命令：

$./config

$make

$maketest

$makeinstall前面的操作将在系统默认位置/usr/local/ssl下创建并安装OpenSSL。如果想指定安装位置，可以输入：

$./config--prefix=/usr/local--openssldir=/usr/local/openssl更多有关

./config(或

./Configure)的配置可以查看相关帮助。

(2)在Windows平台安装OpenSSL。在安装OpenSSL中，如果你的系统是基于Win32的，你需要安装Perl工具；如果系统是基于Cygwin的，你需要安装ActiveStatePerl。

另外，你必须具备一种C编译器(如VisualC++，BorlandC或GNUC)。

下面给出安装过程：*使用VisualC++编译器。创建一个OpenSSL的FIPS-certified变量并添加到选项“fips”。*运行Configure：>perlConfigureVC-WIN32*组建Makefiles和可选的汇编语言文件；如果使用MASM，运行>ms\do_masm；如果使用NASM，运行>ms\do_nasm；如果不使用任何汇编语言文件，运行

>ms\do_ms。

*最后运行>nmake-fms\ntdll.mak。如果所有操作都成功，你将获得一些DLL文件，它们可以在out32dll上运行。如果你想测试这些文件，可以输入

>cdout32dll

>..\ms\test*使用BorlandC++builder5编译器。*配置BorlandBuilder：

>perlConfigureBC-32*创建合适的makefile：

>ms\do_nasm*运行：

>make-fms\bcb.mak*使用GNUC(Cygwin)编译器。Cygwin提供了一种在NT4.0，Windows9x，WindowsME，Windows2000，andWindowsXP的bashshell和GNU工具环境。所以用Cygwin安装OpenSSL与在GNUbash环境下(如Linux)接近。

Cygwin执行一个Posix/Unix运行时系统(cygwin1.dll)。它也可以使用MinGW创建Win32类库(msvcrt.dll或crtdll.dll)，或者使用下面的步骤安装。

*安装Cygwin(详见/)。*安装Perl并确信Cygwin与perl(5.6.1-2或更高)和ActivePerl工作在同个路径。*运行Cygwinbashshell。*在控制台输入：

$tarzxvfopenssl-x.x.x.tar.gz

$cdopenssl-x.x.x如果创建Cygwin版的OpenSSL，运行：$./config[...]$make[...]$maketest$makeinstall如果在Cygwin上创建MinGW版(nativeWindows)OpenSSL，运行：$./Configuremingw[...]$make[...]$maketest$makeinstall

3)OpenSSL应用

OpenSSL的应用一般可以分为两种不同的方式：基于OpenSSL指令的应用和基于OpenSSL加密库及协议库的应用。前者简单，而后者相对复杂。这两种应用不一定是截然分离的，可以相互结合使用，比如使用SSL协议的API，但是证书使用OpenSSL的指令签发。基于OpenSSL指令的应用很容易，只要安装好了OpenSSL就可以开始使用。最简单的应用就是使用Req、CA以及X509指令来签发一个证书，该证书可以用于各种目的，比如很多Apache服务器就是使用OpenSSL的指令生成的证书作为服务器证书的。此外，作为测试目的，使用OpenSSL指令生成一个证书也是不错的选择。

单纯依靠OpenSSL指令的成功应用要数OpenCA，它是一个完全基于OpenSSL指令开发的证书认证中心(CA)程序，没有使用任何OpenSSL的API。当然，它不仅仅使用了OpenSSL一个软件包，它还使用了诸如OpenLDAP等软件包。OpenCA从一个侧面证明了OpenSSL指令的作用是很全面的。基于OpenSSL函数库的应用相对于基于OpenSSL指令的应用开发的工作量会大很多，但这并不意味着其应用会更少。事实上，基于OpenSSL的应用大部分是这种方式的，这种方式使得开发者能够根据自己的需求灵活地进行选择，而不必受OpenSSL有限指令的限制。

Mod_SSL是一个基于OpenSSL指令应用的范例，Apache和Mod_SSL结合起来实现了HTTPS在Linux和Windows等平台的运行。Stunnel是另外一个成功应用OpenSSL函数库的程序，该程序提供了一种包含客户端和服务器的安全代理服务器功能，事实上就是在客户端和服务器使用OpenSSL来建立一条安全的SSL通道。除了这些广为人知的项目外，有很多公司的商业密码产品都是基于OpenSSL的函数库开发的，在OpenSSL提供了Engine机制后，这种势头会更加明显。当然，出于各种目的，相当一部分公司在自己的产品中不会声明这一点。

4.3S-HTTP

1．安全超文本传输协议(S-HTTP)简介安全超文本传输协议(S-HTTP)是一种面向安全信息通信的协议，它可以和HTTP结合起来使用。S-HTTP能和HTTP信息模型共存并易于与HTTP应用程序相整合。

S-HTTP协议为HTTP客户机和服务器提供了多种安全机制，提供安全服务选项是为了适用于万维网上各类潜在用户。S-HTTP为客户机和服务器提供了相同的性能(同等对待请求和应答，也同等对待客户机和服务器)，同时维持了HTTP的事务模型和实施特征。

S-HTTP客户机和服务器能与某些加密信息格式标准相结合。S-HTTP支持多种兼容方案并且与HTTP相兼容。使用S-HTTP的客户机能够与沒有使用S-HTTP的服务器连接，反之亦然，但是这样的通信明显地不会利用S-HTTP的安全特征。

S-HTTP不需要客户端公用密钥认证(或公用密钥)，但它支持对称密钥的操作模式，这点很重要，因为这意味着即使没有要求用户拥有公用密钥，私人交易也会发生。虽然S-HTTP可以利用大多现有的认证系统，但S-HTTP的应用并不必依赖这些系统。

S-HTTP支持端对端的安全事务通信。客户机可能“首先”启动安全传输(使用报头的信息)，例如它可以用来支持已填表单的加密。使用S-HTTP，敏感的数据信息不会以明文形式在网络上发送。

S-HTTP提供了完整且灵活的加密算法、模态及相关参数。选项谈判用来决定客户机和服务器在事务模式、加密算法(用于签名的RSA和DSA、用于加密的DES和RC2等)及证书选择方面取得一致意见。

虽然S-HTTP的设计者承认他有意识地利用了多根分层的信任模型和许多公钥证书系统，但S-HTTP仍努力避开对某种特定模型的滥用。S-HTTP与摘要验证(在[RFC-2617]中有描述)的不同之处在于，它支持公钥加密和数字签名，并具有保密性。HTTPS作为另一种安全Web通信技术，是指HTTP运行在TLS和SSL上面的实现安全Web事务的协议。

2．协议结构在语法上，S-HTTP报文与HTTP相同，由请求或状态行组成，后面是信头和主体。显然信头各不相同并且主体密码设置更为精密。正如HTTP报文一样，S-HTTP报文由从客户机到服务器的请求和从服务器到客户机的响应组成。请求报文的格式如下：

为了和HTTP报文区分开来，S-HTTP需要特殊处理，请求行使用特殊的“安全”途径和指定协议“S-HTTP”。因此S-HTTP和HTTP可以在相同的TCP端口混合处理(例如端口80)。为了防止敏感信息的泄漏，URI请求必须带有“*”。

S-HTTP响应采用指定协议“S-HTTP”。响应报文的格式如下：

4.4SMIME

1．多用途的网际邮件扩充协议(MIME/S-MIME)多用途网际邮件扩充协议(MIME，MultipurposeInternetMailExtensions)说明了如何安排消息格式使消息在不同的邮件系统内进行交换。MIME的格式灵活，允许邮件中包含任意类型的文件。MIME消息可以包含文本、图像、声音、视频及其他应用程序的特定数据。具体来说，MIME允许邮件包括：单个消息中可含多个对象；文本文档不限制一行长度或全文长度；可传输ASCII以外的字符集，允许非英语语种的消息；多字体消息；二进制或特定应用程序文件；图像、声音、视频及多媒体消息。

MIME复合消息的目录信息头设有分界标志，这个分界标志绝不可出现在消息的其他位置，而只能是在各部之间以及消息体的开始和结束处。

MIME的安全版本S/MIME(Secure/MultipurposeInternetMailExtensions)设计用来支持邮件的加密。基于MIME标准，S/MIME为电子消息应用程序提供如下加密安全服务：认证、完整性保护、鉴定及数据保密等。

传统的邮件用户代理(MUA)可以使用S/MIME来加密发送邮件及解密接收邮件。S/MIME并不限于邮件的使用，它也能应用于任何可以传送MIME数据的传输机制，例如HTTP。同样，S/MIME利用MIME的面向对象特征允许在混合传输系统中交换安全消息。此外，S/MIME还可应用于消息自动传送代理，它们使用不需任何人为操作的加密安全服务，例如软件文档签名、发送到网上的FAX加密等。

2．协议结构

MIME定义了许多新的RFC822头域用于描述一个MIME实体的内容。这些头域有两种情形(一种作为常规RFC822消息头的一部分，一种是多个结构中的MIME主体部分头)。这些正规头域的定义如下：entity-headers:=[contentCRLF][encodingCRLF][idCRLF][descriptionCRLF]*(MIME-extension-fieldCRLF)MIME-message-headers:=entity-headers[fields]versionCRLF;TheorderingoftheheaderfieldsimpliedbythisBNFdefinitionshouldbeignored.MIME-part-headers:=entity-headers[fields];Anyfieldnotbeginningwith"content-"canhavenodefinedmeaningandmaybeignored.;TheorderingoftheheaderfieldsimpliedbythisBNFdefinitionshouldbeignored.

MIME加入安全特性就是S/MIME，它是MIME的延伸，RFC1847就是S/MIME的标准。当一篇MIME加入电子签章或编码后，S/MIME会把整个MIME邮件视作一个不可分割的主体，对这个主体实施PKI安全操作(加密或签名等)，并加入必需的S/MIME头信息，这样就产生了S/MIME格式的邮件。

(1)经过数字签名的邮件结构如图4-7所示。

图4-7经过数字签名的邮件结构

(2)经过加密的邮件如图4-8所示。

图4-8经过加密的邮件

4.5SET

1．SET简介电子商务是在开放的Internet环境中实现交易应用。电子商务涉及资金流和物流信息的传送，因此安全至关重要。

针对电子商务的要求，目前最有影响力的安全协议是安全电子交易协议(SET，SecureElectronicTransaction)。该协议是由VISA和MasterCard两大信用卡公司于1997年5月联合推出的。SET采用公钥密码体制和X.509数字证书标准，它主要是为了解决用户、商家和银行之间通过信用卡支付的交易而设计的，以保证支付信息的机密、支付过程的完整、商户及持卡人的合法身份以及可操作性。SET协议中的核心技术主要有公钥加密、数字签名、电子信封、电子安全证书等。SET协议是PKI框架下的一个典型实现，也是一个基于可信的第三方认证中心的方案，它不仅加密两个端点间的单个会话，还可以加密和认定三方间的多个信息。

SET协议的目标：

(1)信息在Internet上的安全传输，保证网上传输的数据不被黑客窃听。

(2)订单信息和个人账号信息的隔离，在将包括消费者账号信息的订单送到商家时，商家只能看到订货信息，而看不到消费者的账户信息。

(3)消费者和商家的相互认证，以确定通信双方的身份，一般由第三方机构负责为在线通信双方提供信用担保。

(4)要求软件遵循相同的协议和消息格式，使不同厂家开发的软件具有兼容和互操作功能，并且可以运行在不同的硬件和操作系统平台上。在一次完整的电子商务交易中，SET涉及到持卡人、商家、收单银行、发卡机构、认证中心(CA)、支付网关等实体，具体关系如图4-9所示。

图4-9SET协议的电子商务模型

图4-9电子商务模型中各实体的具体含义如下：*持卡人：在电子商务环境中，消费者和团体购买者通过计算机与商家交流，持卡人通过由发卡机构颁发的付款卡(例如信用卡、借记卡)进行结算。在持卡人和商家的会话中，SET可以保证持卡人的个人账号信息不被泄漏。*商家：提供商品或服务，使用SET就可以保证持卡人个人信息的安全。接收卡的商家必须和银行有关系。

*收单银行：在线交易的商家在银行开立账号，并且处理支付卡的认证和支付。*发卡机构：它是一个金融机构，为每一个建立了账户的顾客颁发付款卡，发卡机构根据不同品牌卡的规定和政策，保证对每一笔认证交易的付款。*认证中心(CA)：通常是由一些发卡机构共同委托，并负责向持卡人、电子商家发行公开密钥证书的机构。*支付网关：是由银行操作的，将Internet上的传输数据转换为金融机构内部数据的设备，或由指派的第三方处理商家支付信息和顾客的支付指令。