基于標識的動態口令系統

劉瑩+龍毅宏

摘要：作為用戶身份驗證技術，動態口令技術比傳統的靜態口令技術具有更高的安全性。針對目前動態口令系統存在的用戶令牌種子密鑰管理麻煩、種子密鑰數據庫安全要求高，與應用系統集成存在帳戶方面的限制，缺少用戶種子密鑰自動更新的功能等問題，提出了一種基于標識的動態口令系統方案，并從基于時間與基于挑戰/響應兩種方式進行實現。該系統具有用戶種子密鑰自動更新的功能，并且具有易于密鑰管理、易于與應用系統集成等特點。

關鍵詞：身份認證；動態口令；身份標識。

引言

口令是目前用的最廣泛的身份認證技術。口令分為靜態與動態兩種，傳統的靜態口令身份認證技術采用簡單的用戶名和固定不變的口令進行登錄驗證，存在易于被網絡竊聽、易受字典攻擊等問題。1981年，Lamport提出了一次性口令的概念，引入了不確定因素，保證用戶每次使用不同的口令進行登錄，因此具有更高的安全性。Haller在Lamport基礎上提出S/KEY方案，該方案基于MD4和MD5算法，采用c/s模式的操作，能夠對用戶與服務器進行綜合驗證。但是該方案生成的動態口令有限，用完之后得重新注冊才能使用。

常用的動態口令的實現方式有基于時間的動態口令生成方式和基于挑戰/響應的動態口令生成方式。其中基于時間的動態口令生成方式屬于同步認證技術，引人時間作為不確定因素參與動態口令的生成，基于挑戰/響應的動態口令生成方式屬于非同步認證技術，引人一個隨機產生的挑戰數作為不確定因素參與動態口令的生成。這兩種動態口令生成方式都采用單向散列函數生成口令，它們的安全性由單向散列函數的不可逆性保證，常用的單向散列函數包括：SHA-1、SHA-2（SHA-224、SHA-256、SHA-384、SHA-512）、MD5等。

目前的動態口令系統存在以下幾個方面的問題：

1）用戶動態口令種子密鑰管理麻煩、密鑰集中存儲安全要求高。

動態口令系統服務端需要分別為每位用戶創建一個賬戶以維護和管理種子密鑰，種子密鑰集中存儲需要極高的安全性。

2）與應用系統集成存在帳戶方面限制。

當采用動態口令系統的應用系統對用戶提交的動態口令進驗證時，應用系統需要知道用戶在動態口令系統的帳戶名，一般采取讓用戶在應用系統與動態口令系統中使用相同的帳戶名，或是將用戶在應用系統中的帳戶同用戶在動態口令系統中的帳戶綁定的方法，但前者對應用系統造成限制，不適用于已存在的應用系統，后者實現賬戶綁定比較麻煩。

3）缺少用戶種子密鑰自動更新的功能。

1基于標識的動態口令系統整體設計

本文中使用到的符號及含義如表1所示：

1.1系統結構

基于標識的動態口令系統結構如圖1所示，主要包括：

1）Cotv：安裝在用戶手機端或是用戶主機中的一個獨立程序，維護一個本地存儲的終端種子密鑰keye，由用戶控制完成由不確定因素（時間或挑戰數）計算動態口令的過程，自主定時與Soto通信，更新keyc。

2）Sotp：維護有一張保存UID、serial以及key。的標識信息表。Soto主要完成對otp的驗證及響應Coto更新key。的請求的功能。

3）web頁面：完成用戶與Sweb之間交互。接收用戶輸入信息，反饋提示信息。

4）Sweb：維護有一個保存username和對應用戶UID的數據表。主要完成用戶web界面的通訊、用戶存在性驗證（對于挑戰數生成動態口令的方案而言還包括產生隨機碼功能模塊）以及傳遞待驗證動態口令信息等工作。

1.2驗證過程

整個用戶身份驗證基本過程如下：

1）用戶將username通過web頁面傳送給Sweb。

2）sweh驗證username存在性，若存在則提示用戶輸入otp，對于基于挑戰/響應方案，Sweb同時返回一串隨機數。

3）對于基于挑戰/響應的方案，用戶通過操作Coto，利用返回的隨機數生成該用戶當前的otp；對于基于時間的方案，Coto利用當前時間生成用戶當前的otp。

4）用戶將otp輸入web頁面后，Sweb根據username查詢對應的用戶UID并打包相關數據打包發送給Soto。對于基于時間的方案，打包數據包括UID和待驗證otp；對于基于挑戰/響應的方案，打包數據包括UID、待驗證otp以及參與計算的隨機數。

