第七章 Internet安全.ppt

第七章Internet安全 7 1Internet的安全要求7 2SSL TLS 7 3S HTTP7 4安全电子交易 SET 7 5电子邮件的安全性 7 1Internet的安全要求 Web和电子邮件自身存在的各种问题 Web服务器对于来自Internet的攻击显得十分脆弱 Web服务器的重要性日益增加 Web服务器被破坏 除了名誉受损外 经济上也会遭受损失 Web服务器底层软件异乎寻常的复杂 复杂的软件可能隐藏更多的潜在安全问题 Web服务器有可能成为进攻内部网的跳板 没有经过训练的用户不了解存在的安全风险 电子邮件的问题主要是防止欺骗和保证内容的隐私性 电子邮件是传播病毒最快捷的途径 Return 7 2SSL TLS SSL SecureSocketLayer 是一个用来保证安全传输的Internet协议 该协议通过在两个实体 客户和服务器 之间提供一个安全通道 来实现数据在Internet中传输的保密性 1994年 Netscape公司最先提出了SSL 该协议目前有三个版本 SSLv2 SSLv3和TLSv1 SSLv3 1 1995年发布的SSLv3是主要版本 第三版的设计经过了公开的评论并且吸收了工业界的意见 1996年Netscape公司将SSL规范提交给IETF IETF成立了专门的TLS工作组对SSLv3进行标准化 TLS的第一个正式版本已于1999年发布 其本质上可以看成是SSLv3 1 与SSLv3非常接近并且兼容 7 2 1SSL结构 7 2 2SSL会话和SSL连接 两个重要的概念 SSL连接和SSL会话 SSL连接 本质上讲就是TCP连接 不同之处在于每个连接要与一个SSL会话相关联 SSL会话 是客户和服务器之间的关联 会话通过握手协议来创建 会话定义了加密安全参数的一个集合 该集合可以被多个SSL连接所共享 在任何一对交互实体之间可能存在多个安全连接 在交互实体之间也可以同时存在多个会话 SSL会话是有状态的 主要的状态有 当前读和当前写 挂起读和挂起写 由握手协议来协调客户端和服务器端的会话状态 会话状态的相关参数 会话标识符对方的证书压缩方法密码规范 加密算法 MAC算法及加密属性 主密钥 48字节密钥 可重用否 一个标志 用于指明该会话是否可以用来初始化一个新的连接 连接状态的相关参数 服务器端和客户端随机数 连接 服务器端写MAC密钥客户端写MAC密钥服务器写密钥 对称加密 客户写密钥 对称加密 初始向量 CBC 序列号 报文 64Bit 7 2 3SSL记录协议 1 记录协议的功能和报文格式功能 将上层传来的数据进行分段 压缩 MAC值计算和加密处理 并添加记录报头 然后交给下层协议 当收到下层传来的数据时 进行相反的处理 然后交给上层协议 记录协议为高层提供两种服务 机密性服务和报文鉴别服务 SSL可为多种TCP IP应用提供基本安全服务 IANA 已经为具备SSL功能的应用分配了固定端口号 例如 带SSL的HTTP https 被分配的端口号为443 带SSL的SMTP ssmtp 被分配的端口号为465 带SSL的NNTP snntp 被分配的端口号为563 记录协议报文格式如图所示内容类型 8比特 高层协议 修改密码规范 告警 握手和应用数据 主要版本 8比特 次要版本 8比特 压缩长度 16比特 数据MAC字段 2 记录层报文的产生过程 允许使用的加密算法 7 2 4SSL修改密码协议与告警协议 1 修改密码协议修改密码协议是使用SSL记录协议的三个SSL有关协议之一 目的是使挂起状态被复制到当前状态 改变了这个连接将要使用的密码算法 这个协议由单个报文组成 而报文又由值为1的单个字节组成 2 告警协议告警协议是用来将SSL有关的告警传送给对方实体 和其他使用SSL的应用一样 告警报文按照当前状态被压缩和加密 该协议的每个报文由两个字节组成 第一个字节为告警级别 警告和致命 第二个字节包含了指出特定告警的代码 如果级别是致命的 SSL将立刻终止该连接 但同一会话的其他连接可以继续 但该会话不能再建立新的连接了 7 2 5SSL握手协议 握手协议的功能和报文格式握手协议用来协商会话的安全属性 握手协议产生的报文作为记录层的数据 按照当前活动会话的状态被封装 处理和传输 握手协议的功能主要包括 服务器与客户间的相互身份鉴别 协商加密和MAC算法 交换加密密钥 握手协议由一组在客户和服务器之间交换的报文组成 握手协议报文由三个字段组成 类型 1字节 长度 3字节 字节为单位 内容 1字节 P174 177 Return 7 3S HTTP S HTTP是WWW上使用的超文本传输协议 HTTP 的安全增强版本 S HTTP提供了文件级的安全机制 因此每个文件都可以被设成加密 签名状态 用作加密及签名的算法可以由参与通信的收发双方进行协商 S HTTP提供了对多种单向散列 Hash 函数的支持 如 MD5及SHA 对多种常规加密技术的支持 如 DES 3DES RC2 RC4 对数字签名技术的支持 如 RSA和DSS 7 3 1HTTP介绍 1 基本原理从层次的角度看 HTTP是面向事务的应用层协议 它是WWW上可靠交换文件 包括文本 声音 图像等各种多媒体文件 的重要基础 每个WWW网点都有一个服务器进程 它不断地监听TCP的80端口 以便发现是否有浏览器 即客户进程 向它发出连接建立请求 一但监听到连接建立请求并建立了TCP连接之后 浏览器就向服务器发出浏览某个页面的请求 服务器接着就返回所请求的页面作为响应 最后 释放TCP连接 在浏览器和服务器之间交互所遵循的格式和规则就是超文本传送协议HTTP HTTP规定在HTTP客户与HTTP服务器之间的每次交互都由一个规定格式的请求报文和一个规定格式的响应报文组成 2 报文结构 HTTP有两类报文 请求报文和响应报文 方法 URI 版本 请求行 空格 回车换行 首部字段名 值 首部字段名 值 实体主体 首部行 版本 状态码 短语 状态行 首部字段名 值 首部字段名 值 实体主体 首部行 请求报文 响应报文 HTTP请求报文 典型的HTTP请求报文如下 GET PUBLIC docu htmlHTTP 1 1 请求行 Connection close 首部行 User agent Mozilla 4 0Accept text html audio base image gif video mpegAccept language en 空行 HTTP响应报文 典型的HTTP响应报文如下 HTTP 1 1200OK 状态行 Connection Close 从这行开始的6行都是首部行 Date Wed 16Oct200212 36 15GMTServer Apache 1 3 0 Unix Last Modified Mon 11Aug200210 30 28GMTContent Length 5963 文件长度的字节数 Content Type text html 空行 DATADATADATA 所请求的文件 7 3 2S HTTP基本原理 S HTTP是一种面向消息的安全通信协议 可以与HTTP协同使用 S HTTP为HTTP客户和服务器之间的通信提供了各种安全机制 这种安全服务的可选特性能够适应WWW中可能存在的各种潜在应用 S HTTP为客户和服务器两者提供了均衡的能力 S HTTP的客户和服务器可以使用多种密码信息格式 并与HTTP兼容 1 S HTTP消息的创建 S HTTP包括消息首部和加密消息主体 消息首部中可能包含了指示接收者应如何解释消息主体以及此后接收者应该怎样执行消息主体的信息 消息发送者 客户端 服务器 S HTTP消息的创建需要以下信息 明文消息接收者支持的加密方法和密钥素材发送者支持的加密方法和密钥素材发送者将自己支持的加密方法和接收者支持的加密方法综合在一起 形成双方支持的加密方法和相关密钥素材表 通过使用这些数据 发送者可以将明文消息转换成S HTTP消息 2 S HTTP消息的恢复 S HTTP消息的恢复过程需要以下信息 S HTTP消息接收者先前声明所支持的加密方法和密钥素材 接收者目前支持的加密方法和密钥素材发送者先前声明所支持的加密方法和密钥素材为了恢复一个S HTTP消息 接收者需要阅读该消息的首部 以确定发送者对消息主体进行的密码操作 然后对消息进行解密恢复出明文 3 S HTTP的安全机制 S HTTP协议对消息的保护主要分为三个方面 消息签名 消息鉴别和消息加密 一个S HTTP消息可以被签名 鉴别 加密或三者的任意组合 当然也包括与HTTP兼容的明文传输方式 S HTTP提供了多种密钥管理机制S HTTP安全机制的要点 签名 将证书或证书链附加在消息中传给对方 密钥交换和加密 Inband公钥 Outband秘密密钥 对称加密 消息完整性和发送者鉴别 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 Message Digest Algorithms字段 指出报文摘要算法 MD5 SHA SHTTP Symmetric Content Algorithms字段 指出对称加密算法 DES 3DES RC4 7 3 3S HTTP的报文格式 S HTTP消息报文的格式与HTTP是相同的 即都是由一个请求行 状态行 后面跟首部行和一个实体部分 所不同的是首部的内容范围及实体部分在典型情况下是加密的 1 请求行 为了区分S HTTP报文 HTTP报文和所允许的特殊处理 请求行使用了特殊的安全方法 Secure 和协议标识符 Secure HTTP 1 4 S HTTP和HTTP进程都使用相同的TCP端口号80 为了防止敏感信息的泄露 请求URI将由 替代 请求行的例子如下 Secure Secure HTTP 1 42 状态行 S HTTP响应使用协议标识符 Secure HTTP 1 4 状态行的例子如下 Secure HTTP 1 4200OK3 首部行 S HTTP定义了一系列新首部行 Content type message http表明S HTTP报文封装的是HTTP消息 Content type application s http表明S HTTP报文封装的是非HTTP数据 Content Privacy Domain首部行有两个取值 CMS或MOSS CMS是英文 CryptographicMessageSyntaxStandard 的缩写 是一种类似于PEM标准的加密消息封装格式 MOSS是英文 MIMEObjectSecurityServices 的缩写 指明消息实体中携带的是MIME兼容消息 Prearranged Key Info首部行指明密钥交换方法 取值有 Inband Outband MAC Info首部行说明用于消息鉴别码计算的散列函数和共享密钥 S HTTP报文格式的详细描述可以参阅RFC 2660 Return 7 4安全电子交易 SET 7 4 1概述7 4 2SET的商业需求和主要特点7 4 3SET协议中的参与者和交易事件序列7 4 4双重签名7 4 5支付处理 Return 7 4 1概述 安全电子交易 SecureElectronicTransaction SET 是设计用来保护Internet上信用卡交易的安全协议 版本SETv1是在1996年2月根据MasterCard和Visa安全标准需要设计的 SET本身不是一个支付系统 而是一个安全协议和格式的集合 它使得用户可以以一种安全的方式 将已经存在的信用卡支付基础设施配置在开放网络 例如Internet 上 SET协议工作在应用层 从本质上讲 SET提供了三种服务 在交易涉及的各方之间提供安全的通信信道 通过使用X 509v3数字证书来提供信任 保证机密性 信息只是在必要的时候 必要的地方才对交易各方可用 Return 7 4 2SET的商业需求和主要特点 了解SET协议首先要了解它的商业背景和主要特点 1 商业需求在开放网络上使用支付卡进行安全支付处理的商业需求 保证订购信息和支付信息的机密性 保证所有传输数据的完整性 对卡的拥有者进行鉴别 对商家是否可以接受支付卡交易进行鉴别 使用最好的安全策略和系统设计技术来保护电子商务交易中的所有合法方 创建既不依赖于运输层安全机制又不阻止它们使用的协议 2 SET协议的特点 1 信息机密性 必须确保持卡人的账号和支付信息在通过网络传输时的安全性 2 数据完整性 SET协议保证信息内容在传输过程中不被修改 3 持卡人账号的鉴别 SET协议提供了一种方法来鉴别持卡人是否是有效支付卡帐号的合法用户 4 商人的鉴别 SET也提供了持卡人鉴别商家的方法 5 互操作性 可以在不同的硬 软件平台上应用该规范 Return 7 4 3SET协议中的参与者和交易事件序列 1 SET协议模型中的参与者SET协议改变了传统支付系统中参与者之间的相互作用模式 在传统面对面的零售交易或邮购交易中 电子处理过程开始于商家或收单行 而在SET的交易模型中 电子处理过程则开始于持卡人 SET协议模型中的参与者包括如下成员 1 持卡人 2 发卡行 3 商家 4 收单行 5 支付网关 6 证书管理机构 CA SET协议模型中的参与者 2 交易事件序列 1 消费者申请支付卡 成为持卡人 2 消费者获得电子身份证书 3 商家获得电子身份证书 两个证书 4 消费者提出订购请求 5 消费者鉴别商家 6 消费者发送订购和支付信息 被加密 7 商家请求支付认可 8 商家确认该项订购 9 商家提供货物或服务 10 商家请求支付 Return 7 4 4双重签名 在介绍SET协议的细节之前 先讨论SET协议引入的一个重要概念 双重签名 双重签名的目的 是为了连接两个发送给不同接收者的报文 通常 消费者要将订购信息 OI 发送给商家 将支付信息 PI 发送给银行 商家不必知道消费者的信用卡号码 银行也不必知道消费者订单的细节 但是 这两个项目必须采用一种必要时可以用来解决争执的方式连接起来 这种连接是必需的 因为消费者可以证明这个支付是用于这次订购而不是用于其他的货物或服务 1 双重签名的创建PIMD H PI OIMD H OI POMD H PIMD OIMD DS EKRc H H PI H OI 其中PI是支付信息 OI是订购信息 KRc是消费者的私有密钥 2 双重签名的验证商家验证双重签名 商家获得了双重签名 DS OI PI的报文摘要 PIMD 以及从消费者证书中取得消费者的公开密钥KUc后 商家可以计算下面两个数值 H PIMD H OI 和DKUc DS 其中KUc是消费者的公开密钥 如果这两个数值相等 商人就验证了该双重签名 银行验证双重签名 银行获得了DS PI OI的报文摘要 OIMD 以及消费者的公开密钥KUc后 银行可以计算下面两个数值 H H PI OIMD 和DKUc DS 如果这两个数值相等 银行就验证了该双重签名 3 双重签名的使用 1 商家收到OI并通过验证双重签名来鉴别OI信息 2 银行收到PI并通过验证双重签名来鉴别PI信息 3 消费者将OI和PI连接起来并且能够证明这种连接关系 假设商家为了自己的利益 想要在这个交易中用另一个OI来冒充 就必须找到另一个OI 其散列码与现有OIMD相匹配 这在计算上是不可行的 因此 商家不能将另一个OI与这个PI相连接 Return 7 4 5支付处理 1 SET支持的交易类型持卡人注册 商家注册 向CA注册 购买请求 支付认可 检验持卡人卡账号的支付能力 支付获取 商家向支付网关请求支付 证书调查和状态 购买调查 持卡人检查订购处理的状态 认可撤消 商家更正以前的认可请求 获取撤消 商家纠正获取请求中的差错 退款 退款撤消 支付网关证书请求等 这里将重点讨论购买请求 支付认可和支付获取三种交易类型的细节 2 参与者证书说明在SET协议中 处于Internet环境的参与者有持卡人 商家和支付网关 为了证明自己的身份 它们必须从所属的CA处获得证书 持卡人证书 CA在向持卡人颁发证书时 要求持卡人提供帐户信息并通过发卡行进行验证 如果信息属实且符合条件 CA将生成持卡人帐户信息摘要 HMAC 并嵌入证书中 商家证书 商家在向CA申请证书前 必须先要与收单行建立委托关系 CA在受理商家的证书申请后 通过收单行进行验证 如果信息属实且符合条件 CA将向商家颁发证书 商家通常需要两个证书 签名证书和密钥交换证书 支付网关证书 支付网关通常需要两个证书 签名证书和密钥交换证书 3 购买请求初始阶段 持卡人进行商品的浏览 选择和订购后 商家将完整的订购表格发送给消费者 初始阶段是在不使用SET协议的情况下进行的 购买请求阶段 需要交换四个报文 发起请求 发起响应 购买请求和购买响应 发起请求报文 卡用户 商家 目的 请求商家和支付网关的证书 身份鉴别 明文传输 报文主要内容 请求 响应对ID 现时C 信用卡商标 发卡行标识 发起响应报文 商家 卡用户 商家生成响应 并用自己的私有密钥对其签名 报文主要内容 请求 响应对ID 现时C 现时M 交易ID 商家签名证书 支付网关密钥交换证书 购买请求 卡用户 商家 收到响应报文后 卡用户通过相应的CA签名来验证商家证书 签名证书 和网关证书 密钥交换证书 然后检验报文的合法性 创建OI和PI 商家赋予的交易ID被放在OI和PI中 OI中并不包含明显的订购数据 如货物的数量和价格 它包含了在交换SET报文之前购物阶段期间 商家和消费者之间交换时生成的订购的引用 接下来 卡用户准备购买请求报文 为了这个目的 卡用户生成了一次性的对称加密密钥KS 购买响应 商家 卡用户 商人收到了购买请求报文后 进行如下处理 验证卡用户的证书 签名证书 使用消费者证书中的公开密钥来验证双重签名 处理订购信息 并将支付信息转交给支付网关 支付认可 向卡用户发送购买响应报文 商家验证消费者的购买请求 购买响应报文包括 响应块响应块签名商家的签名证书 该响应块确认订购并且引用了相应的交易号码 商家使用签名证书的私有密钥对响应块进行签名 当持卡人的软件收到了购买响应报文时 它验证商家的签名证书 然后验证响应块上的签名 基于响应报文采取动作 显示消息 修改数据库订购状态 4 支付认可在收到来自持卡人的购买请求后 如果证书和双签名验证通过 在向持卡人发送购买响应报文之前 商家要请求支付网关认可该项交易 支付认可将保证交易得到了发卡行的批准 且保证商家可以得到支付 支付认可由两个报文组成 认可请求和认可响应 在完成支付认可过程后 商家才决定是否向卡用户发购买响应报文 认可请求 商家 支付网关 商家向支付网关发送一个认可请求报文 该报文由以下几个部分组成 1 与购买有关的信息 来自消费者 PI 支付信息 双重签名DS 用消费者的私有密钥签名 OI报文摘要 OIMD 数字信封 封装会话密钥 2 认可有关的信息 由商家生成 认可数据块 包括一个使用商家私有密钥签名的 并且使用商家生成的一次性对称密钥加密的交易ID 数字信封 通过使用支付网关密钥交换证书中的公开密钥对一次性对称密钥进行加密形成 3 证书 包括卡用户签名密钥证书和商家签名密钥证书和商家密钥交换证书 用会话密钥加密 支付网关在收到商家发来的认可请求报文后 完成下面一些任务 验证所有的证书 用户签名证书 商家签名证书 商家密钥交换证书 用私钥解密认可数据块的数字信封以获得对称密钥 然后解密认可数据块 验证认可数据块中商家的签名 用私钥解密支付数据块的数字信封以获得对称密钥 然后解密支付数据块 PI DS OIMD 验证支付数据块的双重签名 验证从商家那里收到的交易ID与从消费者那里收到的PI中的交易ID是否匹配 向发卡行请求和接收一个认可 认可响应 支付网关 商家 从发卡行获得了认可之后 支付网关向商家返回认可响应报文 它包括如下内容 与认可有关的信息 认可数据块 使用支付网关的私有签名密钥进行签名 并且使用支付网关生成的一次性对称密钥进行加密 数字信封 该数字信封使用商家密钥交换证书中的公开密钥对一次性对称密钥进行加密形成 获取权标信息 这个信息将影响以后的支付 该数据块的形式与认可数据块相同 即签名并加密的获取权标加上数字信封 证书 支付网关的签名证书 商家收到来自支付网关的认可响应报文后 完成如下工作 验证支付网关的签名证书 用商家密钥交换证书中的私钥解密数字信封获得对称密钥并解密认可响应数据 用支付网关签名证书中的公钥验证认可数据块中的签名 保存加密的获取权标信息和对应的数字信封 之后的支付获取过程要用到这些信息 商家这时可以按照持卡人定单的要求提供货物或服务了 5 支付获取支付获取由获取请求和获取响应报文组成 获取请求 商家 支付网关 获取请求报文包含商家生成 签署并加密的获取请求数据块 该数据块中包括了支付的数量和交易ID 获取请求报文还包括以前收到的关于这个交易的加密的获取权标 在认可响应中 商家的签名证书和密钥交换证书 当支付网关收到了获取请求报文后 解密并验证获取请求数据块 解密并验证获取权标块 检查获取请求和获取权标的一致性 创建清算请求并通过私有支付网络发送给发卡行 这个请求引起资金被划拨到商家的账户中 清算响应 支付网关在获取响应报文中通知商家支付情况 获取响应报文包括由支付网关签名和加密的获取响应数据块 报文还包括支付网关的签名证书 商家的软件将这个获取响应保存下来 用于同从获得者 收单行 那里接收的支付相匹配 SET协议的报文交互 Return 7 5电子邮件的安全性 电子邮件是因特网上使用最多的网络应用之一 也是惟一在所有网络结构和厂家平台上被广泛支持的分布式应用 电子邮件面临的安全问题可分为两类 电子邮件自身的安全 存在邮件的假冒 篡改和窃听 可通过鉴别和加密等安全机制解决 网络的电子邮件应用已经成为网络安全的薄弱环节 许多计算机病毒或其他恶意代码 通过电子邮件进入内部网 造成巨大危害 本节主要讨论电子邮件自身的安全问题 用来保护电子邮件安全的因特网协议主要有三种 PEM PrivacyEnhancedMail 由IETF组织开发 用于因特网环境的安全邮件系统 具有数据加密 源点鉴别和完整性保护功能 PGP PrettyGoodPrivacy 主要由PhilZimmermann开发 是自由软件 PGP提供了电子邮件机密性和鉴别的服务 可以用于电子邮件和文件存储应用 S MIME Secure MultipurposeInternetMailExtension 安全通用Internet邮件扩展 7 5电子邮件的安全性 7 5 1PGP加密软件7 5 1 1PGP概述7 5 1 2PGP基本服务描述7 5 1 3PGP密钥管理7 5 2S MIME7 5 2 1MIME介绍7 5 2 2S MIME的功能7 5 2 3S MIME报文 7 5 1 1PGP概述 PGP的最初版本是由PhilZimmermann开发的并作为共享软件在网上发表 后经网上各国程序员的不断完善形成了现在的PGP加密软件版本 PGP加密软件为电子邮件应用提供了机密性和鉴别服务 并可用于文件的存储 PGP加密软件所采取的措施主要有 选择经过考验的 无专利问题困扰的加密算法作为基础构件 将所选算法有机地整合在一起 形成可靠的整体安全性 使软件易于移植 易于使用 为了在网上发布 并免费提供给用户使用 制作了包括源代码的软件包和相关文档 与商业公司合作 为需要服务的用户提供与免费PGP完全兼容的 低价格商用版本 由于采取了上述措施 PGP发展的非常迅速 已被广泛应用 这为具有相同想法的人提供了一个很好的借鉴 PGP成功的原因可以概括如下 作为Internet上的共享软件 在世界范围内可以免费得到 软件包括能在不同平台上运行的多个版本 另外 低价的商用版本满足了那些想要获得厂家技术支持的用户的需要 使用经过实践检验 成熟的安全算法 如RSA DSS和Diffie Hellman公钥算法 CAST 128 IDEA和3DES常规加密算法 以及散列算法SHA 1 应用范围广 可用于文件加密和网上信息的安全传输 公司 组织和个人都可使用 不属于任何政府或组织 Return 7 5 1 2PGP基本服务描述 PGP提供五种基本服务 鉴别机密性压缩电子邮件的兼容性分段 鉴别 RSA和SHA 1 DSS和SHA 1 机密性 机密性与鉴别结合 先签名 后加密 压缩 默认情况下 在签名之后加密之前 PGP对报文进行压缩 这样做可以节约存储空间 这里要注意的是压缩算法的放置位置 可能的位置有签名前压缩和签名后压缩 一般签名后压缩 在压缩之后对报文加密可以增加加密的强度 因为压缩过的报文比原始明文冗余更少 密码分析更加困难 PGP使用的压缩算法是ZIP 4 电子邮件的兼容性使用PGP时 至少传输报文的一部分需要被加密 如果只使用签名服务 那么报文摘要被加密 如果使用机密性服务 报文加上签名 如果存在 被加密 因此 部分或全部的结果报文由任意的8bit字节流组成 但由于历史的原因 目前很多电子邮件系统只转发由ASCII正文组成的报文 为了解决这个问题 PGP提供了转换服务 采用的方案 对PGP软件的输出进行radix 64转换 每三个字节的二进制数据为一组映射成四个ASCII字符 作为选项 PGP可以配置成只将报文的签名部分转换成radix 64的格式 这样可使接收报文的人不使用PGP就能阅读报文 但必须使用PGP才能验证签名 转换举例 假设有24位原始正文序列如下 输入 0010001101011100100100010010001101011100100100018535017I1yR输出 01001001001100010111100101010010 5 分段和重组由于历史的原因 电子邮件设施经常会限制最大报文长度 例如 很多Internet可访问设施有最大报文长度50000个字节的限制 任何超长的报文都必须划分成更小的报文段单独发送 否则将拒收超长的邮件报文 为了满足这个限制 PGP自动将超长的报文划分成合格的报文段 分段是在所有其他处理 包括radix 64转换 完成之后进行的 这样会话密钥和签名部分只在第一个报文段的开始位置出现一次 在接收端 PGP必须在解密步骤之前剥掉所有邮件的附加首部 并重新装配成原来完整的报文 发送流程 X 文件 压缩X Z X 编码X R64 X 生成签名X 签名 X 加密X EKUb Ks Ks X Y Y N N Return 分段 7 5 1 3PGP密钥管理 PGP使用四种类型的密钥 会话密钥 加密报文 接收者的公开密钥 加密一次性常规密钥 发送者的私有密钥 对报文散列值签名 基于口令的常规密钥 加密发送者存储的私有密钥 会话密钥的生成 由随机数产生器生成128位随机数 2个64位的明文分组 和预先选定的128位密钥一起作为指定加密算法的输入 产生的128位密文即为一次性会话密钥 目的是产生不可预测的密钥序列 公开 私有密钥对的管理问题 允许用户拥有多个公开 私有密钥对 管理方法 密钥标识 为每个公开 私有密钥对中的公开密钥指派一个密钥ID 该密钥ID由公开密钥的最低64位构成 即KUmod264 私有密钥环 是一张表 用来存储发送者的公开 私有密钥对 其中的私有密钥被加密 可使用用户ID或密钥ID进行索引 公开密钥环 也是一张表 用来存储接收者的公开密钥 可使用用户ID或密钥ID进行索引 存储私有密钥时的加密 口令 散列码 密钥当系统生成新的公开 私有密钥对时 要求用户输入口令 系统使用SHA 1散列算法生成该口令的160位散列码 然后丢弃该口令 系统使用160位散列码中的128位作为密钥 对私有密钥进行加密 然后丢弃该散列码 接收者公开密钥的获得 物理的方法 共同信任的第三方 数字证书 PGP报文的一般格式 发送方 签名报文 使用用户ID作为索引从私有密钥环中查找发送者的私有密钥 输入口令解密私有密钥 构造报文签名 加密报文 生成一次性密钥加密报文 使用接收者的用户ID在公开密钥环中索引 找出接收者的公开密钥 构造数字信封 接收方 解密报文 使用报文数字信封部分的密钥ID作为索引 从私有密钥环中查找接收者的私有密钥 输入口令恢复私有密钥 利用私有密钥恢复Ks利用Ks解密报文 鉴别报文 使用报文签名部分的密钥ID作为索引 从公开密钥环中查找发送者的公开密钥 恢复传输的报文摘要 计算报文摘要比对鉴别 Return 7 5 2S MIME S MIME Secure MultipurposeInternetMailExtension 是MIME电子邮件标准在安全方面的扩充 用来保护电子邮件的安全 S MIME所提供的安全服务 报文鉴别 报文机密性和不可抵赖 S MIME除了用于保护电子邮件外 还可以用于其他利用MIME进行传输的协议 如HTTP S MIME与上一节介绍的PGP之间的区别在于S MIME继承了MIME多用途的特点 Return 7 5 2 1MIME介绍 1 RFC822RFC822定义了使用电子邮件发送正文报文的格式 RFC822标准中 报文 信封 内容 信封包含了完成传输和交付的所有信息 内容组成了要交付给接收者的对象 内容 首部 主体 RFC822规定了邮件内容中的首部 header 格式 而对邮件的主体 body 部分则让用户自由撰写 用户写好首部后 邮件系统将自动地将信封所需的信息提取出来并写在信封上 而用户不需要填写电子邮件信封上的信息 首部与主体之间通过一个空行分隔 首部行通常由一个关键词 一个冒号和关键词的参数组成 格式允许长的行被分割成多个行 最常用的关键词是From To Subject和Date 一个例子 Date Tue 16Jan200410 37 17 EST From xyz Subject TheSyntaxinRFC822TO abc CC def Hello ThisSectionbeginstheactualmessagebody whichisdelimitedfromthemessageheadingbyablankline 在RFC822首部经常发现的另一个字段是Message ID 这个字段包含了与此报文相关联的惟一的标识符 2 MIME概述MIME是对RFC822标准的扩充 目的 解决使用SMTP或其他邮件传输协议传递邮件时存在的一些问题和局限 如不能传输可执行文件或其他二进制对象 不能处理超过一定长度的邮件报文等 MIME标准包括了如下一些内容 定义了五个新的 可包含在RFC822报文首部的字段 这些字段提供了有关报文主体的说明信息 定义了一组内容格式 标准化了对多媒体电子邮件的支持 定义了传送编码 使得任何格式的内容都可以被转换成一种独立于不同邮件系统的形式 MIME定义的五个首部字段是 MIME Version 版本 指示使用的MIME版本 Content Type 内容类型 描述了包含在报文主体中的数据 使接收报文的用户代理可以选择合适的机制为用户表示数据 或者以合适的方法来处理数据 Content Transfer Encoding 内容传送编码 指示转换类型 这种转换可以将报文主体转换成可以进行邮件传输的形式 Content ID 内容ID 可选 在多个上下文中 用来惟一标识MIME实体的标识符 Content Description 内容描述 可选 对于报文主体中对象的正文描述 在该对象不可读的情况下 这个字段非常有用 如音频 视频数据 3 MIME内容类型和传送编码内容类型MIME标准中定义了多种不同的内容类型 7个主类型和15个子类型 主内容类型说明了数据的一般属性 而子类型则说明了本种类型数据的特定形式 其中Multiparttype 多部分类型 指示报文主体包含了多个独立的部分 Content Type首部字段包括了称为boundary 边界 的参数 定义了在报文的不同部分之间的分隔符 每个边界开始于一个新行 由两个连字符跟着一个分隔符组成 xxxx最后一个部分结束边界还有两个连字符作为后缀 xxxx 在报文主体的每个部分 可以存在可选的普通的MIME首部 传送编码MIME标准的另一个主要部分是对报文主体传送编码的定义 目的是提供跨越大范围环境的可靠交付 在所定义的传送编码中最常用的是quoted printable和base64 quoted printable用来处理主要由可打印ASCII字符组成的8位组数据 Base64 也称为radix 64编码 是将任意二进制数据转换成一种不会被邮件传输系统破坏的编码形式 在PGP中也使用这种方法 Return 7 5 2 2S MIME的功能 就一般功能来讲 S MIME与PGP非常类似 两者都提供了对报文进行签名和加密的功能 但从整体上看 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的RC2算法和三重DES算法 但符合标准的实现必须支持40bit的RC2 该算法为弱加密算法 符合联邦出口控制标准 S MIME定义了发送和接收方协商各种加密算法的过程 下面是发送方代理在决策时使用的规则 已知能力 如果发送代理从预想的接收者那里获得了解密能力的列表 它应该选择能使用的列表中的第一个 最高优先级 能力 未知能力但已知使用了加密 如果发送代理没有接收者的能力清单 但曾经从接收者哪里收到过加密报文 那么就采用收到的最后一个签名和加密报文所使用的加密算法对报文进行处理 未知能力且未知S MIME版本 如果发送者以前没有和接收者进行过安全通信 也不知道对方的能力 如果发送者愿意冒着接收者可能不能解密报文的危险 那么发送代理应该使用3DES 如果不愿意冒着接收者可能不能解密报文的危险 那么发送代理必须使用RC2 40 报文需要发送给多个接收者 但却不能选择共同的加密算法 那么发送代理将需要发送多个报文 Return 7 5 2 3S MIME报文 S MIME报文由MIME实体和PKCS对象组成 PKCS是RSA实验室发布的公开密钥加密规约的集合 S MIME增加了一些新的MIME内容类型 所有新的应用类型都使用了指定的PKCS对象 1 安全化MIME实体安全化MIME实体的一般步骤 S MIME按照MIME报文准备的一般规则来准备MIME实体 一个MIME实体可以是一个完整的报文 除了RFC822首部 也可以是multipart类型的一个或多个子部分 将准备好的MIME实体转换成规范形式 这种转换使得在生成签名和验证签名时惟一地 无二义性地表示该MIME实体 将该MIME实体加上一些与安全有关的数据 如算法标识符和证书 经过S MIME处理生成称为PKCS的对象 PKCS对象被看作报文内容并包装成MIME 提供合适的MIME首部 2 创建EnvelopedData报文application pkcs7 mime子类型可用于三类S MIME处理 每类处理都有惟一的smime类型参数 准备一个加密的MIME实体的步骤如下 为选定的常规加密算法 RC2 40或三重组DES 生成会话密钥 使用会话密钥加密MIME实体 对每个不同的接收者 使用对应的公开RSA密钥对会话密钥进行加密 数字信封 为每个不同的接收者准备称为RecipientInfo 接收者信息 的数据块 该块中包含了发送者的公开密钥证书 用来加密会话密钥算法的标识以及加密的会话密钥 生成的加密数据放在RecipientInfo块后 拼接 使用base64对RecipientInfo块和加密数据进行编码 简单的报文例子如下 去掉了RFC822首都 Content Type application pkcs7 mime smime type enveloped data name smime p7mContent Transfer Enc