密码学sec-chap11.ppt

1、第11讲 认证协议和身份认证实例,2020/8/14,认证协议,2,第11讲的主要内容,认证协议 Kerberos X.509认证服务,2020/8/14,认证协议,3,认证协议,双方认证 (mutual authentication) 单向认证 (one-way authentication),2020/8/14,认证协议,4,双边认证协议,最常用的协议，该协议使得通信各方互相认证鉴别各自的身份，然后交换会话密钥。 基于认证的密钥交换核心问题有两个： 保密性 时效性 为了防止伪装和防止暴露会话密钥，基本认证与会话密钥信息必须以保密形式通信。这就要求预先存在密钥或 公开密钥供实现加密使用。第二

2、个问题也很重要，因为 涉及防止消息重放攻击。,2020/8/14,认证协议,5,消息重放：最坏情况下可能导致暴露会话密钥，或成功地冒充其他人；至少也可以干扰系统的正常运行，处理不好将导致系统瘫痪。 对付重放攻击的一种方法是在认证交换中使用一个序数来给每一个消息报文编号。仅当收到的消息序数顺序合法时才接受之。但这种方法的困难是要求双方必须保持上次消息的序号。,2020/8/14,认证协议,6,1、时间戳：问题是时间是很难同步的。 2、（Challenge/Response）：A期望从B获得一个新消息 ，首先发给B一个临时值(challenge)，并要求后续从B收到的消息（response）包含正

3、确的这个临时值。,2020/8/14,认证协议,7,Kerberos,Kerberos: part of Project Athena at MIT Greek Kerberos: 希腊神话故事中一种三个头的狗，还有一个蛇形尾巴。是地狱之门的守卫。 Modern Kerberos: 意指有三个组成部分的网络之门的保卫者。“三头”包括： 认证(authentication) 簿记(accounting) 审计(audit),2020/8/14,认证协议,8,问题,在一个开放的分布式网络环境中，用户通过工作站访问服务器上提供的服务。 服务器应能够限制非授权用户的访问并能够认证对服务的请求。 工作站

4、不能够被网络服务所信任其能够正确地认定用户，即工作站存在三种威胁。 一个工作站上一个用户可能冒充另一个用户操作； 一个用户可能改变一个工作站的网络地址，从而冒充另一台工作站工作； 一个用户可能窃听他人的信息交换，并用重放攻击获得对一个服务器的访问权或中断服务器的运行。,2020/8/14,认证协议,9,Kerberos要解决的问题,所有上述问题可以归结为一个非授权用户能够获得其无权访问的服务或数据。 不是为每一个服务器构造一个身份认证协议，Kerberos提供一个中心认证服务器，提供用户到服务器和服务器到用户的认证服务。 Kerberos采用对称加密算法（无公钥体制）。 Kerberos Ve

5、rsion4和Version5 (RFC1510)。,2020/8/14,认证协议,10,信息系统资源保护的动机,单用户单机系统。用户资源和文件受到物理上的安全保护； 多用户分时系统。操作系统提供基于用户标识的访问控制策略，并用logon过程来标识用户。 Client/Server网络结构。由一组工作站和一组分布式或中心式服务器组成。,2020/8/14,认证协议,11,C/S环境下三种可能的安全方案,相信每一个单独的客户工作站可以保证对其用户的识别，并依赖于每一个服务器强制实施一个基于用户标识的安全策略。 要求客户端系统将它们自己向服务器作身份认证，但相信客户端系统负责对其用户的识别。 要求

6、每一个用户对每一个服务证明其标识身份，同样要求服务器向客户端证明其标识身份。,2020/8/14,认证协议,12,Kerberos的解决方案,Kerberos支持以上三种策略。 在一个分布式的client/server体系机构中采用一个或多个Kerberos服务器提供一个认证服务。 总体方案是提供一个可信第三方的认证服务。,2020/8/14,认证协议,13,Kerberos系统应满足的要求,安全。网络窃听者不能获得必要信息以假冒其它用户；Kerberos应足够强壮以至于潜在的敌人无法找到它的弱点连接。 可靠。Kerberos应高度可靠，并且应借助于一 个分布式服务器体系结构，使得一个系统能够

