潘爱民，北京大学计算机研究所 http://www.icst.pku.edu.cn/InfoSecCourse 网络与信息安全 安全基础 (一) 潘爱民，北京大学计算机研究所 http://www.icst.pku.edu.cn/InfoSecCourse.

Presentation on theme: "潘爱民，北京大学计算机研究所 http://www.icst.pku.edu.cn/InfoSecCourse 网络与信息安全 安全基础 (一) 潘爱民，北京大学计算机研究所 http://www.icst.pku.edu.cn/InfoSecCourse."— Presentation transcript:

1 潘爱民，北京大学计算机研究所 http://www.icst.pku.edu.cn/InfoSecCourse
网络与信息安全 安全基础 (一) 潘爱民，北京大学计算机研究所

2 内容 关于认证协议 Windows平台的认证协议 HTTP认证协议 与身份认证相关的研究工作介绍

3 安全层次 应用安全 系统安全 网络安全 安全协议 安全的密码算法

4 回顾：信息安全的需求 保密性Confidentiality 完整性Integrity 可用性Availability
系统完整性 数据完整性 可用性Availability 真实性 authenticity 认证 消息认证 身份认证：验证真实身份和所声称身份相符的过程 ……

5 认证协议 基于对称密码算法的认证方案 基于公钥密码算法的认证方案 是否需要密钥分发中心(KDC)？ 对于协议的攻击手法 认证的对象
消息发送方 消息本身 基于公钥密码算法的认证方案 公钥和身份的绑定

6 基于对称密码算法的认证 消息认证 身份认证 MAC码或者HMAC码 前提：存在共享密钥 依据 基于口令 双向和单向认证
密钥管理中心 或者用一个密钥交换协议 身份认证 依据 所知：口令、密钥，等 所有：身份证、智能卡，等 物理标识：指纹、笔迹、DNA，等 基于口令 证明是否知道口令 口令的强度 双向和单向认证 目的：分发密钥、签名有效性，……

7 通讯方式 两方通讯 有第三方介入的认证 在线和离线 其他情形 一方发起通讯，另一方应答 双向和单向认证 第三方为可信任方，KDC 多方认证
跨域认证 委托认证模型、信任模型 ……

8 为什么需要认证协议 本地多用户认证 远程用户认证 Login：如何管理口令 一次性 多次访问资源或者服务 访问资源或者服务之前进行认证
身份，获得credential 利用credential访问资源或者服务

9 认证例子：263的邮件登录

10 认证例子：sina的邮件登录

11 Client与Proxy-Server之间的认证

12 Client与Proxy-Server之间认证(续)

13 基于口令的认证+明文传输！！！ Telnet远程登录 逐个字母发送，明文方式 POP3邮件登录 Ftp服务 ……

14 如果你知道Kab, 那么你就知道Ks, 我就知道你是A
认证协议：设计一个协议(一) 假设A和B要进行通讯，A和B有一个共享的密钥Kab,如何利用这个密钥进行认证，并且商定一个会话密钥Ks 我是A 告诉你Ks， 以后就用它， 别让别人知道 A B 好的，我用它 试试，可我怎 么知道你是B呢 Kab 如果你知道Kab, 那么你就知道Ks, 我就知道你是A 1 AB: (IDA||N1) 2 BA: EKab[Ks,IDB,f(N1),N2)] 3 AB: EKs[f(N2)] 这里的f函数为某个确定的运算，比如f(x)=x+1

15 认证协议：设计一个协议(二) 假设A和B要进行通讯，A和B与KDC各有一个共享密钥Ka和Kb, 如何利用这两个密钥进行认证，并且商定一个会话密钥Ks 会话密钥Ks，由A送给B的认证信息 KDC 我是A，我 想和B通讯 Ka Kb 我把必要的 信息告诉你 A B 我把消息给你，如果 你是B,你就可以解开 AKDC: (IDA||IDB||N1) KDCA: EKa[Ks||IDB||N1||EKb(Ks,IDA)] AB: EKb(Ks,IDA)||EKs(M)

