第十章安全通信协议及交易协议.ppt_第1页
第十章安全通信协议及交易协议.ppt_第2页
第十章安全通信协议及交易协议.ppt_第3页
第十章安全通信协议及交易协议.ppt_第4页
第十章安全通信协议及交易协议.ppt_第5页
已阅读5页,还剩67页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

安全通信协议及交易协议 IPSex协议SSL安全套阶层协议SET安全电子交易协议RADIUS协议 通道 将一个数据报用一个新的数据报封装 SecurityParameterIndex IPDestinationAddress SecurityProtocol 安全关联 SA SA就是两个IPSec系统之间的一个单向逻辑连接 32比特 用于标识具有相同IP地址和相同安全协议的不同SA 可以是普通IP地址 也可是广播或者组播地址 可以是AH或者ESP IP头部 IPSec概念 身份认证报头 AH协议提供数据源身份认证 数据完整性保护 重放攻击保护功能负载安全封装 ESP协议提供数据保密 数据源身份认证 数据完整性 重放攻击保护功能因特网安全关联和密钥管理协议 IKE 以前被叫ISAKMP Oakley 提供自动建立安全关联和管理密钥的功能 IPSec框架的组成 目的地址接受的包 IPsec协议栈组成 IPsec由一系列协议组成 RFC2401 规定了IPsec的基本结构 RFC2402 验证头 RFC2406 封装安全载荷 RFC2407 用于Internet安全联盟和密钥管理协议ISAKMP的InternetIP安全解释域 RFC2408 ISAKMP RFC2409 Internet密钥交换 IKE RFC2411 IP安全文档指南 RFC2412 OAKLEY密钥确定协议 等 IPsec组件包括安全协议验证头 AH 和封装安全载荷 ESP 安全关联 SA 密钥交换 IKE 及加密和验证算法等 安全策略 SecurityPolicy SP 指示对IP数据报提供何种保护 并以何种方式实施保护 安全关联 SecurityAssociation SA 是两个应用IPsec实体 主机 路由器 间的一个单向逻辑连接 决定保护什么 如何保护以及谁来保护通信数据 SA是安全策略的具体化和实例化 为了确保互操作性 IPsec规定了与SA相关的两个名义性数据库 安全策略库 SPD 和安全关联库 SAD IPsec协议栈组成 验证头 AuthenticationHeader AH 是一个安全协议头 可在传输模式下使用 为IP包提供 数据完整性 可判定数据包在传输过程中是否被修改验证服务 终端系统或网络设备可对用户或应用进行验证 过滤通信流 还可防止地址欺骗攻击及重播攻击 AH头插在IP头和上层协议头 如TCP或UDP头 之间 验证头 AH IPsec协议栈组成 封装安全载荷 EncapsulatingSecurityPayload 也是一个安全协议头 采用加密和验证机制 为IP数据报提供数据源验证 数据完整性 抗重播和机密性安全服务 可在传输模式和隧道模式下使用 ESP头插在IP头和上层协议头 如TCP或UDP头 之间 隧道模式下 要对整个IP包封装 ESP头位于内外IP头之间 封装安全载荷 ESP IPsec协议栈组成 隧道 Tunnel 是指将一种协议报头封装在另一种协议报头中 这样 一种协议就可以通过另一种协议的封装进行通信 隧道可在网络的任一层实现最常用的是两层 数据链路层和网络层主要目的是让网络不支持的协议通过数据包的封装进入网络隧道技术可以允许你在ip数据包中加入完整的一个数据包 IPsec的密钥管理包括密钥的确定和分配 有手工和自动两种方式 IPsec默认的自动密钥管理协议是IKE IKE规定了自动验证IPsec对等实体 协商安全服务和产生共享密钥的标准 RFC2409对Internet密钥交换即IKE进行了描述 密钥交换 IKE IPsec协议栈组成 RFC2411对IPsecAH和ESP使用的加密和验证算法的规范进行了描述 并在其他一些文档中对DES HMAC MD5 HMAC SHA 1等算法标准进行了描述 IPsec加密算法用于ESP 目前的IPsec标准要求任何IPsec实现都必须支持DES 另外 IPsec标准规定可使用3DES RC5 IDEA 3IDEA CAST和Blowfish 加密和验证算法 IPsec协议栈组成 IPsec的工作模式 IPsec使用传输模式和隧道模式保护通信数据 IPsec协议和模式有4种可能的组合 AH传输模式 AH隧道模式 ESP传输模式 ESP隧道模式 传输模式 传输模式用于两台主机之间 保护传输层协议头 实现端到端的安全 它所保护的数据包的通信终点也是IPsec终点 实施点 当数据包从传输层递给网络层时 AH和ESP会进行 拦截 在IP头与上层协议头之间需插入一个IPsec头 AH头或ESP头 实施顺序 当同时应用AH和ESP传输模式时 应先应用ESP 再应用AH 这样数据完整性可应用到ESP载荷 隧道模式 实施场景 隧道模式用于主机与路由器或两部路由器之间 保护整个IP数据包 处理 它将整个IP数据包 称为内部IP头 进行封装 然后增加一个IP头 称为外部IP头 并在外部与内部IP头之间插入一个IPsec头 该模式的通信终点由受保护的内部IP头指定 而IPsec终点则由外部IP头指定 如果IPsec终点为安全网关 则该网关会还原出内部IP包 再转发到最终的目的地 IPsec支持嵌套隧道 即对已隧道化的数据包再进行隧道化处理 保留 负载长度 认证数据 完整性校验值ICV 变长 序列号 安全参数索引 SPI 下一头部 认证数据 一个变长字段 也叫IntegrityCheckValue 由SA初始化时指定的算法来计算 长度 整数倍32位比特 保留 负载长度 认证数据 完整性校验值ICV 变长 序列号 安全参数索引 SPI 下一头部 下一头部 8比特 标识认证头后面的下一个负载类型 负载长度 8比特 表示以32比特为单位的AH头部长度减2 Default 4 保留字段 16比特 保留将来使用 Default 0 SPI 32比特 用于标识有相同IP地址和相同安全协议的不同SA 由SA的创建者定义 只有逻辑意义 序列号 32比特 一个单项递增的计数器 用于防止重放攻击 SA建立之初初始化为0 序列号不允许重复 32位 认证头部 AH Internet HostA HostB VPN网关 VPN网关 经过IPSec核心处理以后 经过IPSec核心处理以后 传输模式下的AH认证工作原理 Internet HostA HostB VPN网关1 VPN网关2 经过IPSec核心处理以后 经过IPSec核心处理以后 隧道模式下的AH认证工作原理 认证数据 一个变长字段 也叫IntegrityCheckValue 由SA初始化时指定的算法来计算 长度 整数倍32位比特 下一头部 8比特 标识认证头后面的下一个负载类型 填充字段 8比特 大多数加密算法要求输入数据包含整数个分组 因此需要填充 负载数据 包含由下一头部字段给出的变长数据 SPI 32比特 用于标识有相同IP地址和相同安全协议的不同SA 由SA的创建者定义 只有逻辑意义 填充长度 8比特 给出前面填充字段的长度 置0时表示没有填充 下一头部 填充长度 认证数据 变长的 序列号 安全参数索引 SPI 32位 ESP头部 ESP尾部 ESP认证数据 加密的 认证的 序列号 32比特 一个单项递增的计数器 用于防止重放攻击 SA建立之初初始化为0 序列号不允许重复 负载安全封装 ESP Internet HostA HostB VPN网关 VPN网关 经过IPSec核心处理以后 经过IPSec核心处理以后 传输模式下的ESP工作原理 Internet HostA HostB VPN网关1 VPN网关2 经过IPSec核心处理以后 经过IPSec核心处理以后 隧道模式下的ESP工作原理 Internet HostA HostB VPN网关1 VPN网关2 经过IPSec核心处理以后 经过IPSec核心处理以后 组合IPSec协议 ESP认证 ESP尾 负载 ESP头 IP头 负载 IP头部 认证数据 AH头部 认证数据 AH协议 ESP协议 身份认证数据加密数据完整性校验重放攻击保护 身份认证数据完整性校验重放攻击保护 ESP可以取代AH吗 AH与ESP协议区别 电子商务的安全交易标准 1安全套接层协议 SSL 2安全电子交易协议 SET 电子商务实施初期采用的安全措施 部分告知 partialorder 在网上交易中将最关键的数据 如信用卡帐号及交易金额等略去 然后再用电话告知 以防泄密 另行确认 orderconfirmation 在网上传输交易信息之后 再用电子邮件对交易进行确认 才认为有效 在线服务 onlineservice 为了保证信息传输的安全 用企业提供的内部网来提供联机服务 1安全套接层协议 SSL securesocketslayer 是由Netscape公司是由设计开发的 其目的是通过在收发双方建立安全通道来提高应用程序间交换数据的安全性 从而实现浏览器和服务器 通常是Web服务器 之间的安全通信 SSL是一种利用公共密钥技术的工业标准 已经广泛用于Internet 它使用的是RSA数字签名算法 可以支持X 509证书和多种保密密钥加密算法 其运行机制是 在建立连接过程中采用公钥体制 在回话过程中采用专有密钥 加密的类型和强度则在两端之间建立连接的过程中判断决定 1 SSL提供的基本服务功能 信息保密 使用公钥和对称密钥技术实现信息保密 SSL客户机和SSL服务器之间的所有业务都使用在SSL握手过程中建立的密钥和算法进行加密 这样就防止了某些用户进行非法窃听 信息完整性 SSL利用机密共享和Hash函数组提供信息完整性服务 相互认证 是客户机和服务器相互识别的过程 2 SSL协议通信过程 接通阶段 客户机呼叫服务器 服务器回应客户 认证阶段 服务器向客户机发送服务器证书和公钥 如果服务器需要双方认证 还要向对方提出认证请求 客户机用服务器公钥加密向服务器发送自己的公钥 并根据服务器是否需要认证客户身份 向服务器发送客户端证书 确立会话密钥阶段 客户和服务器之间协议确立会话密钥 会话阶段 客户机与服务器使用会话密钥加密交换会话信息 结束阶段 客户机与服务器交换结束信息 通信结束 凡是支持送SSL协议的网页 都会以https 作为URL的开头 客户在与服务器进行SSL会话中 如果使用的是微软的IE浏览器 可以在右下方状态栏中看到一只金黄色的锁形安全标志 用鼠标双击该标志 就会弹出服务器证书信息 SSL的安全性服务对终端用户尽可能透明 与标准的HTTP连接申请不同 支持SSL的典型网络主机接收SSL连接的默认端口是443 当客户机连接该端口时 首先初始化握手协议 建立一个SSL对话时段 握手结束后 将对通信加密 并检查信息完整性 直到这个对话时段结束为止 每个SSL对话时段只发生一次握手 SSL协议的握手过程 SSL的握手协议非常有效的让客户和服务器之间完成相互之间的身份认证 其主要过程如下 客户端的浏览器向服务器传送客户端SSL协议的版本号 加密算法的种类 产生的随机数 以及其他服务器和客户端之间通讯所需要的各种信息 服务器向客户端传送SSL协议的版本号 加密算法的种类 随机数以及其他相关信息 同时服务器还将向客户端传送自己的证书 客户利用服务器传过来的信息验证服务器的合法性 服务器的合法性包括 证书是否过期 发行服务器证书的CA是否可靠 发行者证书的公钥能否正确解开服务器证书的 发行者的数字签名 服务器证书上的域名是否和服务器的实际域名相匹配 如果合法性验证没有通过 通讯将断开 如果合法性验证通过 将继续进行第四步 用户端随机产生一个用于后面通讯的 对称密码 然后用服务器的公钥 服务器的公钥从步骤 中的服务器的证书中获得 对其加密 然后将加密后的 预主密码 传给服务器 如果服务器要求客户的身份认证 在握手过程中为可选 用户可以建立一个随机数然后对其进行数据签名 将这个含有签名的随机数和客户自己的证书以及加密过的 预主密码 一起传给服务器 服务器和客户端用相同的主密码即 通话密码 一个对称密钥用于SSL协议的安全数据通讯的加解密通讯 同时在SSL通讯过程中还要完成数据通讯的完整性 防止数据通讯中的任何变化 客户端向服务器端发出信息 指明后面的数据通讯将使用的步骤中6中的主密码为对称密钥 同时通知服务器客户端的握手过程结束 服务器向客户端发出信息 指明后面的数据通讯将使用的步骤6中的主密码为对称密钥 同时通知客户端服务器端的握手过程结束 SSL的握手部分结束 SSL安全通道的数据通讯开始 客户和服务器开始使用相同的对称密钥进行数据通讯 同时进行通讯完整性的检验 双向认证SSL协议的具体过程 浏览器发送一个连接请求给安全服务器 服务器将自己的证书 以及同证书相关的信息发送给客户浏览器 客户浏览器检查服务器送过来的证书是否是由自己信赖的CA中心所签发的 如果是 就继续执行协议 如果不是 客户浏览器就给客户一个警告消息 警告客户这个证书不是可以信赖的 询问客户是否需要继续 接着客户浏览器比较证书里的消息 例如域名和公钥 与服务器刚刚发送的相关消息是否一致 如果是一致的 客户浏览器认可这个服务器的合法身份 服务器要求客户发送客户自己的证书 收到后 服务器验证客户的证书 如果没有通过验证 拒绝连接 如果通过验证 服务器获得用户的公钥 客户浏览器告诉服务器自己所能够支持的通讯对称密码方案 服务器从客户发送过来的密码方案中 选择一种加密程度最高的密码方案 用客户的公钥加过密后通知浏览器 浏览器针对这个密码方案 选择一个通话密钥 接着用服务器的公钥加过密后发送给服务器 服务器接收到浏览器送过来的消息 用自己的私钥解密 获得通话密钥 服务器 浏览器接下来的通讯都是用对称密码方案 对称密钥是加过密的 上面所述的是双向认证SSL协议的具体通讯过程 这种情况要求服务器和用户双方都有证书 单向认证SSL协议不需要客户拥有CA证书 具体的过程相对于上面的步骤 只需将服务器端验证客户证书的过程去掉 以及在协商对称密码方案 对称通话密钥时 服务器发送给客户的是没有加过密的 这并不影响SSL过程的安全性 密码方案 这样 双方具体的通讯内容 就是加过密的数据 如果有第三方攻击 获得的只是加密的数据 第三方要获得有用的信息 就需要对加密的数据进行解密 这时候的安全就依赖于密码方案的安全 而幸运的是 目前所用的密码方案 只要通讯密钥长度足够的长 就足够的安全 这也是我们强调要求使用128位加密通讯的原因 3 SSL2 0和SSL3 0比较 第一代Netscape产品采用了SSL2 0协议 如今的Netscape产品采用了新的SSL3 0协议 SSL2 0和SSL3 0在一些基本的SSL服务器上是相同的 例如信息完整性 私密性 相互认证性 SSL3 0增加了的功能有 为提高握手速度而减少握手信息 支持更多的密钥交换和加密算法 支持fortezza插卡 这是走向智能加密卡的第一步 改进了客户机证明申请协议 4 SSL协议的电子交易过程 交易过程的步骤 客户购买的信息首先发往商家 商家再将信息转发银行 银行验证客户信息的合法性后 再通知客户和商家付款成功 商家再通知客户购买成功 当用于银行卡网上支付流程时的缺点首先 客户的银行资料信息先送到商家 让商家阅读 这样 客户银行资料的安全性就得不到保证 其次 SSL协议虽然提供了资料传递过程的安全通道 但SSL协议安全方面有缺少数字签名功能 没有授权和存取控制 多方互相认证困难 不能抗抵赖 用户身份可能被冒充等弱点 SecureElectronicTransaction SET 背景 网上消费者发出的支付指令在由商户送到支付网关之前 是在公用网上传送的 这一点与持卡POS消费者有着本质的不同 因此 在开放的网络上处理交易 如何保证传输数据的安全成为电子商务能否普及的最重要的因素之一 SET正是在这种需求的推动下应运而生的 它是由VISA和MasterCard两大信用卡公司发起 会同IBM Microsoft等信息产业巨头于1997年6月正式制定发布的用于因特网事务处理的一种标准 3 4 2安全电子交易协议 SET协议是信用卡在因特网上进行支付的一种开放式该标准采用RSA公开密钥体制对通信双方进行认证 采用DES等对称加密体制加密要传输的信息 并用数字摘要和数字签名技术来鉴别信息的真伪及其完整性 包括了信用卡在电子商务中的交易协定和信息保密 信息完整 身份认证 数字签名等技术 目前已经被广为认可而成了事实上的国际通用的网上支付标准 其交易形态将成为未来电子商务的规范 1 SET协议的规范及功能 加密算法的应用 例如RSA和DES 证书信息和对象格式 购买信息和对象格式 认可信息和对象格式 划账信息和对象格式 对话实体之间信息的传输协议 SET协议交互操作是通过特定的协议和信息格式设定的 SET中包含多种协议 每一协议用于处理一个事务的不同阶段 通过复用公共密钥和私有密钥技术 单个SET事务最多可用六个不同的公共密钥加密 从而实现了信息集成 全部金融数据的证实和敏感数据的加密等工作 SET为电子商务提供的功能 信息保密性 数据的完整性 提供交易者的身份认证和担保 互操作性 2 SET协议所涉及的角色 持卡人 网上商店 发卡银行 收单银行 支付网关 CA认证中心 电子交易实例 应用SET的网上购物流 流程一 客户查询商品 流程二 客户的购物篮 流程三 客户填写并确认订单 电子支付方式 使用SET的网上购物流程 客户通过网络浏览器浏览在线商家的商品目录 选择要购买的商品 填写订单 包括欲购商品名称 规格 数量 交货时间及地点等信息 订单通过因特网发送给商家 商家进行应答 并告知以上订单货物单价 应付款数额和交货方式 消费者选择付款方式 此时SET开始介入 3 应用SET的购物流程 消费者发送给商家一个完整的订单及其要求付款的指令 在SET中 订单和付款指令由消费者进行数字签名 同时利用双重身份签名技术 保证商家看不到消费者的账号信息 在线商家接受订单后 向客户开户银行请求支付 此信息通过支付网关送达收单银行 并进一步提交发卡银行确认 确认批准后 发卡银行返回确认信息 经收单银行通过支付网关发给在线商家 在线商家发送订单确认信息给客户 客户端记录交易日志 以备日后查考 在线商家发送商品或提供服务 并通知收单银行将货款从客户账号转移到商家账号 或通知发卡银行请求支付 4 SET标准的应用与局限性 SET1 0版自1997年推出以来推广应用较慢 没有达到预期的效果 最大的挑战在于定期进行网上购物的消费者极少 原因主要是SET协议为了保证安全性而牺牲了简便性 操作过于复杂 成本较高 具有较大竞争力的SSL协议的广泛应用以及部分经济发达国家的法律规定了持卡人承担较低的信用卡风险等 SET协议提供了多层次安全保障 复杂程度显著增加 这些安全环节在一定程度上增加了交易的复杂性 另外 SET协议目前只局限于银行卡的网上支付 对其他方式的支付没有给出很好的解决方案 SET协议只支持B2C模式的电子商务 而不支持目前最具有前途和影响力的B2B电子商务交易 SET由于其高度的安全性和规范性 使其逐步发展成为目前安全电子支付的国际标准 RADIUS RemoteAuthenticationDialInUserService远程验证拨入用户服务 拨入用户的远程验证服务 AAA Authentication Authorization Accounting验证 授权 记费 NASNetworkAccessServer 网络接入服务器 1 在NAS端进行认证 授权和计费 2 通过协议进行远程的认证 授权和记帐 实现AAA的协议有RADIUS Kerberos TACACS 等 AAA定义 验证 Authentication 授权 Authorization 计费 Accounting RADIUS概述 RADIUS RemoteAuthenticationDial inUserService 是当前流行的安全服务器协议实现AAA 授权Authorization 验证Authentication和计费Accounting 功能 RADIUS结构及基本原理 RADIUS协议采用客户机 服务器 Client Server 结构 使用UDP协议作为传输协议RADIUS使用MD5加密算法对数据包进行数字签名 以及对口令进行加密RADIUS包机构灵活 扩展性好 采用UDP发送 0 1 2 3 4 5 0 8 16 24 1 为什么使用UDP 1 NAS和RADIUS服务器之间传递的一般是几十至上百个字节长度的数据 用户可以容忍几秒到十几秒的验证等待时间 当处理大量用户时服务器端采用多线程 UDP简化了服务器端的实现过程 2 TCP是必须

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论