计算机网络工程实用技术之身份认证技术

身份认证是指定用户向系统出示自己身份的证明过程，通常是获得系统服务所必须的第一道关卡。VPN用到的身份认证技术有以下几种。

1.数字签名

（1）数字签名原理

数字签名标准（Digital Signature Standard，DSS）是国家标准技术研究所开发的数字签名算法。数字签名（Digital Signature，DS）是一种用使用者的私有密钥加密的Hash值。它可以像正常签名一样用于认证，但它也可以用做与签名相关的信息完整性的认证。

要想了解数字签名，应从电子签名开始。要理解什么是电子签名，需要从传统手工签名或盖印章谈起。在传统商务活动中，为了保证交易的安全与真实，一份书面合同或公文要由当事人或其负责人签字、盖章，以便让交易双方识别是谁签的合同，保证签字或盖章的人认可合同的内容，在法律上才能承认这份合同是有效的。而在电子商务的虚拟世界中，合同或文件是以电子文件的形式表现和传递的。在电子文件上，传统的手写签名和盖章是无法进行的，这就必须依靠技术手段来替代。能够在电子文件中识别双方交易人的真实身份，保证交易的安全性和真实性以及不可抵赖性，起到与手写签名或者盖章同等作用的签名的电子技术手段，称为电子签名。从法律上讲，签名有两个功能，即标识签名人和表示签名人对文件内容的认可。联合国贸发会的《电子签名示范法》中对电子签名做如下定义：“指在数据电文中以电子形式所含、所附或在逻辑上与数据电文有联系的数据，它可用于鉴别与数据电文相关的签名人和表明签名人认可数据电文所含信息”；在欧盟的《电子签名共同框架指令》中就规定：“以电子形式所附或在逻辑上与其他电子数据相关的数据，作为一种判别的方法称电子签名”。实现电子签名的技术手段有很多种，但目前比较成熟的，世界先进国家普遍使用的电子签名技术还是“数字签名”技术。由于保持技术中立性是制定法律的一个基本原则，目前还没有任何理由说明公钥密码理论是制作签名的唯一技术，因此有必要规定一个更一般化的概念以适应今后技术的发展。同样，《中华人民共和国电子签名法》（以下简称《电子签名法》）中提到的签名，一般指的就是数字签名。所谓数字签名就是通过某种密码运算生成一系列符号及代码组成电子密码进行签名，来代替书写签名或印章，对于这种电子式的签名还可进行技术验证，其验证的准确度是一般手工签名和图章的验证无法比拟的。数字签名是目前电子商务、电子政务中应用最普遍、技术最成熟、可操作性最强的一种电子签名方法。它采用了规范化的程序和科学化的方法，用于鉴定签名人的身份以及对一项电子数据内容的认可。它还能验证出文件的原文在传输过程中有无变动，确保传输电子文件的完整性、真实性和不可抵赖性。

数字签名在ISO 7498-2标准中定义为：“附加在数据单元上的一些数据，或是对数据单元所做的密码变换，这种数据和变换允许数据单元的接收者用以确认数据单元来源和数据单元的完整性，并保护数据，防止被人（例如接收者）进行伪造”。美国电子签名标准（DSS，FIPS186-2）对数字签名做了如下解释：“利用一套规则和一个参数对数据计算所得的结果，用此结果能够确认签名者的身份和数据的完整性”。按上述定义PKI（Public Key Infrastructure）可以提供数据单元的密码变换，并能使接收者判断数据来源及对数据进行验证。

目前，实现电子签名的技术手段有好多种，前提是在确认了签署者的确切身份是经过认证之后，电子签名承认人们可以用多种不同的方法签署一份电子记录。这些方法有：基于PKI的公钥密码技术的数字签名；用一个独一无二的以生物特征统计学为基础的识别标识，例如手书签名和图章的电子图像的模式识别；手印、声音印记或视网膜扫描的识别；一个让收件人能识别发件人身份的密码代号、密码或个人识别码PIN；基于量子力学的计算机等。但比较成熟的、使用方便具有可操作性的、在世界先进国家和我国普遍使用的电子签名技术还是基于PKI的数字签名技术。所以，就现在来讲，电子签名就是数字签名。

（2）数字签名的技术实现方法

对一个电子文件进行数字签名并在网上传输，其技术实现过程大致如下：首先要在网上进行身份认证，然后再进行签名，最后是对签名的验证。

1）认证。PKI提供的服务首先是认证，即身份识别与鉴别，就是确认实体即为自己所声明的实体。认证的前提是甲、乙双方都具有第三方CA所签发的证书，认证分单向认证和双向认证。

①单向认证。单向认证是甲、乙双方在网上通信时，甲只需要认证乙的身份。这时甲需要获取乙的证书，获取的方式有两种，一种是在通信时乙直接将证书传送给甲，另一种是甲向CA的目录服务器查询索取。甲获得乙的证书后，首先用CA的根证书公钥验证该证书的签名，验证通过说明该证书是第三方CA签发的有效证书。然后检查证书的有效期及检查该证书是否已被作废（LRC检查）而进入黑名单。

