◆孫 永

（中國(guó)銀行軟件中心 北京 100094）

基于口令的強(qiáng)身份鑒別協(xié)議

◆孫 永

（中國(guó)銀行軟件中心 北京 100094）

本文圍繞身份鑒別分析了Web應(yīng)用安全現(xiàn)狀、存在的問(wèn)題，介紹了基于口令鑒別協(xié)議的發(fā)展，提出SRP協(xié)議改進(jìn)方案，實(shí)現(xiàn)身份雙向鑒別、解決中間人攻擊、會(huì)話(huà)假冒、通信數(shù)據(jù)保密性、完整性等問(wèn)題。最后對(duì)不依賴(lài)PKI和數(shù)字證書(shū)體系解決交易數(shù)據(jù)簽名和防抵賴(lài)進(jìn)行了初步探討。

基于口令身份鑒別；SRP協(xié)議；雙向鑒別；會(huì)話(huà)假冒；中間人攻擊

0 前言

本文討論的用戶(hù)只限于桌面瀏覽器互聯(lián)網(wǎng)客戶(hù)端應(yīng)用的用戶(hù)，不包括移動(dòng)應(yīng)用和內(nèi)網(wǎng)應(yīng)用的用戶(hù)；討論的焦點(diǎn)是身份鑒別，不關(guān)注權(quán)限、可用性等其它安全問(wèn)題。安全控件、動(dòng)態(tài)口令、PKI系統(tǒng)以及內(nèi)部網(wǎng)絡(luò)層、系統(tǒng)層等基礎(chǔ)設(shè)施本身的安全也不在本文討論范圍內(nèi)。

對(duì)互聯(lián)網(wǎng)應(yīng)用熟悉的讀者可以跳過(guò)第二節(jié)；對(duì)信息安全技術(shù)熟悉的讀者可以直接跳到第五節(jié)開(kāi)始閱讀。

1 銀行互聯(lián)網(wǎng)應(yīng)用現(xiàn)狀

1.1 注冊(cè)

常見(jiàn)用戶(hù)注冊(cè)方式有類(lèi)，一類(lèi)是用戶(hù)自己通過(guò)互聯(lián)網(wǎng)或代理機(jī)構(gòu)注冊(cè)，設(shè)置身份識(shí)別和鑒別標(biāo)識(shí)；另一類(lèi)是其他人代理用戶(hù)通過(guò)聯(lián)機(jī)或批量的方式注冊(cè)。后者容易出現(xiàn)身份標(biāo)識(shí)和密碼泄露、弱密碼、用戶(hù)不知情等風(fēng)險(xiǎn)。

1.2 用戶(hù)身份鑒別

登錄身份鑒別：通過(guò)用戶(hù)登錄名、手機(jī)號(hào)等提供唯一身份標(biāo)識(shí)，通過(guò)靜態(tài)口令、短信、動(dòng)態(tài)口令、數(shù)字證書(shū)等方式進(jìn)行身份鑒別，通過(guò)限制錯(cuò)誤次數(shù)、圖片驗(yàn)證碼等機(jī)制防范自動(dòng)登錄攻擊。身份鑒別可以由本系統(tǒng)完成，也可以由受信任的第三方系統(tǒng)完成。登錄后用隨機(jī)但固定的會(huì)話(huà)id作為每次請(qǐng)求的身份鑒別標(biāo)識(shí)。生物識(shí)別方式由于設(shè)備限制還未大量采用。

加強(qiáng)身份鑒別：對(duì)高風(fēng)險(xiǎn)交易，除要求已經(jīng)登錄外還需要提供短信、動(dòng)態(tài)口令、數(shù)字證書(shū)、其它口令等方式進(jìn)行加強(qiáng)身份鑒別，一般要求采用與登錄不同的雙因子鑒別手段。

身份鑒別次數(shù)限制：為了防止攻擊者通過(guò)猜測(cè)或字典方式進(jìn)行暴力攻擊，對(duì)身份鑒別失敗設(shè)置次數(shù)限制。當(dāng)連續(xù)鑒別失敗次數(shù)達(dá)到設(shè)定次數(shù)后需要暫時(shí)或永久鎖死，需等待一定時(shí)間或通過(guò)其它途徑解鎖后才能再次身份鑒別。

靜態(tài)口令策略：為了降低靜態(tài)口令猜測(cè)和泄露風(fēng)險(xiǎn)，對(duì)靜態(tài)口令的長(zhǎng)度、復(fù)雜性、最長(zhǎng)最短有效期、循環(huán)歷史進(jìn)行一定的限制。對(duì)于柜臺(tái)設(shè)置的弱口令、非本人設(shè)置的口令要求首次登錄后強(qiáng)制修改。

1.3 服務(wù)器身份鑒別

服務(wù)器證書(shū)識(shí)別：通過(guò)客戶(hù)端瀏覽器與服務(wù)器建立SSL/TLS連接，客戶(hù)端驗(yàn)證由信任的證書(shū)頒發(fā)機(jī)構(gòu)頒發(fā)的服務(wù)器證書(shū)實(shí)現(xiàn)。

