kerberos安全协议解析与编程实现.doc

Kerberos安全协议解析与编程实现 1．引言 看了好几期的黑防，发现谈论安全协议的文章很少，基本上都是一些HOOK各种API或者底层驱动方面的技术文章。下面我向大家介绍一种安全认证协议—kerberos安全协议的基本原理，并通过编程实现向大家展示如何借助编码设计，简单实现此协议。本文的读者可以是信息安全科班出身的学生但又未涉及到kerberos或者对安全协议感兴趣的任何读者，只要具有一定的安全编程知识即可。 其实安全协议的研究很早就存在，只是以前国内的研究者比较少，国内也没有开设信息安全专业的相关课程，如密码学等课程。直到网络信息高速发展的今天，大量的信息非法盗取、恶意篡改、木马、病毒像幽灵般穿梭在网络中时，大家才开始紧密的关注网络安全技术领域，各大高校也都开始纷纷设立信息安全专业。伟大的信息通信专家Shannon发表《保密系统的信息理论Kerberos安全认证协议基本框架 Kerberos安全认证协议是由MIT的Athena计划的认证服务而开发的，并广泛的应用于开放式的网络环境中，为通信的双方提供很好的双向认证服务，在客户与服务器之间构筑了一个安全桥梁，要求用户对每个向服务器提交的服务请求及其权限，必须预先经过第三方认证中心服务器的认证后，才被允许执行。换句话说，kerberos的整体设计方案是完全基于协议的可信任第三方认证服务的，客户和服务器均信任Kerberos认证服务器的认证。好了，现在我们来揭开它的基本原理： 一个Kerberos环境包含一个Kerberos服务器、若个客户端以及一些应用服务器。Kerberos服务器将客户端用户的用户名及口令均存放在它的数据库中。应用服务器和所有的客户都必须在初始化阶段到Kerberos服务器中注册。基本框架如图1所示： 图 1 kerberos安全认证协议基本结构 3．Kerberos双向认证过程与逆向推理分析 （1）Client → AS：客户端向认证服务器发送认证请求KRB_AS_REQ，其内容是：{ c，Tgs，TS1} 。其中，c表示客户标识，告诉AS 客户端身份，便于AS到数据库中查询c的密钥； Tgs是TGS 服务器标识，告诉AS用户请求访问的TGS；TS1用于使AS能验证客户端时钟是否与AS时钟同步，其实也就是一个时间戳的概念，给AS作参考判断来自Client端的消息是否已经过期。 （2）AS → Client：向客户端发送认证回应KRB_AS_REP，其内容为{K(c，Tgs)，TS2，lifetime，Tickets_Tgs}Kc。K(c，Tgs)是由AS随机产生的一个密钥，用于Client与TGS共享的一个会话私钥。TS2是票据发放的时间戳；Tickets_Tgs是AS 发给Client的用于访问TGS的票据授权票据；有了此票据后，用户就可以向TGS申请任一的应用服务器，而不需要每次重复的输入Client端的登录密钥。它定义为：Tickets_Tgs = { K(c, tgs), c, c_mac, Tgs, TS2, lifetime2 } Ktgs。其中Tickets_Tgs已经采用TGS的私钥加密。这部分其实在Kerberos V5的版本已经作了修改，因为Tickets_Tgs已经采用TGS的私钥加密，故没有必要采用客户端的私钥再次加密。 （3）C→TGS：Client在第2步中获得AS认证，并取得票据授权票据后，Client即可向服务授权服务器（TGS）申请服务票据。发送的消息定义为KRB_TGS_REQ = {AppServ, Tickets_Tgs, Authen_info}，其中AppServ是用户期望访问的服务器；Authen_info 是发送的一条认证消息，用于确认发送票据Tickets_Tgs 的用户合法。定义为：Authen_info = { c , c_mac , TS3 } K(c, tgs)。 这里我们可以假设，若不发送Authen_info 消息，则当cracker截获了Tickets_Tgs票据，同时向TGS发送此票据，那么TGS只针对此Tickets_Tgs票据是无法判断此票据是否真正来自合法客户端，而验证器消息Authen_info则正好解决了此问题，当TGS收到Client发来的Req请求服务授权票据时，TGS首先会采用自己的私钥Ktgs解密Tickets_Tgs，获取AS为Client和TGS双方随机产生的共享密钥K(c, tgs)，然后利用此密钥解密Authen_info消息，提取出客户端用户名及其MAC地址，然后将这些同Tickets_Tgs包含的C和c_mac进行比较，若一致，则断定此次Req来自合法客户端。 （4）TGS → C: 当TGS验证Req来自合法Client时，则构造下面这条消息KRB_TG