16 针对认证协议的一些常见攻击手段和相应对策
中间人攻击(MITM, man in the middle) A B E 如果通讯双方没有任何先决条件，那么这种攻击总是存在的 A和B的协商过程很容易受到这一类攻击 对策： 增加A和B之间的先决知识

17 常见攻击和对策(二) 重放攻击(replay attacks) B A E
偷听者可以记录下当前的通讯流量，以后在适当的时候重发给通讯的某一方，达到欺骗的目的 对策： nonce 保证通讯的唯一性 增加时间戳

18 常见攻击和对策(三) 字典攻击 对策 只要能够获得口令的密文形式，就可以实施字典攻击 在线和离线 字典攻击的有效性
判断一个口令是有效的 对策 用户和管理员：选择好的口令 协议设计：对口令的使用过程中，不要泄露口令的信息 在密文中增加口令以外的额外信息

19 常见攻击和对策(四) 已知明文攻击 选择明文攻击
在许多认证协议中，一方会选择一个随机数，并且明文传输这个随机数，另一方加密这个随机数，并送回来——Challenge/Response， 所以偷听者可以获得已知明文/密文对 对策： 避免传输明文/密文对 增加已知明文攻击的难度 选择明文攻击 在认证协议中，如果随机数的选择没有任何规则，那么中间人或者假冒方就有可能选择随机数，从而实施选择明文攻击 对策 随机数的选择限制

20 认证协议中的常用技术(一) 时间戳 A收到一个消息，根据消息中的时间戳信息，判断消息的有效性 这种方法要求不同参与者之间的时钟需要同步
在网络环境中，特别是在分布式网络环境中，时钟同步并不容易做到 一旦时钟同步失败 要么协议不能正常服务，影响可用性(availability)，造成拒绝服务(DOS) 要么放大时钟窗口，造成攻击的机会 时间窗大小的选择应根据消息的时效性来确定

21 认证协议中的常见技术(二) 询问/应答方式(Challenge/Response) A期望从B获得一个条件
首先发给B一个随机值(challenge) B收到这个值之后，对它作某种变换，得到response，并送回去 A收到这个response，可以验证B符合这个条件 在有的协议中，这个challenge也称为nonce 可能明文传输，也可能密文传输 这个条件可以是知道某个口令，也可能是其他的事情 变换例子：用密钥加密，说明B知道这个密钥; 简单运算，比如增一，说明B知道这个随机值 常用于交互式的认证协议中

22 分析一个协议： Kehn92 1 A → B 2 B → KDC 3 KDC → A 4 A → B IDA||Na
IDB||Nb || EKb[IDA || Na || Tb] 3 KDC → A EKa[IDB||Na ||Ks|| Tb ] || EKb[IDA || Ks || Tb] || Nb 4 A → B EKb[IDA || Ks || Tb] || EKs[ Nb ] KDC 3 2 A 1 B 4

23 关于Kehn92协议 EKb[IDA || Ks || Tb]相当于一个ticket 如果A要再次访问B，可以不再通过KDC
A → B：EKb[IDA || Ks || Tb] || Na’ B检查ticket是否在有效时间，若是，则 B → A：Nb||EKs[Na] A → B：EKs[Nb’] KDC 1 A B 2 3

24 Windows采用的认证方案 LanManager认证(称为LM协议) NTLM v1 认证协议 NTLM v2 认证协议
早期版本 NTLM v1 认证协议 NT 4.0 SP3之前的版本 NTLM v2 认证协议 NT 4.0 SP4开始支持 Kerberos v5认证协议 Windows 2000引进 安全性 加强

25 LanMan认证方案 可以用于共享级认证 Windows 9x/NT都支持 由IBM开发