用戶(hù)提示信息：用戶(hù)登錄后顯示其昵稱(chēng)、預(yù)留歡迎信息、最近登錄成功和失敗時(shí)間等內(nèi)容，輔助識(shí)別釣魚(yú)網(wǎng)站，預(yù)防進(jìn)一步的損失。

1.4 會(huì)話(huà)管理

會(huì)話(huà)與用戶(hù)關(guān)系：除了會(huì)話(huà)ID唯一、不可預(yù)測(cè)的要求外，還要求登錄或退出后更換會(huì)話(huà)，并且同一用戶(hù)不能同時(shí)維持多個(gè)有效會(huì)話(huà)。

會(huì)話(huà)失效時(shí)間：如果用戶(hù)長(zhǎng)時(shí)間沒(méi)有操作，服務(wù)器會(huì)使會(huì)話(huà)失效。有時(shí)會(huì)增加強(qiáng)制會(huì)話(huà)失效機(jī)制，在用戶(hù)登錄后連續(xù)操作的情況下，在一個(gè)比較長(zhǎng)的固定時(shí)間后強(qiáng)制會(huì)話(huà)失效。

1.5 交易數(shù)據(jù)安全

數(shù)據(jù)保密性：客戶(hù)端在通訊層通過(guò)SSL/TLS用128位以上對(duì)稱(chēng)算法對(duì)數(shù)據(jù)加密，在DMZ區(qū)SSL加速器上解密?？诹畹汝P(guān)鍵敏感信息在應(yīng)用層進(jìn)行端到端加密傳輸，加密存儲(chǔ)。

數(shù)據(jù)完整性：一般依賴(lài)于SSL/TLS協(xié)議本身保護(hù)數(shù)據(jù)完整性。有時(shí)采用基于對(duì)稱(chēng)加密或散列的完整性保護(hù)機(jī)制。

2 潛在的問(wèn)題

服務(wù)器假冒：應(yīng)用層與網(wǎng)絡(luò)傳輸層在安全上是分離的，沒(méi)有有機(jī)地結(jié)合在一起。一般網(wǎng)絡(luò)傳輸層SSL/TLS采用單向認(rèn)證方式，瀏覽器只對(duì)網(wǎng)站服務(wù)器做數(shù)字證書(shū)認(rèn)證，網(wǎng)站服務(wù)器不驗(yàn)證瀏覽器端的數(shù)字證書(shū)。采用雙向認(rèn)證采用硬件載體證書(shū)（USBKey）對(duì)用戶(hù)來(lái)說(shuō)操作繁瑣，采用文件證書(shū)又不夠安全。

用戶(hù)識(shí)別假冒網(wǎng)站主要靠：（1）識(shí)別URL地址和HTTPS協(xié)議，但這一點(diǎn)很容易被用戶(hù)忽視，通過(guò)域名仿冒、DNS劫持、SSL中間人等手段也很容易欺騙用戶(hù)；（2）登錄后檢查預(yù)留信息等標(biāo)識(shí)，但這時(shí)候重要認(rèn)證信息已經(jīng)被攻擊者獲取。

會(huì)話(huà)假冒：會(huì)話(huà)層采用簡(jiǎn)單的會(huì)話(huà)ID識(shí)別會(huì)話(huà)，與應(yīng)用層用戶(hù)身份關(guān)聯(lián)，但與SSL/TLS會(huì)話(huà)及密鑰毫無(wú)關(guān)聯(lián)。攻擊者可以劫持用戶(hù)會(huì)話(huà)，隨后可以任意操作交易。原用戶(hù)無(wú)法察覺(jué)此問(wèn)題，兩個(gè)人可以并行操作，直到一方點(diǎn)擊退出按鈕。由于SSL/TLS連接與會(huì)話(huà)建立是分離的，所以此攻擊可以實(shí)施。

控件問(wèn)題：銀行系統(tǒng)普遍采用SSL加速器在DMZ區(qū)做SSL/TLS解密，關(guān)鍵敏感信息僅采用HTTPS不符合端到端加密的安全要求，因此登錄口令等信息的輸入普遍采用安全控件。安全控件目前還面臨瀏覽器間不兼容、高版本瀏覽器逐漸禁止使用的困難。對(duì)于海外市場(chǎng)，很多國(guó)家也禁止安裝安全控件。

3 安全期望

3.1 身份識(shí)別

因?yàn)橛脩?hù)標(biāo)識(shí)的唯一性和注冊(cè)交易必須提示用戶(hù)用戶(hù)名是否已經(jīng)存在，所以無(wú)法完全避免用戶(hù)名猜測(cè)，通過(guò)圖片驗(yàn)證碼僅僅可以減輕程序自動(dòng)猜測(cè)。除非使用USBKEY等隨身設(shè)備，桌面設(shè)備很少采用計(jì)算機(jī)硬件作為身份標(biāo)識(shí)。

3.2 身份鑒別

身份鑒別方式分為以下三類(lèi)：

（1）用戶(hù)是什么（聲音識(shí)別，視網(wǎng)膜掃描）；

