欢迎来到三一文库! | 帮助中心 三一文库31doc.com 一个上传文档投稿赚钱的网站
三一文库
全部分类
  • 研究报告>
  • 工作总结>
  • 合同范本>
  • 心得体会>
  • 工作报告>
  • 党团相关>
  • 幼儿/小学教育>
  • 高等教育>
  • 经济/贸易/财会>
  • 建筑/环境>
  • 金融/证券>
  • 医学/心理学>
  • ImageVerifierCode 换一换
    首页 三一文库 > 资源分类 > PPT文档下载
     

    SecCourse-04安全基础(一).ppt

    • 资源ID:2127422       资源大小:819.01KB        全文页数:60页
    • 资源格式: PPT        下载积分:8
    快捷下载 游客一键下载
    会员登录下载
    微信登录下载
    三方登录下载: 微信开放平台登录 QQ登录   微博登录  
    二维码
    微信扫一扫登录
    下载资源需要8
    邮箱/手机:
    温馨提示:
    用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)
    支付方式: 支付宝    微信支付   
    验证码:   换一换

    加入VIP免费专享
     
    账号:
    密码:
    验证码:   换一换
      忘记密码?
        
    友情提示
    2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
    3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
    4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
    5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。

    SecCourse-04安全基础(一).ppt

    网络与信息安全 安全基础 (一),潘爱民,北京大学计算机研究所 http:/www.icst.pku.edu.cn/InfoSecCourse,内容,关于认证协议 Windows平台的认证协议 HTTP认证协议 与身份认证相关的研究工作介绍,安全层次,安全的密码算法,安全协议,网络安全,系统安全,应用安全,回顾:信息安全的需求,保密性Confidentiality 完整性Integrity 系统完整性 数据完整性 可用性Availability 真实性 authenticity 认证 消息认证 身份认证:验证真实身份和所声称身份相符的过程 ,认证协议,基于对称密码算法的认证方案 是否需要密钥分发中心(KDC)? 对于协议的攻击手法 认证的对象 消息发送方 消息本身 基于公钥密码算法的认证方案 公钥和身份的绑定,基于对称密码算法的认证,消息认证 MAC码或者HMAC码 前提:存在共享密钥 密钥管理中心 或者用一个密钥交换协议 身份认证 依据 所知:口令、密钥,等 所有:身份证、智能卡,等 物理标识:指纹、笔迹、DNA,等 基于口令 证明是否知道口令 口令的强度 双向和单向认证 目的:分发密钥、签名有效性,,通讯方式,两方通讯 一方发起通讯,另一方应答 双向和单向认证 有第三方介入的认证 第三方为可信任方,KDC 在线和离线 其他情形 多方认证 跨域认证 委托认证模型、信任模型 ,为什么需要认证协议,本地多用户认证 Login:如何管理口令 远程用户认证 一次性 访问资源或者服务之前进行认证 多次访问资源或者服务 身份,获得credential 利用credential访问资源或者服务,认证例子:263的邮件登录,认证例子:sina的邮件登录,Client与Proxy-Server之间的认证,Client与Proxy-Server之间认证(续),基于口令的认证+明文传输!,Telnet远程登录 逐个字母发送,明文方式 POP3邮件登录 Ftp服务 ,认证协议:设计一个协议(一),假设A和B要进行通讯,A和B有一个共享的密钥Kab,如何利用这个密钥进行认证,并且商定一个会话密钥Ks,1 AB: (IDA|N1) 2 BA: EKabKs,IDB,f(N1),N2) 3 AB: EKsf(N2) 这里的f函数为某个确定的运算,比如f(x)=x+1,Kab,我是A,告诉你Ks, 以后就用它, 别让别人知道,好的,我用它 试试,可我怎 么知道你是B呢,如果你知道Kab, 那么你就知道Ks, 我就知道你是A,认证协议:设计一个协议(二),假设A和B要进行通讯,A和B与KDC各有一个共享密钥Ka和Kb, 如何利用这两个密钥进行认证,并且商定一个会话密钥Ks,AKDC: (IDA|IDB|N1) KDCA: EKaKs|IDB|N1|EKb(Ks,IDA) AB: EKb(Ks,IDA)|EKs(M),Kb,我是A,我 想和B通讯,Ka,我把必要的 信息告诉你,我把消息给你,如果 你是B,你就可以解开,会话密钥Ks,由A送给B的认证信息,针对认证协议的一些常见攻击手段和相应对策,中间人攻击(MITM, man in the middle),如果通讯双方没有任何先决条件,那么这种攻击总是存在的 A和B的协商过程很容易受到这一类攻击 对策: 增加A和B之间的先决知识,常见攻击和对策(二),重放攻击(replay attacks),偷听者可以记录下当前的通讯流量,以后在适当的时候重发给通讯的某一方,达到欺骗的目的 对策: nonce 保证通讯的唯一性 增加时间戳,常见攻击和对策(三),字典攻击 只要能够获得口令的密文形式,就可以实施字典攻击 在线和离线 字典攻击的有效性 判断一个口令是有效的 对策 用户和管理员:选择好的口令 协议设计:对口令的使用过程中,不要泄露口令的信息 在密文中增加口令以外的额外信息,常见攻击和对策(四),已知明文攻击 在许多认证协议中,一方会选择一个随机数,并且明文传输这个随机数,另一方加密这个随机数,并送回来Challenge/Response, 所以偷听者可以获得已知明文/密文对 对策: 避免传输明文/密文对 增加已知明文攻击的难度 选择明文攻击 在认证协议中,如果随机数的选择没有任何规则,那么中间人或者假冒方就有可能选择随机数,从而实施选择明文攻击 对策 随机数的选择限制,认证协议中的常用技术(一),时间戳 A收到一个消息,根据消息中的时间戳信息,判断消息的有效性 如果消息的时间戳与A所知道的当前时间足够接近 这种方法要求不同参与者之间的时钟需要同步 在网络环境中,特别是在分布式网络环境中,时钟同步并不容易做到 一旦时钟同步失败 要么协议不能正常服务,影响可用性(availability),造成拒绝服务(DOS) 要么放大时钟窗口,造成攻击的机会 时间窗大小的选择应根据消息的时效性来确定,认证协议中的常见技术(二),询问/应答方式(Challenge/Response) A期望从B获得一个条件 首先发给B一个随机值(challenge) B收到这个值之后,对它作某种变换,得到response,并送回去 A收到这个response,可以验证B符合这个条件 在有的协议中,这个challenge也称为nonce 可能明文传输,也可能密文传输 这个条件可以是知道某个口令,也可能是其他的事情 变换例子:用密钥加密,说明B知道这个密钥; 简单运算,比如增一,说明B知道这个随机值 常用于交互式的认证协议中,分析一个协议: Kehn92,1 A B IDA|Na 2 B KDC IDB|Nb | EKbIDA | Na | Tb 3 KDC A EKaIDB|Na |Ks| Tb | EKbIDA | Ks | Tb | Nb 4 A B EKbIDA | Ks | Tb | EKs Nb ,4,2,3,1,关于Kehn92协议,EKbIDA | Ks | Tb相当于一个ticket 如果A要再次访问B,可以不再通过KDC A B:EKbIDA | Ks | Tb | Na B检查ticket是否在有效时间,若是,则 B A:Nb|EKsNa A B:EKsNb,2,1,3,Windows采用的认证方案,LanManager认证(称为LM协议) 早期版本 NTLM v1 认证协议 NT 4.0 SP3之前的版本 NTLM v2 认证协议 NT 4.0 SP4开始支持 Kerberos v5认证协议 Windows 2000引进,LanMan认证方案,可以用于共享级认证 Windows 9x/NT都支持 由IBM开发,LanMan的口令加密方案,从口令hash值 口令变成大写 把口令变成14个字符,或者截断、或者补空字符 这14个字符分成两个7字符 用7个字符和DES算法加密一个“magic ”64位 把两个64位结果拼起来,得到128位值 服务器保存该128位值,作为“hashed password” 缺陷 如果口令长度在8-13位之间,则后面的7字符先破解,对前7个字符的破解可以提供某些信息 建议:使用7位或者14位口令,NT的口令加密方案,从口令变成hash值 把口令变成Unicode编码 使用MD4散列算法 得到128位散列值 一种更好的方法是在口令上添加一些附加的信息,这样可以增加破解的难度 Hash之前增加附加信息 UNIX的crypt使用了附加信息 黑客工具L0phtcrack 下载:www.l0pht.com 使用注意事项,NT口令破解的一个测试结果,在一台高端PC机(4个CPU)上强行破解 5.5小时内破解字母-数字口令 45小时破解字母-数字-部分符号口令 480小时破解字母-数字-全部符号口令,插:UNIX中crypt口令加密方案,crypt()是一个口令加密函数,它基于DES算法。我们可以认为这是一个单向加密操作 函数原型: char *crypt(const char *key, const char *salt); *salt是两个字符,每个字符可从a-zA-Z0-9./中选出来 算法 UNIX标准算法使用DES加密算法,用key对一个常量进行加密,获得一个13字节的密文编码输出,其中包括salt的两个字符from Red Hat Linux 6.2 Salt的作用 同样的口令产生不同的密文 增加了穷举空间? 建议使用更为安全的MD5算法,NTLM认证过程(from MSDN),用户在客户机上,提供域名、用户名和口令。系统计算口令的hash值,然后把口令丢掉 客户把用户名以明文方式发送给服务器 服务器产生一个128位随机数(challenge或者nonce),发送给客户 客户用口令的hash值作为密钥,加密随机数,并把结果送回给服务器。这是应答(response) 服务器把以下信息送给域控制器(DC): 用户名、challenge和response 域控制器利用用户名从SAM(Security Account Manager)数据库得到用户口令的hash值,并用此值加密challenge 域控制器比较它自己算出来的challenge密文和客户算出来的challenge密文。如果相等的话,认证成功,NT Workstation认证协议,C-S ReqChal,Cc S-C Cs C、S计算会话密钥 Ks = E(PW915,E(PW06,Add(Cc,Cs) C: Rc = Cred(Ks,Cc) C-S Authenticate, Rc S: assert(Rc = Cred(Ks,Cc) Rs = Cred(Ks,Cs), S-C Rs C: assert(Rs = Cred(Ks,Cs) From NT Domain Authentication,Kerberos认证协议,Kerberos是一个经过长期考验的认证协议 Kerberos替代NTLM的原因 功能 委托机制 可传递的信任关系 效率方面 服务器不需要每次都与域控制器联系 标准化,Kerberos概要,认证协议实例分析:HTTP认证协议,Web应用的认证机制 HTTP本身支持的认证协议 SSL协议 HTTP/1.1规范 Basic Authentication Digest Access Authentication,认证框架,基本思想:challenge-response机制,服务器询问客户,客户提供认证信息 指明authentication scheme 基本过程 当客户请求一个被保护的资源的时候,服务器返回401(Unauthorized)应答消息 应答头中包含一个WWW-Authenticate域 然后开始认证过程 最后,如果服务器不能接受客户的credential,则应该返回一个401消息,继续下一轮的认证 说明 Proxy在中间必须是透明的,认证框架(续),一些消息类型 认证方案: auth-scheme = token auth-param = token “=“ ( token | quoted-string ) 询问: challenge = auth-scheme 1*SP 1#auth-param 提供范围信息(域) realm = “realm“ “=“ realm-value realm-value = quoted-string 客户提供认证信息 credentials = auth-scheme #auth-param,Basic Authentication,认证的思想:对于每一个域(realm),客户都需要提供一个用户-ID和口令 服务器检查用户-ID和口令 消息 challenge = “Basic” realm credential = “Basic” basic-credentials,Basic Authentication(续),过程 服务器发出challenge,例如 WWW-Authenticate: Basic realm=“xxx(URI)“ 客户收到之后,发送应答 basic-credentials = base64-user-pass base64-user-pass = user-pass = userid “:“ password userid = * password = *TEXT 例如,如果用户id为aladdin,口令为“open sesame”,则消息如下 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ=,插:Base-64和Radix-64编码,特点: 转换到字符集,而不是字符集的编码 目标字符集包括65个可打印字符,其中一个用于padding,其他的可用6位表达 不包括控制字符,所以不怕传输过程中被滤掉 没有使用“-”字符,避免与RFC 822冲突 转换: 3个8位=24位4个6位,每个6位转换到一个字符,最终得到4个字符,如果用ASC码来表达,则为4个字节,编码表,二进制数据的Base-64编码,数据尾部的编码处理,编码时,按24位进行处理,到最后可能出现三种情况: 最后一组正好是24位,则无需特殊处理 最后一组是16位,则前两个6位组按正常情形处理,剩下的4位补上两位0,当作一组编码,然后再补上一个= 最后一组是8位,则第一个6位组正常处理,剩下2位补上4位0,当作一组编码,然后,再补上两个=作为输出。,Digest Access Authentication,仍然基于一个简单的challenge-response结构 但是它用一个nonce值作为challenge 应答是一个hash值(缺省MD5算法),包括 用户名、口令、nonce值、 HTTP方法、以及被请求的URI 好处 口令不在网上传输,Digest Access Authentication,Hash值的编码 HEX编码 每四位变成对应的16进制字符 口令的初始分发没有规定,服务器的WWW-Authenticate 应答,challenge = “Digest“ digest-challenge digest-challenge = 1#( realm | domain | nonce | opaque | stale | algorithm | qop-options | auth-param ) domain = “domain“ “=“ URI ( 1*SP URI ) URI = absoluteURI | abs_path nonce = “nonce“ “=“ nonce-value nonce-value = quoted-string opaque = “opaque“ “=“ quoted-string stale = “stale“ “=“ ( “true“ | “false“ ) algorithm = “algorithm“ “=“ ( “MD5“ | “MD5-sess“ | token ) qop-options = “qop“ “=“ 1#qop-value qop-value = “auth“ | “auth-int“ | token,客户的WWW-Authorization请求头,credentials = “Digest“ digest-response digest-response = 1#( username | realm | nonce | digest-uri | response | algorithm | cnonce | opaque | message-qop | nonce-count | auth-param ) username = “username“ “=“ username-value username-value = quoted-string digest-uri = “uri“ “=“ digest-uri-value digest-uri-value = request-uri ; As specified by HTTP/1.1 message-qop = “qop“ “=“ qop-value cnonce = “cnonce“ “=“ cnonce-value cnonce-value = nonce-value nonce-count = “nc“ “=“ nc-value nc-value = 8LHEX response = “response“ “=“ request-digest request-digest = 32LHEX LHEX = “0“ | “1“ | “2“ | “3“ | “4“ | “5“ | “6“ | “7“ | “8“ | “9“ | “a“ | “b“ | “c“ | “d“ | “e“ | “f“,服务器的Authentication-Info头,AuthenticationInfo = “Authentication-Info“ “:“ auth-info auth-info = 1#(nextnonce | message-qop | response-auth | cnonce | nonce-count ) nextnonce = “nextnonce“ “=“ nonce-value response-auth = “rspauth“ “=“ response-digest response-digest = *LHEX ,可用于双向认证,Digest Access Authentication例子,客户请求一个文档,没有包含Authorization头,则服务器响应 HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm=“testrealmhost.com“, qop=“auth,auth-int“, nonce=“dcd98b7102dd2f0e8b11d0f600bfb0c093“, opaque=“5ccc069c403ebaf9f0171e9517f40e41“ 然后客户提示用户输入用户名和口令,并生成一个新的请求,其中包含Authorization头 Authorization: Digest username=“Mufasa“, realm=“testrealmhost.com“, nonce=“dcd98b7102dd2f0e8b11d0f600bfb0c093“, uri=“/dir/index.html“, qop=auth, nc=00000001, cnonce=“0a4f113b“, response=“6629fae49393a05397450978507c4ef1“, opaque=“5ccc069c403ebaf9f0171e9517f40e41“,两种方案的安全性,Basic Authentication,最严重的问题 口令不加密传输 如果允许用户选择口令,则会波及到其他的系统 碰到假冒的服务器 Digest Authentication 安全性不如基于公钥的机制 总比没有好 安全性强于Basic authentication 不提供保密性 一定程度的完整性,Digest Authentication的攻击,重放攻击 重放攻击是否有意义 因为digest中包含了URI的信息只对当前文档有效 利用ip地址、时间信息、nonce、etag信息等可以减弱重放攻击的危害性 中间人攻击(MITM) 协商方案的时候,中间人降低客户端的认证 中间人提供一个免费的proxy,从而获得口令 中间人欺骗客户去访问它想要的资源,Digest Authentication的攻击(续),选择明文攻击 中间人或者恶意服务器可以选择nonce,以便客户计算response MD5增加了攻击的难度 客户可以使用cnonce 服务器一端的安全性 口令文件必须妥善保管 与response计算策略结合起来 思想类似于UNIX的口令文件,HTTP中的NTLM认证协议示例,请求资源,HTTP中NTLM认证协议示例(续),challenge,与身份认证相关的研究工作介绍,Microsoft Passport Recursive Authentication Protocol Nested signatures Data Integrity in an Active Content System XML中的认证,Hailstorm: Passport,中心化的认证服务 对于所有的成员站点,只需一个登录和配置管理服务,A protected resource,1,Client,3,Passport (Logon Service),4,1 HTTP GET request without Passport ticket 2 return 302 and redirect to the Passport logon service 3 HTTP GET request to the logon service 4 present client a logon form 5 fill out the form, POST back to server (using SSL) 6 authenticate client, and redirect back to the original URI with ticket 7 client request the resource with ticket 8 the originating server authenticates client,5,2,6,7,8,Recursive Authentication Protocol,Nested signatures,Workflow systems Signature on some fields of paper CA hierarchical trees,Data Integrity in an Active Content System,gx+ry mod q,Standards: XML中加入数字签名的例子, MC0CFFrVLtRlk=.,参考资料,书 William Stallings, Cryptography and network security: principles and practice, Second Edition “Hackers Beware”,中文版黑客(攻击透析与防范) 文章 NT Domain Authentication, http:/mailhost.cb1.com/lkcl/ntdom/cifsntdomain.txt Web站点 RFC 2616,2617, http:/www.ietf.org/rfc.html,

    注意事项

    本文(SecCourse-04安全基础(一).ppt)为本站会员(本田雅阁)主动上传,三一文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知三一文库(点击联系客服),我们立即给予删除!

    温馨提示:如果因为网速或其他原因下载失败请重新下载,重复下载不扣分。




    经营许可证编号:宁ICP备18001539号-1

    三一文库
    收起
    展开