1、2022年11月3日星期四第七章第七章 Internet安全安全7.1 Internet的安全要求Web和电子邮件自身存在的各种问题：1.Web服务器对于来自Internet的攻击显得十分脆弱。2.Web服务器的重要性日益增加。Web服务器被破坏，除了名誉受损外，经济上也会遭受损失。3.Web服务器底层软件异乎寻常的复杂。复杂的软件可能隐藏更多的潜在安全问题。4.Web服务器有可能成为进攻内部网的跳板。5.没有经过训练的用户不了解存在的安全风险。6.电子邮件的问题主要是防止欺骗和保证内容的隐私性。7.电子邮件是传播病毒最快捷的途径。Return7.2 SSL/TLS SSL(Secure So
2、cket Layer)是一个用来保证安全传输的Internet协议。该协议通过在两个实体(客户和服务器)之间提供一个安全通道，来实现数据在Internet中传输的保密性。1994年，Netscape公司最先提出了SSL，该协议目 前 有 三 个 版 本：S S L v 2、S S L v 3 和TLSv1(SSLv3.1)。1995年发布的SSLv3是主要版本。第三版的设计经过了公开的评论并且吸收了工业界的意见。1996年Netscape公司将SSL规范提交给IETF。IETF成立了专门的TLS工作组对SSLv3进行标准化。TLS的第一个正式版本已于1999年发布，其本质上可以看成是SSLv3
3、.1，与SSLv3非常接近并且兼容。7.2.1 SSL结构 SSL握手协议握手协议SSL修改密码协议修改密码协议 SSL告警协议告警协议应用层协议SSL记录协议记录协议TCPIP7.2.2 SSL会话和SSL连接 两个重要的概念：SSL连接和SSL会话。SSL连接：本质上讲就是TCP连接，不同之处在于每个连接要与一个SSL会话相关联。SSL会话：是客户和服务器之间的关联，会话通过握手协议来创建。会话定义了加密安全参数的一个集合，该集合可以被多个SSL连接所共享。在任何一对交互实体之间可能存在多个安全连接，在交互实体之间也可以同时存在多个会话。SSL会话是有状态的，主要的状态有：当前读和当前写、
4、挂起读和挂起写。由握手协议来协调客户端和服务器端的会话状态。会话状态的相关参数：会话标识符 对方的证书 压缩方法 密码规范(加密算法，MAC算法及加密属性)主密钥(48字节密钥)可重用否：一个标志，用于指明该会话是否可以用来初始化一个新的连接。连接状态的相关参数：服务器端和客户端随机数(连接)服务器端写MAC密钥 客户端写MAC密钥 服务器写密钥(对称加密)客户写密钥(对称加密)初始向量(CBC)序列号(报文；64Bit)7.2.3 SSL记录协议1、记录协议的功能和报文格式 功能功能：将上层传来的数据进行分段、压缩、MAC值计算和加密处理，并添加记录报头，然后交给下层协议；当收到下层传来的数
5、据时，进行相反的处理，然后交给上层协议。记录协议为高层提供两种服务两种服务：机密性服务和报文鉴别服务。SSL可为多种TCP/IP应用提供基本安全服务。(IANA)已经为具备SSL功能的应用分配了固定端口号，例如，带SSL的HTTP(https)被分配的端口号为443，带SSL的SMTP(ssmtp)被分配的端口号为465，带SSL的NNTP(snntp)被分配的端口号为563。记录协议报文格式如图所示 内容类型(8比特)，高层协议：修改密码规范、告警、握手和应用数据。主要版本(8比特)次要版本(8比特)压缩长度(16比特)数据 MAC字段内容类型 主要版本 次要版本 压缩长度 数据(可选压缩)
6、MAC(0,16,20字节)报文首部加密部分2、记录层报文的产生过程应用数据分段压缩计算MAC加密添加首部允许使用的加密算法：分组密文流密文算法密钥长度算法密钥长度IDEA128RC4-4040RC2-4040RC4-128128DES-4040DES563DES168Fortezza807.2.4 SSL修改密码协议与告警协议1、修改密码协议 修改密码协议是使用SSL记录协议的三个SSL有关协议之一，目的是使挂起状态被复制到当前状态，改变了这个连接将要使用的密码算法。这个协议由单个报文组成，而报文又由值为1的单个字节组成。2、告警协议 告警协议是用来将SSL有关的告警传送给对方实体。和其他使
7、用SSL的应用一样，告警报文按照当前状态被压缩和加密。该协议的每个报文由两个字节组成。第一个字节为告警级别(警告和致命)。第二个字节包含了指出特定告警的代码。如果级别是致命的，SSL将立刻终止该连接，但同一会话的其他连接可以继续，但该会话不能再建立新的连接了。7.2.5 SSL握手协议 握手协议的功能和报文格式 握手协议用来协商会话的安全属性。握手协议产生的报文作为记录层的数据，按照当前活动会话的状态被封装、处理和传输。握手协议的功能主要包括：服务器与客户间的相互身份鉴别；协商加密和MAC算法；交换加密密钥。握手协议由一组在客户和服务器之间交换的报文组成。握手协议报文由三个字段组成：类型(1字
8、节)；长度(3字节；字节为单位)；内容(1字节)(P174-177)Return7.3 S-HTTP7.3.1 HTTP介绍2、报文结构 HTTP有两类报文：请求报文和响应报文。方法URI版本请求行空格回车换行首部字段名：值首部字段名：值实体主体首部行版本状态码短语状态行首部字段名：值首部字段名：值实体主体首部行请求报文响应报文HTTP请求报文 典型的HTTP请求报文如下：GET/PUBLIC/docu.html HTTP/1.1（请求行）Connection：close （首部行）User-agent：Mozilla/4.0Accept：text/html，audio/base，image/
9、gif，video/mpegAccept-language：en（空行）HTTP响应报文 典型的HTTP响应报文如下：HTTP/1.1 200 OK （状态行）Connection：Close （从这行开始的6行都是首部行）Date：Wed，16 Oct 2002 12:36:15 GMTServer：Apache/1.3.0 (Unix)Last-Modified：Mon，11 Aug 2002 10:30:28 GMTContent-Length：5963 （文件长度的字节数）Content-Type：text/html （空行）DATA DATA DATA （所请求的文件）7.3.2 S
10、-HTTP基本原理1、S-HTTP消息的创建S-HTTP包括消息首部和加密消息主体，消息首部中可能包含了指示接收者应如何解释消息主体以及此后接收者应该怎样执行消息主体的信息。消息发送者：客户端/服务器。S-HTTP消息的创建需要以下信息：明文消息接收者支持的加密方法和密钥素材发送者支持的加密方法和密钥素材发送者将自己支持的加密方法和接收者支持的加密方法综合在一起，形成双方支持的加密方法和相关密钥素材表，通过使用这些数据，发送者可以将明文消息转换成S-HTTP消息。2、S-HTTP消息的恢复 S-HTTP消息的恢复过程需要以下信息：S-HTTP消息 接收者先前声明所支持的加密方法和密钥素材。接收
11、者目前支持的加密方法和密钥素材 发送者先前声明所支持的加密方法和密钥素材 为了恢复一个S-HTTP消息，接收者需要阅读该消息的首部，以确定发送者对消息主体进行的密码操作，然后对消息进行解密恢复出明文。3、S-HTTP的安全机制 S-HTTP协议对消息的保护主要分为三个方面：消息签名、消息鉴别和消息加密，一个S-HTTP消息可以被签名、鉴别、加密或三者的任意组合，当然也包括与HTTP兼容的明文传输方式。S-HTTP提供了多种密钥管理机制 S-HTTP安全机制的要点：签名(将证书或证书链附加在消息中传给对方)密钥交换和加密(In band公钥,Out band秘密密钥；对称加密)消息完整性和发送者
12、鉴别(MAC,MD2;MD5;SHA)challenge-response机制(防止重放攻击)4、S-HTTP的协商内容 S-HTTP标准允许通信的双方表达他们的请求或偏好，根据实现能力和特殊的申请请求作出合适的选择。S-HTTP用协商首部来传送权限和请求。下面给出了常用的协商首部字段：SHTTP-Certificate-Types字段：指出所接收的证书类型。(X.509)SHTTP-Key-Exchange-Algorithms字段：指出密钥交换算法。(in-band、out-band)SHTTP-Signature-Algorithms字段：指出数字签名算法。(RSA、DSS)SHTTP-
13、Message-Digest-Algorithms字段：指出报文摘要算法。(MD5、SHA)SHTTP-Symmetric-Content-Algorithms字段：指出对称加密算法。(DES、3DES、RC4)7.3.3 S-HTTP的报文格式 S-HTTP消息报文的格式与HTTP是相同的，即都是由一个请求行/状态行、后面跟首部行和一个实体部分，所不同的是首部的内容范围及实体部分在典型情况下是加密的。1、请求行：为了区分S-HTTP报文、HTTP报文和所允许的特殊处理，请求行使用了特殊的安全方法“Secure”和协议标识符“Secure-HTTP/1.4”。S-HTTP和HTTP进程都使用相
14、同的TCP端口号80。为了防止敏感信息的泄露，请求URI将由“*”替代，请求行的例子如下：Secure*Secure-HTTP/1.4 2、状 态 行：S-H T T P 响 应 使 用 协 议 标 识 符“Secure-HTTP/1.4”。状态行的例子如下：Secure-HTTP/1.4 200 OK 3、首部行：S-HTTP定义了一系列新首部行。Content-type：message/http表明S-HTTP报文封装的是HTTP消息。Content-type：application/s-http表明S-HTTP报文封装的是非HTTP数据。Content-Privacy-Domain首部行
15、有两个取值：CMS或MOSS。CMS是英文“Cryptographic Message Syntax Standard”的缩写，是一种类似于PEM标准的加密消息封装格式。MOSS是英文“MIME Object Security Services”的缩写，指明消息实体中携带的是MIME兼容消息。Prearranged-Key-Info首部行指明密钥交换方法，取值有：Inband,Outband。MAC-Info首部行说明用于消息鉴别码计算的散列函数和共享密钥。S-HTTP报文格式的详细描述可以参阅RFC-2660Return7.4 安全电子交易(SET)7.4.1 概述 7.4.2 SET的商业
16、需求和主要特点 7.4.3 SET协议中的参与者和交易事件序列 7.4.4 双重签名 7.4.5 支付处理 Return7.4.1 概 述v安全电子交易(Secure Electronic Transaction，SET)是设计用来保护Internet上信用卡交易的安全协议。版本SETv1是在1996年2月根据Master Card和Visa安全标准需要设计的。vSET本身不是一个支付系统。而是一个安全协议和格式的集合，它使得用户可以以一种安全的方式，将已经存在的信用卡支付基础设施配置在开放网络(例如Internet)上。SET协议工作在应用层。v从本质上讲，SET提供了三种服务：在交易涉及的
17、各方之间提供安全的通信信道。通过使用X.509v3数字证书来提供信任。保证机密性，信息只是在必要的时候、必要的地方才对交易各方可用。Return7.4.2 SET的商业需求和主要特点 了解SET协议首先要了解它的商业背景和主要特点。1、商业需求在开放网络上使用支付卡进行安全支付处理的商业需求：保证订购信息和支付信息的机密性。保证所有传输数据的完整性。对卡的拥有者进行鉴别。对商家是否可以接受支付卡交易进行鉴别。使用最好的安全策略和系统设计技术来保护电子商务交易中的所有合法方。创建既不依赖于运输层安全机制又不阻止它们使用的协议。2、SET协议的特点：(1)信息机密性：必须确保持卡人的账号和支付信息
18、在通过网络传输时的安全性。(2)数据完整性：SET协议保证信息内容在传输过程中不被修改。(3)持卡人账号的鉴别：SET协议提供了一种方法来鉴别持卡人是否是有效支付卡帐号的合法用户。(4)商人的鉴别：SET也提供了持卡人鉴别商家的方法。(5)互操作性：可以在不同的硬、软件平台上应用该规范。Return7.4.3 SET协议中的参与者和交易事件序列1、SET协议模型中的参与者SET协议改变了传统支付系统中参与者之间的相互作用模式。在传统面对面的零售交易或邮购交易中，电子处理过程开始于商家或收单行。而在SET的交易模型中，电子处理过程则开始于持卡人。SET协议模型中的参与者包括如下成员：(1)持卡人
19、(2)发卡行(3)商家(4)收单行(5)支付网关(6)证书管理机构(CA)SET协议模型中的参与者U N I V E R S I T YU N I V E R S I T Y支付网络支付网络U N I V E R S I T YU N I V E R S I T Y证书管理机构发卡行持卡人收单行支付网关商家2、交易事件序列(1)消费者申请支付卡(成为持卡人)(2)消费者获得电子身份证书(3)商家获得电子身份证书(两个证书)(4)消费者提出订购请求(5)消费者鉴别商家(6)消费者发送订购和支付信息(被加密)(7)商家请求支付认可(8)商家确认该项订购(9)商家提供货物或服务(10)商家请求支付R
20、eturn7.4.4 双重签名 在介绍SET协议的细节之前，先讨论SET协议引入的一个重要概念：双重签名。双重签名的目的：是为了连接两个发送给不同接收者的报文。通常，消费者要将订购信息(OI)发送给商家，将支付信息(PI)发送给银行。商家不必知道消费者的信用卡号码，银行也不必知道消费者订单的细节。但是，这两个项目必须采用一种必要时可以用来解决争执的方式连接起来。这种连接是必需的，因为消费者可以证明这个支付是用于这次订购而不是用于其他的货物或服务。1、双重签名的创建P I M D=H(P I);O I M D=H(O I);POMD=H(PIMD|OIMD)DS=EKRcH(H(PI)|H(OI
21、)其中PI是支付信息，OI是订购信息，KRc是消费者的私有密钥。KRcOIMDPIMDPOMDHOIEPIHH2、双重签名的验证 商家验证双重签名：商家获得了双重签名(DS)、OI、PI的报文摘要(PIMD)以及从消费者证书中取得消费者的公开密钥KUc后。商家可以计算下面两个数值：H(PIMD|H(OI)和DKUcDS其中KUc是消费者的公开密钥。如果这两个数值相等，商人就验证了该双重签名。银行验证双重签名：银行获得了DS、PI、OI的报文摘要(OIMD)以及消费者的公开密钥KUc后，银行可以计算下面两个数值：H(H(PI)|OIMD)和DKUcDS如果这两个数值相等，银行就验证了该双重签名。
22、3、双重签名的使用(1)商家收到OI并通过验证双重签名来鉴别OI信息。(2)银行收到PI并通过验证双重签名来鉴别PI信息。(3)消费者将OI和PI连接起来并且能够证明这种连接关系。假设商家为了自己的利益，想要在这个交易中用另一个OI来冒充，就必须找到另一个OI，其散列码与现有OIMD相匹配，这在计算上是不可行的。因此，商家不能将另一个OI与这个PI相连接。Return7.4.5 支付处理1、SET支持的交易类型持卡人注册，商家注册(向CA注册)；购买请求，支付认可(检验持卡人卡账号的支付能力)，支付获取(商家向支付网关请求支付)；证书调查和状态，购买调查(持卡人检查订购处理的状态)，认可撤消(
23、商家更正以前的认可请求)，获取撤消(商家纠正获取请求中的差错)，退款，退款撤消，支付网关证书请求等。这里将重点讨论购买请求、支付认可和支付获取三种交易类型的细节。2、参与者证书说明 在SET协议中，处于Internet环境的参与者有持卡人、商家和支付网关，为了证明自己的身份，它们必须从所属的CA处获得证书。持卡人证书：CA在向持卡人颁发证书时，要求持卡人提供帐户信息并通过发卡行进行验证。如果信息属实且符合条件，CA将生成持卡人帐户信息摘要(HMAC)并嵌入证书中。商家证书：商家在向CA申请证书前，必须先要与收单行建立委托关系。CA在受理商家的证书申请后，通过收单行进行验证。如果信息属实且符合条
24、件，CA将向商家颁发证书。商家通常需要两个证书：签名证书和密钥交换证书。支付网关证书：支付网关通常需要两个证书：签名证书和密钥交换证书。3、购买请求初始阶段：持卡人进行商品的浏览、选择和订购后，商家将完整的订购表格发送给消费者，初始阶段是在不使用SET协议的情况下进行的。购买请求阶段：需要交换四个报文(发起请求、发起响应、购买请求和购买响应)。卡卡用用户户商商家家支支付付网网关关发发卡卡行行发起请求发起响应购买请求购买响应认可请求认可响应认可请求认可响应获取请求获取响应清算请求请算响应v发起请求报文：(卡用户商家)目的：请求商家和支付网关的证书(身份鉴别)。明文传输。报文主要内容：请求/响应对
25、ID、现时C、信用卡商标、发卡行标识v发起响应报文：(商家卡用户)商家生成响应，并用自己的私有密钥对其签名。报文主要内容：请求/响应对ID、现时C、现时M、交易ID、商家签名证书、支付网关密钥交换证书v购买请求：(卡用户商家)收到响应报文后，卡用户通过相应的CA签名来验证商家证书(签名证书)和网关证书(密钥交换证书)。然后检验报文的合法性。创建OI和PI(商家赋予的交易ID被放在OI和PI中)。OI中并不包含明显的订购数据，如货物的数量和价格。它包含了在交换SET报文之前购物阶段期间，商家和消费者之间交换时生成的订购的引用。接下来，卡用户准备购买请求报文。为了这个目的，卡用户生成了一次性的对称
26、加密密钥KS。双签名KUbOIMDPIMDEOIPIEKs数字信封双签名用户证书请求报文KUb：支付网关的公钥Ks：会话密钥v购买响应：(商家卡用户)商人收到了购买请求报文后，进行如下处理：验证卡用户的证书。(签名证书)使用消费者证书中的公开密钥来验证双重签名。处理订购信息，并将支付信息转交给支付网关。(支付认可)向卡用户发送购买响应报文。商家验证消费者的购买请求 POMDKUcPOMDPIMDHOI数字信封双签名用户证书请求报文HD比较比较将被商家发送到支付网关将被商家发送到支付网关 购买响应报文包括：响应块 响应块签名 商家的签名证书。该响应块确认订购并且引用了相应的交易号码。商家使用签名
27、证书的私有密钥对响应块进行签名。当持卡人的软件收到了购买响应报文时，它验证商家的签名证书，然后验证响应块上的签名。基于响应报文采取动作(显示消息,修改数据库订购状态)。4、支付认可在收到来自持卡人的购买请求后，如果证书和双签名验证通过，在向持卡人发送购买响应报文之前，商家要请求支付网关认可该项交易。支付认可将保证交易得到了发卡行的批准，且保证商家可以得到支付。支付认可由两个报文组成：认可请求和认可响应。在完成支付认可过程后，商家才决定是否向卡用户发购买响应报文。认可请求：(商家支付网关)商家向支付网关发送一个认可请求报文，该报文由以下几个部分组成：(1)与购买有关的信息：(来自消费者)PI：支
28、付信息。双重签名DS：用消费者的私有密钥签名。OI报文摘要(OIMD)数字信封：封装会话密钥。(2)认可有关的信息：(由商家生成)认可数据块：包括一个使用商家私有密钥签名的，并且使用商家生成的一次性对称密钥加密的交易ID。数字信封：通过使用支付网关密钥交换证书中的公开密钥对一次性对称密钥进行加密形成。(3)证书：包括卡用户签名密钥证书和商家签名密钥证书和商家密钥交换证书。用会话密钥加密 支付网关在收到商家发来的认可请求报文后，完成下面一些任务：验证所有的证书。(用户签名证书、商家签名证书、商家密钥交换证书)用私钥解密认可数据块的数字信封以获得对称密钥，然后解密认可数据块。验证认可数据块中商家的
29、签名。用私钥解密支付数据块的数字信封以获得对称密钥，然后解密支付数据块(PI，DS，OIMD)。验证支付数据块的双重签名。验证从商家那里收到的交易ID与从消费者那里收到的PI中的交易ID是否匹配。向发卡行请求和接收一个认可。POMDKUcPOMDOIMDHPI数字信封双签名用户证书认可请求HD比较比较数字信封认可数据块商家密钥证书商家签名证书DKRbDKs2鉴别鉴别支付数据块 认可响应(支付网关商家)从发卡行获得了认可之后，支付网关向商家返回认可响应报文。它包括如下内容：与认可有关的信息。认可数据块，使用支付网关的私有签名密钥进行签名，并且使用支付网关生成的一次性对称密钥进行加密。数字信封，该
30、数字信封使用商家密钥交换证书中的公开密钥对一次性对称密钥进行加密形成。获取权标信息，这个信息将影响以后的支付。该数据块的形式与认可数据块相同，即签名并加密的获取权标加上数字信封。证书，支付网关的签名证书。商家收到来自支付网关的认可响应报文后，完成如下工作：验证支付网关的签名证书。用商家密钥交换证书中的私钥解密数字信封获得对称密钥并解密认可响应数据。用支付网关签名证书中的公钥验证认可数据块中的签名。保存加密的获取权标信息和对应的数字信封，之后的支付获取过程要用到这些信息。商家这时可以按照持卡人定单的要求提供货物或服务了。5、支付获取 支付获取由获取请求和获取响应报文组成。获取请求(商家 支付网关
31、)获取请求报文包含商家生成、签署并加密的获取请求数据块。该数据块中包括了支付的数量和交易ID。获取请求报文还包括以前收到的关于这个交易的加密的获取权标(在认可响应中)。商家的签名证书和密钥交换证书。当支付网关收到了获取请求报文后：解密并验证获取请求数据块。解密并验证获取权标块。检查获取请求和获取权标的一致性。创建清算请求并通过私有支付网络发送给发卡行，这个请求引起资金被划拨到商家的账户中(清算响应)。支付网关在获取响应报文中通知商家支付情况。获取响应报文包括由支付网关签名和加密的获取响应数据块。报文还包括支付网关的签名证书。商家的软件将这个获取响应保存下来，用于同从获得者(收单行)那里接收的支
32、付相匹配。SET协议的报文交互卡卡用用户户商商家家支支付付网网关关发发卡卡行行发起请求发起响应购买请求购买响应认可请求认可响应认可请求认可响应获取请求获取响应清算请求请算响应Return7.5 电子邮件的安全性 v电子邮件是因特网上使用最多的网络应用之一，也是惟一在所有网络结构和厂家平台上被广泛支持的分布式应用。v电子邮件面临的安全问题可分为两类：电子邮件自身的安全：存在邮件的假冒、篡改和窃听。可通过鉴别和加密等安全机制解决。网络的电子邮件应用已经成为网络安全的薄弱环节，许多计算机病毒或其他恶意代码，通过电子邮件进入内部网，造成巨大危害。v本节主要讨论电子邮件自身的安全问题。v用来保护电子邮件
33、安全的因特网协议主要有三种：PEM(Privacy Enhanced Mail)：由IETF组织开发，用于因特网环境的安全邮件系统。具有数据加密、源点鉴别和完整性保护功能。PGP(Pretty Good Privacy)：主要由Phil Zimmermann开发，是自由软件。PGP提供了电子邮件机密性和鉴别的服务，可以用于电子邮件和文件存储应用。S/MIME(Secure/Multipurpose Internet Mail Extension)安全通用Internet邮件扩展7.5 电子邮件的安全性 7.5.1 PGP加密软件 7.5.1.1 PGP概述 7.5.1.2 PGP基本服务描述
34、7.5.1.3 PGP密钥管理 7.5.2 S/MIME 7.5.2.1 MIME介绍 7.5.2.2 S/MIME的功能 7.5.2.3 S/MIME报文 7.5.1.1 PGP概述 PGP的最初版本是由Phil Zimmermann开发的并作为共享软件在网上发表，后经网上各国程序员的不断完善形成了现在的PGP加密软件版本。PGP加密软件为电子邮件应用提供了机密性和鉴别服务，并可用于文件的存储。PGP加密软件所采取的措施主要有：选择经过考验的、无专利问题困扰的加密算法作为基础构件。将所选算法有机地整合在一起，形成可靠的整体安全性。使软件易于移植，易于使用。为了在网上发布，并免费提供给用户使用
35、，制作了包括源代码的软件包和相关文档。与商业公司合作，为需要服务的用户提供与免费PGP完全兼容的、低价格商用版本。由于采取了上述措施，PGP发展的非常迅速，已被广泛应用。这为具有相同想法的人提供了一个很好的借鉴。PGP成功的原因可以概括如下：作为Internet上的共享软件，在世界范围内可以免费得到。软件包括能在不同平台上运行的多个版本。另外，低价的商用版本满足了那些想要获得厂家技术支持的用户的需要。使用经过实践检验、成熟的安全算法。如RSA、DSS和Diffie-Hellman公钥算法；CAST-128、IDEA和3DES常规加密算法；以及散列算法SHA-1。应用范围广。可用于文件加密和网上
36、信息的安全传输。公司、组织和个人都可使用。不属于任何政府或组织。Return7.5.1.2 PGP基本服务描述PGP提供五种基本服务：1.鉴别2.机密性3.压缩4.电子邮件的兼容性5.分段1.鉴别：(RSA和SHA-1、DSS和SHA-1)KRaHEZZ-1DHKUa比较比较源点源点A终点终点B2.机密性:EPECZZ-1DPKRb源点源点A终点终点BKsDCKsKUb机密性与鉴别结合：先签名，后加密。EPECZZ-1DPKRb源点源点A终点终点BKsDCKsKUbKRaHEHDKUa比较比较3.压缩：默认情况下，在签名之后加密之前，PGP对报文进行压缩，这样做可以节约存储空间。这里要注意的是
37、压缩算法的放置位置，可能的位置有签名前压缩和签名后压缩(一般签名后压缩)。在压缩之后对报文加密可以增加加密的强度。因为压缩过的报文比原始明文冗余更少，密码分析更加困难。PGP使用的压缩算法是ZIP。4.电子邮件的兼容性 使用PGP时，至少传输报文的一部分需要被加密:如果只使用签名服务，那么报文摘要被加密。如果使用机密性服务，报文加上签名(如果存在)被加密。因此，部分或全部的结果报文由任意的8bit字节流组成。但由于历史的原因，目前很多电子邮件系统只转发由ASCII正文组成的报文。为了解决这个问题，PGP提供了转换服务。采用的方案：对PGP软件的输出进行radix-64转换，每三个字节的二进制数
38、据为一组映射成四个ASCII字符。作为选项，PGP可以配置成只将报文的签名部分转换成radix-64的格式，这样可使接收报文的人不使用PGP就能阅读报文。但必须使用PGP才能验证签名。转换举例：假设有24位原始正文序列如下：输入:00100011 01011100 10010001 001000 110101 110010 010001 8 53 50 17 I 1 y R输出：01001001 00110001 01111001 010100105、分段和重组 由于历史的原因，电子邮件设施经常会限制最大报文长度。例如：很多Internet可访问设施有最大报文长度50000个字节的限制。任何超
39、长的报文都必须划分成更小的报文段单独发送，否则将拒收超长的邮件报文。为了满足这个限制，PGP自动将超长的报文划分成合格的报文段。分段是在所有其他处理(包括radix-64转换)完成之后进行的，这样会话密钥和签名部分只在第一个报文段的开始位置出现一次。在接收端，PGP必须在解密步骤之前剥掉所有邮件的附加首部，并重新装配成原来完整的报文。发送流程：X文件需要签名吗？需要加密吗？压缩XZ(X)编码XR64(X)生成签名X签名|X加密XEKUbKs|KsX YYNNReturn分段7.5.1.3 PGP密钥管理 PGP使用四种类型的密钥：会话密钥：加密报文。接收者的公开密钥：加密一次性常规密钥。发送者
40、的私有密钥：对报文散列值签名。基于口令的常规密钥：加密发送者存储的私有密钥。会话密钥的生成：由随机数产生器生成128位随机数(2个64位的明文分组)，和预先选定的128位密钥一起作为指定加密算法的输入，产生的128位密文即为一次性会话密钥。目的是产生不可预测的密钥序列。公开/私有密钥对的管理 问题：允许用户拥有多个公开/私有密钥对。管理方法：密钥标识：为每个公开/私有密钥对中的公开密钥指派一个密钥ID，该密钥ID由公开密钥的最低64位构成，即KU mod 264。私有密钥环：是一张表，用来存储发送者的公开/私有密钥对。其中的私有密钥被加密。可使用用户ID或密钥ID进行索引。公开密钥环：也是一张
41、表，用来存储接收者的公开密钥。可使用用户ID或密钥ID进行索引。存储私有密钥时的加密：口令散列码密钥当系统生成新的公开/私有密钥对时，要求用户输入口令。系统使用SHA-1散列算法生成该口令的160位散列码，然后丢弃该口令。系统使用160位散列码中的128位作为密钥，对私有密钥进行加密，然后丢弃该散列码。接收者公开密钥的获得：物理的方法、共同信任的第三方、数字证书。PGP报文的一般格式：数字信封签名报文摘要的前两个八位组 接收者公开密钥KUb的密钥ID 加密的一次性密钥EKUbKs 时间戳 报文摘要 文件名 发送者公开密钥KUa的密钥ID 时间戳 数据数据 报文压缩 加密R64EKRa 发送方：
42、签名报文：使用用户ID作为索引从私有密钥环中查找发送者的私有密钥；输入口令解密私有密钥；构造报文签名。加密报文：生成一次性密钥加密报文；使用接收者的用户ID在公开密钥环中索引，找出接收者的公开密钥；构造数字信封。接收方：解密报文：使用报文数字信封部分的密钥ID作为索引，从私有密钥环中查找接收者的私有密钥；输入口令恢复私有密钥；利用私有密钥恢复Ks 利用Ks解密报文。鉴别报文：使用报文签名部分的密钥ID作为索引，从公开密钥环中查找发送者的公开密钥；恢复传输的报文摘要；计算报文摘要比对鉴别。Return7.5.2 S/MIME S/MIME(Secure/Multipurpose Internet
43、 Mail Extension)是MIME 电子邮件标准在安全方面的扩充，用来保护电子邮件的安全。S/MIME所提供的安全服务：报文鉴别、报文机密性和不可抵赖。S/MIME除了用于保护电子邮件外，还可以用于其他利用MIME进行传输的协议(如HTTP)。S/MIME与上一节介绍的PGP之间的区别在于S/MIME继承了MIME多用途的特点。Return7.5.2.1 MIME介绍1、RFC 822 RFC 822定义了使用电子邮件发送正文报文的格式。RFC 822标准中，报文=信封+内容。信封包含了完成传输和交付的所有信息;内容组成了要交付给接收者的对象。内容=首部+主体。RFC 822规定了邮件
44、内容中的首部(header)格式，而对邮件的主体(body)部分则让用户自由撰写。用户写好首部后，邮件系统将自动地将信封所需的信息提取出来并写在信封上，而用户不需要填写电子邮件信封上的信息。首部与主体之间通过一个空行分隔。首部行通常由一个关键词、一个冒号和关键词的参数组成，格式允许长的行被分割成多个行。最常用的关键词是From，To，Subject和Date。一个例子：Date：Tue，16 Jan 2004 10:37:17(EST)From：“xyz”Subject：The Syntax in RFC 822 TO： CC： HelloThis Section begins the act
45、ual message body，which is delimited from the message heading by a blank line 在RFC 822首部经常发现的另一个字段是Message-ID，这个字段包含了与此报文相关联的惟一的标识符。2、MIME概述 MIME是对RFC 822标准的扩充。目的：解决使用SMTP或其他邮件传输协议传递邮件时存在的一些问题和局限，如不能传输可执行文件或其他二进制对象、不能处理超过一定长度的邮件报文等。MIME标准包括了如下一些内容：定义了五个新的、可包含在RFC 822报文首部的字段，这些字段提供了有关报文主体的说明信息。定义了一组内容
46、格式，标准化了对多媒体电子邮件的支持。定义了传送编码，使得任何格式的内容都可以被转换成一种独立于不同邮件系统的形式。MIME定义的五个首部字段是：MIME-Version(版本)：指示使用的MIME版本。Content-Type(内容类型)：描述了包含在报文主体中的数据，使接收报文的用户代理可以选择合适的机制为用户表示数据，或者以合适的方法来处理数据。Content-Transfer-Encoding(内容传送编码)：指示转换类型，这种转换可以将报文主体转换成可以进行邮件传输的形式。Content-ID(内容ID，可选)：在多个上下文中，用来惟一标识MIME实体的标识符。Content-Des
47、cription(内容描述，可选)：对于报文主体中对象的正文描述，在该对象不可读的情况下，这个字段非常有用(如音频、视频数据)。3、MIME内容类型和传送编码 内容类型 MIME标准中定义了多种不同的内容类型(7个主类型和15个子类型)。主内容类型说明了数据的一般属性，而子类型则说明了本种类型数据的特定形式。其中Multipart type(多部分类型)指示报文主体包含了多个独立的部分。Content-Type首部字段包括了称为boundary(边界)的参数，定义了在报文的不同部分之间的分隔符。每个边界开始于一个新行，由两个连字符跟着一个分隔符组成。-xxxx最后一个部分结束边界还有两个连字符
48、作为后缀。-xxxx-在报文主体的每个部分，可以存在可选的普通的MIME首部。传送编码 MIME标准的另一个主要部分是对报文主体传送编码的定义，目的是提供跨越大范围环境的可靠交付。在所定义的传送编码中最常用的是quoted-printable和base64。quoted-printable用来处理主要由可打印ASCII字符组成的8位组数据。Base64(也称为radix-64编码)是将任意二进制数据转换成一种不会被邮件传输系统破坏的编码形式，在PGP中也使用这种方法。Return7.5.2.2 S/MIME的功能 就一般功能来讲，S/MIME与PGP非常类似。两者都提供了对报文进行签名和加密的
49、功能。但从整体上看，PGP是以整个邮件为对象进行安全防护，而S/MIME则是渗透到邮件内部的安全标准。1、功能目前的S/MIME版本提供了如下安全服务：数据加密 数据签名 纯签名(Clear-signed)签名且加密2、S/MIME支持的加密算法 散列函数算法：必须支持MD5和SHA-1；但应该使用SHA-1。数字签名算法：发送和接收代理都必须支持DSS算法，应该支持RSA算法。密钥加密算法：发送和接收代理都必须支持Diffie-Hellman算法，应该支持RSA算法。常规加密算法：发送代理应该支持40bit的RC2算法、128bit的RC2算法和三重DES算法；接收代理应该支持128bit的
50、RC2算法和三重DES算法。但符合标准的实现必须支持40bit的RC2，该算法为弱加密算法，符合联邦出口控制标准。S/MIME定义了发送和接收方协商各种加密算法的过程，下面是发送方代理在决策时使用的规则：已知能力：如果发送代理从预想的接收者那里获得了解密能力的列表，它应该选择能使用的列表中的第一个(最高优先级)能力。未知能力但已知使用了加密：如果发送代理没有接收者的能力清单，但曾经从接收者哪里收到过加密报文，那么就采用收到的最后一个签名和加密报文所使用的加密算法对报文进行处理。未知能力且未知S/MIME版本：如果发送者以前没有和接收者进行过安全通信，也不知道对方的能力:如果发送者愿意冒着接收者