5）Sotp通過計算，驗證接收到otp的正確性，并經由sweb曲向用戶返回驗證結果。

6）Coto每隔一段時間（如14天）自發地與Sotp進行通信，更新用戶的keyc。

2系統主要功能的實施

2.1基于標識的動態口令的生成

Sotp為每一位用戶保存一個初始值為0的serial。記此處符號“+”表示字符串連接，Hk（）表示KeyedHash計算。

UID+serial UIDEX

（1）

Hk（UIDEX，keys）=key。

（2）

Hk（不確定因子，keyc）=otp

（3）

如式（1）所示，將某一用戶UID和其對應的serial值進行字符串連接即產生該用戶的UIDEX。Sow利用用戶UIDEX和key通過如（2）式KeyedHash運算得出該用戶的keye key。由各用戶的Cow保存管理。keyc和不確定因素（時間/挑戰數）通過（3）式獲得該用戶當前狀態下的otp。

2.2動態口令驗證過程

Sow接收到動態口令驗證請求后，遵循如圖2所示過程進行驗證：

1）利用傳入的數據，查詢標識信息表以確認對應UID存在性，若存在則繼續后續操作，否則驗證未通過。

2）由用戶UID查詢標識信息表以獲取對應的serial值，并利用keys，根據（1）（2）式生成該用戶的key。

3）對于基于挑戰/響應的方案，Sow利用驗證請求數據中的隨機數和上一步獲取的keyc根據（3）式得到動態口令標準值otpl；對于基于時間的方案，Sow獲取精確到秒的本地時間T，由T截取到分鐘后的數據t與keyc根據（3）式得到動態口令標準值otp]。

4）比較otpl和待驗證otp，若相同則驗證通過，若不同，對于基于挑戰/響應的方案而言則驗證未通過；對于基于時間的方案，還需進行后續調整操作。

5）對于基于時間的方案，考慮可能存在的時間不同步問題，以一分鐘作為一個動態口令生成與驗證時間段，Sotp計算T。距離該時刻所在的動態口令生成與驗證時間段的起始與結束兩個時間點的時間長度，判斷最小的時間長度是否在臨界偏差范圍（如1s）內。若在，則以距離更近的相鄰的生成與驗證時間段截取到分鐘后的時間數據作為備選時間數據ts計算動態口令備選標準值otp2，若超出臨界偏差范圍則驗證未通過。

6）比較otp2和otp，若相同則驗證通過，若不同則驗證未通過。

2.3定時更新

Cotp內設置定時器，設定每隔一段時間（如14天）觸發一次的更新。

Cotp通過動態口令向Soto證明當前擁有有效的key～。Sow驗證、確認有效后，Sow對用戶serial值進行加1操作，并用更新后的serial值生成新的終端種子密鑰。

若keyc自動更新失敗，用戶可通過手工方式更新。

2.4時間同步

對于基于時間的方案，可使用NTP協議實現Cow與Sow的時鐘同步，基本過程如下：

Cotp獲取本地時間t1后向Sotp發送一條時間調整命令，Sow接收后獲取本地時間t2。

2）Sow獲取本地時間t3后向Cow返回一條時間調整響應，Cow接收后獲取本地時間t4。

3）Coto根據（4）（5）式分別計算單程網絡延遲6和時間偏差d：

6=（（t4-t1）-（t3-t2））/2

（4）

d=（（t2-t1）+（13-t4））/2

（5）

Coro獲取本地時間t，由（6）式計算調整后的時間T：

T-t+d+6

（6）

Cotp首次安裝時進行時間同步，此后若出現時間同步異常，用戶可通過手工方式同步。

2結束語

本文針對當前動態口令技術存在的問題，提出了一種基于標識的動態口令系統方案，并從基于時間與基于挑戰/響應兩種方式對該方案進行了描述。提出的方案具有以下優勢：

1）無對集中保存的用戶種子密鑰進行安全保護的要求。

動態口令系統服務端不需要單獨為每一個用戶保存、維護終端種子密鑰，而是在需要終端種子密鑰的時候利用用戶身份標識和系統種子密鑰通過散列計算得到，從而省去了集中保存和管理用戶終端種子密鑰的需要和安全保護要求。

2）易于與應用系統集成

在與應用系統集成時，將應用系統原有的帳戶口令改為存放用戶的身份標識即可，應用系統既可以使用原有的帳戶管理系統，也可使用統一的帳戶管理系統，沒有特別的要求限制。

3）具有自動更新用戶種子密鑰的功能

本方案中動態口令生成器定時觸發終端種子密鑰更新，主動與動態口令服務器進行通信，實現用戶種子密鑰的自動更新。