（2）用戶(hù)有什么（ID卡，動(dòng)態(tài)口令牌）；

（3）用戶(hù)知道什么（口令，PIN碼）。

身份鑒別是應(yīng)用安全的第一道關(guān)，是諸如訪(fǎng)問(wèn)控制、數(shù)據(jù)保密、抗抵賴(lài)、資源控制、安全審計(jì)等其它安全防范的前提。但絕大部分的應(yīng)用都使用了靜態(tài)口令身份鑒別方法。

動(dòng)態(tài)口令牌是“用戶(hù)有什么”（令牌）和“用戶(hù)知道什么”（一次性口令）的結(jié)合，一次性口令鑒別的過(guò)程與靜態(tài)口令類(lèi)似，下面對(duì)于口令鑒別的討論大部分情況下也適用于一次性口令。從密碼學(xué)的角度看存在相當(dāng)多的身份鑒別協(xié)議，很多理論上的身份認(rèn)證協(xié)議需要一個(gè)可信的第三方或一個(gè)數(shù)字證書(shū)體系，這在實(shí)際應(yīng)用中過(guò)于復(fù)雜，成本很高，不能作為最基本的通用身份認(rèn)證方案。我們期望最基本的身份鑒別協(xié)議要滿(mǎn)足以下要求：

（1）不需要依賴(lài)于第三方、公鑰基礎(chǔ)體系、永久存儲(chǔ)口令的文件或工具，只需要身份識(shí)別符和人類(lèi)可以記憶的口令即可完成身份鑒別過(guò)程。

（2）身份鑒別過(guò)程的安全和可靠不依賴(lài)于其它層面的安全，只依賴(lài)于協(xié)議本身。

（3）身份鑒別過(guò)程在客戶(hù)端、服務(wù)器雙方進(jìn)行，要達(dá)到雙方互相鑒別的目的。對(duì)服務(wù)器的鑒別不能只依賴(lài)于用戶(hù)主動(dòng)識(shí)別服務(wù)器證書(shū)或預(yù)留信息。

（4）身份鑒別過(guò)程可以防止竊聽(tīng)、重放攻擊，通訊中不暴露口令或其等價(jià)物，每次身份鑒別過(guò)程通訊內(nèi)容不一致。

（5）身份鑒別過(guò)程可以防止離線(xiàn)字典攻擊，攻擊者不能利用通訊中傳輸?shù)膬?nèi)容暴力破解口令。

（6）身份鑒別過(guò)程可以防止中間人攻擊，攻擊者不能成功假冒通訊雙方或獲取重要信息。

（7）如果攻擊者獲得服務(wù)器端存儲(chǔ)的口令驗(yàn)證表，他仍然不能直接獲得口令，也不能假冒用戶(hù)。對(duì)于口令驗(yàn)證表的字典攻擊只能同時(shí)針對(duì)一個(gè)用戶(hù)。

（8）身份鑒別過(guò)程產(chǎn)生一個(gè)會(huì)話(huà)密鑰，用于關(guān)鍵交易數(shù)據(jù)的加密、解密。

目前常規(guī)的靜態(tài)口令鑒別不能滿(mǎn)足上述3、4、5、6、8條，動(dòng)態(tài)口令鑒別不能滿(mǎn)足第1、3、4、6、8條。

3.3 數(shù)據(jù)完整

在交易過(guò)程中需要滿(mǎn)足以下要求：

（1）客戶(hù)端提交的數(shù)據(jù)在傳輸過(guò)程中需要保證數(shù)據(jù)的完整，被攻擊者以偽造、增加、刪除、修改方式篡改后能夠被服務(wù)器發(fā)覺(jué)。

（2）在服務(wù)器端向客戶(hù)端發(fā)送數(shù)據(jù)過(guò)程中需要保證數(shù)據(jù)的完整，被攻擊者以偽造、增加、刪除、修改方式篡改后能夠被客戶(hù)端發(fā)覺(jué)。

如果滿(mǎn)足上述要求，必須在客戶(hù)端和服務(wù)器端對(duì)交易數(shù)據(jù)進(jìn)行計(jì)算產(chǎn)生一個(gè)指紋，數(shù)據(jù)被篡改后通過(guò)指紋驗(yàn)證能夠被發(fā)現(xiàn)。攻擊者無(wú)法偽造指紋，但是攻擊者截?cái)嗤ㄓ崟r(shí)服務(wù)器無(wú)法得知數(shù)據(jù)丟失。因?yàn)榛ヂ?lián)網(wǎng)和HTTP協(xié)議本身不可靠，發(fā)現(xiàn)數(shù)據(jù)被篡改時(shí)不需要自動(dòng)恢復(fù)數(shù)據(jù)，只需要廢棄數(shù)據(jù)，通訊被截?cái)鄷r(shí)也不需要終止會(huì)話(huà)。

3.4 數(shù)據(jù)保密

在交易過(guò)程中需要滿(mǎn)足以下要求：

（1）客戶(hù)端提交的敏感數(shù)據(jù)在傳輸過(guò)程中需要加密傳輸，竊聽(tīng)的攻擊者無(wú)法解密數(shù)據(jù)。