7、备份另一个系统。 透明。理想情况下，用户除了要求输入口令以外应感觉不到认证的发生。 可伸缩。系统应能够支持大数量的客户和服务器。,2020/8/14,认证协议,14,Kerberos Version4,引入一个信任的第三方认证服务，采用一个基于Needham & Schroeder协议。（已经多次了解其认证思想了） 采用DES，精心设计协议，提供认证服务。,2020/8/14,认证协议,15,MIT设计的一个场景,Athena: 雅典娜，智慧与技艺的女神。 Euripides:欧里庇得斯, 希腊的悲剧诗人。 通过Athena不断的构思和Euripides不断的寻找其中的漏洞，使大家明白了Ker

8、beros协议的原理。,2020/8/14,认证协议,16,MIT设计的一个场景,第一幕（有删节） Athena:我想我们可以其它机器来存文件。你可以到任何一台机器上登录去取你的文件。Euripides:打印怎么办呢？每个工作站都要有自已的打印机吗？谁来付钱？电子邮件呢？你怎么把邮件送到所有的工作站上去呢？Athena:啊.很明显我们没钱为每个人配一台打印机，但我们有专门的机器做打印服务。你把请求送到服务器，它就为你打印。邮件也可以这样做。专门有一台邮件服务器。你如果想要你的邮件，就联系邮件服务器，取走你的邮件。,2020/8/14,认证协议,17,MIT设计的一个场景,第二幕 （有删节） A

9、thena:你可以用一个笨办法解决这个问题：服务器让你输入你的口令。通过输口令的办法我可以证明我是谁。Euripides:那确实很笨拙。在像那样的系统里面，每一个服务器必须知道你的口令。如果网络有一千个用户,那每个服务器就要知道一千个口令。如果你想改变口令，你就必须联系所有服务器，通知它们修改口令。我想你的系统不会那么笨。Athena:我的系统没那么笨。它是象这样工作的：不光人有口令，服务也有口令。每个用户知道他们自已的口令，每个服务也知道它自已的口令。有一个认证服务知道所有的口令，用户的和服务的。认证服务把口令保存在一个单独的中央数据库中。 Euripides:把死人送过冥河的人是谁？Ath

10、ena:Charon?,2020/8/14,认证协议,18,MIT设计的一个场景,Athena:好，我猜我该描述一下这个系统了吧，嗯?比如说我们想要一种服务：邮件。在我的系统里面你无法使用一种服务，除非Charon告诉服务你确实是你所申明的人。也就是说你必须得到Charon的认证才能使用服务。当你向Charon请求认证的时候，你必须告诉Charon你要使用哪一个服务。如果你想用邮件，你要告诉Charon。Charon请你证明你的身份。于是你送给它你的密码。Charon把你的密码和它数据库中的密码相比较。如果相等，Charon就认为你通过了验证。Charon现在就要让邮件服务知道你通过了验证。既

11、然Charon知道所有服务的密码，它也知道邮件服务的密码。Charon把邮件服务的密码给你，你就可以使用这个密码使邮件服务相信你已通过验证。问题是，Charon不能直接给你密码，因为你会知道它。下次你想要邮件服务的时候，你就会绕过Charon使用邮件服务而不需要认证。你也可以假装某人来使用邮件服务。所以不是直接给你邮件服务的密码，Charon给你一张邮件服务的“票”。这张票含有你的名字，并且名字是用邮件服务的密码加密的。拿到票，你就可以向邮件服务请求你的邮件。你向邮件服务提出请求，并用你的票来证明你的身份。服务用它自已的密码来把票解密，如果票能被正确的解密，服务器将票里的用户名取出。服务把这个

12、名字和随票一起送上的用户名进行比较。如果相符，服务器就认为你通过了验证，就把你的邮件发给你。,2020/8/14,认证协议,19,一个简单的认证对话,引入认证服务器(AS)，它知道所有用户的口令并将它们存储在一个中央数据库中。另外，AS与每一个服务器共有一个唯一的保密密钥。这些密钥已经通过物理上或以更安全的手段分发。,2020/8/14,认证协议,20,考虑以下假定的对话：,(1) C AS: IDC | PC | IDV (2) AS C: Ticket (3) C V : IDC | Ticket Ticket = EKVIDC | ADC | IDV,其中： C: client AS :

