第十三讲. Kerberos认证协议与 X. 509 上海交通大学计算机科学系
1. 密钥管理 • 所有的密码系统都存在: 如何安全可靠地分 配密钥 • 许多情况下, 出现的安全问题不是因为密码 算法被破, 而是密钥分配系统被破 • 理想的情况是, 密钥分配协议应得到形式化 验证, 目前已有这方面的结果
2. Physical Delivery • 传统的物理方法 • 秘密传送
3. 认证密钥服务器 • • • 第三方可信的在线服务器 服务器与每个客户有个公享秘密钥 向客户分发密钥 可以利用对称密钥算法 Kerberos
4. Kerberos认证服务协议 • 是一项鉴别协议 • 解决的问题： • 在一个公开的分布式环境中， 作站上的用户 希望访问分布在网络中的服务器上的服务 • 服务器希望能够限制授权用户的访问，并能对 服务请求进行鉴别。
5. Kerberos使用的加密体制 • Kerberos不是为每一个服务器构造一个身份认 证协议，而是提供一个中心认证服务器，提供 用户到服务器和服务器到用户的认证服务。 • Kerberos采用传统加密算法（无公钥体制） • 常用版本：Kerberos Version 4和Version 5 (RFC 1510)
6. Kerberos的解决方案 • 在一个分布式的client/server体系机构中采用一个或 多个Kerberos服务器提供一个认证服务。 • 总体方案是提供一个可信第三方的认证服务。
7. Kerberos系统满足的要求 • 安全。网络窃听者不能获得必要信息以假冒其 它用户；Kerberos应足够强壮以至于潜在的敌 人无法找到它的弱点连接。 • 可靠。Kerberos应高度可靠，并且应借助于一 个分布式服务器体系结构，使得一个系统能够 备份另一个系统。 • 透明。理想情况下，用户除了要求输入口令以 外应感觉不到认证的发生。 • 可伸缩。系统应能够支持大数量的客户和服务 器
8. Kerberos Version 4 • 引入一个信任的第三方认证服务，采用一个基 于Needham & Schroeder协议。 • 采用DES，精心设计协议，提供认证服务。
9. 一个简单的认证对话 • 引入认证服务器(AS)，它知道所有用户的口令 并将它们存储在一个中央数据库中。另外，AS 与每一个服务器共有一个唯一的保密密钥。这 些密钥已经通过物理上或以更安全的手段分发
考虑以下假定的对话： (1) C AS: IDC || PC || IDV (2) AS C: Ticket (3) C V : IDC || Ticket AS Ticket = EKV[IDC || ADC || IDV] 其中： C : client AS : Authentication Server V : server IDC: identifier of user on C ADC防止何种攻击？ (1) (2) C IDV PC ADC KV (3) V : identifier of V : password of user on C : network address of C : AS与V共有的保密密钥
10. 上述对话存在的问题 • 两个主要问题 –希望用户输入口令的次数最少。 –口令以明文传送会被窃听。 • 解决办法 –票据重用（ticket reusable） –票据需可服务器（ticket-granting server，TGS）
![改进后的假想的对话： 用户登录的每次对话: (1) C AS : IDC || IDtgs (2) AS C : EKC[Tickettgs]](https://present5.com/presentation/1349a1ae15a2e54c2bc4020aec0038bb/image-13.jpg "改进后的假想的对话： 用户登录的每次对话: (1) C AS : IDC || IDtgs (2) AS C : EKC[Tickettgs]")
改进后的假想的对话： 用户登录的每次对话: (1) C AS : IDC || IDtgs (2) AS C : EKC[Tickettgs] 每种服务类型一次： (3) C TGS : IDC || IDv || Tickettgs (4) TGS C : Ticket. V Kerberos AS TGS (2) (3) (1) C 每种服务会话一次： (5) C V : IDC || Ticket. V Tickettgs = EKtgs[IDC||ADC||IDtgs||TS 1||Lifetime 1] Ticket. V = EKV[IDC||ADC||IDV||TS 2||Lifetime 2] (4) (5) V
11. 方案的详细描述 • 用户向AS请求代表该用户的票据许可票据。 • AS发回加密的票据，密钥由口令导出(Why？) • 票据许可票据包含用户ID、网络地址、TGS的 ID、时戳与生存期(Why? )。 • 用户请求服务许可票据。 • TGS验证，如通过则发服务许可票据。 • 用户使用服务许可票据请求服务。
• 改进方案仍存在的问题 –与TGS相关的生存期问题； • 太长则？太短则？如何应付票据的过期使 用？ –需要服务器向客户进行认证其本身； • 假的服务器
12. Kerberos V 4 的认证对话 • 解决方案 –会话密钥（session key） AS用安全方式向用户和TGS各自提供一块秘密 信息， 然后用户也以安全方式向TGS出示该秘密来证 明自己 的身份。这个秘密就是会话密钥
13. Kerberos V 4报文交换总结（1） • 认证服务交换：获得票据许可票据 – (1) C AS : IDC || IDtgs || TS 1 – (2) AS C : EKC[Kc, tgs || IDtgs || TS 2 || Lifetime 2 || Tickettgs] – Tickettgs = EKtgs [Kc, tgs || IDC || ADC || IDtgs || TS 2 || Lifetime 2]
Kerberos V 4报文交换总结（2） • 票据许可服务交换：获得服务许可票据 –(3) C TGS : IDV || Tickettgs || Authenticatorc –(4) TGS C : EKc, tgs[Kc, v || IDV || TS 4 || Ticketv] Tickettgs = EKtgs[Kc, tgs|| IDC|| ADC|| IDtgs || TS 2 || Lifetime 2] Ticketv = EKV[Kc, v||IDC||ADC|| IDv||TS 4||Lifetime 4] Authenticatorc = EKc, tgs[IDc||ADc||TS 3]
Kerberos V 4报文交换总结（3） • 客户/服务器认证交换：获得服务 –(5) C V : Ticketv || Authenticatorc –(6) V C : EKc, v[TS 5+1] ( for mutual authentication) Ticketv = EKV[Kc, v||IDc||ADc||IDv||TS 4||Lifetime 4] Authenticatorc = EKc, v[IDc||ADc||TS 5]
14. 公开公证或证书机构 • • 可信的离线服务器 server 有个公开的公钥 server 对每个用户签名公钥证书 利用公钥加密
15. 要素与基本原理 (a) 认证服务交换 Message(1) Client 请求 ticket-granting ticket IDC : 告诉AS本client端的用户标识； IDtgs : 告诉AS用户请求访问TGS； TS 1 : 让AS验证client端的时钟是与AS的时钟同步的； Message(2) AS返回ticket-granting ticket EKC : 基于用户口令的加密，使得AS和client可以验证口令， 并保护Message(2)。 Kc, tgs : session key的副本，由AS产生，client可用于在AS与 client 之间信息的安全交换，而不必共用一个永久的key。 IDtgs : 确认这个ticket是为TGS制作的。 TS 2 : 告诉client该ticket签发的时间。 Lifetime 2: 告诉client该ticket的有效期； Tickettgs: client用来访问TGS的ticket。
16. 基本原理(续) (b) 票据许可服务交换 Message(3) client 请求service-granting ticket IDv: 告诉TGS用户要访问服务器V； Tickettgs : 向TGS证实该用户已被AS认证； Authenticatorc: 由client生成，用于验证ticket； Message(4) TGS返回service-granting ticket EKc, tgs : 仅由C和TGS共享的密钥；用以保护Message(4)； Kc, tgs: session key的副本，由TGS生成，供client和server之间 信息的安全交换，而无须共用一个永久密钥。 IDv : 确认该ticket是为server V签发的； TS 4 : 告诉client该ticket签发的时间； Ticket. V : client用以访问服务器V的ticket； Tickettgs: 可重用，从而用户不必重新输入口令； EKtgs : ticket用只有AS和TGS才知道的密钥加密，以预防篡改； Kc, tgs : TGS可用的session key副本，用于解密authenticator, 从而 认证ticket； IDc : 指明该ticket的正确主人；
17 基本原理 客户/服务器鉴别交换: Message(5) client 请求服务 Ticketv : 向服务器证实该用户已被AS认证； Authenticatorc: 由客户生成，用于验证ticket有效； Message(6) 客户对服务器的可选认证 Ekc, v : 使C确认报文来自V； TS 5＋1： 使C确信这不使报文重放； Ticket. V : client用以访问服务器V的ticket； EKv : 用只有AS和TGS才知道的密钥加密的票据，以预 防篡改； Kc, v: 用户的会话密钥副本； IDc ： 票据的合法用户； ADc： 防止非法使用； IDv: 使服务器确信解密正确；
18. Kerberos领域和多个域服务 • 一个完整的Kerberos环境（域）包括一个 Kerberos服务器，一组 作站，和一组应用服 务器，满足下列要求： –Kerberos服务器必须在其数据库中拥有所有 参与用户的ID(UID)和口令散列表。所有用 户均在Kerberos服务器上注册。 –Kerberos服务器必须与每一个服务器之间共 享一个保密密钥。所有服务器均在Kerberos 服务器上注册。
19. 不同域间的鉴别机制 • 条件： • 每一个辖区的Kerberos 服务器与其它辖区内 的Kerberos服务器之间共享一个保密密钥。两 个Kerberos服务器互相注册。
20. 获得另一领域中的认证服务 • 分三步骤： （1）获得本地TGS的访问权； （2）请求一张远程TGS的票据许可票据； （3）向远程TGS申请其领域内的服务许可票据
细节描述： (1) C AS : IDC || IDtgs || TS 1 (2) AS C : EKC[Kc, tgs || IDtgs || TS 2 || Lifetime 2 || Tickettgs] (3) C TGS: IDtgsrem || Tickettgs || Authenticatorc (4) TGS C: EKc, tgs[Kc, tgsrem || IDtgsrem || TS 4 || Tickettgsrem] (5) C TGSrem: IDvrem || Tickettgsrem || Authenticatorc (6) TGS C: EKc, tgsrem[Kc, vrem || IDvrem || TSb || Ticketvrem] (7) C Vrem: Ticketvrem || Authenticatorc AS TGS (4) (1) (2) (3) C TGSrem (5) (6) (7) Vrem
21. Kerberos Version 5 • 改进version 4 的环境缺陷 –加密系统依赖性，需DES –Internet协议依赖性，需IP地址 –消息字节次序（不明确字节顺序） –Ticket的时效性（可能太短） –认证转发，用户的认证不能转发到其它主机或用户。 –域间认证，
22. 公钥证书 • • • 公钥管理包括公钥证书的使用 证书将用户身份与公钥绑定 也包括其他信息: 有效期、使用权限 所有内容有可信中心签名 (CA) 假设任何人可以得到或已知CA的公钥，并验证 证书
23. X. 509 鉴别服务 • CCITT X. 500 一部分，目录服务标准 • X. 509 定义了认证服务框架 • 这种目录可以存储证书 • 定义了利用证书的认证协议 • 使用公钥密码与数字签名 • 推荐使用RSA （不是标准）
24. X. 509 证书 • • • 由证书授权 (CA) 机构发送： each certificate contains: version (1, 2, or 3) serial number (unique within CA) identifying certificate signature algorithm identifier issuer X. 500 name (CA) period of validity (from - to dates) subject X. 500 name (name of owner) subject public-key info (algorithm, parameters, key) issuer unique identifier (v 2+)
25. X. 509 证书（续） • • subject unique identifier (v 2+) extension fields (v 3) signature (of hash of all fields in certificate) notation: CA<<User>> means CA has signed certificate details for User
26. 证书 扩展项 • 证书中，其它信息是有必要的 • 如： email address/URL, policy details, usage constraints etc • 参见 SSL的使用
27. 证书性质 • 任何能够访问CA的用户，可以得到CA上的任何 证书 • 只有 CA 能够修改证书 • 因为证书不能伪造，证书可以放在目录中 •
28. CA 分层结构 • 如果两个用户享有一个共同的CA，他们可以得到 CA的一个相同的公钥 • 若不是一个CA，则需要CA分层 • 利用证书链验证其它CA • 每个 CA 有对客户的证书和其上一级CA的证书 • 每个用户相信更高层的CA’S • 能够使得任何CA的用户验证其它CA签发的任何证 书
29. CA 分层 • A acquires B certificate following chain: • X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>> • B acquires A certificate following chain: • Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>> •
30. 认证流程 • X. 509 包括三种认证形式: • 单向认证（One-Way Authentication ） • 双向认证（Two-Way Authentication ） • 三向认证（Three-Way Authentication ）
31. 单向认证 • 1 个消息 ( A->B)： A{t. A, r. A, B, sgn. Data, Ek. Ub[Kab] } • 验证A的身份及消息来源于 • 发送到 B • 包括内容： timestamp, nonce, B's identity signed by A •
32. 双向认证 • 2 消息 (A->B, B->A) A{t. A, r. A, B, sgn. Data, Ek. Ub[Kab] } B{t. B, r. B, A, r. A, sgn. Data, Ek. Ua[Kba] }
33. 三向认证 • 3 messages (A->B, B->A, A->B) A{t. A, r. A, B, sgn. Data, Ek. Ub[Kab] } B{t. B, r. B, A, r. A, sgn. Data, Ek. Ua[Kba] } A{r. B}
34. 小结 • 密钥管理问题 • X. 509 证书与 CA's
Скачать презентацию 第十三讲 Kerberos认证协议与 X 509 上海交通大学计算机科学系 1 密钥管理
1349a1ae15a2e54c2bc4020aec0038bb.ppt