26 LanMan的口令加密方案 从口令——〉hash值 缺陷 建议：使用7位或者14位口令 口令变成大写
把口令变成14个字符，或者截断、或者补空字符 这14个字符分成两个7字符 用7个字符和DES算法加密一个“magic ”64位 把两个64位结果拼起来，得到128位值 服务器保存该128位值，作为“hashed password” 缺陷 如果口令长度在8-13位之间，则后面的7字符先破解，对前7个字符的破解可以提供某些信息 建议：使用7位或者14位口令

27 NT的口令加密方案 从口令变成hash值 一种更好的方法是在口令上添加一些附加的信息，这样可以增加破解的难度 黑客工具L0phtcrack
把口令变成Unicode编码 使用MD4散列算法 得到128位散列值 一种更好的方法是在口令上添加一些附加的信息，这样可以增加破解的难度 Hash之前增加附加信息 UNIX的crypt使用了附加信息 黑客工具L0phtcrack 下载： 使用注意事项

28 NT口令破解的一个测试结果 在一台高端PC机(4个CPU)上强行破解 5.5小时内破解字母-数字口令 45小时破解字母-数字-部分符号口令
480小时破解字母-数字-全部符号口令

29 插：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算法

30 NTLM认证过程(from MSDN) 用户在客户机上，提供域名、用户名和口令。系统计算口令的hash值，然后把口令丢掉
客户把用户名以明文方式发送给服务器 服务器产生一个128位随机数(challenge或者nonce)，发送给客户 客户用口令的hash值作为密钥，加密随机数，并把结果送回给服务器。这是应答(response) 服务器把以下信息送给域控制器(DC): 用户名、challenge和response 域控制器利用用户名从SAM(Security Account Manager)数据库得到用户口令的hash值，并用此值加密challenge 域控制器比较它自己算出来的challenge密文和客户算出来的challenge密文。如果相等的话，认证成功