13、 Authentication Server V : server IDC: identifier of user on C,IDV: identifier of V PC: password of user on C ADC: network address of C KV: AS与V共有的保密密钥,C,V,AS,(1),(2),(3),ADC防止何种攻击？,2020/8/14,认证协议,21,MIT设计的一个场景,第三幕 （有删节） Euripides:听起来好像每次我想要得到服务我都要去取一张新票。如果我整天的工作，我可能不只一次的要取我的邮件。我每次取邮件都要去取一张新票吗？如果真是这

14、样，我不喜欢你的系统。 Euripides:好一些。但我仍有问题。你似乎暗示我每次使用还没有票的服务时，我都必须给Charon我的密码我登录后想取我的文件。我向Charon请求我的票，这意味着我不得不使用我的密码。然后我想读我的邮件。又向Charon发一次请求，我又要输一次我的密码。现在假设我想把我的邮件送去打印。我又要向Charon发一次请求。你知道了吧？,2020/8/14,认证协议,22,MIT设计的一个场景,第三幕 （有删节） Athena:我以第一项限制开始：你只需要输入你的口令一次。我创造了一个新的网络服务来解决这个问题。它叫做“票据授权”服务，这个服务把Charon的票给用户。使

15、用它必须要有票：票据授权的票。票据授权服务其实只是Charon的一个版本，它可以存取Charon的数据库。它是Charon的一部分，可以让你通过票而不是口令来进行认证。总之，认证系统现在是象这样工作的：你登录到一个工作站，用一个叫kinit的程序与Charon服务器通讯。你向Charon证明你的身份，kinit程序取得一张票据授权票。现在你想从邮件服务器上取你的邮件。你还没有邮件服务器的票，所以你用“票据授权”票去取邮件服务的票。你不需要使用口令去取新的服务票。,2020/8/14,认证协议,23,MIT设计的一个场景,第三幕 （有删节） Euripides:非常正确。我想票需要增加两项信息：

16、生存期表示票多长时间内是合法的，和一个时间标记来说明Charon是什么时候发出这张票的。 Euripides:好的，我没话说，只要你在取得票据授权票的时候没有用明文在网上传输你的口令。,2020/8/14,认证协议,24,更安全的认证对话,两个主要问题 希望用户输入口令的次数最少。 口令以明文传送会被窃听。 解决办法 票据重用（ticket reusable） 票据许可服务器（ticket-granting server，TGS）,2020/8/14,认证协议,25,改进后的假想的对话：,用户登录的每次对话: (1) C AS : IDC | IDtgs (2) AS C : EKCTicke

17、ttgs 每种服务类型一次： (3) C TGS : IDC | IDv | Tickettgs (4) TGS C : TicketV 每种服务会话一次： (5) C V : IDC | TicketV Tickettgs = EKtgsIDC|ADC|IDtgs|TS1|Lifetime1 TicketV = EKVIDC|ADC|IDV|TS2|Lifetime2,2020/8/14,认证协议,26,Kerboros方案的详细描述,用户向AS请求代表该用户的票据许可票据。 AS发回加密的票据，密钥由口令导出。 票据许可票据包含用户ID、网络地址、TGS的ID、时戳与生存期。 用户请求服务

18、许可票据。 TGS验证，如通过则发服务许可票据。 用户使用服务许可票据请求服务。,2020/8/14,认证协议,27,Kerberos V4 的认证对话,两个问题 与TGS相关的生存期问题； 太长则？太短则？如何应付票据的过期使用？ 需要服务器向客户进行认证其本身； 假的服务器。 解决方案 会话密钥（session key） AS用安全方式向用户和TGS各自提供一块秘密信息， 然后用户也以安全方式向TGS出示该秘密来证明自己 的身份。这个秘密就是会话密钥。,2020/8/14,认证协议,28,2020/8/14,认证协议,29,Kerberos V4报文交换总结,认证服务交换：获得票据许可票据

