認證技術是信息安全中的一個重要內容，在“網絡與信息安全”課程中我們學習了兩種認證技術：消息認證與身份認證，消息認證用於保證信息的完整性與抗否認性，身份認證則用於鑑別用戶身份。在網上商務日益火爆的今天，從某種意義上說，認證技術可能比信息加密本身更加重要。因爲，很多情況下用戶並不要求購物信息保密，只要確認網上商店不是假冒的（這就需要身份認證），自己與網上商店交換的信息未被第三方修改或僞造，並且網上商家不能賴帳（這就需要消息認證）,商家也是如此。由於認證技術是一項包含很廣泛的技術，集中於某一方面可能更有針對性，所以，在這篇論文中我沒有涉及消息認證技術。運用課堂學到的理論、課後閱讀獲得的知識根據自己的分析，我對身份認證技術作了總結分類，並針對每一種認證技術分析了優點和漏洞，然後剖析了一些應用，最後提出了自己想到的一個簡單的利用數字簽名實現的身份認證方案。
一、 身份認證的方法及可能的漏洞
身份認證的本質是被認證方有一些信息（無論是一些祕密的信息還是一些個人持有的特殊硬件或個人特有的生物學信息），除被認證方自己外，任何第三方（在有些需要認證權威的方案中，認證權威除外）不能僞造，被認證方能夠使認證方相信他確實擁有那些祕密（無論是將那些信息出示給認證方或者採用零知識證明的方法），則他的身份就得到了認證。
根據被認證方賴以證明身份的祕密的不同，身份認證可以分爲兩大類：基於祕密信息的身份認證方法和基於物理安全性的身份認證方法。
1.基於祕密信息的身份認證方法
1.1口令覈對
鑑別用戶身份最常見也是最簡單的方法就是口令覈對法：系統爲每一個合法用戶建立一個用戶名/口令對，當用戶登錄系統或使用某項功能時，提示用戶輸入自己的用戶名和口令，系統通過覈對用戶輸入的用戶名、口令與系統內已有的合法用戶的用戶名/口令對（這些用戶名/口令對在系統內是加密存儲的）是否匹配，如與某一項用戶名/口令對匹配，則該用戶的身份得到了認證。
這種方法有如下缺點：其安全性僅僅基於用戶口令的保密性，而用戶口令一般較短且容易猜測，因此這種方案不能抵禦口令猜測攻擊[5]；另外，攻擊者可能竊聽通信信道或進行網絡窺探（sniffing），口令的明文傳輸使得攻擊者只要能在口令傳輸過程中獲得用戶口令，系統就會被攻破。
儘管有許多漏洞，這種方法在非網絡環境下還是經常被採用的，由於沒有了傳輸的過程，所以這時上面列舉的第二個缺陷不會被攻擊者利用。
在網絡環境下，明文傳輸的缺陷使得這種身份認證方案變得極不安全，一些網絡環境中的服務，如FTP，雖然仍然使用了明文傳輸的用戶名/口令身份認證方案，但多數時候這種服務已經退化爲無需口令（或口令公開）的匿名文件傳輸服務。
解決的辦法是將口令加密傳輸，這時可以在一定程度上彌補上面提到的第二個缺陷，但攻擊者仍可以採用離線方式對口令密文實施字典攻擊[5]。
加密傳輸口令的另一個困難是加密密鑰的交換，當採用對稱密鑰加密方式時，要求認證方和被認證方共享一個密鑰，但由於身份認證前雙方的身份還不明確，不可能預先共享一個密鑰，解決的辦法是求助於第三方——一個可信任的權威機構，這就是下面要分析的認證方案的思想。當採用非對稱密鑰加密方式時，口令可以用認證方的公鑰加密，由於公鑰可以通過公開的渠道獲得，這時不存在採用對稱密鑰加密時遇到的那種矛盾，當然，這也需要密鑰分發機制的配合。由此，我們也看到，身份認證與密鑰分發經常是聯繫在一起的，所以，下面提到的許多認證協議中也包含了密鑰分發的功能。
1.2單向認證
如果通信的雙方只需要一方被另一方鑑別身份，這樣的認證過程就是一種單向認證，前面提到的口令覈對法實際也可以算是一種單向認證，只是這種簡單的單向認證還沒有與密鑰分發相結合。
與密鑰分發相結合的單向認證主要有兩類方案：一類採用對稱密鑰加密體制，需要一個可信賴的第三方——通常稱爲KDC（密鑰分發中心）或AS（認證服務器），由這個第三方來實現通信雙方的身份認證和密鑰分發；另一類採用非對稱密鑰加密體制，無需第三方參與。
[1]需第三方參與的單向認證：
1、 A ® KDC ：IDA||IDB|| N1
2 、KDC ® A ：EKa[Ks || IDB || N1 || EKb [Ks || IDA]]
3 、A ® B ：EKb [Ks || IDA] || EKs[M]
[1]無需第三方參與的單向認證：
A ® B ：EKUb[Ks ]|| EKs[M]
[1]當信息不要求保密時，這種無需第三方的單向認證可簡化爲：
A ® B ：M || EKRa[H(M)]
（符號約定同課堂講義）
1.3雙向認證
在雙向認證過程中，通信雙方需要互相認證鑑別各自的身份，然後交換會話密鑰，雙向認證的典型方案是Needham/Schroeder協議。
[1]Needham/Schroeder Protocol [1978]
1、A ® KDC ：IDA||IDB||N1
2 、KDC ® A ：EKa[Ks||IDB||N1||EKb[Ks||IDA]]
3 、A ® B ： EKb[Ks||IDA]
4 、B ® A ： EKs[N2]
5 、A ® B ： EKs[f(N2)]
這種認證的漏洞和改進老師在課堂上已經講過，這裏就不重複了。
1.4身份的零知識證明
通常的身份認證都要求傳輸口令或身份信息（儘管是加密傳輸），如果不傳輸這些信息，身份也能得到證明就好了，這就需要身份的零知識證明技術。
零知識證明是這樣一種技術，被認證方P掌握某些祕密信息，P想設法讓認證方V相信他確實掌握那些信息，但又不想讓V也知道那些信息（如果連V都不知道那些祕密信息，第三者想盜取那些信息當然就更難了）。
被認證方P掌握的祕密信息可以是某些長期沒有解決的猜想問題的證明，如：費爾瑪最後定理，圖的三色問題，也可以是缺乏有效算法的難題解法，如：大數因式分解等，信息的本質是可以驗證的，即可通過具體的步驟來檢測它的正確性。
[2]下面是一個利用零知識證明技術認證身份的協議的例子：
設I(P)爲被認證方P的身份信息，要求P可以不透露I(P)的一個比特使認證方確信P確實掌握I(P)。協議假定存在一個可信賴的機構，它的職責在於公佈模數n，n等於兩個大素數p和g之積，p和q都是mod 4與3同餘。
I(P)必須包含P的許多信息。假定I(P)包含有P的祕密身份的k個數c[1],c[2],…,c[k]，1<=c[i]<p，i=1,2,…,k；還有他的公開身份PI(P)的另外k個數d[1],d[2], …,d[k]，1<=d[i]<p，i=1,2,…,k，而且滿足
d[j]*c[j] 2 ≡ ±1 mod n j = 1,2, …,k
認證方V知道n和PI(P)。P爲了使V相信他掌握I(P)，下面４個步驟算是一輪。通過輪數越多，P作假的概率越小。
S1．P選一隨機數r，計算 ± r2 mod n，P取其中一個告訴V，稱之爲x 。
S2．V從{1,2,…,k}中選一子集S告訴P。
S3．P告訴V
y = rTc mod n
其中 Tc = ∏ c[j] 對所有的 j ∈s
S4．V驗證
X = ± y 2 Td mod n ?
其中 Td = ∏ d[j] 對所有的 j ∈s
若等號成立，開始新的一輪驗證或停止，否則予以拒絕。
由於d[j]*c[j] 2 ≡ ±1 mod n，j = 1,2, …,k。
所以 y 2 Td ≡ r2 Tc2 Td = r2 ∏ c[j] 2 d[j] ≡ ± r2 ≡ ±x mod n
隨機數r是必要的，否則V選S = { j }，從而找到c[j]，對c[j]要求(c[j],n) = 1，j = 1,2, …,k，否則n可能被因數分解。
2．基於物理安全性的身份認證方法
儘管前面提到的身份認證方法在原理上有很多不同，但他們有一個共同的特點，就是隻依賴於用戶知道的某個祕密的信息。與此對照，另一類身份認證方案是依賴於用戶特有的某些生物學信息或用戶持有的硬件。
基於生物學信息的方案包括基於指紋識別的身份認證、基於聲音識別的身份認證以及近來流行的基於虹膜識別的身份認證等。
基於智能卡的身份認證機制在認證時認證方要求一個硬件——智能卡（智能卡中存有祕密信息，通常是一個隨機數），只有持卡人才能被認證。這樣可以有效的防止口令猜測，但又引入了一個嚴重的缺陷：系統只認卡不認人，而智能卡可能丟失，拾到或竊得智能卡的人將很容易假冒原持卡人的身份。
爲解決丟卡的問題，可以綜合前面提到的兩類方法，即認證方即要求用戶輸入一個口令，又要求智能卡。這樣，既不擔心卡的丟失（只要口令沒有泄漏），又不擔心口令的泄漏（只要卡沒有丟）。
文獻[4]提供了一個使用智能卡的單向認證協議的具體的例子，這裏就不詳述了。
三、身份認證的應用
1.Kerberos認證服務[7]
Kerberos認證服務老師在課堂上講過，在課後我又讀了介紹Kerberos認證服務的文獻[7]，在這裏根據自己的理解簡述一下。
Kerberos是一種受託的第三方認證服務(trusted third-party authentication service)，它是建立在前面提到的Needham和Schroeder[1978]提出的模型基礎上的，Kerberos要求信任第三方——即Kerberos認證服務器。Kerberos把網絡劃分成安全域，稱爲區域(realms)，每個區域有自己的認證服務器並實現自己的安全策略。在每個區域內的認證過程是這樣的：
Kerberos爲客戶和服務提供證明自己身份的票(ticket)以及雙方安全通信的會話密鑰(session key)。除客戶第一次獲得的初始票(initial ticket)是由Kerberos認證服務器(Kerberos authentication server,記作AS)簽發外，其他票是由發票服務器(ticket-granting server,記作TGS)簽發的，一個票可以使用多次直至過期。票的內容爲：
{s,c,addr,timestamp,life,Ks,c} Ks 記作Tc,s
其中，s爲服務名，c爲客戶名，addr爲客戶地址，timestamp爲時間戳，life爲生存週期，Ks,c爲服務s與客戶c之間的會話密鑰，全部信息用服務s的密鑰Ks加密。
客戶方請求服務方提供一個服務時，不僅要向服務方發送從發票服務器領來的票，同時還要自己生成一個證(authenticator)一同發送。證是一次性的，內容如下：
{c,addr,timestamp} Ks,c 記作A c
其中，c爲客戶名，addr爲客戶所在工作站的地址，timestamp爲工作站當前時間，全部信息用客戶c與所要請求的服務s之間的會話密鑰Ks,c加密。
具體過程分以下三步：
一、取得初始票
二、取得某項服務的票
三、請求該項服務
其中，timestamp是上一步中客戶c發給服務s的證Ac中的timestamp，這樣做的目的是使客戶c確信與它會話的確實是服務s。（只有s才知道Kc,s，故只有s才能發回這個信息。）
另外，文獻[7]中具體介紹了一個在SUN NFS中加入Kerberos身份認證功能的例子。
2.HTTP中的身份認證[6]
HTTP協議目前已經有了三個版本HTTP 0.9、HTTP 1.0和HTTP 1.1，HTTP 0.9只定義了最基本的簡單請求和簡單回答；HTTP 1.0較完善，也是目前用得最廣泛的一個版本，HTTP 1.1新增加了大量的報頭域。
HTTP 1.0中提供了一個基於口令的基本認證方法，目前，所有的Web服務器都可以通過“基本身份認證”支持訪問控制。當用戶請求某個頁面或運行某個CGI程序時，被訪問對象所在目錄下有訪問控制文件（如NCSA用.haaccess文件）規定那些用戶可以訪問該目錄， Web服務器讀取該訪問控制文件，從中獲得訪問控制信息並要求客戶方提交用戶名/口令組合，瀏覽器將用戶輸入的用戶名和口令對經過一定的編碼（一般是Base64方式），傳給服務方，在檢驗了用戶身份和口令後，服務方纔發送回所請求的頁面或執行CGI程序。可見，HTTP1.0採用的是前面講述過的明文傳輸的口令覈對方式（傳輸過程中儘管進行了編碼，但並沒有加密），這當然是很不安全的。
爲增加安全性，用戶可以選擇使用SSL建立加密信道後再採用基本身份認證方式進行身份認證，當然，SSL中也有自己的更完善的身份認證機制，關於SSL老師在課堂上講過。
HTTP 1.1在身份認證上，針對基本認證方式以明文傳輸口令這一最大弱點，補充了摘要認證方法，不再傳遞口令的明文，而是將口令經過散列函數變換以後傳輸它的摘要。使用摘要認證攻擊者再也不能截獲口令，他最多隻能進行重放攻擊，而且被限定在很短時間內，並只能用於同樣的訪問請求。儘管如此，摘要認證仍然不夠安全，與基本認證一樣，容易受到中間者攻擊，如一個惡意的或被破壞的代理可能將服務方的摘要認證回答換成基本認證回答，從而竊得口令。
爲HTTP提供更安全的認證方式需要與Kerberos服務相結合，如：CMU的Minotaur方案是結合特別的MIME類型和Plugin程序實現的。
3.IP中的身份認證
IP協議由於在網絡層，無法理解更高層的信息，所以IP協議中的身份認證實際不可能是基於用戶的身份認證，而是基於IP地址的身份認證。老師在講IPSec時提到過其中的認證技術，這裏就不講了。
四、身份認證技術討論
前面對身份認證技術的理論與應用進行了總結和分析，下面將結合自己的理解，進一步討論一下身份認證的其他實現途徑。
由於數字簽名有一項功能是保證信息發出者的身份真實性，即信息確實是所聲稱的簽名人簽名的，別人不能僞造，這和身份認證的情形有些相似：身份認證的核心是要確認某人確實是他所聲稱的身份。那麼，我想應該能借用數字簽名機制實現身份認證，但這可能有一個困難，如果不預先進行密鑰分發（即使是公鑰，也要有一個機制將真實的公鑰信息傳遞給每一個用戶），可能數字簽名也無從實現。（這可能就是前面總結的身份認證方法多與密鑰分發結合進行的原因，可見，身份認證是衆多安全要求中首先要解決的。）
但我們假設數字簽名的公鑰可從一個公認的權威處取得。
方案很簡單：
1．雙方首次與聯繫時，認證方先給被認證方發一條隨機的信息，且對其進行簽名。
2．被認證方檢驗認證方發來的信息的完整性，如完整，則去掉原簽名，用自己的密鑰重新進行簽名，併發給認證方；如不完整，則要求重發（重發式認證方不能再用原來的信息，要換一條隨機信息）。
3．認證方檢驗信息中被認證方的簽名，如通過，則被認證，否則被拒絕。
這個方案可能不夠完善，比如：由於都是明文傳輸，雖然信息都是一次性的，不怕暴露，但一旦信息的完整性遭破壞，認證就須重新進行；但，這個方案還是有一些優越性，如：祕密的信息不需在網絡中傳輸、協議簡單且可利用現成的數字簽名機制等。
本篇文章來源於【能人網】www.nengr.com 原文鏈接地址：http://www.nengr.com/article/7158.html