（2）在服務(wù)器端向客戶(hù)端發(fā)送的敏感數(shù)據(jù)需要加密傳輸，竊聽(tīng)的攻擊者無(wú)法解密數(shù)據(jù)。

如果嚴(yán)格按照端到端的方式滿(mǎn)足上述要求，必須在客戶(hù)端和服務(wù)器端對(duì)敏感數(shù)據(jù)加密。出于性能的考慮，選用對(duì)稱(chēng)算法，用身份鑒別過(guò)程中產(chǎn)生的會(huì)話(huà)密鑰進(jìn)行數(shù)據(jù)加解密。

3.5 抗抵賴(lài)

在交易過(guò)程中需要滿(mǎn)足以下要求：

客戶(hù)端提交的重要交易數(shù)據(jù)在傳輸前在客戶(hù)端以某種形式簽名，除知道口令的客戶(hù)端外，攻擊者和服務(wù)器無(wú)法仿造此簽名。通過(guò)此簽名和當(dāng)時(shí)的口令可以證明客戶(hù)端確實(shí)發(fā)出過(guò)交易數(shù)據(jù)。因?yàn)闆](méi)有第三方可信時(shí)間服務(wù)器，以服務(wù)器時(shí)間為準(zhǔn)。

因?yàn)榫W(wǎng)絡(luò)金融應(yīng)用中客戶(hù)端不宜記錄交易數(shù)據(jù)，所以基本沒(méi)有對(duì)服務(wù)器的抗抵賴(lài)要求，通過(guò)數(shù)據(jù)完整性提供的功能，保證數(shù)據(jù)是由服務(wù)器發(fā)出的真實(shí)完成數(shù)據(jù)即可。

3.6 防會(huì)話(huà)假冒

HTTP現(xiàn)有的會(huì)話(huà)識(shí)別方式無(wú)法避免會(huì)話(huà)假冒。為了防止這種攻擊，會(huì)話(huà)過(guò)程中需要服務(wù)器發(fā)送數(shù)據(jù)時(shí)帶隨機(jī)挑戰(zhàn)碼，客戶(hù)端每次對(duì)服務(wù)器發(fā)送的挑戰(zhàn)碼進(jìn)行某種加密計(jì)算，而攻擊者無(wú)法模仿。因?yàn)椴皇菄?yán)格的一發(fā)一收的串行會(huì)話(huà)，所以服務(wù)器應(yīng)能夠容忍一定的并發(fā)會(huì)話(huà)。如果全部會(huì)話(huà)數(shù)據(jù)已經(jīng)在應(yīng)用層加密，就已經(jīng)起到防會(huì)話(huà)假冒的作用。

4 基于口令鑒別協(xié)議的發(fā)展

基于口令的身份鑒別只需要用戶(hù)記住相對(duì)簡(jiǎn)短的口令，不需要依賴(lài)設(shè)備或軟件輔助記錄很長(zhǎng)的秘密信息（如私鑰），出于成本、簡(jiǎn)單和易用的考慮，口令鑒別是最廣范應(yīng)用的鑒別方法?？诹铊b別的基礎(chǔ)是客戶(hù)端知道一個(gè)秘密（口令），服務(wù)器也知道這個(gè)秘密或與這個(gè)秘密相關(guān)的信息，而攻擊者不知道此秘密。從最不安全到最安全，口令鑒別協(xié)議發(fā)展出以下各種形式：

4.1 簡(jiǎn)單口令鑒別

最簡(jiǎn)單的身份鑒別方法是客戶(hù)和服務(wù)器共享一個(gè)相同的口令，登錄時(shí)客戶(hù)輸入用戶(hù)名和這個(gè)口令，服務(wù)器驗(yàn)證這個(gè)口令是否匹配。這是最不安全也是應(yīng)用最多的方式，面臨竊聽(tīng)、服務(wù)器口令表被竊等各種攻擊。

4.2 散列口令鑒別

稍好一點(diǎn)的方法是客戶(hù)不直接發(fā)送口令，而是發(fā)送口令（加鹽）的散列值，服務(wù)器端存放（加鹽的）口令散列值。這種方式的優(yōu)點(diǎn)是竊聽(tīng)者不能直接獲取口令明文，攻破服務(wù)器之后也不能拿到明文口令類(lèi)表。但是竊聽(tīng)者可以用一個(gè)口令字典進(jìn)行散列計(jì)算，與竊聽(tīng)的單一口令或竊取的口令列表比對(duì)，從中找到匹配的口令，實(shí)現(xiàn)離線(xiàn)字典攻擊。加鹽的原因是防止攻擊者對(duì)口令字典進(jìn)行一次散列計(jì)算就可以與所有口令列表進(jìn)行匹配，加鹽后攻擊者不得不對(duì)每個(gè)鹽進(jìn)行全字典散列運(yùn)算，這往往是不切實(shí)際的。更直接的攻擊方式是重放攻擊，攻擊者不需要破解口令，只需要發(fā)送記錄的散列值就可以假冒客戶(hù)。

4.3 挑戰(zhàn)應(yīng)答口令鑒別