19、 (1) C AS : IDC | IDtgs | TS1 (2) AS C : EKCKc,tgs | IDtgs | TS2 | Lifetime2 | Tickettgs Tickettgs = EKtgs Kc,tgs | IDC | ADC | IDtgs | TS2 | Lifetime2,2020/8/14,认证协议,30,Kerberos V4报文交换总结,票据许可服务交换：获得服务许可票据 (3) C TGS : IDV | Tickettgs | Authenticatorc (4) TGS C : EKc,tgsKc,v | IDV | TS4 | Ticketv Tic

20、kettgs = EKtgsKc,tgs| IDC| ADC| IDtgs | TS2 | Lifetime2 Ticketv = EKVKc,v|IDC|ADC| IDv|TS4|Lifetime4 Authenticatorc = EKc,tgsIDc|ADc|TS3,2020/8/14,认证协议,31,Kerberos V4报文交换总结,客户/服务器认证交换：获得服务 (5) C V : Ticketv | Authenticatorc (6) V C : EKc,vTS5+1 ( for mutual authentication) Ticketv = EKVKc,v|IDc|ADc|

21、IDv|TS4|Lifetime4 Authenticatorc = EKc,vIDc|ADc|TS5,2020/8/14,认证协议,32,基本原理 (a) 认证服务交换 Message(1)Client 请求 ticket-granting ticket IDC :告诉AS本client端的用户标识； IDtgs :告诉AS用户请求访问TGS； TS1 :让AS验证client端的时钟是与AS的时钟同步的； Message(2)AS返回ticket-granting ticket EKC :基于用户口令的加密，使得AS和client可以验证口令， 并保护Message(2)。 Kc,tgs

22、:session key的副本，由AS产生，client可用于在AS与client 之间信息的安全交换，而不必共用一个永久的key。 IDtgs :确认这个ticket是为TGS制作的。 TS2 :告诉client该ticket签发的时间。 Lifetime2:告诉client该ticket的有效期； Tickettgs:client用来访问TGS的ticket。,2020/8/14,认证协议,33,(b) 票据许可服务交换 Message(3)client 请求service-granting ticket IDv:告诉TGS用户要访问服务器V； Tickettgs :向TGS证实该用户已被

23、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签发的； TS4 :告诉client该ticket签发的时间； TicketV :client用以访问服务器V的ticket； Tickettgs:可重用，从而用户不必重新输入口

24、令； EKtgs :ticket用只有AS和TGS才知道的密钥加密，以预防篡改； Kc,tgs :TGS可用的session key副本，用于解密authenticator,从而 认证ticket； IDc :指明该ticket的正确主人；,2020/8/14,认证协议,34,客户/服务器鉴别交换 Message(5)client 请求服务 Ticketv :向服务器证实该用户已被AS认证； Authenticatorc:由客户生成，用于验证ticket有效； Message(6)客户对服务器的可选认证 Ekc,v :使C确认报文来自V； TS51： 使C确信这不使报文重放； TicketV

25、:client用以访问服务器V的ticket； EKv :用只有AS和TGS才知道的密钥加密的票据，以预防篡改； Kc,v: 用户的会话密钥副本； IDc ： 票据的合法用户； ADc： 防止非法使用； IDv: 使服务器确信解密正确；,2020/8/14,认证协议,35,Kerberos管辖范围与多重服务,一个完整的Kerberos环境包括一个Kerberos服务器，一组工作站，和一组应用服务器，满足下列要求： Kerberos服务器必须在其数据库中拥有所有参与用户的ID(UID)和口令散列表。所有用户均在Kerberos服务器上注册。 Kerberos服务器必须与每一个服务器之间共享一个保

26、密密钥。所有服务器均在Kerberos服务器上注册。,2020/8/14,认证协议,36,2020/8/14,认证协议,37,获得另一领域中的认证服务,分三步骤： （1）获得本地TGS的访问权； （2）请求一张远程TGS的票据许可票据； （3）向远程TGS申请其领域内的服务许可票据,2020/8/14,认证协议,38,细节描述： (1) C AS :IDC | IDtgs | TS1 (2) AS C :EKCKc,tgs | IDtgs | TS2 | Lifetime2 | Tickettgs (3) C TGS:IDtgsrem | Tickettgs | Authenticatorc

