3.4 身份认证
对信息系统进行安全防护,常常需要正确识别与检查用户的身份,即身份认证[3]。身份认证这种认证形式可以将非授权用户屏蔽在系统之外,它是信息系统的第一道安全防线,其防护意义主要体现在两方面。首先,防止攻击者轻易进入系统,在系统中收集信息或者进行各类攻击尝试。其次,有利于确保系统的可用性不受破坏。信息系统的资源都是有限的,非授权用户进入系统将消耗系统资源,如果系统资源被耗尽,正常的系统用户将无法获得服务。
身份认证的本质是由被认证方提供标识自己身份的信息,信息系统对所提供的信息进行验证从而判断被认证方是否是其声称的用户。具体来看,身份认证涉及到识别和验证两方面的内容。所谓识别,指的是系统需要确定被认证方是谁,即被认证方对应于系统中的哪个用户。为了达到此目的,系统必须能够有效区分各个用户。一般而言,被用于识别用户身份的参数在系统中是唯一的,不同用户使用相同的识别参数将使得系统无法区分。最典型的识别参数是用户名,像电子邮件系统、BBS系统这类常见的网络应用系统都是以用户名标识用户身份的。而网上银行、即时通信软件系统常常以数字组成的账号、身份证号、手机号码作为用户身份的标识。验证则是在被认证方提供自己的身份识别参数以后,系统进行判断,确定被认证方是否对应于所声称的用户,防止身份假冒。验证过程一般需要用户输入验证参数,同身份标识一起由系统进行检验。
身份认证可以基于以下四种与用户有关的内容之一或它们的组合实现:
(1)所知。个人所知道的或所掌握的知识或信息,如密码、口令。
(2)所有。个人所具有的东西,如身份证、护照、信用卡、智能门卡等。
(3)所在。个人所用计算机的IP地址、办公室地址等。
(4)用户特征。主要是个人生物特征,如指纹、笔迹、声纹、手形、脸形、视网膜、虹膜、DNA,还有个人的一些行为特征,如走路姿态、击键动作、笔迹等。
目前,身份认证技术主要包括口令认证、信物认证、地址认证、用户特征认证和密码学认证。
1.口令认证
口令(或密码)认证是最典型的基于用户所知的验证方式。系统为每一个合法用户建立用户名和口令的对应关系,当用户登录系统或者执行需要认证身份的操作时,系统提示用户输入用户名和口令,并对用户输入的信息与系统中存储的信息进行比较,以判断用户是否是其所声称的用户。
口令认证简单、易于实施,应用非常广泛。但其存在很多缺点,以普通的网络应用系统为例,用户通过客户端向服务器发送用户名、口令信息进行身份认证,在客户端、通信链路以及服务器三处都有口令泄露的可能。具体来看,用户在使用客户端主机时,口令输入过程可能被其他人偷窥。此外,如果用户使用的客户端感染了盗号木马,木马可能采取键盘记录、屏幕截取等方式获取用户输入的账号、口令(密码)。在通信链路上,如果口令以明文传输,黑客采用网络监听工具就能对通信内容进行监视,可以轻易获取传输的用户名和口令信息。此外,在服务器端,如果服务器存在漏洞,黑客获取权限后,可以盗取存储口令信息的文件进行破解,获得用户口令。假若以上三方面的防护都很完善,但用户一旦使用的是比较简单的口令,则黑客可以很容易地猜解出来。
2.信物认证
信物认证是典型的基于用户所有的验证方式,它通常采用特定的信物标识用户身份,所使用的信物通常是磁卡或者各种类型的智能存储卡。拥有信物的人被认定为信物对应的用户。信物认证方式一般需要专门的硬件设备对信物进行识别和判断,其优点是不需要用户输入信息,用户使用方便。这种认证方式的难点是必须保证信物的物理安全,防止遗失被盗等情况。如果信物落入其他人手中,其他人可以以信物所有人的身份通过验证进入系统。
3.地址认证
地址认证是基于用户所在地址的一种认证方式。以IP地址为基础进行认证是使用最多的一种地址认证方式。系统根据访问者的源地址判断是否允许其访问或者完成其他操作。例如,在Linux环境下,可以在配置文件.rhost中添加主机所信任主机的IP地址,然后通过这些IP地址访问主机就可以直接进入系统。此外,互联网上很多下载站点限定只有指定IP地址范围的主机允许下载资源,如一些大学网站的教学资源只允许本校IP地址范围的主机访问。这种基于用户所在的认证方式,其优点是对用户透明,用户使用授权的地址访问系统,可以直接获得相应权限。缺点是IP地址的伪造非常容易,攻击者可以采用这种方式轻易进入系统。
4.用户特征认证
用户特征认证主要利用个人的生物特征和行为特征进行身份认证。指纹认证、人脸识别、虹膜扫描、语音识别都是较为常见的基于用户特征的认证方式。以使用广泛的指纹认证为例,每个人的指纹各不相同,采用这种验证方式的信息系统,必须首先收集用户的指纹信息并存储于专门的指纹库中。用户登录时,通过指纹扫描设备输入自己的指纹,系统将用户提供的指纹与指纹库中的指纹进行匹配,如果匹配成功,则允许用户以相应身份登录,否则用户的访问将被拒绝。
用户行为特征如果具有很强的区分度也可以被用于验证。例如,每个人的手写笔迹都不相同,手写签名在日常生活中被广泛用于标识用户身份。如果为信息系统增加专用的手写识别设备,也可以利用手写签名验证用户身份。每个用户键盘输入的速度、击键力量等均存在差异,可以利用击键模式作为用户认证的手段。
用户特征认证方式很难保证百分之百可靠,通常存在两种威胁。首先,系统可能由于特征判断的不准确,将非授权用户判定为正常用户接纳到系统中。其次,可能由于用户特征发生变化,如手指受伤导致指纹发生变化,天太冷导致击键比平常慢等,或者由于判定条件的不同,如采用人脸识别的验证方法,光线的不同、角度的差异以及表情的变化都有可能使系统将授权用户判定为非法用户。
5.密码学认证
密码学认证主要利用基于密码技术的用户认证协议进行用户身份的认证。协议规定了通信双方为了进行身份认证甚至建立会话密钥所需要进行交换的消息格式或次序。这些协议需要能够抵抗口令猜测、地址假冒、中间人攻击、重放攻击等。
常用的密码学认证协议有一次性口令认证、基于共享密钥的认证、基于公钥证书的认证、零知识证明和标识认证等。基于公钥证书的认证引入可信第三方认证机构(CA),以解决公钥认证时公钥的可靠获取问题,我们将在第4章介绍这一技术。零知识证明和标识认证读者可参考文献[21]。本节主要介绍其中的一次性口令认证协议S/KEY、基于共享密钥的认证技术。
3.4.1 一次性口令认证
很多网络应用使用口令进行用户认证,这种认证方式最大问题是如果口令设置很简单,或者不经常更改的话,甚至以明文形式在网络上传输,则很容易被人破解或截获下来进行重放攻击。因此,网络环境下的口令认证方式不能使用长期不变的静态口令,而应该在每次登录过程中加入不确定因素,使得每次登录的口令均不同,这就是一次性口令(One-Time Password,OTP)。
一次性口令一般使用双运算因子来实现:固定因子,即用户的口令或口令散列值;动态因子,每次不一样的因子,如时间,把流逝的时间作为变动因子,用户密码产生器和认证服务器产生的密码在时间上必须同步;事件序列,把变动的数字序列作为密码产生器的一个运算因子,加上用户的口令或口令散列值一起产生动态密码;挑战/应答,由认证服务器产生的随机数字序列(challenge)作为变动因子,不会重复,也不需要同步。
比较著名的一次性口令认证系统是1991年贝尔通信研究中心研制的挑战/应答式(challenge/response)动态密码身份认证系统S/KEY,其一次性口令生成原理如图3-6所示。
图3-6 S/KEY一次性口令生成原理
在S/KEY中,服务器产生挑战(challenge)信息。挑战信息由迭代值(Iteration Count,IC)和种子(seed)组成。迭代值,指定散列计算的迭代次数,为1~100之间的数,每执行一次挑战/响应过程,IC减1(当IC为1时,则必须重新进行初始化)。种子由两个字母和5个数字组成。例如,挑战信息“05 xa13783”表示迭代值为05,种子为“xa13783”。客户端收到挑战后,要将秘密口令与种子“xa13783”拼接后,做5次散列运算。
在S/KEY中支持三种散列函数,即MD4、MD5和SHA。OTP服务器将散列函数的固定输出折叠成64位(OTP的长度)。64位OTP可以被转换为一个由6个英文单词组成的短语,每个单词由1~4个字母组成,被编码成11位,6个单词共66位,其中最后2位(11*6 -64=2)用于存储校验和。校验和的计算方法是:OTP的64位被分解成许多位对,将这些位对进行求和,和的最低2位即为校验和。所有的OTP产生器必须计算出校验和,所有OTP服务器也必须能将校验和作为OTP的一部分进行校验。
在初始化阶段,认证服务器选取一个口令pwd(由种子和用户的秘密口令拼接而成)和一个数n(也就是IC),以及一个散列函数f,计算y=f n(pwd),并把y(即用户的首个OTP)和n的值存储在服务器上。初始登录时,服务器收到客户端的连接请求后,将seed和(n-1)作为挑战信息发送给客户端。客户端收到挑战信息后,计算y'=f(n-1)(pwd),并将y'作为响应发送给服务器。服务器收到后,计算z=f n(y')。如果z等于服务器上保存的y,则验证成功,然后将y的值替代成y',将n减1。下次登录时,客户端计算y''=f(n-1 -1)(pwd),以此类推,直到n等于1。当n等于1时,客户和服务器必须重新进行初始化。
下面我们来分析一下S/KEY的安全性。
在S/KEY中,用户的秘密口令没有在网络上传输,传输的只是一次性口令,并且一次性口令即使在传输过程中被窃取,也不能再次使用;客户端和服务器存储的是用户秘密口令的散列值,即使客户端和服务器被攻陷导致口令散列值被窃取,也需破解口令散列才能获得明文口令。因此,该方案有比较好的安全性。同时,该方案实现简单,成本不高,用户使用方便。由于使用散列函数计算一次性口令,因此,S/KEY的安全性与散列函数的安全性密切相关。如前所述,S/KEY使用的散列函数MD4、MD5和SHA-1都已不再安全。
S/KEY也存在一些不足,主要包括:
(1)用户登录一定次数后,客户和服务器必须重新初始化口令序列。
(2)为了防止重放攻击,系统认证服务器具有唯一性,不适合分布式认证。
(3)S/KEY是单向认证(即服务器对客户端进行认证),不能保证认证服务器的真实性。
(4)S/KEY使用的种子和迭代值采用明文传输,攻击者可以利用小数攻击来获取一系列口令冒充合法用户。攻击的基本原理是:①当用户向服务器请求认证时,攻击者截取服务器传给用户的种子和迭代值,并将迭代值改为较小的值;②然后,假冒服务器,将得到的种子和较小的迭代值发送给用户;③用户利用种子和迭代值计算一次性口令,发送给服务器;④攻击者再次截取用户传过来的一次性口令,并利用已知的散列函数依次计算较大迭代值的一次性口令,就可获得该用户后续的一系列口令,从而在一段时间内冒充合法用户而不被发现。
在S/KEY中,用户口令散列在网络中传输,增加了被攻击和破解的风险。为了解决这一问题,研究人员提出了改进的S/KEY协议。主要思想是:使用用户的口令散列对挑战进行散列计算,并将计算结果发送给服务器。服务器收到后,同样使用服务器保存的用户口令散列对挑战进行散列计算,并与客户端发来的应答进行比较,如果相同则认证通过,否则拒绝。认证通过后,服务器生成一个随机数作为后续会话的对称加密密钥,并用用户的口令散列加密后发送给客户端。后续的通信就可用该密钥加密,保障会话的机密性。方案中,一次性口令散列不会在网络上传输,降低了被截获的风险。Windows 2000及其之后版本中的NTLM认证所实现的挑战/响应机制就使用了这个改进的S/KEY协议。
3.4.2 基于共享密钥的认证
基于共享密钥的认证的基本要求是示证者和验证者共享密钥(通常是对称密码体制下的对称密钥)。对于只有少量用户的系统,每个用户预先分配的密钥的数量不多,共享还比较容易实现。但是,如果系统规模较大,通常需要一个可信第三方作为在线密钥分配器。国际标准化组织(ISO)和国际电子协议(IEC)分别定义了几个不需要可信第三方的认证方案,读者可参考文献[21]。本节主要介绍两个基于可信第三方的共享密钥认证方案。
1.Needham-Schroeder双向鉴别协议
下面我们来介绍著名的Needham-Schroeder双向鉴别协议(简称N-S协议),它综合利用了前面介绍的报文源认证、报文宿认证、报文内容认证、报文顺序认证技术,实现双向身份认证及密钥分配功能,后来很多鉴别协议(如Kerberos)都是基于N-S协议的。
N-S协议假定系统中有一个通信双方都信任的密钥分配中心(Key Distribution Center,KDC),负责双方通信会话密钥Ks的产生和分发。为了分配会话密钥,还必须有用于保护会话密钥的由通信双方和KDC共享的主密钥:Ka和Kb。主密钥通过带外方法分发,由于只用于保护会话密钥的分发,使用次数少,暴露机会少,因此只需定期更换。会话密钥Ks由KDC产生(每次不同),用主密钥保护分发,用于保护消息本身的传输,加密报文的数量多,但只使用有限时间,下次会话需重新申请。
N-S协议过程如图3-7所示。
图3-7 N-S协议过程
具体步骤如下:
(1)A向密钥分配中心申请与B通信的会话密钥Ks,请求中带上自己的身份标识符(IDA)和B的身份标志符(IDB)以及一个现时值(N1)。
(2)KDC产生会话密钥Ks,并用A的主密钥Ka对会话密钥分配消息(包括会话密钥Ks、B的ID号IDB、现时值N1、用B的主密钥Kb加密地发送给B的会话密钥信息)进行加密后发送给A。由于消息是用Ka加密的,因此只有A能成功解密消息,并且A知道该消息是由KDC发来的。A用Ka解密消息后,获得会话密钥Ks,并通过N1来判断响应是不是重放的。
(3)A从会话密钥分配消息中取出KDC给其通信对象B的会话密钥分配信息E(Kb,[Ks|| IDA])。由于消息用Kb加密了,所以可以防止窃听。B收到后,用自己的主密钥Kb解密消息,得到会话密钥密钥Ks。由于消息只能被B解密,因此A可以证实对方是B。解密后报文中的IDA使得B证实该会话密钥用于与A的通信。
执行完上述三个步骤后,A和B已得到了由KDC分配的一次性会话密钥,可用于后续的保密通信。但为了应对可能的重放攻击,还需执行以下两个步骤。
(4)B产生现时值N2,并用得到的会话密钥Ks加密,将密文发送A。用户A收到后用Ks解密,得到现时值N2。此步骤说明B已获得Ks。
(5)A用转换函数f对N2进行处理后,用Ks对f(N2)加密,发送给B。B收到后,解密消息,并还原出N2。此步骤使B确信A也知道Ks,现时f(N2)使B确信这是一条新的消息,而不是重放的。函数f通常是散列函数。
增加步骤(4)和(5)主要目的是防止攻击者截获步骤(3)中的报文并直接重放。尽管如此,上述N-S协议仍然有可能受到重放攻击。假设攻击者X得到了之前的会话密钥,虽然这一假设要比攻击者简单地观察和记录步骤(3)更难发生,但可能性是存在的,除非B无限期保存了所有之前和A会话时使用过的会话密钥,否则B就不确定下述过程是重放攻击:如果X能够截获步骤(4)的握手消息,他就能伪造步骤(5)中A的回复并将其发送给B,而B却认为该消息来自于A且用已认证的会话密钥加密。为了解决这一问题,Denning提出了改进措施,在步骤(2)和步骤(3)中添加时间戳来防止这种攻击,但这种方案需要实现网络中所有节点的时钟是同步的。详细情况读者可参考文献[16]的15.2.1节。
2.Kerberos认证协议
Kerberos[4]认证协议以N-S协议为基础,通过可信第三方进行客户和服务器间的相互认证,交换会话密钥,以建立客户和服务器间的信任和安全传输信道。Kerberos由美国麻省理工学院(MIT)首先提出并实现,是该校雅典娜计划的一部分。Kerberos共有五个主要版本,其中第1版到第3版主要由该校内部使用,第4版在MIT校外得到了广泛应用,后来发展到了第5版(V5)。第5版由John Kohl和Clifford Neuman设计,于1993年作为IETF标准草案颁布(RFC 1510),后经多次修订(RFC 1964,RFC 4120,RFC 4121,RFC 4757),最新文档是2012年7月颁布的RFC 6649。Windows从Windows 2000就开始支持基于Kerberos的认证协议。
Kerberos协议包含很多子协议,提供认证功能的主要有三个:
(1)认证服务交换(Authentication Service Exchange)协议。在客户(Client)和认证服务器(Authentication Server,AS)之间进行,客户向认证服务器发出认证请求。
(2)票证授予服务交换(Ticket Granting Service Exchange)协议。在完成AS交换后,在客户和票证授予服务器(Ticket Granting Server,TGS)之间进行,客户获得访问应用服务器的票证或许可证(Ticket Granting Ticket,TGT)。
(3)客户-服务器认证交换(Client/Server Exchange)协议。完成TGS交换后,客户使用获得的票证和应用服务器(Service Server,SS)或服务器(Server,S)进行交互。
在Kerberos中,密钥分配中心(KDC)由认证服务器(AS)和票证授予服务器(TGS)组成。将KDC分为两个子服务器的主要目的是为了方便实现用户的单点登录(Single Sign On,SSO)。单点登录主要发生在一个Kerberos域的用户访问其他Kerberos域的应用服务器的情况下,跨域之间的访问需要不同域的TGS预先建立信任。用户通过单个AS完成登录后,就能够获得多个TGS提供的服务,进而获得多个应用服务器提供的服务。
Kerberos协议中相互认证或请求服务的实体被称为委托人(principal)。委托人是一个具有唯一标识的实体,可以是一台计算机或一项服务,通过使用KDC颁发的票证来进行通信。委托人可以分为两类:用户和服务,分别具有不同种类的标识符。用户通过如“user@REALM”格式的用户主体名称(User Principal Name,UPN)来标识。一般来说,名称中的域名用大写,例如用户“bob”在“bhusa.com”域中应该表示为bob@BHUSA.COM。服务主体名称(Service Principal Name,SPN)是用于域中的服务和计算机账户。SPN的格式形如“serviceclass/host_ port/serviceName”。例如,主机“dc1.bhusa.com”上LDAP服务的SPN可能类似于“ldap/dc1.bhusa.com”,“ldap/dc1”和“ldap/dc1.bhusa.com/bhusa.com”。一个服务可能注册为多个SPN。通常是通过DNS来规范化主机名称的。这就解释了DNS为什么是微软Kerberos环境中的一个必要组件。查询服务的“规范化”名称,然后生成请求服务的SPN。
下面我们介绍Kerberos V5的基本内容(如无特别说明,下文出现的Kerberos指的是Kerberos V5),有关Kerberos V4的详细内容读者可参考文献[16]。
Kerberos的一般认证过程如表3-4所示。
表3-4 Kerberos协议过程
续表
表3-4中的“报文内容”所使用的符号说明如下。
● IDC:用户主体标志;
● IDS:应用服务器主体标志;
● IDTGS:票证授予服务器(TGS)标志;
● REX:标志用户X所属的域(Realm / Domain);
● ||:报文拼接符;
● ADX:用户X的网址;
● TS:时间戳(timestamp);
● KX:X的秘密密钥;
● KC,S:C与S的会话密钥;
● KC,TGS:C与TGS交互的会话密钥,由AS创建;
● E(KX,info):用密钥KX对info加密;
● TC,TGS:C与TGS交互的许可证,用KTGS加密;
● TC,S:C使用应用服务S的许可证,用KS加密;
● AC:客户端生成的认证码(Authenticator);
● Times:用于客户请求在许可证中设置时间,包括:from(请求许可证的起始时间),till(请求许可证的过期时间),rtime(请求till更新时间);
● Nonce:现时值,确保消息是新的,而不是攻击者重放的;
● Options:用于请求在返回的许可证中设置指定的标志位(Flags,如表3-5所示,详细解释读者可参考文献[16]);
● Subkey:子密钥,客户选择一个子密钥来保护与某特定应用服务间的会话,如果此域被忽略,则客户使用KC,S作为会话密钥;
● seq#:可选域,用于说明在此次会话中服务器向客户发送消息的序列号,以防止重放攻击。
表3-5 Kerberos V5中的标志域(Flags)
续表
如表3-4所示,Kerberos域内认证过程如下:
1.用户(Client)向AS发起请求(AS-REQ),申请访问许可证(TGT)。TGT与应用服务器(Server)无关,即用一个TGT可以申请多个Server的Ticket。发送的请求中包含Client自己的标志(IDC)、TGS标志(IDTGS)、起止时间(Times),用于客户请求在许可证中设置起止时间和现时(Nonce1)。与Kerberos V4不同的是,V5中将V4中的生命期(Lifetime,8位长,每单位表示5分钟,因此最长生命期为28×5=1280分钟)修改为精确的起止时间,允许许可证拥有任意长的生命期,同时使用Nonce1来防止重放。此外,V5在请求中增加了Options字段。
2.AS收到Client发来的请求(AS-REQ)后,验证IDC。验证通过后根据用户标识IDC在密钥数据库中检索得到该用户的基于用户口令的密钥KC,选择一个随机加密密钥KC,TGS,然后给Client发送响应(TGT)。响应中主要包括两部分:用客户密钥KC加密的KC,TGS、AS-REQ请求中设定的时间、现时和TGS标志,以及用TGS密钥KTGS加密的客户和TGS交互的许可证TC.TGS,里面包含了KC,TGS、标志(Flags)、主体信息(REC,IDC,ADC)、起止时间(Times)等。ADC为客户的地址信息,V4只使用IP地址,不支持其他地址类型,如ISO网络地址,V5中用类型和长度标记网络地址,允许使用任何类型的网络地址。
3.Client收到AS发回的响应(TGT)后,首先用自己的密钥KC(一般使用用户口令进行保护)解密得到KC,TGS,并保存加密的访问许可证TC,TGS。然后,Client向TGS发送一个请求(TGS-REQ),其中包括一个加密的TC,TGS和新生成的认证码AC。AC包含一个时间戳(TS1)和客户信息(REC,IDC),并用会话密钥KC,TGS加密。
4.TGS收到Client发来的请求(TGS-REQ)后,TGS用自己的密钥KTGS解密得到许可证TC,TGS,并用得到的会话密钥KC,TGS解密AC。通过比较它们之中的时间戳的有效性确定用户的请求是否合法。确认用户合法后,TGS生成用户要访问的某个应用服务器S的许可证TC,S,包括标志Flags、会话密钥KC.S、客户信息(REC,IDC)、TC,S的有效生存期,并且使用服务器S的密钥KS加密。然后,将TC,S和用KC,TGS加密的KC.S、生存期、现时、应用服务器的标志等信息一起发给用户C(响应TKT)。
5.Client收到TGS发来的响应(TKT)后,用KC,TGS解密得到会话密钥KC,S。当用户请求应用服务时(AP-REQ),提交该服务器的许可证TC,S以及认证码AC(包括时间戳、用户信息、子密钥等,并用会话密钥KC,S加密)。V5对V4的客户与应用服务器间的认证交换进行了改进,增加了两个新的域:子密钥(Subkey)和序列号(seq#)。在V5中,客户和服务器可以协商得到子会话密钥,使得每个会话密钥仅被使用一次。降低因为多次使用同一个许可证访问特定服务情况时,被攻击者获得以前的会话消息的可能性。
6.应用服务器(Server)收到TC,S和AC后,先用自己的密钥KS解密TC,S,得到会话密钥KC,S,通过它解密AC。通过比较时间戳的有效性,确认信息是否被修改。如果信息合法即认证成功。至此,用户和应用服务器之间就完成了会话密钥KC,S的交换。在V4中,如果用户要求与应用服务器相互认证,则应用服务器将自己刚得到的时间戳递增,加密后发送给用户(AP-REP)。在V5中,由于攻击者不可能在不知道密钥的情况下,创建消息AP-REP,因此不需要对时间戳进行上述处理。在许可证的有效期内,用户可随时用自己持有的许可证TC,S或使用协商的子密钥申请应用服务,并可用会话密钥或子密钥加密它们之间的通信。
上述过程中,完成了第2步,客户得到了自己与TGS通信的会话密钥KC,TGS和一个被TGS的密钥加密的数据包(包含KC,TGS和关于自己的一些确认信息)。接下来,客户必须提供更多的身份证明信息(称为Authenticator,主要包括一些Client身份标识、地址等信息和当前时间戳)给TGS以证明自己的身份(第3步)。TGS验证通过后,才将客户和应用服务器通信用的会话密钥(KC,S)和许可证(TC,S)发送给客户(第4步)。完成了上述4步,客户和应用服务器就可以直接进行双向认证了(第5、6步)。
在Kerberos V4中,使用DES作为加密算法,V5对此进行了改进:用加密类型标记密文,这样就可以使用多种加密技术。用加密类型和长度标记的密钥允许同一个密钥在不同算法中使用,并允许在给定算法中具有不同的表现形式。
Kerberos协议使用时间戳来防止重放,而基于时间戳的认证机制只有在Client和Server端的时间保持同步的情况才有意义。所以,使用Kerberos协议认证需保证域内所有节点的时间同步。在实际应用中,一般通过访问同一个时间服务器来获得当前时间的方式来实现时间的同步,如使用网络时间同步协议(NTP)实现时钟同步。
此外,KDC并没有将客户和服务器间的会话密钥KC,S发送给服务器,而只是发送给了客户,然后由客户发送给服务器。这样做的目的主要基于两点考虑:
(1)由于一个Server会面对许多不同的Client,而每个Client都有一个不同的会话密钥。那么Server就会为所有的Client维护这样一个会话密钥的列表,这样做对于Server来说是比较麻烦而低效的。
(2)由于网络传输的不确定性,可能出现这样一种情况:Client很快获得了会话密钥,并用这个会话密钥加密认证请求发送到Server,但是用于Server的会话密钥还没有收到,并且很有可能承载这个会话密钥的报文永远也到不了Server端。这样的话,Client将永远得不到Server的认证。
上面介绍的是在一个域(Realm)内的认证,跨域认证过程如图3-8所示。每个互操作域的Kerberos服务器(TGS)应共享一个对称密钥,双方的Kerberos服务器应相应注册。这种模式要求每一个域的Kerberos服务器必须相互信任其他域的Kerberos服务器对其域内用户的认证。如果有N个域,则需要N×(N-1)/2次安全密钥交换,才可以实现一个域与其他域的交互,可伸缩性不好。
图3-8 Kerberos跨域认证
Kerberos认证协议具有以下优点:
(1)一旦用户获得过访问某个服务器的许可证,只要在许可证的有效期内,该服务器就可根据这个许可证对用户进行认证,而无须KDC的再次参与。
(2)实现了客户和服务器间的双向认证。
(3)支持跨域认证。
(4)互操作性好。Kerberos现在已经成为计算机安全领域一个被广泛接受的标准,所以使用Kerberos可以轻松实现不同平台之间的互操作。
Kerberos也存在一些安全问题,主要包括:
(1)Kerberos认证中使用的时间戳机制依赖于域内时钟同步,如果时间不同步则存在较大的安全风险。例如,如果主机时间不同步,原来的许可证可能会被替换;如果应用服务器的时间提前或落后于客户和AS的时间,则应用服务器可能会把有效的许可证看成是一个重放攻击而拒绝它。实践中,使用的时钟同步协议(NTP)也存在不少安全隐患。
(2)Kerberos无法应付口令猜测攻击。AS在传输用户与TGS间的会话密钥时是以用户密钥加密的,而用户密钥是由用户口令生成的,因此可能会受到口令猜测攻击。在Kerberos V5中,新增了一种称为“预认证机制”使得口令攻击更困难,但无法杜绝。
(3)用户必须保证他们的私钥的安全。如果一个入侵者通过某种方法窃取了用户的私钥,他就能冒充用户的身份。
(4)Kerberos中AS和TGS采用集中式管理,容易形成瓶颈,系统的性能和安全性也过分依赖于这两个服务的性能和安全。
此外,Kerberos采用对称密码体制,因此很难实现不可否认性。Kerberos使用的散列函数MD4、MD5、SHA-1也已不再安全。
3.4.3 可扩展认证协议EAP
生活中,很多终端接入互联网是通过拨号网络(如ADSL)、无线网络(如Wi-Fi)、局域网(如单位内网)接入的。大多数情况下,只有注册用户使用的终端才能接入。接入过程主要包括两个步骤:认证使用终端的用户是否是注册用户和建立注册用户使用的终端与互联网中资源之间的传输路径,由接入控制设备完成。其中,第一步就是互联网接入控制过程中的身份认证。
在互联网接入控制中,早期拨号接入中常用的认证协议有口令认证协议(Password Authentication Protocol,PAP)、挑战握手认证协议(Challenge Handshake Authentication Protocol,CHAP)(参考文献[18]),无线接入网络中常用的认证协议有WEP、WPA/WPA2(将在第5章介绍)等。PAP协议和CHAP协议均是基于PPP(Point to Point Protocol)协议来实现终端和接入控制设备之间认证报文的传输。随着接入方式的增多,认证协议仅以PPP作为认证协议的承载协议已不再可行,需要定义新的认证协议的传输协议来适配接入网络的数据链路层协议。在这样的背景下,IETF在RFC 3748中定义了可扩展认证协议(Extensible Authentication Protocol,EAP)。
EAP是一种普遍使用的支持多种认证方法的认证框架协议,在客户和认证服务器之间为认证信息交换提供了一种通用的传输服务,可以封装多种认证方法的协议报文。在数据链路建立阶段不需要选定某一种特定的认证机制,只需说明要使用EAP认证即可,而把具体认证过程推迟到后面一个独立的认证阶段。在该阶段进行认证方式的协商和具体认证过程,并根据认证成功与失败来决定是否允许终端接入网络。
EAP协议层次结构如图3-9所示。
图3-9 EAP协议层次结构图
许多认证方法都可以在EAP协议上工作,如图3-9所示的EAP-TLS协议(RFC 5216)、EAP-TTLS协议(RFC 5281)、EAP-GPSK(RFC 5433)、EAP-IKEv2(RFC 5106)。EAP-TLS(EAP Transport Layer Security)使用TLS(Transport Layer Security)协议(将在第7章介绍)的握手协议进行认证,客户和服务器使用其数字证书进行双方认证。无线接入网(Wi-Fi)支持EAP-TLS认证,具体认证过程参见第5.1.3节。EAP-TTLS(EAP Tunneled TLS)和EAP-TLS基本相同,不同之处在于服务器首先要通过证书向客户证明自己,它使用密钥建立一个安全连接(“隧道”)用来对客户进行认证。此外,EAP-TTLS中服务器也允许使用PAP和CHAP进行认证。EAP-GPSK(EAP Generalized Pre-Shared Key)指定了一个适用于交互认证的基于预共享密钥的EAP认证方法。EAP-IKEv2(EAP Internet Key Exchange version 2)在IKEv2协议(将在第6章介绍)的基础上进行交互认证。
无论使用何种认证方法,认证信息和认证协议报文都由EAP协议进行传输。基于EAP的认证系统中,一般包括以下组件:
(1)EAP请求者(EAP peer):请求访问网络的客户终端。
(2)EAP认证者(EAP Authenticator):一个接入点(Access Point,AP)或网络访问服务器(Network Access Server,NAS)。它们要求客户先进行认证后才能接入网络。
(3)认证服务器(Authenticator Server):利用EAP认证方法和EAP客户进行交互,验证客户提供的信息,授权其访问网络。典型情况下,授权服务器是一个提供远程认证拨入用户服务(Remote Authentication Dial In User Service,RADIUS)的服务器。
认证服务器作为后台服务器可以为许多EAP认证者提供认证客户的服务,而后由EAP认证者进一步决定是否给客户提供接入服务,这就是EAP转移模式。有些情况下,认证者可能会集成了认证服务器的功能,此时就无须独立的认证服务器了。
认证前,客户通常使用一个底层协议(如PPP协议或IEEE 802.1x)与认证者建立连接。EAP客户和服务器之间交互的报文由以下几个域(Field)组成:
(1)类型(Code),1字节:指定EAP报文的类型,共4种:Request、Response、Success、Failure,对应的类型码分别为:1、2、3、4。
(2)标志符(Identifier),1字节:标识某一次请求/响应过程,用于匹配某一次认证过程中的Request和Response消息。
(3)长度(Length),2字节:EAP报文的长度,包含了Code、Identifier、Length和Data域。
(4)数据(Data):具体与认证有关的信息,通常包括Type域(1字节)和Type-Data域,其中Type域指定认证数据的类型(即认证机制或认证方法),如1表示身份(由于每个用户可能采用不同的认证机制,因此在开始认证过程前,需确定用户身份,然后才开始具体的认证过程),4表示CHAP认证,5表示OTP认证,13表示TLS认证等。Success和Failure类报文没有Data域。
在建立了客户和EAP认证者之间的底层通信连接后,就可以开始认证。EAP转换模式下的报文交互过程如图3-10所示。
图3-10 EAP转换模式下的报文交互过程
首先,认证者向客户(EAP请求者)发送一个对于其身份的请求(Data域的Type域为1),客户会返回一个带有其身份信息的响应,通过认证者转发给认证服务器。在收到身份响应后,认证服务器会根据用户的身份选择一种EAP认证方法,并发送第一个EAP请求报文,报文Data域的Type子域与认证方法有关。如果客户支持这种认证方法,就会响应一个该方法所对应的响应;否则,客户发送一个NAK,服务器要么选择另一种EAP认证方法,要么发送Failure报文结束认证。客户与服务器间交换的请求和响应次数取决于所使用的认证方法。交换过程中还包括密钥信息等认证相关信息的交换。
两种情况下认证过程结束:一是认证者认为该客户不能通过认证,给其发认证失败报文(Failure),二是认证者认为其认证成功,给其发认证成功报文(Success)。
有关不同认证方法下的EAP报文交换过程的详细情况读者可参考文献[18],本书的第5章、第6章、第7章也将有所介绍。