本文在研究一次性口令認證機制的基礎上,將一次性口令認證應用到 Kerberos協議的初始認證階段,在沒有增加 Kerberos認證會話次數的前提下,有效解決了Kerberos協議存在的易于遭受口令猜測攻擊和重放攻擊的問題。實驗結果顯示,該方案不僅增強了Kerberos的安全性,而且效率相比PKINIT有了較大的提升,初始認證服務交互時間減少了32.3%。
S/Key一次性口令認證方案是由Bellcore基于單向散列函數MD4和MD5實現的。該方案基于挑戰-應答機制,可以有效抵抗口令猜測攻擊和重放攻擊,并且簡單、易于實施。但是,它不能實現雙向認證,存在服務器冒充攻擊和小數攻擊的缺陷。通過監聽網絡通信,截獲用戶的ID和Password來冒充合法用戶是一種常見的網絡攻擊。一次性口令機制的設計目的就是用戶在每次登錄過程中,使用不同的Password,使得黑客即使截獲,也無法應用到下次認證過程中。
一次性口令實現的主要機制有兩種:
(1)挑戰-應答機制:用戶登錄時,認證服務器產生一條挑戰信息,發給用戶,用戶根據挑戰信息和自身的通行密語產生一次性口令,返回給認證服務器,完成認證過程。
(2)時間同步機制:用戶將登錄時間作為不確定因素,連同自己的通行密語一起產生一次性口令。
目前使用最多的就是基于挑戰應答機制的一次性口令機制,S/KEY一次性口令認證系統就是其中的典型代表。然而S/Key系統不能抵抗小數攻擊和冒充攻擊。為了改進它的缺陷,提出使用基于公鑰加密的數字簽名鏈(Signature Chain)的方法來代替S/Key系統的hash函數鏈,實現一次性口令機制。
所謂數字簽名鏈就是對一條初始消息進行重復簽名,其過程類似于S/Key系統的hash函數鏈。但是,數字簽名鏈的長度可以無限擴展,而且即使認證服務器重啟后,也不需要重新設置。其具體定義如下:S是一種公鑰簽名算法(例如,RSA,ECDSA等),PRC是用戶C的私鑰,V是S對應的公鑰簽名驗證算法PUC是用戶C的公鑰。那么,可以構造一對簽名和驗證函數:

Kerberos協議是基于可信第三方的身份認證協議,用于實現用戶(Client)和應用程序服務器(Application Server)之間的相互認證。Kerberos密鑰分配中心(Key Distribute Center,KDC)由認證服務器(Authentication Server,AS)和票據授權服務器(Ticket Granting Server,TGS)組成。Kerberos協議的認證過程中,最為重要的就是第一步:認證服務交互,只有在驗證了用戶的合法身份以后,對其頒發票據授權票據(Tickettgs)和服務授權票據(Ticketv)才有意義。
為了抵抗口令猜測攻擊,Kerberos協議在V5版本中引入預認證機制,在KRB_AS_REQ消息中增加預認證塊Pre-authentica tor。改進后的Kerberos V5認證服務交換如下:KRB_AS_REQ:

我們分兩個階段來解釋OTP-Kerberos方案:注冊階段和認證階段。
認證開始前,我們選取橢圓曲線,產生一對公私鑰,將用戶的公鑰注冊到Kerberos認證服務器,此處,我們采取ECC數字簽名算法,因此公鑰長度可選取160bits。同時,用戶注冊自己ID和Password到認證服務器。用戶本身并不需要記住自己的password,只需要保存好自己的私鑰 PRC就可以了,同時,用戶端需要保存KDC的公鑰PUc。認證服務器上保存一張表,用以記錄用戶ID,公鑰,本次驗證使用的一次性口令以及一次性口令的序號。
認證服務器收到請求后,首先使用自己的私鑰PRas對加密的一次性口令進行解密,獲得P1,然后根據用戶ID,查找用戶公鑰PUc,使用PUc對P1做驗證。如果H(P0,P1)=1,那么,該用戶是合法用戶,一次性口令序號加1,保存P1作為新的一次性口令并使用P1作為密鑰,加密Kc,tgs和時間戳隨機數等加密后,形成KRB_AS_REP消息,返回給用戶。否則,拒絕該用戶,返回KRB_ERROR消息。第i次登錄過程與第一次登錄處理過程類似。證明過程如下:因為,所以只有產生正確的一次性口令Pi,才能使得公式(2)H(Pi-1,Pi)=1。OTP-Kerberos方案在保持 Kerberos協議會話次數不增加的基礎上,對初始認證服務進行改進,解決Kerberos協議原有的易于遭受口令猜測攻擊和重放攻擊的缺陷,剩余的Kerberos服務交互會話與原版本一致。
本文提出一種基于一次性口令增強 Kerberos的方案OTP-Kerberos,將基于 ECC數字簽名鏈的一次性口令機制應用于 Kerberos協議的初始認證服務交互。經過安全性分析,OTP-Kerberos協議可以有效抵抗口令猜測攻擊、重放攻擊等原Kerberos協議的缺陷。實驗結果顯示,我們提出的OTP-Kerberos協議完成認證交互服務的時間相比PKINIT減少32.3%。