②双向认证。双向认证是甲、乙双方在网上通信时，甲不但要认证乙的身份，乙也要认证甲的身份。其认证过程的每一方都与上述单向认证过程相同，即乙方也用同样的过程认证甲方的证书有效性。甲乙双方在网上查询对方证书的有效性及黑名单时，采用LDAP协议（Light Directory Access Protocol），它是一种轻型目录访问协议。

2）数字签名与验证过程。网上通信的双方，在互相认证身份之后，即可发送签名的数据电文。数字签名的全过程分两大部分，即签名与验证。发方将原文用哈希算法求得数字摘要，用签名私钥对数字摘要加密求得数字签名，然后将原文与数字签名一起发送给收方。收方验证签名，即用发方公钥解密数字签名，得出数字摘要，收方将原文采用同样哈希算法又得一新的数字摘要，将两个数字摘要进行比较，如果两者匹配，说明经数字签名的电子文件传输成功。

3）数字签名的操作过程。数字签名的操作过程需要有发方的签名证书的私钥及其验证公钥。

数字签名操作具体过程如下：首先是生成被签名的电子文件（《电子签名法》中称数据电文），然后对电子文件用哈希算法做数字摘要，再对数字摘要用签名私钥做非对称加密，即做数字签名。之后是将以上的签名和电子文件原文以及签名证书的公钥加在一起进行封装，形成签名结果发送给收方，待收方验证。

4）数字签名的验证过程。收方收到发方的签名结果后进行签名验证。

收方收到数字签名的结果包括数字签名、电子原文和发方公钥，即待验证的数据。收方进行签名验证。验证过程是：收方首先用发方公钥解密数字签名，导出数字摘要，并对电子文件原文做同样哈希算法得一个新的数字摘要，将两个摘要的哈希值进行结果比较，结果相同签名得到验证，否则签名无效。《电子签名法》中要求对签名不能改动，对签署的内容和形式也不能改动。

如果收方对发方数字签名验证成功，就可以说明以下3个实质性的问题。

①该电子文件确实是由签名者的发方所发出的，电子文件来源于该发送者。因为签署时电子签名数据由电子签名人所控制。

②被签名的电子文件确实是经发方签名后发送的，说明发方用了自己的私钥做的签名，并得到验证，达到不可否认的目的。

③收方收到的电子文件在传输中没有被篡改，保持了数据的完整性，因为，签署后对电子签名的任何改动都能够被发现。

《电子签名法》中规定：“安全的电子签名具有与手写签名或者盖章同等的效力”。

2.认证授权

认证授权（Certificate Authority，CA）是一个实体，通常是一台计算机，它保存了一些公开密钥。事实上，它保存的一些称为认证的目标包含了用户或设备的信息，其中包括它们的公开密钥。认证包含某个公开密钥的所有者的认证信息，如姓名、地址、公司等。认证的目的有两个：标志一个用户或设备的公开密钥；确认假设的公开密钥的拥有者是公开密钥的真实拥有者。

CA的作用是检查证书持有者身份的合法性，并签发证书（用数学方法在证书上签字），以防证书被伪造或篡改。CA认证是顺应我国电子商务和电子政务的发展应运而生的。随着网上银行的普遍应用和在线支付手段的不断完善，网上交易已经变得越来越大众化，安全问题就显得日益重要。而网络间的身份认证成为根本。认证机构相当于一个权威可信的中间人，它的职责是核实交易各方的身份，负责电子证书的发放和管理。理想化的状态是，上网的每一个企业或者个人都要有一个自己的网络身份证作为唯一的识别。而这些网络身份证的发放、管理和认证就是一个复杂的过程，也就是所谓的CA认证。(www.xing528.com)

3.KerberosV5身份验证

Kerberos V5是 用于处理用户和系统身份的身份验证的Internet标准安全协议，是在Win-dows 2000 Server域 中进行身份验证的主要安全协议。使用Kerberos V5，通过网络线路所发送的密码将经过加密而不作为纯文本进行发送。Kerberos V5协 议校验了用户的身份和网络服务。这种双重验证被称为相互身份验证。

（1）Kerberos协议简介

在希腊神话中，Kerberos是守护地狱之门的三头狗。在计算世界里，美国麻省理工学院（MIT）把他们开发的这一网络认证系统命名为Kerberos。Kerberos认证协议是由美国麻省理工学院（MIT）在20世纪80年代首先提出并实现的，是该校Athena计划的一部分。因为Kerberos是一个第三方认证协议，根据称为密匙分配中心（KDC）的第三方服务中心来验证网络中计算机相互的身份，并建立密匙以保证计算机间安全连接。Kerberos协议基本上是可行的并且有效的。KDC由两部分组成：认证服务器AS和票据授权服务器TGS。Kerberos是一种网络认证协议，允许一台计算机通过交换加密消息在整个非安全网络上与另一台计算机互相证明身份。一旦身份得到验证，Kerberos协议将会给这两台计算机提供密匙，以进行安全通信对话。Kerberos协议可以认证试图登录上网用户的身份，并通过使用密匙密码为用户间的通信加密。总体来说，Kerberos是一种基于私钥加密算法的，需要可信任的第三方作为认证服务器的网络认证系统。它允许在网络上通信的实体互相证明彼此的身份，并且能够阻止旁听和重放等手段的攻击。不仅如此，它还能够提供对通信数据保密性和完整性的保护。