4.3.1 形式描述

這種形式的具體協(xié)議有很多，但都有如下形式：

（1）客戶(hù)端發(fā)送用戶(hù)名和隨機(jī)消息給服務(wù)器；

（2）服務(wù)器發(fā)送給客戶(hù)端一個(gè)隨機(jī)消息，稱(chēng)作挑戰(zhàn)（challenge）；

（3）客戶(hù)端基于挑戰(zhàn)、第一個(gè)隨機(jī)消息、口令執(zhí)行某種計(jì)算。將此應(yīng)答（response）發(fā)送給服務(wù)器，服務(wù)器做同樣的計(jì)算來(lái)驗(yàn)證客戶(hù)端的應(yīng)答。

因?yàn)榉?wù)器的挑戰(zhàn)在每次鑒別嘗試時(shí)都不相同，一個(gè)捕獲的應(yīng)答在未來(lái)的會(huì)話(huà)中是無(wú)用的，這可以抵御重放攻擊。但是攻擊者可以從一個(gè)成功的鑒別嘗試中捕獲隨機(jī)數(shù)、挑戰(zhàn)、應(yīng)答，并用離線(xiàn)字典攻擊猜測(cè)出口令。而且挑戰(zhàn)-應(yīng)答協(xié)議是明文等價(jià)的，所以一個(gè)即獲得口令文件又可以竊聽(tīng)的入侵者可以輕易擊敗它。

4.3.2 實(shí)例MS-CHAPv2

MS-CHAPv2[1]協(xié)議是微軟用于撥號(hào)網(wǎng)絡(luò)認(rèn)證和VPN登錄的協(xié)議，是PPP[2]（點(diǎn)對(duì)點(diǎn)協(xié)議）的CHAP[3]（挑戰(zhàn)應(yīng)答認(rèn)證協(xié)議）的一種實(shí)現(xiàn)，在MS-CHAPv1[4]基礎(chǔ)上改進(jìn)而來(lái)，MS-CHAPv2在v1基礎(chǔ)上增加了相互認(rèn)證功能。B.Schneier等對(duì)MS-CHAPv1的分析[5]發(fā)現(xiàn)有嚴(yán)重安全問(wèn)題，因此微軟推出了改進(jìn)的MS-CHAPv2。但B.Schneier等對(duì)MS-CHAPv2的分析[6]發(fā)現(xiàn)它仍然易受到L0phtcrack等工具的離線(xiàn)字典猜測(cè)攻擊，安全依賴(lài)于用戶(hù)選擇的口令是否足夠復(fù)雜；而且對(duì)MS-CHAPv1的兼容支持導(dǎo)致版本回退攻擊：攻擊者可以讓客戶(hù)端和服務(wù)器都認(rèn)為對(duì)方只能支持MS-CHAPv1。

4.3.3 EKE協(xié)議族

Bellovin和Merritt在1992年提出了加密密鑰交換（Encrypted Key Exchange，EKE）[7]協(xié)議，使用對(duì)稱(chēng)和公鑰密碼術(shù)的結(jié)合，而且不依賴(lài)可信第三方或PKI體系，抵御離線(xiàn)字典攻擊。EKE也執(zhí)行一個(gè)密鑰交換，所以一旦鑒別建立之后雙方可以加密它們的傳輸。EKE的最大問(wèn)題是明文等價(jià)，需要客戶(hù)和主機(jī)訪(fǎng)問(wèn)同樣的秘密口令或口令散列值。后續(xù)還有許多通訊協(xié)議如DH-EKE[8]、SPEKE[9]、A-EKE[10]等在EKE基礎(chǔ)上增加前向保密、解決明文等價(jià)問(wèn)題，但未能同時(shí)解決所有問(wèn)題。B-SPEKE[11]解決了前向保密、解決明文等價(jià)問(wèn)題，但以犧牲性能為代價(jià)。

4.4 AKE框架

4.4.1 AKE介紹

在EKE發(fā)展的基礎(chǔ)上，出現(xiàn)了稱(chēng)為不對(duì)稱(chēng)密鑰交換AKE（Asymmetric Key Exchange）的新架構(gòu)，是一個(gè)基于驗(yàn)證碼協(xié)議的一般化形式。因?yàn)轵?yàn)證碼和口令設(shè)計(jì)為不等價(jià)的，這強(qiáng)制要求協(xié)議的計(jì)算結(jié)構(gòu)天生非對(duì)稱(chēng)。能夠構(gòu)造安全的基于驗(yàn)證碼協(xié)議所必須的數(shù)學(xué)變換的方法屈指可數(shù)。EKE類(lèi)的協(xié)議使用預(yù)先共享的秘密（口令）作為鑒別基礎(chǔ)。這意味著雙方維持相同或等價(jià)的字符串用于間接鑒別對(duì)方。因?yàn)閾碛羞@個(gè)秘密足以模仿對(duì)方，而且這個(gè)秘密在雙方有被竊的可能，所以雙方都有責(zé)任安全地交換初始秘密、小心地保護(hù)這個(gè)秘密。

