第 8章 安全协议协议就是规范。安全协议是对某些基于密码体制的信任关系的规范。
具体地说，就是在密码体制的基础上，根据应用目的，将密钥分配、
身份认证、信息保密以及数据交换予以规范化。
一般说来，安全协议的评估可以从它在以下 4个方面的 性能上进行：
（ 1） 认证性。 认证是分布式系统中的主体进行身份识别的过程。这个过程是通过对主体和认证服务器共享的一个秘密（如口令、加密密钥等）的证明进行的。通过认证，可以建立一种信任关系，对抗假冒攻击。
（ 2） 秘密性。 秘密性用来保护协议消息不泄露给非授权拥有此协议者。它也是建立一种信任关系，
根据是否对秘密拥有解释权，把主题分为有信任关系和没有信任关系的两部分。但是，在安全协议中，
一般不考虑密码算法的细节。
（ 3） 完整性。 完整性用来保护协议信息不被非法篡改、删除和替代。最常用的方法是封装和签名，如把消息认证码和杂凑码附在消息上，作为验证消息完整性的依据。
（ 4） 不可否认性。 不可否认性要求协议主题对自己的合法行为负责，也不可事后否认。为此，要收集对方参与协议交换的证据，用于出现纠纷时可信仲裁证明。证据一般以数字签名方式给出。
安全协议都是基于特定的目的制定的。按照制定的目的，安全协议可以分为密钥交换协议、认证协议、
认证和密钥交换协议以及其他一些不同应用领域的安全协议等。有些协议前面已经介绍了。这一章主要介绍目前在应用中人们比较关注的协议。
8.1 政务电子公文流转安全协议
8.1.1 电子公文流转概述
1,电子公文流转软件开发的关键问题随着政府信息化基础设施建设的逐渐完备，
改革传统办公模式，开展电子政务，使业务办公、公文流转和管理过程电子化、信息化，
让文职人员从长期繁杂的办公事务中解放出来，通过统一办公规范，提高工作效率，降低行政成本，实现办公自动化已势在必行。
公文流转系统作为一类非标准性的软件产品，具有很强的随意性和扩展性，其成功与否主要受三个关键技术的制约：
（ 1）开发模式：是 B/S模式，还是 C/S模式。
（ 2）开发平台与框架。目前主要有：
基于 LotusNotes的公文流转系统。
基于 ExchangeServer的公文流转系统。
基于 Windows,Net框架的公文流转系统。
基于 JAVA的公文流转系统。
其他。
（ 3）其他。主要涉及：公文流定义、身份验证、数字签名与传输加密、审批、电子签章和痕迹跟踪等。
2,电子公文流转系统的安全保障
（ 1） 身份验证政府机关公文处理工作保密性、严肃性特点，
因而公文流转系统必须使用与之相适应的身份验证技术。目前的身份验证技术主要有简单用户密码匹配、物理地址识别、智能卡等硬件识别、生物识别等，它们的安全程度不同，开发和应用成本也有很大差别。
（ 2） 数字签名与传输加密技术政府公文流转过程中严格的保密性是公文流转系统基本要求之一，也是政务类应用软件验收的硬性指标，所以一个成熟的公文流转系统必须使用数字签名技术，并在其基础上对数据传输进行加密，数字签名技术也是识别用户身份、确定公文责任的主要技术。在一些公文流转系统中已经应用了小型的 CA数字签名认证系统。
（ 3） 电子签章技术传统的公文是否有效与其是否具有公章直接相关，
这种“红头 +公章”的公文处理模式仍会延续到公文处理系统中，由于没有具体规定的出台，因而对于电子签章的合法性问题还存在很大的争议。在一些公文系统中，使用模拟化的电子签章，在公文上直接加盖，再由高精度打印设备打印，或作为二次加盖传统公章的凭据。在政府机关未形成大范围的无纸化办公的前提下，电子签章技术的发展趋势呈现以数字化的虚拟签章使公文在系统中生效，一旦需要出现纸介质公文时，在输出后对公文的合法性进行数字与人工的混合验证，并加盖传统的公章。
（ 4） 痕迹跟踪技术公文在处理的过程往往经过多个部门的多个工作人员，可能存在大量的修改行为，为了保证公文的原始信息，确定公文责任，需要对各种修改行为进行跟踪，并形成附属公文的流程跟踪报表。目前的公文流转系统大多实现了这一功能，或在数据库中、或在文档上保留公文处理的痕迹，以备审核 。
3,电子公文流转安全协议应当说，电子公文流转安全协议是上述电子公文安全保证在不同层次上的规范化和标准化。这里仅根据现行公文流转的方式和未来可能的需求，讨论电子公文流转安全协议应当具备的主要性能，主要涉及：
电子公文完整性验证。
发文单位验证。
收文单位验证。
收文方已签收验证。
电子公文佐证验证。
电子公文防窃取验证。
8.1.2 收文端单方认证协议单方认证协议可以让收文端对发文端认证，以确保电子公文的完整性。这类协议一般用于没有责任归属问题的公文传输，如会议通知、政府公告等。这类协议可以有三个层次。
1,电子公文完整性及发文单位验证协议这两个协议的作业程序如 图 8.1所示。它们是基于数字签名的认证。它们是基于数字签名的认证：
使用公开密钥体系，可以验证发文单位。
使用数字签名，可以验证公文的完整性。
这两个安全协议主要用于敏感性较低、防窃取需求不太明显的公文发送。
图 8.1 电子公文完整性及发文单位验证协议作业过程
2,电子公文防窃取验证这个协议用以保护敏感性较高，一旦泄密会造成严重损失的公文，如重要会议通知、一定机密程度的公文。因此，因此，如 图 8.2所示，它不仅要需要进行数据完整性认证和发放身份认证，还要对公文进行加密。
图 8.2 电子公文防窃取验证协议作业过程
8.1.3 不可否认电子公文流转协议不可否认公文流转协议主要用于传送具有责任归属的公文，如工作部署、人事任免、疫情报告等。下面介绍这类协议的几种不同形式。
1,双方三次认证的不可否认电子公文流转协议双方认证的不可否认电子公文流转协议的基本操作过程如 图 8.3所示，它是一个三次认证过程（也称三次握手协议）：
① 发文方发送用主密钥加密公文和用发文方的私钥加密的杂凑值。收文方用发文方的公钥验证签名的正确性。但是收文方没有主密钥对公文解密。
② 收文方验证签名后，用自己的私钥对杂凑值加密，作为收文证明传送给发文方。
③ 发文方用收文方的公钥验证收文证明后，
将主密钥传给收文方。收文方解密公文。
图 8.3 不可否认电子公文流转的双方三次认证协议操作过程
2,公正第三方参与的电子公文佐证协议有公正第三方参与的电子公文佐证协议是在不可否认电子公文流转协议的基础上，增加一个公正第三方（ Trust Third Party,TTP）角色，
为有责任归属的电子公文流转中的认证提供第三方佐证，以备以后有争议时，协助裁决。由于地三方的加入，认证过程也由原来的三次握手，变为 7次握手，如 图 8.4所示。
图中：“中”指公正第三方 ——公正中心
8.2 安全电子交易协议 SET
8.2.1 电子交易中的安全支付问题
1,电子商务中的 B to C交易过程交易指双方买卖双方之间进行商品买卖的行为。广义的交易是一个复杂的过程。在电子商务中，由于参与方不同等原因，会形成不同的交易过程，如 B to B（ Business to
Business，企业间电子商务，也缩写作 B2B）
的交易过程,B to C（ Business to
Consumer，企业对消费者的电子商务）的交易过程等。
下面主要介绍 B to C的交易过程在 B to C的交易过程中，主要角色有：
商家（ Merchant）：商品或服务的提供者。
银行（ Acquirer）：为在线交易者开设账号，并处理支付卡的认证和支付业务。
支付网关（ Payment gateway）：将 Internet上的传输数据转换为金融机构内部数据。
持卡者（ Cardholder）：消费者，可以使用付款卡结算。
发卡机构（ Issuer）：为每一个建立了账户的客户颁发付款卡，也可以由指派的第三方处理商家支付信息和客户支付命令。
图 8.5为 B to C的基本交易过程下面进一步介绍
（ 1） 订货
① 消费者上网，查看企业和商家网页，选择商品；消费者通过对话框填写订货单（姓名、
地址、品种、规格、数量、价格）给商家。
（ 2） 支付
② 商家核对消费者订货单后，向用户发出付款通知，同时向银行发出转账请求。
③ 消费者选择支付方式，如向发卡机构提交付款卡。
（ 3） 转账
④ 发卡机构验证消费者付款卡后，将卡号加密传向银行（支付网关）。银行审查消费者付款卡（有效、款够等）合格后，进行转账。
⑤ 转账成功，向商家发出和发卡机构出转账成功回执。
⑥ 发卡机构向消费者发出支付收据。
（ 4） 付货
⑦ 商家向消费者付货。
2,电子支付中的安全需求支付是交易的重要环节。由于电子支付的虚拟性，它的安全倍受人们关注，也是电子商务安全的最重要和最困难环节。
电子支付的问题表现在支付的每一个方面和每一个步骤中。归纳起来，主要表现为有如下一些安全需求：
确定交易过程中交易伙伴的真实性。
保证电子单据的隐秘性，防范被无关者窃取。
保证业务单据不丢失，即使丢失也可察觉。
验证电子单据内容的完整性。
验证电子单据内容的真实性。
具有防抵赖性和可仲裁性。
保证存储的交易信息的安全性。
8.2.2 SET的目标、角色和安全保障作用
SET（ Secure Electric Transaction，安全电子交换）协议是一种利用加密技术
（ Cryptography），以确保信用卡消费者、
销售上及金融机构在 Internet上从事电子交易的安全性和隐私性的协议。它是由两大信用卡公司 ——VISA和 Master在 GTE,IBM、
Microsoft\,Netscape,SAIC,Terisa
System,Verisign等著名 IT公司的支持下开发的。于 1996年 2月 1日正式发表。
1,SET的目标
SET的主要目标是：
（ 1） 保证数据在 Internet上安全传输，不被窃取。
（ 2） 订单信息与账号信息隔离，如把包含消费者账号信息的订单送给商家时，商家应看不到消费者账号信息。
（ 3） 消费与商家可以互相认证（一般由第三方提供信用担保），确定通信双方身份。
（ 4） 采用统一的协议和数据格式，使不同厂家开发的软件具有兼容性和互操作性，并可以运行在不同的硬件和操作系统平台上。
2,SET的参与角色一个 SET交易过程可能会涉及如下 6种角色：
（ 1） 消费者，即持卡人，必须持有
发卡机构支付卡账号；
认证机构颁发的身份证书；
上网条件。
（ 2） 商家，即经营者，必须持有：
网上经营许可权；
经过银行委托授权机构（认证中心,CA）颁发的数字证书；
相应的电子商务平台：处理消费者申请、与支付网关通信、存储自身公钥签名、存储自己的公钥交换私钥、存储交易参与方的公钥交换私钥、申请和接受认证、与后台数据库通信等。
（ 3） 银行：给在线交易参与者建立账号，处理转账业务。
（ 4） 发卡机构：金融机构，为建立了账号的消费者发卡。
（ 5） 支付网关，实际上是一台可以处理 SET
协议数据的计算机，可在 SET协议和银行交易系统之间进行数据格式转换，实现传统银行网上支付功能的延伸。支付网关有如下服务：
确定商家和消费者身份；
解密持卡人的支付指令；
签署数字响应。
支付网关必须具有：
银行授权；
CA颁发的数字证书。
（ 6） 认证机构，是参与交易各方都信任的第三方，可以接受发卡行和收单行的委托，对持卡人、商家和支付网关完成数字证书的发放。
3,SET的安全保障作用
（ 1） 基于持卡人的安全保障
对账号数据保密；
对交易数据保密；
持卡人对商家的认证。
（ 2） 基于商家的安全保障
对交易数据完整性的认证；
对持卡人账户数据的认证；
对持卡人的认证；
对银行端的认证；
对交易数据保密；
提供交易数据的佐证。
（ 3） 基于银行（支付网关）的安全保障
对消费者账号数据的认证；
对交易数据的间接认证；
对交易数据完整性的认证；
提供交易数据的佐证。
8.2.3 SET关键技术
1,双重签名
SET有一个基本性能：不需要让某个角色无关的其他角色的机密，就不让它知道，例如
只与持卡人和商家之间的交易有关的机密数据，不必要，也不可以让银行知道。
持卡者的账户数据也是持卡者的个人秘密数据，不必要，也不可以让厂商知道。
但是，在知道他人机密的情况下，还要对其数据的正确性进行认证。例如，在商家不知道持卡者账户数据，银行也不知道持卡者与商家之间的交易数据的情况下，让商家和银行都可以确定这些数据确实由持卡者产生、
送出的，还可以间接、直接地对这些数据进行认证。
这一性能，在 SET中使用双重签名（ Dual
Signature）技巧解决。
下面介绍用双重签名实现这一性能的过程。
① 持卡者（ C）产生两个签名：
CSig(H ( H (OI),H ( PI )))：持卡者对交易数据（ OI）
和账户数据（ PI）的签名。
CSig ( H (OI ))：持卡者对交易数据（ OI）的签名。
将两个签名、账户数据杂凑值 H（ PI）和交易数据
（ OI）都传送给商家。
② 商家（ M）操作：
验证 CSig(H ( H (OI),H ( PI ))),CSig ( H (OI ))和 H
（ PI），确定是否持卡者的签名。
生成对交易数据的签名 MSig ( H (OI ))。
将 MSig ( H (OI )),CSig(H ( H (OI),H ( PI )))一同送银行（支付网关）。
③ 支付网关（ P）操作：
验证 MSig ( H (OI ))，确定 H (OI )为交易数据的杂凑值。
用已知的 PI，验证 CSig(H ( H (OI),H ( PI )))
的正确性，确认交易数据和账户数据都是正确的。
根据政策，确认此笔交易是否成功。
图 8.6为 SET交易过程
2,SET认证中心为了使交易参加方有一个可信的第三方，建立了一个认证中心 CA来为消费者、商家和银行颁布数字证书，分配密钥。
SET认证中心采用层次结构。其最高层 CA
（既 Root CA）的安全维系着整个 SET协议的安全。为了防止 Root CA遭破解,SET将其密钥长度定在 2048，比一般用户的密钥长度 1024长一倍。
8.3 安全套接层协议 SSL
SSL（ Secure Socket Layer）是 Netscape公司提出的基于 Web应用的安全协议，它是建构在传输层 TCP之上、应用层之下的 Internet
通信的安全标准，被称为安全套接层
（ Secure Socket Layer,TLS）协议，主要用于点对点的信息传输。 1999年,SSL被 IETF
接受后，更名为 TLS（ Transport Layer
Security） 1.0协议。
8.3.1 Web安全分析
SSL基于 Web应用的安全协议。为了说明 SSL的原理和功能，首先分析一下 Web的安全威胁。
1,Web服务器的安全威胁
Web服务器的安全威胁主要来自两个方面。
（ 1） Web服务的内容丰富，功能强大，出现安全漏洞的概率大。
（ 2） Web服务器存放的有价值信息和隐私，会吸引攻击者加大力度的攻击。这些信息的泄露或被更改，
将会造成很大损失。其中尤其是那些用于存储用户名和口令的文件一旦被泄露，造成的损失将无法估计。
对服务器的攻击手段很多。例如,CGI漏洞攻击、缓冲溢出出攻击等，都会使服务器遭受严重破坏，尤其是木马程序可以将数据权限降级，将敏感信息发送到未受保护的区域，
扩大了访问范围，给攻击创造了条件。
2,Web浏览器的安全威胁
Web浏览器遭受的攻击主要来自在静态网页中嵌入的使网页动态化的小应用程序。当用户使用浏览器查看一个带有活动内容的网页时，网页中嵌入的小应用程序就会被自动下载，并在客户机上启动运行。假如这些小应用程序是病毒或木马，就会产生破坏作用。
3,通信信道的安全威胁
Internet起源于 ARPANET，其最初的重要目标是提供可靠性，保证当一个或多个通信线路出现故障时仍然可以正常通信。但是，它没有过多地考虑安全问题，从而使它在保密性、完整性和即需性方面显得脆弱。在保密性方面，它的许多数据以明文形式传输和存储，非常容易遭受嗅觉器的攻击；在完整性方面，它所传输或存储的数据极易遭到破坏和修改；在即需性方面，它极容易遭受拒绝服务攻击而是网络速度降到不能忍受的程度。
8.3.2 SSL的目标、体系结构和基本技术
1,SSL的目标按照优先顺序,SSL的设计目标依次为：
（ 1） 加密安全：通过保密性技术、消息完整性技术和验证，为实体之间建立安全的连接。
（ 2） 互操作性：保证不同的开发者开发的 SSL都能够成功地交换加密参数。
（ 3） 可扩展性：新的公开密钥加密方法和对称加密方法在必要时可以添加进来。
（ 4） 相对高效：通过可选的会话高速缓存机制，减少从头建立的连接数量，尽量减少加密操作占用的 CPU时间。
2,SSL体系结构
SSL体系结构如 图 8.7所示，它位于传输层之上、应用层之下。它独立与应用层，使应用层可以直接建立在
SSL上。
SSL由一些子协议组成：
（ 1） SSL记录协议（ Record Protocol）：建立在 TCP之上，用来封装高层协议。
（ 2） SSL握手协议（ Handshake Protocol）：
准许服务器端与客户端在开始传输数据前，可以通过特定的加密算法相互鉴别。
（ 3） SSL更改密码说明协议（ Change Cipher
Spec）：保证可扩展性。
（ 4） SSL警告协议（ Alert Protocol）：产生必要的警告信息。
3,SSL采用的基本技术
SSL主要是为应用层数据提供传输中的安全。
它所采用的基本技术为：
（ 1） 身份认证采用公开密钥体制；
（ 2） 数据保密采用对称密钥体制；
（ 3） 消息的完整性保护采用带密钥的消息认证码（ MAC）。
4,SSL协议运作方式
（ 1） 通信双方执行握手协议建立连接后，都可以获得共有的通信密码作加密密钥。
（ 2） 要传输的数据在执行记录协议阶段用上述通信密码加密后传送出去。对方用相同的密码作为解密密钥。
（ 3） 在运行握手协议或记录协议的过程中，任何一方有异常出现，可以用警告协议通知对方，以进行相应的处理。
（ 4） 任何一方想更换密钥时，可以运行更改密码说明协议。
8.3.3 SSL核心技术由上面的讨论可以知道,SSL记录协议和 SSL握手协议是 SSL的核心。下面分别介绍这两个子协议。
1,SSL记录协议的封装过程在 SSL体系中，当上层（应用层或表示层）的应用要选用 SSL协议时，上层（握手、警告、更改密码说明,HTTP等）协议信息，会通过 SSL记录子协议使用一些必要的程序，将加密码、压缩码,MAC等封装成若干数据包，再通过其下层（基本上都是从呼叫 socket接口层）传送出去。
记录协议的封装过程如图 8.8所示
2,SSL握手连接（ Connection）和会话（ Session）是 SSL中的两个重要概念。
一个 SSL会话是客户机与服务器之间的一个关联。
一个 SSL连接提供一种合适服务类型的传输。 SSL
连接是点对点的关系，并且连接是暂时的，每一个连接只与一个会话关联。会话定义了一组可供多个连接共享的加密安全参数，以避免为每一个连接提供新的安全参数所需的昂贵谈判代价。
客户机与服务器要建立一个会话，就必须进行握手过程。 SSL会话由 SSL握手协议创建或恢复。
图 8.9（ a） 为创建一个会话的握手过程,图 8.9（ b） 为恢复一个会话的握手过程。
下面主要介绍创建会话时的握手过程。
（ 1） Hello阶段握手协议从 Client发出的第一道信息 ClientHello开始。
① ClientHello和 ServerHello，用于协商安全参数，
包括：
协议版本号、会话识别码（ session_id）、时间戳、
密码算法协商（ cipher suit）、压缩算法、两个 28
字节随机数（ ClientHello.random和
ServerHello.random）。
② Certificate，密钥交换信息。在要验证 Server时发出。
③ ServerKeyExchange，送出 Client可以计算出共享秘密的参数，包含 Server临时公钥。这些信息一般包含在 Certificate中。只在下列情况下才由 Server
发出：
不需要验证 Server；
要求验证 Server，但 Server无证书或 Server证书是用于签名。
④ CertificateRequest,Server要求验证 Client时发出。
⑤ ServerHelloDone，表示双方握手过程的 Hello阶段结束。
这时,Server等待 Client回音。
（ 2） 加解密参数传输
① Certificate，回答 Server的 CertificateRequest要求的信息。 Server无要求时，不发。
② ClientKeyExchange，对 ClientHello和
ServerHello密钥交换算法的回复；以
ServerKeyExchange所选的算法进行，让双方可以共享秘密。
③ CertificateVerify，对此前 Server送来的所有信息
（ ClientHello,ServerHello,Certificate和
ServerKeyExchange）产生的签名，让 Server进一步确定 Client的正确性。
④ ExchangeCipherSpec,SSL更改密码说明协议消息。
⑤ 用协商好的算法和密钥加密的 Finished消息，握手完成消息。
（ 3） Server确认
① ExchangeCipherSpec，回复 Client的
ExchangeCipherSpec消息。
② 用协商好的算法和密钥加密的 Finished消息，握手完成消息。
（ 4） 会话数据传输传输应用数据。
恢复一个已经存在的会话时，握手过程一般只需要 Hello阶段。
3,SET协议和 SSL协议的比较
(1)交易效率
SET协议非常复杂、庞大，处理速度慢，系统负载重。而 SSL协议则简单得多，系统负载轻，整个交易过程仅需几秒钟，显然其工作效率要比 SET高。
(2)认证机制
SSL协议不能实现多方认证,SSL中只有商家服务器的认证是必须的，客户端认证则是可选的。相比
SET协议的认证要求较高，所有参与 SET交易的成员都必须申请数字证书，并且解决了客户与银行、
客户与商家、商家与银行之间的多方认证问题。
3,SET协议和 +SSL协议的比较
(3) 安全性
SET协议由于采用了公钥加密、信息摘要和数字签名等安全技术，可以确保信息的保密性、可鉴别性、完整性和不可否认性。 SSL协议也采用了公钥加密、信息摘要和 MAC
检测，可以提供保密性，完整性和一定程度的鉴别功能，
但由于其缺乏一套完整的认证体系，不能提供完备的防抵赖功能。从网上安全支持这一角度来看，显然 SET比 SSL针对性更强，更安全。
(4)协议层次和功能这两种协议在网络协议层的位置和功能并不相同,SSL是基于传输层的通用安全协议，它只占据电子商务体系中的一部分。从电子商务特性来看，它并不具备商务性、服务性、
协调性和集成性。而 SET位于应用层；对网络上其他各层也有涉及,SET规范了整个商务活动的流程，从而最大限度地保证了商务性，服务性、协调性和集成性。
3,SET协议和 +SSL协议的比较
(5 ) 应用范围由于 SET协议是基于信用卡交易的安全协议，它只适用于 B2C模式，在电子商务应用中具有一定的局限性。而 SSL协议现已嵌入 Navigate,IE等浏览器中，使其在电子商务的各种模式及其他需要安全的领域中得到广泛的应用 综上所分析，并结合目前我国的具体情况，可得出如下结论,．
1)近期,SET与 SSL共存，优势互补。
2)远期，开发一种能融合 SET与 SSL优点的安全协议和认证体系。
总结,SET和 SSL协议的比较安全套接层（ SSL）协议提供了两个端点之间的安全链接，能对信用卡和个人信息提供较强的保护； SSL
协议被大部分 Web浏览器和 web服务器所内置，比较容易被应用。
SET协议比 SSL协议复杂，在理论上安全性也更高，
因为 SET协议不仅加密两个端点间的连接，还可以加密和认定三方的多个信息，而这是 SSL协议所未能解决的问题。 SET标准的安全程度很高，它结合了数据加密标准 DES,RSA算法和安全超文本传输协议，为每一项交易都提供了多层加密。
SET和 SSL协议的比较
SET与 SSL相比主要有以下 4个方面的优点：
（ 1） SET对商家提供了保护自己的手段,使商务免受欺诈的困扰,
使商家的运营成本降低 。
（ 2） 对消费者而言,SET保证了商家的合法性,并且用户的信用卡号不会被窃取 。
（ 3） SET使得信用卡网上支付具有更低的欺骗概率,使得它比其他支付方式具有更大的竞争力 。
（ 4） SET对于参与交易的各方定义了互操作接口,一个系统可以由不同厂商的产品构筑 。
SET的主要缺陷：
SET协议过于复杂，对商户、用户和银行的要求比较高；
处理速度慢，支持 SET的系统费用较大。
8.4 IP Sec
8.4.1 IP安全分析
IP层是 TCP/IP中最关键的一层，也是关系整个 TCP/IP安全的核心和基础。但是，由于当初设计时的环境和考虑的基本出发点,IP没有过多地考虑防卫问题，只是设法使网络能够方便地互通互联。这种不设防政策，给
Internet造成许多安全隐患和漏洞，并随着攻击技术提高，使问题的严重性日益加剧。下面举几个例子来说明 IP遭受的安全威胁。
（ 1） IPv4缺乏对通行双方真实身份的验证能力，仅仅采用基于源 IP地址的认证机制，并且 IP地址可以进行软件配置。这样，就给攻击者以有机可乘，可以在一台计算机上假冒另一台计算机向接收方发送数据包，而接收方又无法判断接收到的数据包的真实性。这种 IP欺骗可以在多种场合制造灾难。
（ 2） IPv4缺乏不对网络上传输的数据包进行机密性和完整性保护，一般情况下 IP包是明文传输的，第三方很容易窃听到 IP数据包并提取其中的数据，甚至篡改窃取到的数据包内容，而且不被发觉，因为只要相应地修改校验和即可。
（ 3） 由于数据包中没有携带时间戳、一次性随机数等，很容易遭受重放攻击。攻击者搜集特定 IP包，进行一定处理就可以一一重新发送，欺骗对方。
（ 4） 路由器布局是 Internet的骨架。路由器不设防，将会使路由信息暴露，为攻击者提供入侵途径。
8.4.2 IP Sec的安全概念
IP Sec（ IP Security）是由 IETF以 RFC形式公布的一组安全 IP协议集，是在 IP包级为 IP
业务提供安全保护的协议标准。它使用现代密码学方法，支持机密性和认证性服务，使用户有选择地使用这些安全机制，以得到期望的安全服务。
1,IP Sec安全结构与数据包格式
IP Sec是一套协议包，它把多种安全技术集合到一起，可以建立一个安全和可靠的隧道。
IPSec的安全结构包括 3个基本协议：
（ 1） AH（ Authentication Header，认证报头）协议，
为 IP包提供信息源验证和完整性保证。
（ 2） ESP（ Encapsulating Security Payload，封装安全负荷）协议，提供加密保证。
（ 3） IKE（ Internet Key Exchange密钥交换）协议，
提供双方交流时的共享安全信息。
IPSec数据包结构如下，它是在 IP包头后面增加几个新的字段来实现安全保证。如 图 8.10所示。
2,传输模式和隧道模式
IP Sec有两种运行模式：
（ 1） 传输模式（ Transport Mode）
传输模式的特点是：
用于两个主机之间；
仅对上层协议数据部分提供安全保护，即在传输模式中，只有高层协议（ TCP,UDP，
ICMP等）及数据进行加密，源地址、目的地址以及 IP包头的内容都不加密。简单地说，
传输协议为上层协议提供安全保护。
AH和 ESP都支持传输协议。在正常情况下，
TCP数据包在 IP层中被添加 IP头后构成 IP数据包。启用 IP Sec后,IP Sec会在 TCP数据前增加 AH包头或 ESP包头或二者都增加，形成图 8.11所示的 3种传输模式 IP Sec数据包。
（ 2） 隧道模式（ Tunnel Mode）：
隧道模式的特点是：
用于有一端是安全网关或路由器；
对整个 IP数据包提供安全保护。即在隧道模式中，整个用户的 IP数据包被用来计算 ESP
包头，整个 IP包被加密并和 ESP包头一起被封装在一个新的 IP包内。于是，当数据在
Internet上传送时，真正的源地址和目的地址被隐藏起来。
IP Sec不仅可以保证隧道的安全，同时还有一套保证数据安全的措施，利用它建立起来的隧道具有更强的安全性和可靠性。一方面它可以和 L2TP等其他协议一起使用，一方面可运行于网络的任何一部分
（路由器和防火墙之间、路由器和路由器之间,PC
机和服务器之间,PC机和拨号访问设备之间）。
如果路由器要为自己转发的数据包提供 IP Sec服务，
就要使用隧道模式，并把这个 IP数据包作为一个整体进行保护，在这个 IP数据包之前添加 AH头或 ESP
头，然后再添加新的 IP头，组成新的 IP数据包发送出去。形成的新的 IP数据包如 图 8.12所示。
图 8.12 隧道模式的 IP Sec数据包这种数据包在传输的过程中，路由器只检查新的 IP头。
用于封装新 IP头，定义了从源路由器到目的路由器之间的一条虚拟路径，这就是隧道。
3,安全关联安全关联（ Security Associations,SA）是 IP Sec
的一个关键概念，它构成了 IP Sec的基础。 AH协议和 ESP协议的执行都依赖于 SA。
SA是两个 IP Sec实体（主机、安全网关）之间经过协商建立起来的一种协定，内容包括：
采用何种 IP Sec协议（ AH,ESP）；
运行模式（传输模式，隧道模式）；
采用的验证算法、加密算法、加密密钥、密钥生存期，抗重放窗口、计数器等
保护什么？如何保护？谁来保护？
一个 SA通过一个三元组来唯一标识：
（安全参数索引 SPI，目的 IP地址，安全协议（ AH或
ESP）标识符）
SA提供的安全服务取决于所选的安全协议,SA模式、
SA作用的两端点和安全协议所要求的服务。例如，
AH为 IP数据包提供的服务有：
数据源验证（但不对数据包加密）。
无连接完整性。
及抗重播服务。
接收端是否需要这一服务，可以自行决定。
ESP为 SA提供的服务有：
加密和验证（不包括外 IP头），或者其中之一。这种有限业务流机密性可以隐藏数据包的源地址和最终目的地址。
对数据包进行填充，从而隐藏了数据包的真实大小，进而隐藏了其通信特征。
抗重播服务。
SA仅为其上所携带的业务流提供一种安全机制（ AH或 ESP）。如果需要对特定业务提供多种安全保护，就要有多个 SA序列的组合 —
—SA捆绑。
4,安全策略数据库与安全关联数据库在 IP Sec中，为处理 IP业务流，需要维护两个与 SA相关的数据库：安全策略数据库
（ Security Policy Database,SPD）与安全关联数据库（ Security Association Database，
SAD）。
（ 1） SAD
SAD由一系列 SA条目组成，每个条目定义了一个 SA的参数，所以 SAD包含了与每个活动
SA相关的所有参数信息。
（ 2） SPD
安全策略（ Security Policy,SP）定义了对所有入数据 /出数据应当采取的安全策略，决定了为一个包提供的安全服务以及以什么方式提供。 SPD实际上不是通常意义上的数据库，而是将所有的 SP定义了对所有出 /入业务应当采取的安全策略，以某种数据结构集中存储列表。当要将 IP包发出去或者接收到
IP包时，首先要查找 SPD来决定如何进行处理。
SPD对 IP包的处理有 3种可能：
丢弃。
绕过 ——不用 IP Sec。
采用 IP Sec。
5,IP Sec的安装当 IP Sec运行于路由器 /网关时，安装配置简单，只需在网络设备上进行配置，由网络提供安全性。
当 IP Sec运行于服务器 /PC机时，可以提供端到端的安全，在应用层进行控制，缺点是安装配置和管理比较复杂。
8.4.3 IP Sec体系结构
IP Sec各部件之间的关系结构如图 8.13所示下面对有关部分作进一步介绍
1,AH协议
（ 1） 功能
AH为 IP包提供数据完整性和验证服务：
对数据使用完整性检查，可以判定数据包在传输过程中是否被修改。
通过验证机制，终端系统或设备可以对用户或应用进行验证，并过滤通信流；还可以防止地址欺骗和重放攻击。
（ 2） 格式
AH具有 图 8.14所示的格式
下一个头（ 8比特）：标识紧跟验证头的下一个头的类型。
载荷长度（ 8比特）：以 32比特为单位的验证数据长度加 1。如，缺省的验证数据字段长度为 96比特，
为 3个 32比特，加上 1，得 4。即缺省的验证数据的
AH头的载荷长度为 4。
保留（ 16比特）：备以后使用。
安全参数索引（ 32比特）：用于标识一个安全关联。
序号（ 8比特）：无符号单调递增计数值，用于 IP数据包的重放检查。
验证数据（ 32比特的整数倍的可变长数据）：包含有数据包的 ICV（完整性校验值）或 MAC。
2,ESP协议
（ 1） 功能为 IP数据包提供如下服务：
数据源验证。
数据完整性。
抗重放。
机密性。
（ 2） 格式
ESP具有 图 8.15所示的格式
下一个头（ 8比特）：通过标识载荷中的第一个头
（如 IPv6中的扩展头，或诸如 TCP等上层头）决定载荷数据字段中数据的类型。
安全参数索引（ 32比特）：标识一个安全关联。
序号（ 8比特）：无符号单调递增计数值，用于 IP数据包的重放检查。
验证数据（ 32比特的整数倍的可变长数据）：用于填入 ICV（完整性校验值）。 IVC的计算范围为 ESP
包中除掉验证数据字段部分。
填充项（ 0~255比特）：额外字节。
填充长度（ 8比特）：填充的字节数。
载荷数据（可变）：在传输模式下为传输层数据段，
在隧道模式下为 IP包。
3,密钥交换协议
IP Sec的密钥管理包括密钥的确定和分配，
可以采用手工或自动方式进行。 IP Sec默认的自动密钥管理协议是 IKE。
IKE规定了验证 IP Sec对等实体、协商安全服务和生成会话密钥的方法。 IKE将密钥协商结果保留在 SA中，供 AH和 ESP以后通信时使用。
IKE有 4种身份认证方式：
（ 1） 基于数字签名的认证：利用数字证书表示身份，
利用数字签名算法计算出一个签名来验证身份。
（ 2） 基于公开密钥的认证：用对方的公钥加密身份，
通过检查对方发来的该 Hash值进行认证。
（３） 基于修正的公钥，对上述方式修正。
（４） 基于预共享字符串：双方事先商定好一个双方共享的字符串。
DOI的作用是为使用 IKE进行协商 SA的协议统一分配标识符。
4,加密和验证算法
IP Sec的加密只用于 ESP。目前的 IP Sec标准要求任何 IP Sec实现都必须支持 DES，此外还可以使用
3DES,RC5,IDEA,3IDEA,CAST和 Blowfish。
由于 DES在网络上加密的缺点，今后将有采用
3DES和 AES（高级加密标准）的趋势。
IP Sec的验证算法可用于 AH和 ESP，主要采用
HMAC。 HMAC将消息和密钥作为输入来计算 MAC。
MAC保存在 AH/ESP头中的验证数据字段中。目的地收到 IP包后，使用相同的验证算法和密钥计算一个新的 MAC，并与数据包中的 MAC比对。
8.5 VPN技术虚拟专用网（ VPN,Virtual Private
Network），是指将物理上分布在不同地点的专用网络，通过不可信任的公共网络构造成逻辑上的虚拟子网，进行安全的通信。这里公共网络主要指 Internet。
8.5.1 VPN的基本原理图 8.16为 VPN的结构示意图。在这个图例中，
有 4个内部网，它们都位于一个 VPN设备的后面，同时由路由器连接到公共网。 VPN技术采用了加密、认证、存取控制、数据完整性等措施，相当于在各 VPN设备间形成一些跨越 Internet的虚拟通道 ——“隧道”，使得敏感信息只有预定的接收者才能读懂，实现信息的安全传输，使信息不被泄露、篡改和复制。
图 8.16 VPN的结构与基本原理
VPN的基本处理过程为：
① 要保护的主机发送明文信息到其 VPN设备；
② VPN设备根据网络管理员设置的规则，确定是对数据进行加密还是直接传送；
③ 对需要加密的数据,VPN设备将其整个数据包
（包括要传送的数据、源 IP地址和目标 IP地址）进行加密并附上数字签名，加上新的数据报头（包括目的地 VPN设备需要的安全信息和一些初始化参数），重新封装；
④ 将封装后的数据包通过隧道在公共网上传送；
⑤ 数据包到达目的 VPN设备，将数据包解封，核对数字签名无误后，对数据包解密。
8.5.2 隧道协议隧道技术是 VPN技术的核心，它涉及到数据的封装，
可以利用 TCP/IP协议作为主要传送协议以一种安全的方式在公用网络（如 Internet）上传送。隧道分为两种方式：强制型隧道和自愿型隧道。强制型隧道不需要用户在自己的计算机上安装特殊的软件，使用起来比较方便，主要供 ISP将用户连接到 Internet
时使用。自愿型隧道则需要用户在自己的计算机中安装特殊的软件，以便在 Internet中可以任意使用隧道技术，完全地控制自己数据的安全。
在 VPN中，双方的通信量很大，并且往往很熟悉，
这样就可以使用复杂的专用加密和认证技术对通信双方的 VPN进行加密和认证。为了实现这些功能，
隧道被构造为一种 3层结构：
（ 1） 最底层是传输。传输协议用来传输上层的封装协议,IP,ATM,PVC和 SVC都是非常合适的传输技术。其中因为 IP具有强大的路由选择能力，可以运行于不同的介质上，因而应用最为广泛。
（ 2） 第二层是封装。封装协议用来建立、保持和拆卸隧道，或者说是数据的封装、打包与拆包。
（ 3） 第三层是认证。
每一层的功能都是由相应的协议支持的，下面介绍一些有关的协议。
1,点对点隧道协议 PPTP
PPTP（ Point-to-Point Tunneling Protocol）
是基于 IP的点对点隧道协议，它将其他协议和数据封装于 IP网络，用公共的 Internet创建
VPN，使远程用户能够透过任何支持 PPTP和
ISP访问某一专用网。
通过 PPTP，客户可以采用拨号方式接入到 ISP再接入到公共 IP网络 Internet。具体过程为：客户按常规方式拨号到 ISP的接入服务器（ NAS），建立 PPP连接；在此基础上，进行第二次拨号，建立到 PPTP服务器的连接，即建立 PPTP隧道。对于直接连接到
Internet上的客户，不需要第一次的 PPP连接，可以直接与 PPTP服务器建立虚拟通道。可以说,PPTP
实质上是基于 IP的 PPP协议的扩展，它只支持 IP作为传输协议，但其 IP数据报可以封装多种协议数据，
包括 TCP/IP,IPX和 NetBEUI。 PPTP采用了基于
RSA公司的 RC4的数据加密方法，提供了一种在
Internet上建立多协议的安全 VPN通信方式。
2,第 2层转发协议 L2F
L2F是由 Cisco公司提出的可以在多种传输网络（如 ATM、帧中继,IP网）上建立多协议的安全虚拟专用网的通信方式。远程用户能够通过拨号方式接入公共网络。具体过程为：
客户按常规方式拨号到 ISP的接入服务器
（ NAS），建立 PPP连接； NAS根据用户名等信息，发起第二重连接，通向 FGW服务器。
在这种情况下，隧道的配置和建立对用户完全透明。
3,第 2层隧道协议 L2TP
L2TP是把数据链路层 PPP帧封装在公共网络设施如 IP,ATM、帧中继中进行隧道传输的封装协议。 L2TP主要由 L2TP访问集中器 LAC
（ L2TP Access Concentrator）和 L2TP网络服务器 LNS（ L2TP Network Sever）组成。
LAC支持客户端的 L2TP，用于发起呼叫，接收呼叫和建立隧道； LNS是所有隧道的终点。
L2TP的建立过程为：
① 用户通过公共电话网或 ISDN拨号至本地，
接入服务器 LAC（ LAC是连接的终点）；
② LAC接收呼叫并进行辨认，如果用户被认为是合法用户，就建立一个通向 LNS的 VPN
隧道；
③ 内部网的安全服务器（如 TACACS+，
RADIUS等）鉴定拨号用户；
④ LNS与远程用户交换 PPP信息，分配 IP地址；
⑤ 端对端的数据从拨号用户传到 LNS。
与 PPTP与 L2F相比,L2TP的优点是它提供了差错和流量控制。此外，作为 PPP的扩展，
L2TP支持标准安全特性 CHAP和 PAP，可以进行用户身份认证。 L2TP定义了控制包的加密传输，对每个隧道生成一个独一无二的随机密钥，以抵御欺骗性的攻击，但是它对传输中的数据不加密。
8.5.3 IP Sec VPN和 SSL VPN
目前,IP Sec和 SSL是实现 VPN的两大实现技术。
其中 IP Sec VPN是基于网络层的,SSL VPN是基于应用层的。下面分别介绍它们实现 VPN的思想。
1,IP Sec VPN
IP Sec VPN是网络层的 VPN技术，表示它是独立于应用程序的。采用隧道运行模式的 IP Sec可以一自己的头（ AH或 ESP）去封装原始的 IP数据包，隐藏所有的应用协议信息，进而实现各种类型的一对多的连接，如 Web、电子邮件、文件传输,VoIP等连接。
2,SSL VPN
SSL是一种在 Internet上保证发送信息安全的通用协议，它基于公钥加密进行工作。由于它建立在应用层上，与 IP Sec相比，更容易提供细粒度的远程访问和企业外网 VPN需要的控制。
SSL VPN以 HTTP为基础。由于目前大多数计算机在出厂时都安装了支持 HTTP和 HTTPS（以 SSL为基础的 HTTP）的 Web浏览器，所以通常把 SSL
VPN称为“无客户端”。
3,SSL VPN与 IP Sec VPN的特性比较表 8.1为 SSL VPN与 IP Sec VPN的特性比较。
表 8.1 SSL VPN与 IP Sec VPN的特性比较习 题
1,在不可否认的电子公文流转协议中，若遇到下面的情形，应如何处理？
（ 1） 收文方在超时后，仍然没有收到发文方的主密码。
（ 2） 收文方验证的签证不吻合。
2,用一个实例说明在 SET支持下的电子购物的工作流程。
3,SET能不能支持 B to B的交易过程？
4,为什么在 SET中要明确参与角色，而 SSL
中没有？
5,SSL如何解决 Web中的安全问题？
6,IP Sec如何解决 IP面临的安全威胁问题？
7.举例说明 IP Sec有哪些应用。
8,试述 VPN的工作原理，叙述 VPN与租用专线有何区别。
9,试设计一个用防火墙构造 VPN的方案。
10,查阅资料，对目前市场上的各种 VPN产品的技术性能和经济性能进行分析比较。
具体地说，就是在密码体制的基础上，根据应用目的，将密钥分配、
身份认证、信息保密以及数据交换予以规范化。
一般说来，安全协议的评估可以从它在以下 4个方面的 性能上进行：
（ 1） 认证性。 认证是分布式系统中的主体进行身份识别的过程。这个过程是通过对主体和认证服务器共享的一个秘密（如口令、加密密钥等）的证明进行的。通过认证，可以建立一种信任关系，对抗假冒攻击。
（ 2） 秘密性。 秘密性用来保护协议消息不泄露给非授权拥有此协议者。它也是建立一种信任关系，
根据是否对秘密拥有解释权，把主题分为有信任关系和没有信任关系的两部分。但是，在安全协议中，
一般不考虑密码算法的细节。
（ 3） 完整性。 完整性用来保护协议信息不被非法篡改、删除和替代。最常用的方法是封装和签名，如把消息认证码和杂凑码附在消息上，作为验证消息完整性的依据。
（ 4） 不可否认性。 不可否认性要求协议主题对自己的合法行为负责，也不可事后否认。为此，要收集对方参与协议交换的证据，用于出现纠纷时可信仲裁证明。证据一般以数字签名方式给出。
安全协议都是基于特定的目的制定的。按照制定的目的，安全协议可以分为密钥交换协议、认证协议、
认证和密钥交换协议以及其他一些不同应用领域的安全协议等。有些协议前面已经介绍了。这一章主要介绍目前在应用中人们比较关注的协议。
8.1 政务电子公文流转安全协议
8.1.1 电子公文流转概述
1,电子公文流转软件开发的关键问题随着政府信息化基础设施建设的逐渐完备，
改革传统办公模式，开展电子政务，使业务办公、公文流转和管理过程电子化、信息化，
让文职人员从长期繁杂的办公事务中解放出来，通过统一办公规范，提高工作效率，降低行政成本，实现办公自动化已势在必行。
公文流转系统作为一类非标准性的软件产品，具有很强的随意性和扩展性，其成功与否主要受三个关键技术的制约：
（ 1）开发模式：是 B/S模式，还是 C/S模式。
（ 2）开发平台与框架。目前主要有：
基于 LotusNotes的公文流转系统。
基于 ExchangeServer的公文流转系统。
基于 Windows,Net框架的公文流转系统。
基于 JAVA的公文流转系统。
其他。
（ 3）其他。主要涉及：公文流定义、身份验证、数字签名与传输加密、审批、电子签章和痕迹跟踪等。
2,电子公文流转系统的安全保障
（ 1） 身份验证政府机关公文处理工作保密性、严肃性特点，
因而公文流转系统必须使用与之相适应的身份验证技术。目前的身份验证技术主要有简单用户密码匹配、物理地址识别、智能卡等硬件识别、生物识别等，它们的安全程度不同，开发和应用成本也有很大差别。
（ 2） 数字签名与传输加密技术政府公文流转过程中严格的保密性是公文流转系统基本要求之一，也是政务类应用软件验收的硬性指标，所以一个成熟的公文流转系统必须使用数字签名技术，并在其基础上对数据传输进行加密，数字签名技术也是识别用户身份、确定公文责任的主要技术。在一些公文流转系统中已经应用了小型的 CA数字签名认证系统。
（ 3） 电子签章技术传统的公文是否有效与其是否具有公章直接相关，
这种“红头 +公章”的公文处理模式仍会延续到公文处理系统中，由于没有具体规定的出台，因而对于电子签章的合法性问题还存在很大的争议。在一些公文系统中，使用模拟化的电子签章，在公文上直接加盖，再由高精度打印设备打印，或作为二次加盖传统公章的凭据。在政府机关未形成大范围的无纸化办公的前提下，电子签章技术的发展趋势呈现以数字化的虚拟签章使公文在系统中生效，一旦需要出现纸介质公文时，在输出后对公文的合法性进行数字与人工的混合验证，并加盖传统的公章。
（ 4） 痕迹跟踪技术公文在处理的过程往往经过多个部门的多个工作人员，可能存在大量的修改行为，为了保证公文的原始信息，确定公文责任，需要对各种修改行为进行跟踪，并形成附属公文的流程跟踪报表。目前的公文流转系统大多实现了这一功能，或在数据库中、或在文档上保留公文处理的痕迹，以备审核 。
3,电子公文流转安全协议应当说，电子公文流转安全协议是上述电子公文安全保证在不同层次上的规范化和标准化。这里仅根据现行公文流转的方式和未来可能的需求，讨论电子公文流转安全协议应当具备的主要性能，主要涉及：
电子公文完整性验证。
发文单位验证。
收文单位验证。
收文方已签收验证。
电子公文佐证验证。
电子公文防窃取验证。
8.1.2 收文端单方认证协议单方认证协议可以让收文端对发文端认证，以确保电子公文的完整性。这类协议一般用于没有责任归属问题的公文传输，如会议通知、政府公告等。这类协议可以有三个层次。
1,电子公文完整性及发文单位验证协议这两个协议的作业程序如 图 8.1所示。它们是基于数字签名的认证。它们是基于数字签名的认证：
使用公开密钥体系，可以验证发文单位。
使用数字签名，可以验证公文的完整性。
这两个安全协议主要用于敏感性较低、防窃取需求不太明显的公文发送。
图 8.1 电子公文完整性及发文单位验证协议作业过程
2,电子公文防窃取验证这个协议用以保护敏感性较高，一旦泄密会造成严重损失的公文，如重要会议通知、一定机密程度的公文。因此，因此，如 图 8.2所示，它不仅要需要进行数据完整性认证和发放身份认证，还要对公文进行加密。
图 8.2 电子公文防窃取验证协议作业过程
8.1.3 不可否认电子公文流转协议不可否认公文流转协议主要用于传送具有责任归属的公文，如工作部署、人事任免、疫情报告等。下面介绍这类协议的几种不同形式。
1,双方三次认证的不可否认电子公文流转协议双方认证的不可否认电子公文流转协议的基本操作过程如 图 8.3所示，它是一个三次认证过程（也称三次握手协议）：
① 发文方发送用主密钥加密公文和用发文方的私钥加密的杂凑值。收文方用发文方的公钥验证签名的正确性。但是收文方没有主密钥对公文解密。
② 收文方验证签名后，用自己的私钥对杂凑值加密，作为收文证明传送给发文方。
③ 发文方用收文方的公钥验证收文证明后，
将主密钥传给收文方。收文方解密公文。
图 8.3 不可否认电子公文流转的双方三次认证协议操作过程
2,公正第三方参与的电子公文佐证协议有公正第三方参与的电子公文佐证协议是在不可否认电子公文流转协议的基础上，增加一个公正第三方（ Trust Third Party,TTP）角色，
为有责任归属的电子公文流转中的认证提供第三方佐证，以备以后有争议时，协助裁决。由于地三方的加入，认证过程也由原来的三次握手，变为 7次握手，如 图 8.4所示。
图中：“中”指公正第三方 ——公正中心
8.2 安全电子交易协议 SET
8.2.1 电子交易中的安全支付问题
1,电子商务中的 B to C交易过程交易指双方买卖双方之间进行商品买卖的行为。广义的交易是一个复杂的过程。在电子商务中，由于参与方不同等原因，会形成不同的交易过程，如 B to B（ Business to
Business，企业间电子商务，也缩写作 B2B）
的交易过程,B to C（ Business to
Consumer，企业对消费者的电子商务）的交易过程等。
下面主要介绍 B to C的交易过程在 B to C的交易过程中，主要角色有：
商家（ Merchant）：商品或服务的提供者。
银行（ Acquirer）：为在线交易者开设账号，并处理支付卡的认证和支付业务。
支付网关（ Payment gateway）：将 Internet上的传输数据转换为金融机构内部数据。
持卡者（ Cardholder）：消费者，可以使用付款卡结算。
发卡机构（ Issuer）：为每一个建立了账户的客户颁发付款卡，也可以由指派的第三方处理商家支付信息和客户支付命令。
图 8.5为 B to C的基本交易过程下面进一步介绍
（ 1） 订货
① 消费者上网，查看企业和商家网页，选择商品；消费者通过对话框填写订货单（姓名、
地址、品种、规格、数量、价格）给商家。
（ 2） 支付
② 商家核对消费者订货单后，向用户发出付款通知，同时向银行发出转账请求。
③ 消费者选择支付方式，如向发卡机构提交付款卡。
（ 3） 转账
④ 发卡机构验证消费者付款卡后，将卡号加密传向银行（支付网关）。银行审查消费者付款卡（有效、款够等）合格后，进行转账。
⑤ 转账成功，向商家发出和发卡机构出转账成功回执。
⑥ 发卡机构向消费者发出支付收据。
（ 4） 付货
⑦ 商家向消费者付货。
2,电子支付中的安全需求支付是交易的重要环节。由于电子支付的虚拟性，它的安全倍受人们关注，也是电子商务安全的最重要和最困难环节。
电子支付的问题表现在支付的每一个方面和每一个步骤中。归纳起来，主要表现为有如下一些安全需求：
确定交易过程中交易伙伴的真实性。
保证电子单据的隐秘性，防范被无关者窃取。
保证业务单据不丢失，即使丢失也可察觉。
验证电子单据内容的完整性。
验证电子单据内容的真实性。
具有防抵赖性和可仲裁性。
保证存储的交易信息的安全性。
8.2.2 SET的目标、角色和安全保障作用
SET（ Secure Electric Transaction，安全电子交换）协议是一种利用加密技术
（ Cryptography），以确保信用卡消费者、
销售上及金融机构在 Internet上从事电子交易的安全性和隐私性的协议。它是由两大信用卡公司 ——VISA和 Master在 GTE,IBM、
Microsoft\,Netscape,SAIC,Terisa
System,Verisign等著名 IT公司的支持下开发的。于 1996年 2月 1日正式发表。
1,SET的目标
SET的主要目标是：
（ 1） 保证数据在 Internet上安全传输，不被窃取。
（ 2） 订单信息与账号信息隔离，如把包含消费者账号信息的订单送给商家时，商家应看不到消费者账号信息。
（ 3） 消费与商家可以互相认证（一般由第三方提供信用担保），确定通信双方身份。
（ 4） 采用统一的协议和数据格式，使不同厂家开发的软件具有兼容性和互操作性，并可以运行在不同的硬件和操作系统平台上。
2,SET的参与角色一个 SET交易过程可能会涉及如下 6种角色：
（ 1） 消费者，即持卡人，必须持有
发卡机构支付卡账号；
认证机构颁发的身份证书；
上网条件。
（ 2） 商家，即经营者，必须持有：
网上经营许可权；
经过银行委托授权机构（认证中心,CA）颁发的数字证书；
相应的电子商务平台：处理消费者申请、与支付网关通信、存储自身公钥签名、存储自己的公钥交换私钥、存储交易参与方的公钥交换私钥、申请和接受认证、与后台数据库通信等。
（ 3） 银行：给在线交易参与者建立账号，处理转账业务。
（ 4） 发卡机构：金融机构，为建立了账号的消费者发卡。
（ 5） 支付网关，实际上是一台可以处理 SET
协议数据的计算机，可在 SET协议和银行交易系统之间进行数据格式转换，实现传统银行网上支付功能的延伸。支付网关有如下服务：
确定商家和消费者身份；
解密持卡人的支付指令；
签署数字响应。
支付网关必须具有：
银行授权；
CA颁发的数字证书。
（ 6） 认证机构，是参与交易各方都信任的第三方，可以接受发卡行和收单行的委托，对持卡人、商家和支付网关完成数字证书的发放。
3,SET的安全保障作用
（ 1） 基于持卡人的安全保障
对账号数据保密；
对交易数据保密；
持卡人对商家的认证。
（ 2） 基于商家的安全保障
对交易数据完整性的认证；
对持卡人账户数据的认证；
对持卡人的认证；
对银行端的认证；
对交易数据保密；
提供交易数据的佐证。
（ 3） 基于银行（支付网关）的安全保障
对消费者账号数据的认证；
对交易数据的间接认证；
对交易数据完整性的认证；
提供交易数据的佐证。
8.2.3 SET关键技术
1,双重签名
SET有一个基本性能：不需要让某个角色无关的其他角色的机密，就不让它知道，例如
只与持卡人和商家之间的交易有关的机密数据，不必要，也不可以让银行知道。
持卡者的账户数据也是持卡者的个人秘密数据，不必要，也不可以让厂商知道。
但是，在知道他人机密的情况下，还要对其数据的正确性进行认证。例如，在商家不知道持卡者账户数据，银行也不知道持卡者与商家之间的交易数据的情况下，让商家和银行都可以确定这些数据确实由持卡者产生、
送出的，还可以间接、直接地对这些数据进行认证。
这一性能，在 SET中使用双重签名（ Dual
Signature）技巧解决。
下面介绍用双重签名实现这一性能的过程。
① 持卡者（ C）产生两个签名：
CSig(H ( H (OI),H ( PI )))：持卡者对交易数据（ OI）
和账户数据（ PI）的签名。
CSig ( H (OI ))：持卡者对交易数据（ OI）的签名。
将两个签名、账户数据杂凑值 H（ PI）和交易数据
（ OI）都传送给商家。
② 商家（ M）操作：
验证 CSig(H ( H (OI),H ( PI ))),CSig ( H (OI ))和 H
（ PI），确定是否持卡者的签名。
生成对交易数据的签名 MSig ( H (OI ))。
将 MSig ( H (OI )),CSig(H ( H (OI),H ( PI )))一同送银行（支付网关）。
③ 支付网关（ P）操作：
验证 MSig ( H (OI ))，确定 H (OI )为交易数据的杂凑值。
用已知的 PI，验证 CSig(H ( H (OI),H ( PI )))
的正确性，确认交易数据和账户数据都是正确的。
根据政策，确认此笔交易是否成功。
图 8.6为 SET交易过程
2,SET认证中心为了使交易参加方有一个可信的第三方，建立了一个认证中心 CA来为消费者、商家和银行颁布数字证书，分配密钥。
SET认证中心采用层次结构。其最高层 CA
（既 Root CA）的安全维系着整个 SET协议的安全。为了防止 Root CA遭破解,SET将其密钥长度定在 2048，比一般用户的密钥长度 1024长一倍。
8.3 安全套接层协议 SSL
SSL（ Secure Socket Layer）是 Netscape公司提出的基于 Web应用的安全协议，它是建构在传输层 TCP之上、应用层之下的 Internet
通信的安全标准，被称为安全套接层
（ Secure Socket Layer,TLS）协议，主要用于点对点的信息传输。 1999年,SSL被 IETF
接受后，更名为 TLS（ Transport Layer
Security） 1.0协议。
8.3.1 Web安全分析
SSL基于 Web应用的安全协议。为了说明 SSL的原理和功能，首先分析一下 Web的安全威胁。
1,Web服务器的安全威胁
Web服务器的安全威胁主要来自两个方面。
（ 1） Web服务的内容丰富，功能强大，出现安全漏洞的概率大。
（ 2） Web服务器存放的有价值信息和隐私，会吸引攻击者加大力度的攻击。这些信息的泄露或被更改，
将会造成很大损失。其中尤其是那些用于存储用户名和口令的文件一旦被泄露，造成的损失将无法估计。
对服务器的攻击手段很多。例如,CGI漏洞攻击、缓冲溢出出攻击等，都会使服务器遭受严重破坏，尤其是木马程序可以将数据权限降级，将敏感信息发送到未受保护的区域，
扩大了访问范围，给攻击创造了条件。
2,Web浏览器的安全威胁
Web浏览器遭受的攻击主要来自在静态网页中嵌入的使网页动态化的小应用程序。当用户使用浏览器查看一个带有活动内容的网页时，网页中嵌入的小应用程序就会被自动下载，并在客户机上启动运行。假如这些小应用程序是病毒或木马，就会产生破坏作用。
3,通信信道的安全威胁
Internet起源于 ARPANET，其最初的重要目标是提供可靠性，保证当一个或多个通信线路出现故障时仍然可以正常通信。但是，它没有过多地考虑安全问题，从而使它在保密性、完整性和即需性方面显得脆弱。在保密性方面，它的许多数据以明文形式传输和存储，非常容易遭受嗅觉器的攻击；在完整性方面，它所传输或存储的数据极易遭到破坏和修改；在即需性方面，它极容易遭受拒绝服务攻击而是网络速度降到不能忍受的程度。
8.3.2 SSL的目标、体系结构和基本技术
1,SSL的目标按照优先顺序,SSL的设计目标依次为：
（ 1） 加密安全：通过保密性技术、消息完整性技术和验证，为实体之间建立安全的连接。
（ 2） 互操作性：保证不同的开发者开发的 SSL都能够成功地交换加密参数。
（ 3） 可扩展性：新的公开密钥加密方法和对称加密方法在必要时可以添加进来。
（ 4） 相对高效：通过可选的会话高速缓存机制，减少从头建立的连接数量，尽量减少加密操作占用的 CPU时间。
2,SSL体系结构
SSL体系结构如 图 8.7所示，它位于传输层之上、应用层之下。它独立与应用层，使应用层可以直接建立在
SSL上。
SSL由一些子协议组成：
（ 1） SSL记录协议（ Record Protocol）：建立在 TCP之上，用来封装高层协议。
（ 2） SSL握手协议（ Handshake Protocol）：
准许服务器端与客户端在开始传输数据前，可以通过特定的加密算法相互鉴别。
（ 3） SSL更改密码说明协议（ Change Cipher
Spec）：保证可扩展性。
（ 4） SSL警告协议（ Alert Protocol）：产生必要的警告信息。
3,SSL采用的基本技术
SSL主要是为应用层数据提供传输中的安全。
它所采用的基本技术为：
（ 1） 身份认证采用公开密钥体制；
（ 2） 数据保密采用对称密钥体制；
（ 3） 消息的完整性保护采用带密钥的消息认证码（ MAC）。
4,SSL协议运作方式
（ 1） 通信双方执行握手协议建立连接后，都可以获得共有的通信密码作加密密钥。
（ 2） 要传输的数据在执行记录协议阶段用上述通信密码加密后传送出去。对方用相同的密码作为解密密钥。
（ 3） 在运行握手协议或记录协议的过程中，任何一方有异常出现，可以用警告协议通知对方，以进行相应的处理。
（ 4） 任何一方想更换密钥时，可以运行更改密码说明协议。
8.3.3 SSL核心技术由上面的讨论可以知道,SSL记录协议和 SSL握手协议是 SSL的核心。下面分别介绍这两个子协议。
1,SSL记录协议的封装过程在 SSL体系中，当上层（应用层或表示层）的应用要选用 SSL协议时，上层（握手、警告、更改密码说明,HTTP等）协议信息，会通过 SSL记录子协议使用一些必要的程序，将加密码、压缩码,MAC等封装成若干数据包，再通过其下层（基本上都是从呼叫 socket接口层）传送出去。
记录协议的封装过程如图 8.8所示
2,SSL握手连接（ Connection）和会话（ Session）是 SSL中的两个重要概念。
一个 SSL会话是客户机与服务器之间的一个关联。
一个 SSL连接提供一种合适服务类型的传输。 SSL
连接是点对点的关系，并且连接是暂时的，每一个连接只与一个会话关联。会话定义了一组可供多个连接共享的加密安全参数，以避免为每一个连接提供新的安全参数所需的昂贵谈判代价。
客户机与服务器要建立一个会话，就必须进行握手过程。 SSL会话由 SSL握手协议创建或恢复。
图 8.9（ a） 为创建一个会话的握手过程,图 8.9（ b） 为恢复一个会话的握手过程。
下面主要介绍创建会话时的握手过程。
（ 1） Hello阶段握手协议从 Client发出的第一道信息 ClientHello开始。
① ClientHello和 ServerHello，用于协商安全参数，
包括：
协议版本号、会话识别码（ session_id）、时间戳、
密码算法协商（ cipher suit）、压缩算法、两个 28
字节随机数（ ClientHello.random和
ServerHello.random）。
② Certificate，密钥交换信息。在要验证 Server时发出。
③ ServerKeyExchange，送出 Client可以计算出共享秘密的参数，包含 Server临时公钥。这些信息一般包含在 Certificate中。只在下列情况下才由 Server
发出：
不需要验证 Server；
要求验证 Server，但 Server无证书或 Server证书是用于签名。
④ CertificateRequest,Server要求验证 Client时发出。
⑤ ServerHelloDone，表示双方握手过程的 Hello阶段结束。
这时,Server等待 Client回音。
（ 2） 加解密参数传输
① Certificate，回答 Server的 CertificateRequest要求的信息。 Server无要求时，不发。
② ClientKeyExchange，对 ClientHello和
ServerHello密钥交换算法的回复；以
ServerKeyExchange所选的算法进行，让双方可以共享秘密。
③ CertificateVerify，对此前 Server送来的所有信息
（ ClientHello,ServerHello,Certificate和
ServerKeyExchange）产生的签名，让 Server进一步确定 Client的正确性。
④ ExchangeCipherSpec,SSL更改密码说明协议消息。
⑤ 用协商好的算法和密钥加密的 Finished消息，握手完成消息。
（ 3） Server确认
① ExchangeCipherSpec，回复 Client的
ExchangeCipherSpec消息。
② 用协商好的算法和密钥加密的 Finished消息，握手完成消息。
（ 4） 会话数据传输传输应用数据。
恢复一个已经存在的会话时，握手过程一般只需要 Hello阶段。
3,SET协议和 SSL协议的比较
(1)交易效率
SET协议非常复杂、庞大，处理速度慢，系统负载重。而 SSL协议则简单得多，系统负载轻，整个交易过程仅需几秒钟，显然其工作效率要比 SET高。
(2)认证机制
SSL协议不能实现多方认证,SSL中只有商家服务器的认证是必须的，客户端认证则是可选的。相比
SET协议的认证要求较高，所有参与 SET交易的成员都必须申请数字证书，并且解决了客户与银行、
客户与商家、商家与银行之间的多方认证问题。
3,SET协议和 +SSL协议的比较
(3) 安全性
SET协议由于采用了公钥加密、信息摘要和数字签名等安全技术，可以确保信息的保密性、可鉴别性、完整性和不可否认性。 SSL协议也采用了公钥加密、信息摘要和 MAC
检测，可以提供保密性，完整性和一定程度的鉴别功能，
但由于其缺乏一套完整的认证体系，不能提供完备的防抵赖功能。从网上安全支持这一角度来看，显然 SET比 SSL针对性更强，更安全。
(4)协议层次和功能这两种协议在网络协议层的位置和功能并不相同,SSL是基于传输层的通用安全协议，它只占据电子商务体系中的一部分。从电子商务特性来看，它并不具备商务性、服务性、
协调性和集成性。而 SET位于应用层；对网络上其他各层也有涉及,SET规范了整个商务活动的流程，从而最大限度地保证了商务性，服务性、协调性和集成性。
3,SET协议和 +SSL协议的比较
(5 ) 应用范围由于 SET协议是基于信用卡交易的安全协议，它只适用于 B2C模式，在电子商务应用中具有一定的局限性。而 SSL协议现已嵌入 Navigate,IE等浏览器中，使其在电子商务的各种模式及其他需要安全的领域中得到广泛的应用 综上所分析，并结合目前我国的具体情况，可得出如下结论,．
1)近期,SET与 SSL共存，优势互补。
2)远期，开发一种能融合 SET与 SSL优点的安全协议和认证体系。
总结,SET和 SSL协议的比较安全套接层（ SSL）协议提供了两个端点之间的安全链接，能对信用卡和个人信息提供较强的保护； SSL
协议被大部分 Web浏览器和 web服务器所内置，比较容易被应用。
SET协议比 SSL协议复杂，在理论上安全性也更高，
因为 SET协议不仅加密两个端点间的连接，还可以加密和认定三方的多个信息，而这是 SSL协议所未能解决的问题。 SET标准的安全程度很高，它结合了数据加密标准 DES,RSA算法和安全超文本传输协议，为每一项交易都提供了多层加密。
SET和 SSL协议的比较
SET与 SSL相比主要有以下 4个方面的优点：
（ 1） SET对商家提供了保护自己的手段,使商务免受欺诈的困扰,
使商家的运营成本降低 。
（ 2） 对消费者而言,SET保证了商家的合法性,并且用户的信用卡号不会被窃取 。
（ 3） SET使得信用卡网上支付具有更低的欺骗概率,使得它比其他支付方式具有更大的竞争力 。
（ 4） SET对于参与交易的各方定义了互操作接口,一个系统可以由不同厂商的产品构筑 。
SET的主要缺陷：
SET协议过于复杂，对商户、用户和银行的要求比较高；
处理速度慢，支持 SET的系统费用较大。
8.4 IP Sec
8.4.1 IP安全分析
IP层是 TCP/IP中最关键的一层，也是关系整个 TCP/IP安全的核心和基础。但是，由于当初设计时的环境和考虑的基本出发点,IP没有过多地考虑防卫问题，只是设法使网络能够方便地互通互联。这种不设防政策，给
Internet造成许多安全隐患和漏洞，并随着攻击技术提高，使问题的严重性日益加剧。下面举几个例子来说明 IP遭受的安全威胁。
（ 1） IPv4缺乏对通行双方真实身份的验证能力，仅仅采用基于源 IP地址的认证机制，并且 IP地址可以进行软件配置。这样，就给攻击者以有机可乘，可以在一台计算机上假冒另一台计算机向接收方发送数据包，而接收方又无法判断接收到的数据包的真实性。这种 IP欺骗可以在多种场合制造灾难。
（ 2） IPv4缺乏不对网络上传输的数据包进行机密性和完整性保护，一般情况下 IP包是明文传输的，第三方很容易窃听到 IP数据包并提取其中的数据，甚至篡改窃取到的数据包内容，而且不被发觉，因为只要相应地修改校验和即可。
（ 3） 由于数据包中没有携带时间戳、一次性随机数等，很容易遭受重放攻击。攻击者搜集特定 IP包，进行一定处理就可以一一重新发送，欺骗对方。
（ 4） 路由器布局是 Internet的骨架。路由器不设防，将会使路由信息暴露，为攻击者提供入侵途径。
8.4.2 IP Sec的安全概念
IP Sec（ IP Security）是由 IETF以 RFC形式公布的一组安全 IP协议集，是在 IP包级为 IP
业务提供安全保护的协议标准。它使用现代密码学方法，支持机密性和认证性服务，使用户有选择地使用这些安全机制，以得到期望的安全服务。
1,IP Sec安全结构与数据包格式
IP Sec是一套协议包，它把多种安全技术集合到一起，可以建立一个安全和可靠的隧道。
IPSec的安全结构包括 3个基本协议：
（ 1） AH（ Authentication Header，认证报头）协议，
为 IP包提供信息源验证和完整性保证。
（ 2） ESP（ Encapsulating Security Payload，封装安全负荷）协议，提供加密保证。
（ 3） IKE（ Internet Key Exchange密钥交换）协议，
提供双方交流时的共享安全信息。
IPSec数据包结构如下，它是在 IP包头后面增加几个新的字段来实现安全保证。如 图 8.10所示。
2,传输模式和隧道模式
IP Sec有两种运行模式：
（ 1） 传输模式（ Transport Mode）
传输模式的特点是：
用于两个主机之间；
仅对上层协议数据部分提供安全保护，即在传输模式中，只有高层协议（ TCP,UDP，
ICMP等）及数据进行加密，源地址、目的地址以及 IP包头的内容都不加密。简单地说，
传输协议为上层协议提供安全保护。
AH和 ESP都支持传输协议。在正常情况下，
TCP数据包在 IP层中被添加 IP头后构成 IP数据包。启用 IP Sec后,IP Sec会在 TCP数据前增加 AH包头或 ESP包头或二者都增加，形成图 8.11所示的 3种传输模式 IP Sec数据包。
（ 2） 隧道模式（ Tunnel Mode）：
隧道模式的特点是：
用于有一端是安全网关或路由器；
对整个 IP数据包提供安全保护。即在隧道模式中，整个用户的 IP数据包被用来计算 ESP
包头，整个 IP包被加密并和 ESP包头一起被封装在一个新的 IP包内。于是，当数据在
Internet上传送时，真正的源地址和目的地址被隐藏起来。
IP Sec不仅可以保证隧道的安全，同时还有一套保证数据安全的措施，利用它建立起来的隧道具有更强的安全性和可靠性。一方面它可以和 L2TP等其他协议一起使用，一方面可运行于网络的任何一部分
（路由器和防火墙之间、路由器和路由器之间,PC
机和服务器之间,PC机和拨号访问设备之间）。
如果路由器要为自己转发的数据包提供 IP Sec服务，
就要使用隧道模式，并把这个 IP数据包作为一个整体进行保护，在这个 IP数据包之前添加 AH头或 ESP
头，然后再添加新的 IP头，组成新的 IP数据包发送出去。形成的新的 IP数据包如 图 8.12所示。
图 8.12 隧道模式的 IP Sec数据包这种数据包在传输的过程中，路由器只检查新的 IP头。
用于封装新 IP头，定义了从源路由器到目的路由器之间的一条虚拟路径，这就是隧道。
3,安全关联安全关联（ Security Associations,SA）是 IP Sec
的一个关键概念，它构成了 IP Sec的基础。 AH协议和 ESP协议的执行都依赖于 SA。
SA是两个 IP Sec实体（主机、安全网关）之间经过协商建立起来的一种协定，内容包括：
采用何种 IP Sec协议（ AH,ESP）；
运行模式（传输模式，隧道模式）；
采用的验证算法、加密算法、加密密钥、密钥生存期，抗重放窗口、计数器等
保护什么？如何保护？谁来保护？
一个 SA通过一个三元组来唯一标识：
（安全参数索引 SPI，目的 IP地址，安全协议（ AH或
ESP）标识符）
SA提供的安全服务取决于所选的安全协议,SA模式、
SA作用的两端点和安全协议所要求的服务。例如，
AH为 IP数据包提供的服务有：
数据源验证（但不对数据包加密）。
无连接完整性。
及抗重播服务。
接收端是否需要这一服务，可以自行决定。
ESP为 SA提供的服务有：
加密和验证（不包括外 IP头），或者其中之一。这种有限业务流机密性可以隐藏数据包的源地址和最终目的地址。
对数据包进行填充，从而隐藏了数据包的真实大小，进而隐藏了其通信特征。
抗重播服务。
SA仅为其上所携带的业务流提供一种安全机制（ AH或 ESP）。如果需要对特定业务提供多种安全保护，就要有多个 SA序列的组合 —
—SA捆绑。
4,安全策略数据库与安全关联数据库在 IP Sec中，为处理 IP业务流，需要维护两个与 SA相关的数据库：安全策略数据库
（ Security Policy Database,SPD）与安全关联数据库（ Security Association Database，
SAD）。
（ 1） SAD
SAD由一系列 SA条目组成，每个条目定义了一个 SA的参数，所以 SAD包含了与每个活动
SA相关的所有参数信息。
（ 2） SPD
安全策略（ Security Policy,SP）定义了对所有入数据 /出数据应当采取的安全策略，决定了为一个包提供的安全服务以及以什么方式提供。 SPD实际上不是通常意义上的数据库，而是将所有的 SP定义了对所有出 /入业务应当采取的安全策略，以某种数据结构集中存储列表。当要将 IP包发出去或者接收到
IP包时，首先要查找 SPD来决定如何进行处理。
SPD对 IP包的处理有 3种可能：
丢弃。
绕过 ——不用 IP Sec。
采用 IP Sec。
5,IP Sec的安装当 IP Sec运行于路由器 /网关时，安装配置简单，只需在网络设备上进行配置，由网络提供安全性。
当 IP Sec运行于服务器 /PC机时，可以提供端到端的安全，在应用层进行控制，缺点是安装配置和管理比较复杂。
8.4.3 IP Sec体系结构
IP Sec各部件之间的关系结构如图 8.13所示下面对有关部分作进一步介绍
1,AH协议
（ 1） 功能
AH为 IP包提供数据完整性和验证服务：
对数据使用完整性检查，可以判定数据包在传输过程中是否被修改。
通过验证机制，终端系统或设备可以对用户或应用进行验证，并过滤通信流；还可以防止地址欺骗和重放攻击。
（ 2） 格式
AH具有 图 8.14所示的格式
下一个头（ 8比特）：标识紧跟验证头的下一个头的类型。
载荷长度（ 8比特）：以 32比特为单位的验证数据长度加 1。如，缺省的验证数据字段长度为 96比特，
为 3个 32比特，加上 1，得 4。即缺省的验证数据的
AH头的载荷长度为 4。
保留（ 16比特）：备以后使用。
安全参数索引（ 32比特）：用于标识一个安全关联。
序号（ 8比特）：无符号单调递增计数值，用于 IP数据包的重放检查。
验证数据（ 32比特的整数倍的可变长数据）：包含有数据包的 ICV（完整性校验值）或 MAC。
2,ESP协议
（ 1） 功能为 IP数据包提供如下服务：
数据源验证。
数据完整性。
抗重放。
机密性。
（ 2） 格式
ESP具有 图 8.15所示的格式
下一个头（ 8比特）：通过标识载荷中的第一个头
（如 IPv6中的扩展头，或诸如 TCP等上层头）决定载荷数据字段中数据的类型。
安全参数索引（ 32比特）：标识一个安全关联。
序号（ 8比特）：无符号单调递增计数值，用于 IP数据包的重放检查。
验证数据（ 32比特的整数倍的可变长数据）：用于填入 ICV（完整性校验值）。 IVC的计算范围为 ESP
包中除掉验证数据字段部分。
填充项（ 0~255比特）：额外字节。
填充长度（ 8比特）：填充的字节数。
载荷数据（可变）：在传输模式下为传输层数据段，
在隧道模式下为 IP包。
3,密钥交换协议
IP Sec的密钥管理包括密钥的确定和分配，
可以采用手工或自动方式进行。 IP Sec默认的自动密钥管理协议是 IKE。
IKE规定了验证 IP Sec对等实体、协商安全服务和生成会话密钥的方法。 IKE将密钥协商结果保留在 SA中，供 AH和 ESP以后通信时使用。
IKE有 4种身份认证方式：
（ 1） 基于数字签名的认证：利用数字证书表示身份，
利用数字签名算法计算出一个签名来验证身份。
（ 2） 基于公开密钥的认证：用对方的公钥加密身份，
通过检查对方发来的该 Hash值进行认证。
（３） 基于修正的公钥，对上述方式修正。
（４） 基于预共享字符串：双方事先商定好一个双方共享的字符串。
DOI的作用是为使用 IKE进行协商 SA的协议统一分配标识符。
4,加密和验证算法
IP Sec的加密只用于 ESP。目前的 IP Sec标准要求任何 IP Sec实现都必须支持 DES，此外还可以使用
3DES,RC5,IDEA,3IDEA,CAST和 Blowfish。
由于 DES在网络上加密的缺点，今后将有采用
3DES和 AES（高级加密标准）的趋势。
IP Sec的验证算法可用于 AH和 ESP，主要采用
HMAC。 HMAC将消息和密钥作为输入来计算 MAC。
MAC保存在 AH/ESP头中的验证数据字段中。目的地收到 IP包后，使用相同的验证算法和密钥计算一个新的 MAC，并与数据包中的 MAC比对。
8.5 VPN技术虚拟专用网（ VPN,Virtual Private
Network），是指将物理上分布在不同地点的专用网络，通过不可信任的公共网络构造成逻辑上的虚拟子网，进行安全的通信。这里公共网络主要指 Internet。
8.5.1 VPN的基本原理图 8.16为 VPN的结构示意图。在这个图例中，
有 4个内部网，它们都位于一个 VPN设备的后面，同时由路由器连接到公共网。 VPN技术采用了加密、认证、存取控制、数据完整性等措施，相当于在各 VPN设备间形成一些跨越 Internet的虚拟通道 ——“隧道”，使得敏感信息只有预定的接收者才能读懂，实现信息的安全传输，使信息不被泄露、篡改和复制。
图 8.16 VPN的结构与基本原理
VPN的基本处理过程为：
① 要保护的主机发送明文信息到其 VPN设备；
② VPN设备根据网络管理员设置的规则，确定是对数据进行加密还是直接传送；
③ 对需要加密的数据,VPN设备将其整个数据包
（包括要传送的数据、源 IP地址和目标 IP地址）进行加密并附上数字签名，加上新的数据报头（包括目的地 VPN设备需要的安全信息和一些初始化参数），重新封装；
④ 将封装后的数据包通过隧道在公共网上传送；
⑤ 数据包到达目的 VPN设备，将数据包解封，核对数字签名无误后，对数据包解密。
8.5.2 隧道协议隧道技术是 VPN技术的核心，它涉及到数据的封装，
可以利用 TCP/IP协议作为主要传送协议以一种安全的方式在公用网络（如 Internet）上传送。隧道分为两种方式：强制型隧道和自愿型隧道。强制型隧道不需要用户在自己的计算机上安装特殊的软件，使用起来比较方便，主要供 ISP将用户连接到 Internet
时使用。自愿型隧道则需要用户在自己的计算机中安装特殊的软件，以便在 Internet中可以任意使用隧道技术，完全地控制自己数据的安全。
在 VPN中，双方的通信量很大，并且往往很熟悉，
这样就可以使用复杂的专用加密和认证技术对通信双方的 VPN进行加密和认证。为了实现这些功能，
隧道被构造为一种 3层结构：
（ 1） 最底层是传输。传输协议用来传输上层的封装协议,IP,ATM,PVC和 SVC都是非常合适的传输技术。其中因为 IP具有强大的路由选择能力，可以运行于不同的介质上，因而应用最为广泛。
（ 2） 第二层是封装。封装协议用来建立、保持和拆卸隧道，或者说是数据的封装、打包与拆包。
（ 3） 第三层是认证。
每一层的功能都是由相应的协议支持的，下面介绍一些有关的协议。
1,点对点隧道协议 PPTP
PPTP（ Point-to-Point Tunneling Protocol）
是基于 IP的点对点隧道协议，它将其他协议和数据封装于 IP网络，用公共的 Internet创建
VPN，使远程用户能够透过任何支持 PPTP和
ISP访问某一专用网。
通过 PPTP，客户可以采用拨号方式接入到 ISP再接入到公共 IP网络 Internet。具体过程为：客户按常规方式拨号到 ISP的接入服务器（ NAS），建立 PPP连接；在此基础上，进行第二次拨号，建立到 PPTP服务器的连接，即建立 PPTP隧道。对于直接连接到
Internet上的客户，不需要第一次的 PPP连接，可以直接与 PPTP服务器建立虚拟通道。可以说,PPTP
实质上是基于 IP的 PPP协议的扩展，它只支持 IP作为传输协议，但其 IP数据报可以封装多种协议数据，
包括 TCP/IP,IPX和 NetBEUI。 PPTP采用了基于
RSA公司的 RC4的数据加密方法，提供了一种在
Internet上建立多协议的安全 VPN通信方式。
2,第 2层转发协议 L2F
L2F是由 Cisco公司提出的可以在多种传输网络（如 ATM、帧中继,IP网）上建立多协议的安全虚拟专用网的通信方式。远程用户能够通过拨号方式接入公共网络。具体过程为：
客户按常规方式拨号到 ISP的接入服务器
（ NAS），建立 PPP连接； NAS根据用户名等信息，发起第二重连接，通向 FGW服务器。
在这种情况下，隧道的配置和建立对用户完全透明。
3,第 2层隧道协议 L2TP
L2TP是把数据链路层 PPP帧封装在公共网络设施如 IP,ATM、帧中继中进行隧道传输的封装协议。 L2TP主要由 L2TP访问集中器 LAC
（ L2TP Access Concentrator）和 L2TP网络服务器 LNS（ L2TP Network Sever）组成。
LAC支持客户端的 L2TP，用于发起呼叫，接收呼叫和建立隧道； LNS是所有隧道的终点。
L2TP的建立过程为：
① 用户通过公共电话网或 ISDN拨号至本地，
接入服务器 LAC（ LAC是连接的终点）；
② LAC接收呼叫并进行辨认，如果用户被认为是合法用户，就建立一个通向 LNS的 VPN
隧道；
③ 内部网的安全服务器（如 TACACS+，
RADIUS等）鉴定拨号用户；
④ LNS与远程用户交换 PPP信息，分配 IP地址；
⑤ 端对端的数据从拨号用户传到 LNS。
与 PPTP与 L2F相比,L2TP的优点是它提供了差错和流量控制。此外，作为 PPP的扩展，
L2TP支持标准安全特性 CHAP和 PAP，可以进行用户身份认证。 L2TP定义了控制包的加密传输，对每个隧道生成一个独一无二的随机密钥，以抵御欺骗性的攻击，但是它对传输中的数据不加密。
8.5.3 IP Sec VPN和 SSL VPN
目前,IP Sec和 SSL是实现 VPN的两大实现技术。
其中 IP Sec VPN是基于网络层的,SSL VPN是基于应用层的。下面分别介绍它们实现 VPN的思想。
1,IP Sec VPN
IP Sec VPN是网络层的 VPN技术，表示它是独立于应用程序的。采用隧道运行模式的 IP Sec可以一自己的头（ AH或 ESP）去封装原始的 IP数据包，隐藏所有的应用协议信息，进而实现各种类型的一对多的连接，如 Web、电子邮件、文件传输,VoIP等连接。
2,SSL VPN
SSL是一种在 Internet上保证发送信息安全的通用协议，它基于公钥加密进行工作。由于它建立在应用层上，与 IP Sec相比，更容易提供细粒度的远程访问和企业外网 VPN需要的控制。
SSL VPN以 HTTP为基础。由于目前大多数计算机在出厂时都安装了支持 HTTP和 HTTPS（以 SSL为基础的 HTTP）的 Web浏览器，所以通常把 SSL
VPN称为“无客户端”。
3,SSL VPN与 IP Sec VPN的特性比较表 8.1为 SSL VPN与 IP Sec VPN的特性比较。
表 8.1 SSL VPN与 IP Sec VPN的特性比较习 题
1,在不可否认的电子公文流转协议中，若遇到下面的情形，应如何处理？
（ 1） 收文方在超时后，仍然没有收到发文方的主密码。
（ 2） 收文方验证的签证不吻合。
2,用一个实例说明在 SET支持下的电子购物的工作流程。
3,SET能不能支持 B to B的交易过程？
4,为什么在 SET中要明确参与角色，而 SSL
中没有？
5,SSL如何解决 Web中的安全问题？
6,IP Sec如何解决 IP面临的安全威胁问题？
7.举例说明 IP Sec有哪些应用。
8,试述 VPN的工作原理，叙述 VPN与租用专线有何区别。
9,试设计一个用防火墙构造 VPN的方案。
10,查阅资料，对目前市场上的各种 VPN产品的技术性能和经济性能进行分析比较。