Kerberos从提出到今天，共经历了5个版本的发展。其中版本1到版本3主要在该校内部使用。当它发展到版本4的时候，已经取得了在MIT校园外的广泛认同和应用。但由于版本4的传播，人们逐渐发现了它的一些局限性和缺点（例如适用网络环境有限，加密过程存在冗余等）。MIT也充分吸收了这些意见，对版本4进行了修改和扩充，形成了今天非常完善的版本5。现在MIT提供的Kerberos V5的最新实现是版本krb51.3.3，本节中提到的实现都是以它为依据的。

（2）Kerberos协议术语解释

Principal：在Kerberos中Principal是参加认证的基本实体。一般来说有两种，一种用来表示Kerberos数据库中的用户，另一种用来代表某一特定主机，也就是说Principal是用来表示客户端和服务端身份的实体。Principal的格式采用ASN.1标准，即Abstract Syntax Notation One，来准确定义。Principal由3个部分组成：名字（name），实例（instance），域（REALM）。比如一个标准的Kerberos的用户是：name/instance@REALM。

Name：第1部分。在代表客户方的情况，它是一个用户名；在代表主机的情况，它是写成host。

Instance：第2部分。对name的进一步描述，例如name所在的主机名或name的类型等，可省略。它与第1部分之间用/分隔，但是作为主机的描述时写成host/Instance。

Realm：第3部分。是Kerberos在管理上的划分，在KDC中所负责的一个域数据库称作Realm。这个数据库中存放有该网络范围内的所有Principal和它们的密钥，数据库的内容被Ker-beros的认证服务器AS和票据授权服务器TGS所使用。Realm通常是也永远是大写的字符，并且在大多数Kerberos系统的配置中，一般Realm和该网络环境的DNS域是一致的。与第2部分之间用@分隔，默认为本地的Realm。比如，Principal“cnhawk/hawk.the9.com@THE9.COM”表示Realm“THE9.COM”中主机hawk.the9.com上的用户cnhawk，而Principal“host/hawk.the9.com@THE9.COM”则通常用来表示Realm“THE9.COM”中主机hawk.the9.com。

Credential：Ticket和与它相联系的会话密钥合在一起称为Credential。之所以有这个概念是因为它们是客户端在向服务器证明自己的身份时必需的两样东西。在一个Ticket的生存期内客户端会将这两样东西以Credential为单位保存在一个Cache文件中。

Ticket：一个Ticket是一个用于安全地传递用户身份所需要的信息的集合。它不仅包含该用户的身份，而且包含其他一些相关的信息。一般来说，它主要包括客户方Principal，目的服务方Principal，客户方IP地址，时间戳（分发该Ticket的时间），该Ticket的生存期，以及会话密钥等内容。它的格式亦用ASN.1来准确定义。

Authenticator：是在客户端向服务端进行认证时，伴随Ticket一起发送的另外一个部分。它的作用是证明发送Ticket的用户就是拥有Ticket的用户，即防止重放攻击。它的主要内容是一个时间戳（客户端发送Ticket的时间），在rfc 1510中有它的完整的ASN.1定义。

AS（Authentication Server）：为用户分发TGT（Ticket Granting Ticket）的服务器。

TGT（Ticket Granting Ticket）：用户向TGS（Ticket Granting Server）证明自己身份的Ticket。

TGS（Ticket Granting Server）：为用户分发到最终目的Ticket的服务器，用户使用这个Ticket向自己要求提供服务的服务器证明自己的身份。在实现上，AS和TGS实际上是由同一程序完成的，因为它们的实现机制并没有太大的差别，只是在加密所发出的Ticket时候所使用的密钥不同（AS使用用户的密钥，而TGS使用会话密钥）。

KDC（Key Distribution Center）：密钥发放中心，通常将AS和TGS统称为KDC，有时也把AS单独称为KDC。

（3）认证过程

1）Client→KDC：用户cnhawk向密钥分配中心（KDC）申请TGT。

2）KDC→Client：通过KDC的用户密码认证，cnhawk得到KDC发放的TGT。

3）Client→KDC：申请取得用户cnhawk所需要的host/s。

4）KDC→Client：KDC根据用户cnhawk提供的TGT，KDC向cnhawk发放host/s。

5）Client→Server：用户cnhawk向Server提供cnhawk、TGT和host/s；Server根据主机上保存的host/s和用户cnhawk的信息来验证cnhawk的登录申请。

6）Server→Client：Server确认，发送信息给Client允许cnhawk登录Server。