然而AKE描述了一個(gè)“對(duì)換秘密”方法，雙方計(jì)算一個(gè)秘密并用單向函數(shù)計(jì)算產(chǎn)生一個(gè)對(duì)方也掌握的驗(yàn)證碼。雖然保護(hù)驗(yàn)證碼防止字典攻擊仍然很重要，但被竊的驗(yàn)證碼不再足以模仿用戶(hù)，仍然需要對(duì)應(yīng)的秘密口令。這項(xiàng)技術(shù)的一個(gè)特殊案例是只有一方產(chǎn)生秘密并計(jì)算驗(yàn)證碼，這在對(duì)方是存儲(chǔ)許多驗(yàn)證碼的多用戶(hù)系統(tǒng)時(shí)看起來(lái)非常有用。這種應(yīng)用中用戶(hù)的秘密（口令）在初始設(shè)置和交換過(guò)程中永遠(yuǎn)不需要離開(kāi)用戶(hù)主機(jī)；只需要發(fā)送驗(yàn)證碼。

4.4.2 AKE實(shí)例 SRP

滿(mǎn)足AKE框架的協(xié)議有多個(gè)，SRP[12]是沒(méi)有其中專(zhuān)利、得到較多實(shí)際應(yīng)用的一種，并已經(jīng)發(fā)布了三個(gè)IETF RFC文檔[13，14，15]。SRP經(jīng)過(guò)分析和改進(jìn)，SRP-6版本定義如下：

表1 SRP-6數(shù)學(xué)符號(hào)

注冊(cè)過(guò)程：客戶(hù)端選擇選一個(gè)隨機(jī)數(shù)鹽s，并計(jì)算v，將s和v發(fā)送到服務(wù)器保存，x被丟棄。

鑒別過(guò)程：

SRP協(xié)議在僅使用口令的情況下可以滿(mǎn)足以下安全要求，并產(chǎn)生一個(gè)會(huì)話(huà)密鑰：

（1）在身份鑒別過(guò)程中沒(méi)有口令或它相關(guān)的信息被泄露，防止攻擊者從交換的消息中猜測(cè)或證實(shí)口令。

（2）在身份鑒別過(guò)程中沒(méi)有關(guān)于會(huì)話(huà)密鑰的相關(guān)信息被泄露。因?yàn)闀?huì)話(huà)密鑰是一個(gè)強(qiáng)密碼的密鑰，不需要擔(dān)心對(duì)它的嘗試攻擊。

（3）即沒(méi)有用戶(hù)口令又沒(méi)有主機(jī)口令文件的攻擊者無(wú)法發(fā)動(dòng)對(duì)口令的離線(xiàn)字典攻擊。這可以降低對(duì)用戶(hù)口令復(fù)雜度的要求，即使弱口令也能在應(yīng)用系統(tǒng)對(duì)在線(xiàn)攻擊進(jìn)行限制的情況下保持較高的安全。

（4）攻擊者不能對(duì)客戶(hù)端或服務(wù)器成功模仿對(duì)方或得到任何關(guān)于口令或會(huì)話(huà)密鑰的信息。攻擊者最多只能導(dǎo)致鑒別失敗。

（5）如果攻擊者攻破服務(wù)器獲得口令文件，它能夠能防止攻擊者在不經(jīng)過(guò)昂貴的字典搜索的情況下模仿一個(gè)客戶(hù)端。

（6）已經(jīng)入侵服務(wù)器的攻擊者不能從合法的鑒別嘗試中獲得口令。

（7）如果過(guò)去的會(huì)話(huà)密鑰被竊，它不能幫助入侵者猜測(cè)或推算用戶(hù)的口令。

（8）如果用戶(hù)的口令被竊，它不能讓入侵者確定過(guò)去的會(huì)話(huà)密鑰并解密會(huì)話(huà)。

5 改進(jìn)的身份鑒別解決方案

（1）身份鑒別

靜態(tài)口令簡(jiǎn)單的一次交互的身份鑒別協(xié)議無(wú)法滿(mǎn)足安全的要求，挑戰(zhàn)應(yīng)答協(xié)議和EKE類(lèi)協(xié)議也不夠好，使用SRP或類(lèi)似協(xié)議是一個(gè)較好的解決方法。因?yàn)楝F(xiàn)有銀行網(wǎng)絡(luò)應(yīng)用在服務(wù)器端已經(jīng)注冊(cè)了大量用戶(hù)，一般也不存放口令明文，因此需要對(duì)SRP協(xié)議進(jìn)行適應(yīng)分析。

SRP需要三次交互，第一次僅是通過(guò)用戶(hù)名獲得鹽。鹽的作用是為了防止攻擊者獲得服務(wù)器口令清單后容易實(shí)施字典攻擊設(shè)置的一個(gè)障礙，在用戶(hù)注冊(cè)時(shí)設(shè)置，以后不再變化，對(duì)攻擊者不需要保密。為了數(shù)據(jù)兼容性，對(duì)已經(jīng)有鹽存儲(chǔ)口令的網(wǎng)絡(luò)應(yīng)用我們?nèi)匀槐Ａ暨@個(gè)設(shè)計(jì)，同時(shí)在不降低協(xié)議強(qiáng)度的基礎(chǔ)上將SRP的三次交互減少為兩次交互。采用SRP除完成雙方相互認(rèn)證外還可以產(chǎn)生會(huì)話(huà)密鑰用于加密敏感數(shù)據(jù)。