27、(4) TGS C: EKc,tgsKc,tgsrem | IDtgsrem | TS4 | Tickettgsrem (5) C TGSrem: IDvrem | Tickettgsrem | Authenticatorc (6) TGS C: EKc,tgsremKc,vrem | IDvrem | TSb | Ticketvrem (7) C Vrem:Ticketvrem | Authenticatorc,C,AS,TGS,TGSrem,Vrem,(1),(2),(3),(4),(5),(6),(7),2020/8/14,认证协议,39,Kerberos Version 5,改进ver

28、sion 4 的环境缺陷 加密系统依赖性，需DES Internet协议依赖性，需IP地址 消息字节次序（不明确字节顺序） Ticket的时效性（可能太短） 认证转发，用户的认证不能转发到其它主机或用户。 域间认证，,2020/8/14,认证协议,40,Kerberos Version 5,改进Version 4 的技术缺陷 Double encryption PCBC encryption Session key Password attacks,2020/8/14,认证协议,41,Kerberos 应用：,移动银行 MIDlet,2020/8/14,认证协议,42,Kerberos 应用：

29、,手机用户向 MIDlet 应用程序提供他或者她的用户名和密码（只由用户和电子银行共享的一个秘密）。这个密码只用于在 J2ME 应用程序内部的处理，它永远也不会进入网络。通过网络传输的只有用户名。 MIDlet 将用户名和密码交给 Kerberos 客户机。由 Kerberos 客户机负责建立与电子银行进行安全通信的上下文。 Kerberos 客户机请求 AS 发出一个 TGT。一个 TGT 请求表示一个安全会话。一个客户机可以在一个安全会话中建立多个子会话。 TGT 请求包含了发出请求的客户的用户名，但是不包括密码（共享的秘密）。 Kerberos 客户机向 AS 发送请求。 当 AS 收到

30、 TGT 请求时，它从请求中提出用户名并从内部数据库中取出相应的密码（共享的秘密）。然后 AS 发布一个 TGT 并将 TGT 包装在回复消息中。这个 TGT 包含一个纯文本部分和一个密码文本（加密的）部分。为了加密 TGT 的密码部分，AS 使用了由用户的密码生成的加密密钥。因此，只有知道密码的用户才能解开加密的部分。TGT 的加密部分还包含一个加密密钥，称为 会话密钥。,2020/8/14,认证协议,43,Kerberos 应用：,AS 向发出请求的 Kerberos 客户机发送回复消息（包括 TGT）。 收到 AS 的回复后，Kerberos 客户机从回复中取出 TGT 并解密 TGT

31、中加密的部分。 然后 Kerberos 客户机发出一个服务票据请求。这个请求包含了 TGT 和一个称为 鉴别码 (authenticator) 的加密结构。客户机用从 TGT 提取出的会话密钥加密鉴别码。鉴别码证明客户机掌握会话密钥。服务票据请求还指定了电子银行业务逻辑服务器的名字。 客户机向 TGS（它是电子银行的 KDC 的一部分）发送服务票据请求。 收到服务票据请求后，TGS 提取客户机向其请求服务票据的服务器的名称，然后授予一个服务票据。服务票据与 TGT 没有很大差别。与 TGT 一样，服务票据包含一个纯文本部分和一个密码文本（加密的）部分。TGS 用服务器的密钥（一个用服务器的共享

32、秘密生成的密钥）加密服务票据的密码文本部分，这样只有那个服务器可以解密这个服务票据的密码文本部分。TGS 在服务票据的密码文本部分中还加入了一个新的加密密钥。这个密钥称为 子会话密钥。注意现在有两个密钥：会话密钥和子会话密钥。 授予了服务票据之后，TGS 将服务票据包装在一个响应消息中。这个响应消息也包含一个密码文本部分，它是用会话密钥加密的。响应消息的密码文本部分包含子会话密钥。,2020/8/14,认证协议,44,Kerberos 应用：,TGS 向客户机发送响应消息。 收到 TGS 响应后，客户机用会话密钥解密密码文本部分，从而提取出子会话密钥。客户机还提取服务票据。 然后客户机向电子银