31 NT Workstation认证协议 C->S ReqChal,Cc S->C Cs
C、S计算会话密钥 Ks = E(PW[9..15],E(PW[0..6],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

32 Kerberos认证协议 Kerberos是一个经过长期考验的认证协议 Kerberos替代NTLM的原因 功能 效率方面 标准化 委托机制
可传递的信任关系 效率方面 服务器不需要每次都与域控制器联系 标准化

33 Kerberos概要

34 认证协议实例分析：HTTP认证协议 Web应用的认证机制 HTTP/1.1规范 HTTP本身支持的认证协议 SSL协议
Basic Authentication Digest Access Authentication

35 认证框架 基本思想：challenge-response机制，服务器询问客户，客户提供认证信息 基本过程 说明
指明authentication scheme 基本过程 当客户请求一个被保护的资源的时候，服务器返回401(Unauthorized)应答消息 应答头中包含一个WWW-Authenticate域 然后开始认证过程 最后，如果服务器不能接受客户的credential，则应该返回一个401消息，继续下一轮的认证 说明 Proxy在中间必须是透明的

36 认证框架(续) 一些消息类型 认证方案： 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

37 Basic Authentication 认证的思想：对于每一个域(realm)，客户都需要提供一个用户-ID和口令 消息
challenge = “Basic” realm credential = “Basic” basic-credentials

38 Basic Authentication(续)
过程 服务器发出challenge，例如 WWW-Authenticate: Basic realm=“xxx(URI)" 客户收到之后，发送应答 basic-credentials = base64-user-pass base64-user-pass = <base64 [4] encoding of user-pass, except not limited to 76 char/line> user-pass = userid ":" password userid = *<TEXT excluding ":"> password = *TEXT 例如，如果用户id为aladdin，口令为“open sesame”，则消息如下 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

39 插：Base-64和Radix-64编码 特点： 转换： 转换到字符集，而不是字符集的编码
目标字符集包括65个可打印字符，其中一个用于padding，其他的可用6位表达 不包括控制字符，所以不怕传输过程中被滤掉 没有使用“-”字符，避免与RFC 822冲突 转换： 3个8位=24位——〉4个6位，每个6位转换到一个字符，最终得到4个字符，如果用ASC码来表达，则为4个字节

40 编码表

41 二进制数据的Base-64编码

42 数据尾部的编码处理 编码时，按24位进行处理，到最后可能出现三种情况： 最后一组正好是24位，则无需特殊处理
最后一组是16位，则前两个6位组按正常情形处理，剩下的4位补上两位0，当作一组编码，然后再补上一个‘=’ 最后一组是8位，则第一个6位组正常处理，剩下2位补上4位0，当作一组编码，然后，再补上两个‘=’作为输出。

43 Digest Access Authentication
仍然基于一个简单的challenge-response结构 但是它用一个nonce值作为challenge 应答是一个hash值(缺省MD5算法)，包括 用户名、口令、nonce值、 HTTP方法、以及被请求的URI 好处 口令不在网上传输

44 Digest Access Authentication
Hash值的编码 HEX编码 每四位变成对应的16进制字符 口令的初始分发没有规定

45 服务器的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

46 客户的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"

47 服务器的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 <"> 可用于双向认证

48 Digest Access Authentication例子
客户请求一个文档，没有包含Authorization头，则服务器响应 HTTP/ Unauthorized WWW-Authenticate: Digest qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" 然后客户提示用户输入用户名和口令，并生成一个新的请求，其中包含Authorization头 Authorization: Digest username="Mufasa", uri="/dir/index.html", qop=auth, nc= , cnonce="0a4f113b", response="6629fae49393a c4ef1",

49 两种方案的安全性 Basic Authentication，最严重的问题 Digest Authentication 口令不加密传输
如果允许用户选择口令，则会波及到其他的系统 碰到假冒的服务器 Digest Authentication 安全性不如基于公钥的机制 总比没有好 安全性强于Basic authentication 不提供保密性 一定程度的完整性

50 Digest Authentication的攻击
重放攻击 重放攻击是否有意义 因为digest中包含了URI的信息——只对当前文档有效 利用ip地址、时间信息、nonce、etag信息等可以减弱重放攻击的危害性 中间人攻击(MITM) 协商方案的时候，中间人降低客户端的认证 中间人提供一个免费的proxy，从而获得口令 中间人欺骗客户去访问它想要的资源

51 Digest Authentication的攻击(续)
选择明文攻击 中间人或者恶意服务器可以选择nonce，以便客户计算response MD5增加了攻击的难度 客户可以使用cnonce 服务器一端的安全性 口令文件必须妥善保管 与response计算策略结合起来 思想类似于UNIX的口令文件

52 HTTP中的NTLM认证协议示例 请求资源 拒绝，要求认证 又一个连接

53 HTTP中NTLM认证协议示例(续) challenge response 授权访问

54 与身份认证相关的研究工作介绍 Microsoft Passport Recursive Authentication Protocol
Nested signatures Data Integrity in an Active Content System XML中的认证

55 Hailstorm: Passport 中心化的认证服务 对于所有的成员站点，只需一个登录和配置管理服务 Passport
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 A protected resource 1 2 Client 7 8 3 4 5 Passport (Logon Service) 6

56 Recursive Authentication Protocol

57 Nested signatures Workflow systems CA hierarchical trees
Signature on some fields of paper CA hierarchical trees

58 Data Integrity in an Active Content System
gx+ry mod q

59 Standards: XML中加入数字签名的例子
<Signature Id="MyFirstSignature” xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" <SignatureMethod Algorithm=" <Reference URI=" </Reference> </SignedInfo> <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>

60 参考资料 书 William Stallings, Cryptography and network security: principles and practice, Second Edition “Hackers Beware”，中文版《黑客(攻击透析与防范) 》 文章 NT Domain Authentication, Web站点 RFC 2616,2617,