表2 身份鑒別

（2）會(huì)話(huà)識(shí)別

為了防止攻擊者通過(guò)某種方式獲得會(huì)話(huà)ID后模仿登錄后的用戶(hù)，應(yīng)用必須在應(yīng)用服務(wù)器提供的會(huì)話(huà)機(jī)制之外實(shí)現(xiàn)自己的會(huì)話(huà)識(shí)別。會(huì)話(huà)識(shí)別包括服務(wù)器識(shí)別客戶(hù)端和客戶(hù)端識(shí)別服務(wù)器兩部分，因?yàn)檎?qǐng)求都是由客戶(hù)端主動(dòng)發(fā)起，所以對(duì)服務(wù)器識(shí)別意義不大。登錄握手后雙方已經(jīng)建立會(huì)話(huà)密鑰，以后的交互過(guò)程中每次服務(wù)器響應(yīng)時(shí)產(chǎn)生服務(wù)器端的挑戰(zhàn)碼，在客戶(hù)端下次提交或發(fā)送請(qǐng)求時(shí)對(duì)此服務(wù)器挑戰(zhàn)碼進(jìn)行加密，由服務(wù)器進(jìn)行驗(yàn)證。因?yàn)檫@種交互不完全是串行的，所以服務(wù)器需要保留并驗(yàn)證最后幾次的挑戰(zhàn)碼。

上述會(huì)話(huà)識(shí)別機(jī)制只能保護(hù)登錄之后的會(huì)話(huà)，因此登錄之前的交易需要盡可能少暴露重要信息。

（3）注冊(cè)過(guò)程

SRP身份鑒別的前提是雙方預(yù)先協(xié)商口令及其驗(yàn)證碼。計(jì)算在客戶(hù)端進(jìn)行，服務(wù)器端只需要保存驗(yàn)證碼v：

如果注冊(cè)過(guò)程是在柜臺(tái)等安全內(nèi)網(wǎng)，直接傳輸v沒(méi)有問(wèn)題，但在互聯(lián)網(wǎng)環(huán)境下，上述注冊(cè)過(guò)程并不夠安全，因此更好的方式為：在注冊(cè)時(shí)使用一個(gè)雙方已知的秘密（比如電話(huà)銀行密碼、卡密碼等）作為鑒別口令通過(guò)SRP協(xié)議建立安全通道，使用會(huì)話(huà)密鑰K加密v后傳輸。

（4）修改、重置靜態(tài)口令過(guò)程

無(wú)論是登錄后修改口令還是登錄前重置口令，都需要先驗(yàn)證身份，建立安全通道，使用會(huì)話(huà)密鑰K加密新口令的驗(yàn)證碼v后傳輸。

（5）交易數(shù)據(jù)機(jī)密性

通過(guò)SRP建立會(huì)話(huà)后，雙向通訊數(shù)據(jù)通過(guò)會(huì)話(huà)密鑰K加密，加密采用AES、SM4等強(qiáng)對(duì)稱(chēng)算法。為了便于傳輸加密結(jié)果使用Base64編碼。

（6）交易數(shù)據(jù)完整性

數(shù)據(jù)完整性的實(shí)現(xiàn)方式有多種，可以對(duì)交易數(shù)據(jù)通過(guò)會(huì)話(huà)密鑰K產(chǎn)生的密鑰進(jìn)行HMAC等算法產(chǎn)生一個(gè)鑒別碼，也可以使用下一節(jié)采用的交易簽名方式來(lái)進(jìn)行。交易數(shù)據(jù)要在加密前參加鑒別碼運(yùn)算。

會(huì)話(huà)密鑰在會(huì)話(huà)結(jié)束后不在服務(wù)器保存。如果需要事后進(jìn)行監(jiān)督、電子證據(jù)提取，最好使用交易簽名保證數(shù)據(jù)完整性。

（7）防抵賴(lài)

防抵賴(lài)是通過(guò)對(duì)數(shù)據(jù)簽名來(lái)完成。普通客戶(hù)大部分不使用PKI數(shù)字證書(shū)，所以簽名最好由SRP協(xié)議握手過(guò)程中產(chǎn)生的非對(duì)稱(chēng)密鑰對(duì)完成。