33、行业务逻辑服务器发出消息，并在消息中包装了服务票据。这个消息请求服务器与客户机建立新的安全会话。 客户机向电子银行的业务逻辑服务器发送消息。 电子银行的业务逻辑服务器从请求中提取服务票据，解密它的密码文本部分，并提取子会话密钥。这样客户机和服务器就都掌握这个密钥了。 电子银行的服务器向客户机发送一个肯定应答。,2020/8/14,认证协议,45,Kerberos 应用Window2000：,Windows 2000中有两种验证协议， 即Kerberos和公钥基础结构（Public Key Infrastructure， PKI）， 这两者的不同之处在于： Kerberos是对称密钥， 而PKI

34、是非对称密钥。 Kerberos作为基本的Windows 2000认证协议，与Windows 2000认证和存取控制安全框架进行了紧密整合。初始的Windows域登录由WinLogon提供，它使用Kerberos安全提供者（security provider）来获取一个初始的Kerberos票据。操作系统的其他组件，如转向器（Redirector）则使用安全提供者的SSPI接口来获取一个会话票据，以连接对远程文件存取的SMB服务器。,2020/8/14,认证协议,46,Kerberos 更深入了解：,The Evolution of the Kerberos Authentication Sy

35、stem“ 作者Cliff Neumann and Theodore Tso.,2020/8/14,认证协议,47,X.509认证服务,公钥基础设施（Public-Key Infrastructure）是信息安全的重要基础设施。在PKI技术框架中，许多方面都经过严格的定义，如用户的注册流程、数字证书的格式、CRL的格式、证书的申请格式以及数字签名格式等。国际电信联盟ITU X.509协议，是PKI技术体系中应用最为广泛、也是最为基础的一个国际标准。 是证书的标准,2020/8/14,认证协议,48,X.509认证服务PKI技术,PKI实际上是一套软硬件系统和安全策略的集合，它提供了一整套以证书

36、为基础，通过信任关系传递来保证安全通讯和电子商务交易的服务。,2020/8/14,认证协议,49,X.509认证服务PKI的要求,产生、验证和分发密钥：用户公私钥对的产生、验证及分发有两种方式，即用户自己产生或由代理产生。 签名和验证：在PKI体系中，对信息及文件的签名，以及对数字签名的认证是很普遍的操作。PKI成员对数字签名和认证可以采用多种算法，如RSA，DES等，这些算法可以由硬件、软件或硬软结合的加密模块（硬件）来完成。 证书的获取：在验证信息的数字签名时，用户必须事先获取信息发送者的公钥证书，以对信息进行解密验证，同时还需要CA对发送者所发的证书进行验证，以确定发送者身份的有效性。,

37、2020/8/14,认证协议,50,X.509认证服务 PKI的要求,验证证书：验证证书的过程是迭代寻找证书链中下一个证书和它相应的上级CA的证书。在使用每一个证书前，必须检查相应的CRL（Certificate Revocation List）。 保存证书：保存证书是指PKI实体在本地存储证书，以减少在PKI体系中获得证书的时间，并提高证书签名的效率。在存储每个证书之前，应该验证该证书的有效性。 本地保存的证书的获取：CA证书可以集中存放，也可分布式存放，即可从本地保存的证书中获取证书。,2020/8/14,认证协议,51,X.509认证服务CA的要求,一个典型的CA系统包括安全服务器、注册

38、机构RA、CA服务器、LDAP目录服务器和数据库服务器等。,2020/8/14,认证协议,52,X.509认证服务,X.509最早于1988年发布，1995起草了第三版。它是一个重要的标准，有广泛的应用：IP安全，SSL，SET等。 X.509基于公钥加密和签名。推荐使用RSA，没有指定散列算法。,2020/8/14,认证协议,53,X.509证书,X.509方案的核心是与每个用户联系的公开密钥证书。证书由可信证书权威机构（CA）创建，由CA或用户放在目录中。 目录服务器不负责公钥的生成或证书函数，它仅提供一个易于访问的位置以便用户获得证书。,2020/8/14,认证协议,54,X.509证书,X.509目前有三个版本：V1、V2和V3，其中V3是在V2的基础上加上扩展项后的版本，这些扩展包括由ISO文档（X.509-AM）定义的标准扩展，也包括由其他组织或团体定义或注册的扩展项。,2020/8/14,认证协议,55,