對(duì)客戶(hù)端的防抵賴(lài)：數(shù)據(jù)提交前由安全控件先散列計(jì)算，然后用私鑰進(jìn)行計(jì)算簽名，服務(wù)器用公鑰進(jìn)行驗(yàn)證。為了事后進(jìn)行驗(yàn)簽名，服務(wù)器需要保留原始數(shù)據(jù)、數(shù)據(jù)簽名、當(dāng)時(shí)的用戶(hù)公鑰。因?yàn)闀?huì)話(huà)中產(chǎn)生的公私鑰對(duì)僅在一次會(huì)話(huà)中有效，即使記錄下來(lái)也不好證明當(dāng)時(shí)的公鑰，所以使用和口令相關(guān)的私鑰x和口令驗(yàn)證碼v，服務(wù)器需要記錄歷史口令驗(yàn)證碼?？梢圆捎玫暮灻惴ㄓ泻芏啵?yàn)镾RP協(xié)議基于離散對(duì)數(shù)問(wèn)題，所以用基于離散對(duì)數(shù)的簽名算法更方便一些。以ElGamal簽名算法為例：

簽名過(guò)程：M=H（message）

選擇隨機(jī)數(shù)r，r與n-1互質(zhì)

計(jì)算 c = gr（mod n）

再用擴(kuò)展 Euclidean 算法對(duì)下面方程求解d：

簽名就是（c，d），隨機(jī)數(shù)r丟棄。

驗(yàn)證過(guò)程：要驗(yàn)證下式：

同時(shí)要檢驗(yàn)是否滿(mǎn)足1＜= c ＜ n。防止簽名偽造。

對(duì)服務(wù)器的防抵賴(lài)：因?yàn)樵赪eb方式下客戶(hù)端一般不會(huì)記錄交易日志，所以基本沒(méi)有防抵賴(lài)的需求。如果將來(lái)需要，可以按照上述算法同樣處理。

防抵賴(lài)算法同時(shí)能夠完成客戶(hù)端交易數(shù)據(jù)完整性的功能。因?yàn)槠渌藳](méi)有簽名私鑰，防抵賴(lài)算法也能代替會(huì)話(huà)識(shí)別功能。

（8）實(shí)現(xiàn)問(wèn)題

因?yàn)镾RP協(xié)議相對(duì)較新，應(yīng)用較少，JDK目前不直接提供支持。雖然有一些開(kāi)源密碼項(xiàng)目已經(jīng)支持SRP協(xié)議，在某些Linux系統(tǒng)中得到應(yīng)用，但仍需要在對(duì)此方案進(jìn)行安全評(píng)審，并在評(píng)審?fù)ㄟ^(guò)的基礎(chǔ)上搭建環(huán)境進(jìn)行代碼開(kāi)發(fā)和試驗(yàn)。SRP協(xié)議與常見(jiàn)安全規(guī)范、安全檢查要求中不一致的地方還需要協(xié)商解決。

SRP協(xié)議不能解決所有的安全問(wèn)題，客戶(hù)端需要一個(gè)最小的安全條件——瀏覽器本身的安全。在沒(méi)有硬件封裝、也無(wú)法利用可信插件的情況下，基于腳本的客戶(hù)端SRP協(xié)議需要依賴(lài)于瀏覽器的安全。

[1]Zorn,G． Microsoft PPP CHAP Extensions，Version 2．RFC 2759,January ，2000．

[2]Simpson,W．，Editor．The Point-to-Point Protocol（PP P）．STD 51，RFC 1661，Daydreamer，July ，1994．

[3]Simpson,W．PPP Challenge Handshake Authentication P rotocol（CHAP），RFC 1994，August 1996．

[4]Zorn,G．,Cobb,S．Microsoft PPP CHAP Extensions, RFC 2433,October， 1998．

[5]B．Schneier,Mudge．Cryptanalysis of Microsoft's Point-to -Point Tunneling Protocol（PPTP），Proceedings of the 5th ACM Conference on Communications and Computer Securit y，ACM Press，pp．132-141．

[6]B．Schneier,Mudge．Cryptanalysis of Microsoft's PPTP A uthentication Extensions（MS-CHAPv2），CQRE '99，Spring er-Verlag，1999．

[7]S．M．Bellovin,M．Merritt．Encrypted key exchange：Passwo rd-based protocols secure against dictionary attacks．In Proceedi ngs of the 1992 IEEE Computer Society Conference on Rese arch in Security and Privacy，pages 72-84，1992．

[8]M．Steiner，G．Tsudik，and M．Waidner．Refinement and extension of encrypted key exchange．ACM Operating Systems Review，29（3），July 1995．

[9] D．Jablon，Strong Password-Only Authenticated Key E xchange，Computer Communication Review，26（5）：5-26，October， 1996．

[10]S．M．Bellovin and M．Merritt．Augmented encrypted key exchange：A password-based protocol secure against dictionar y attacks and password file compromise．Technical report，AT& T Bell Laboratories，1994．

[11]D．Jablon，Extended Password Key Exchange Protocols I mmune to Dictionary Attacks，IEEE Computer Society．Jun，1997．

[12] T．Wu．Secure remote password protocol．In Network and Distributed System Security Symposium，1998．

[13] T．Wu．Telnet Authentication：SRP．RFC 2944，Septe mber ，2000．

[14] T．Wu．The SRP Authentication and Key Exchange S ystem．RFC 2945，September， 2000．

[15]Taylor,T．Wu,N．Mavrogiannopoulos,T．Perrin．Using the Secure Remote Password（SRP）Protocol for TLS Authentic ation，RFC 5054，November， 2007．