對網站系統安全的需求分析

本文從數據安全與業務邏輯安全兩個角度對應用系統的安全進行需求分析，

要緊包含保密性需求、完整性需求、可用性需求三部分；隨后對業務邏輯安全需

求進行了分析，包含身份認證、訪問操縱、交易重復提交操縱、異步交易處理、

交易數據不可否認性、監控與審計等兒個方面；最后還分析了系統中一些其它的

安全需求。

2.1數據安全需求

2.1.1數據保密性需求

數據保密性要求數據只能由授權實體存取與識別，防止非授權泄露。從目前

國內應用的安全案例統計數據來看，數據保密性是最易受到攻擊的一個方面，通

常表現為客戶端發生的數據泄密，包含用戶的基本信息、賬戶信息、登錄信息等

的泄露。在應用系統中，數據保密性需求通常要緊表達在下列幾個方面：

A.客戶端與系統交互時輸入的各類密碼：包含系統登錄密碼、轉賬密碼、

憑證查詢密碼、憑證交易密碼等務必加密傳輸及存放，這些密碼在應用系統中只

能以密文的方式存在，其明文形式能且只能由其合法主體能夠識別。

以網銀系統為例，在網銀系統中，通常存有四種密碼：系統登錄密碼、網銀

轉賬密碼、柜面交易密碼及一次性密碼。系統登錄密碼用來認證當前登錄者為指

定登錄名的合法用戶，網銀用戶的登錄密碼與網銀轉賬密碼由用戶在柜面開戶時

指定，用戶在首次登錄網銀系統時，系統務必強制用戶修改初始密碼，通常要求

長度不得少于六位數，且不能是類似于111111、1234567、9876543等的簡單數

字序列，系統將進行檢查。

網銀轉賬密碼是指網銀系統為鞏固用戶資金安全，在涉及資金變動的交易中

對用戶身份進行了再認證，要求用戶輸入預設的密碼，網銀交易密碼僅針對個人

用戶使用，企業用戶沒有網銀交易密碼。建立多重密碼機制，將登錄密碼與網銀

轉賬密碼分開管理，有利于加強密碼的安全性。由于用戶在使用網銀時每次都務

必先提供登錄密碼，故登錄密碼暴露的機會較多，安全性相對較弱；但登錄網銀

的用戶并不是每次都會操作賬戶資金的，因此專門設定網銀轉賬密碼可加強賬戶

的安全性。網銀轉賬密碼在網銀開戶時設定，網銀用戶在系統中作轉賬支付、理

財、代繳費等資金變動類交易時使用。

柜面交易密碼是指用戶在銀行柜面辦理儲蓄時，針對儲蓄憑證（如卡折、存

單等）而設的密碼。柜面交易密碼常用于POS系統支付時、ATM取款時、憑證

柜面取款時，柜面交易密碼一個明顯的特征是它目前只能是六位的數字，這是由

于目前柜面密碼輸入設備的限制而造成的。柜面交易密碼與上述的網銀轉賬密碼

的區別在于：網銀轉賬密碼與系統登錄密碼都產生于網銀系統，儲存在網銀系統

中，僅限網銀系統中認證使用；而柜面交易密碼產生于銀行柜臺，能夠在外圍渠

道如ATM、電話銀行、自助終端上修改，它儲存在銀行核心系統中，供外圍各

個渠道系統共同使用。另外網銀轉賬密碼能夠有非數字字符構成，而柜面交易密

碼只能是六位的數字。網銀中使用到柜面交易密碼的交易包含：網銀開戶、加掛

賬戶c

一次性密碼由用戶的智能卡、令牌卡產生，或者由動態密碼系統產生通過短

信方式發送到用戶注冊的手機上。一次性密碼的作用與網銀轉賬密碼相同，適用

的場合也相同。一次性密碼在農商行網銀系統中是可選的安全服務，用戶需到柜

面辦理開通手續才能使用，沒有開通一次性密碼服務的用戶務必設定網銀交易密

碼，開通一次性密碼服務的用戶則無需設定網銀交易密碼，要求網銀系統自動推

斷并提示用戶在某個交易中是要輸入網銀交易密碼還是提示一次性密碼。

B.應用系統與其它系統進行數據交換時在特定安全需求下需進行端對端的

加解密處理。這里的數據加密要緊是為了防止交易數據被銀行內部人士截取利

用，具體通訊加密方案參照應用系統的特定需求。

2.1.2數據完整性需求

數據完整性要求防止非授權實體對數據進行非法修改。用戶在跟應用系統進

行交互時，其輸入設備如鍵盤、鼠標等有可能被木馬程序偵聽，輸入的數據遭到

截取修改后被提交到應用系統中，如原本用戶準備向A賬戶轉一筆資金在交易

數據遭到修改后就被轉到B賬戶中了。同樣的威脅還存在于交易數據的傳輸過

程中，如在用戶向應用系統提交的網絡傳輸過程中或者應用系統跟第三方等其它

系統的通訊過程中，另外存儲在應用系統數據庫中的數據也有可能遭到非法修

改，如SQL注入攻擊等。

2.1.3數據可用性需求

數據可用性要求數據關于授權實體是有效、可用的，保證授權實體對數據的

合法存取權利。

對數據可用性最典型的攻擊就是拒絕式攻擊（DoS）與分布式拒絕攻擊，兩

者都是通過大量并發的惡意請求來占用系統資源，致使合法用戶無法正常訪問目

標系統，如SYNFlood攻擊等，將會直接導致其他用戶無法登錄系統。另外，應

用登錄機器人對用戶的密碼進行窮舉攻擊也會嚴重影響系統的可用性。

2.2業務邏輯安全需求

業務邏輯安全要緊是為了保護應用系統的業務邏輯按照特定的規則與流程

被存取及處理。

2.2.1身■份認證需求

身份認證就是確定某個個體身份的過程。系統通過身份認證過程以識別個體

的用戶身份，確保個體為所宣稱的身份。應用系統中身份認證可分為單向身份認

證與雙向身份認證，單向身份認證是指應用系統對用戶進行認證，而雙向身份認

證則指應用系統與用戶進行互相認證，雙向身份認證可有效防止“網絡釣魚”等

假網站對真正系統的旨充。

應用服務器使用數字證書，向客戶端提供身份認證，數字證書要求由權威、

獨立、公正的第三方機構頒發；系統為客戶端提供兩種可選身份認證方案，服務

器端對客戶端進行多重身份認證，要求充分考慮到客戶端安全問題。將客戶端用

戶身份認證與賬戶身份認證分開進行，在用戶登錄系統時，使用單點用戶身份認

證，在用戶提交更新類、管理類交易請求時，再次對用戶的操作進行認證或者對

用戶身份進行二次認證，以確保用戶信息安全。

2.2.2訪問操縱需求

訪問操縱規定了主體對客體訪問的限制，并在身份識別的基礎上，根據身份

對提出資源訪問的請求加以操縱。訪問操縱是應用系統中的核心安全策略，它的

要緊任務是保證應用系統資源不被非法訪問。主體、客體與主體對客體操作的權

限構成訪問操縱機制的三要素。訪問操縱策略能夠劃分為自主訪問操縱、強制訪

間操縱與基于角色的訪問操縱三種。

2.2.3交易重復提交操縱需求

交易重復提交就是同一個交易被多次提交給應用系統。查詢類的交易被重復

提交將會無故占用更多的系統資源，而管理類或者金融類的交易被重復提交后，

后果則會嚴重的多，譬如一筆轉賬交易被提交兩次則將導致用戶的賬戶被轉出兩

筆相同額的資金，顯然用戶只想轉出一筆。交易被重復提交可能是無意的，也有

可能是有意的：

A.用戶的誤操作。在B/S結構中，從客戶端來看，服務器端對客戶端的響

應總有一定的延遲，這在某些交易處理上表達的更為明顯，特別是那些涉及多個

系統交互、遠程訪問、數據庫全表掃描、頁面數據簽名等交易，這種延遲通常都

會在5至7秒以上。這時用戶有可能在頁面已提交的情況下，再次點擊了提交按

鈕，這時將會造成交易被重復提交。

R.被提交的交易數據有可能被拿來作重放攻擊.

應用系統務必對管理類與金融類交易提交的次數進行操縱，這種操縱即要有

效的杜絕用戶的誤操作，還不能影響用戶正常情況下對某個交易的多次提交。比

如說：當某個用戶在10秒內提交了兩筆相同的轉賬業務，則系統務必對此進行

操縱；另一方面，當用戶在第一筆轉賬業務完成后，再作另一筆數據相同的轉賬

時，則系統不能對此進行誤操縱。這里推斷的根據就是交易重復提交的操縱因子

a,當交易提交的間隔小于a時，系統認為這是重復提交，提交間隔大于a的則

不作處理，操縱因子的大小由應用系統業務人員決定，系統應可對其進行配置化

管理。

2.2.4異步交易處理需求

所謂異步交易就是指那些錄入與提交不是同時完成的交易，這里的同時是指

客戶端在錄入交易數據與提交交易的過程中，應用系統服務器端并沒有對錄入的

數據進行持久化儲存，而異步交易在系統處理過程中，錄入與提交時間上發生在

兩個相分離的階段，在兩階段之間，應用系統對錄入的數據進行了持久化儲存。

由于異步交易是被系統分兩階段受理的，這就涉及到下列三個方面的問題：

A.錄入與提交的關系管理。

B.如何保證提交的數據就是用戶當初錄入的數據。

C.如何記錄交易在兩階段的日志狀態。

錄入與提交的關系定義不當將會導致交易錄入與提交被同時完成而違反了

業務處理流程，錄入的數據被系統儲存后有可能遭到非法篡改，非異步交易執行

后的日志狀態不可能被更新而異步交易在提交后日志狀態將會被更新。

應用系統中需要定義成異步的交易通常有下列兩類：

令需要授權的交易。出于業務管理與業務安全方面的考慮，大部分管理類

與金融類的交易都需要通過一定的授權流程后方能被提交。

令部分定時交易，如預約轉賬等。預約一筆在周三轉賬的預約轉賬有可能

是周一被錄入的，用戶在錄入后，預約轉賬的數據將被網銀系統儲存直

到周三這筆轉賬才會真正發生。

應用系統務必定義簡單、清晰、易保護的錄入與提交關系模型，保證被儲存

的錄入數據不可能被非法篡改，同時要求異步交易的日志狀態是明確的，不應出

現錄入與提交相矛盾的F1志狀態.

2.2.5交易數據不可否認性需求

交易數據不可否認性是指應用系統的客戶不能否認其所簽名的數據，客戶對

交易數據的簽名是通過應用系統使用客戶的數字證書來完成的。數字證書的應用

為交易數據不可否認性提供了技術支持，而電子簽名法的頒布為交易數據不可否

認性提供了法律基礎。

在應用系統中通常要求對所有管理類與金融類的交易進行數字簽名，以防客

戶事后對交易或者交易數據的抵賴。應用系統需同時儲存客戶錄入的原始數據與

簽名后的數據，儲存期限依業務部門的具體要求而定?？紤]到系統性能與對用戶

的響應問題，應用系統可只簽與交易有關的關鍵數據，支付類的交易只應付款人

賬號、付款金額、收款人姓名、收款人賬號、收款人開戶行五個字段進行數字簽

名就能夠了。

2.2.6監控與審計需求

安全級別要求高的應用系統應提供對系統進行實時監控的功能，監控的內容

包含系統當前登錄的用戶、用戶類型、用戶正在訪問的交易、用戶登錄的IP等。

對金融類、管理類的交易與應用系統登錄交易需要完整地記錄用戶的訪問過程，

記錄的關鍵元素包含：用戶登錄名、登錄IP、交易日期及時間、交易名稱、交

易有關數據等，對有授權流程的交易要求完整記錄授權的通過，授權記錄與交易

記錄分開存放。

2.3其它安全需求

2.3.1登錄操縱需求

登錄通常是應用系統的關鍵交易，系統通過登錄交易對用戶身份進行認證。

針對不一致角色的用戶指定不一致的登錄策略：

令最小權限集用戶，可使用用戶登錄名+靜態登錄密碼+圖形識別碼方式登

錄。低安全性。

令普通權限集用戶，可使用用戶登錄名+動態登錄密碼+數圖形識別碼方式

登錄。

。高權限集用戶，可使用用戶登錄名+數字證書+靜態密碼+數圖形識別碼

方式登錄.

令所有權限集用戶，可使用用戶登錄名+數字證書+動態密碼+數圖形識別

碼方式登錄。

應用系統可提供客戶端加密控件對用戶輸入的密碼域進行加密處理后再提

交。

連續登錄多次失敗的用戶，其IP將被應用系統鎖定，24小時后系統將自動

對鎖定的IP進行解鎖。這里登錄失敗的次數與IP鎖定時長根據業務需求說明應

由配置文件進行設定。

關于首次登錄系統的用戶，系統將強制定位到修改密碼的頁面，要求用戶修

改初始密碼重新登錄方可使用系統。關于密碼類型與長度，系統將規則檢查。

關于成功登錄的用戶，應用系統自動清除其連續登錄失敗的次數，同時初始

化用戶的有關數據并同時對登錄數據進行記錄，以備審計工

2.3.2會話操縱需求

233被訪問對象操縱需求

應用系統對用戶的關鍵資源或者信息，提供操作權限設置支持，權限分為：

查詢與更新兩類。權限為查詢的資源或者信息只能對其進行查詢操作，不能進行

更新。資源權限由開戶時指定，為加強安全性，雙限分配可通過落地處理開通。

2.3.4交易提醒需求

交易提醒是指將客戶的賬號與客戶手機號、電子郵件等關聯起來，當客戶信息

發生變動時.，向客戶的手機發送一條短信或者電話通知或者發送一封電子郵件，及

時準確的告知客戶。另通過通知提醒功能，系統應定期向用戶發送統計、明細、確

認等信息。

第三章應用系統安全的總體解決方案

3.1安全技術

安全技術是安全子系統的理論基礎，安全子系統中要緊涉及的安全技術包

含：密碼技術、PKI技術體系、一次性口令技術等，另外考慮到目前實際應用中,

大部分WEB應用系統是基于J2EE平臺的，J2EE平臺本身也對系統安全提供了

較多內置的支持，如JAAS技術等，因此本章中關于J2EE平臺的安全技術特性

也有少量的討論。

3.1.1密碼技術

密碼技術是保護信息系統安全的基礎技術之一，密碼技術能夠保證數據的保

密性與完整性，同時它還具有身份認證與數字簽名的功能。從密碼體制方面來說,

密碼技術可分為對稱密鑰密碼技術與非對稱密鑰密碼技術兩大類。在應用系統中

常用的密碼技術要緊有下列幾種：

A.加密解密技術

加密(Encryption)就是指通過特定的加密算法對數據進行變換，將明文

(Plaintext)轉換成密文(Cryptograph)；解密(Decryption)是加密的逆過程,

解密的過程就是將密文還原為明文。設明文為P,密文為C,E為加密算法，D

為解密算法，則加密解密的過程能夠記為：

C=E(P)

(3.1)

P=D(C)

上述的加密與解密過程沒有使用到密鑰，通常稱之為無密鑰密碼體

制。無密鑰密碼要緊依靠加密算法提供保密性，在應用系統中這種密碼

很少用到，要緊使用還是有密鑰的密碼體制，在有密鑰的密碼體制中，

密文的保密性依靠于密鑰而不依靠于算法，算法能夠公開。其中，只有

一個密鑰K的密碼體制稱之單鑰體制(One-keySystem),又稱對稱

加密體制(SymmetricalEncryption)；有加密密鑰KE與解密密鑰KD

兩個密鑰的密碼體制稱之雙鑰體制(Two-kcySystem),又稱非對稱加

密體制(DissymmetricalEncryption),有的時候也叫公開密鑰算法(P

ublicKeyAlgorithm)。應用系統中經常使用最廣泛的對稱加密算法是D

ES算法(DataEncryptionStandard),非對稱加密算法是RSA算法(R

eceive,Shamir,Adelman)?單鑰體制的加密解密過程能夠記為:

C=E(P,K)

(3.2)

P=D(C.K)

上式用圖示能夠表示為：

圖5單鑰體制加密解密過程圖

雙鑰體制的加密解密過程能夠記為：

C=E(P,KE)

P=D(C,KD)

上式用圖示能夠表示為：

圖6雙鑰體制加密解密過程圖

還有一種應用系統中經常用到的加密技術是數據摘要，數據摘要就

是應用單向散列函數算法，將輸入的任意長度明文變換成固定長度的密

文，而將此密文再轉換成明文在數學上來說是困難的。應用系統中應用

最廣泛的數據摘要算法要緊有MD5與SHA兩種，MD5輸出壓縮值為

128bits,SHA輸出壓縮值為160bits。設Hash表示單向散列函數,則數

據摘要的過程能夠記為：

C=Hash(P)(3.4)

上式用圖示能夠表示為:

明文、|--------密文

二^"Hash_

圖7數據摘要的過程圖

B.數字簽名。

數字簽名是指通過密碼算法對原始數據信息進行加密處理后，生成一段原始

數據信息的信息標識，這段信息標識稱之原始數據信息的數字簽名。通常數字簽

名與原始數據信息是放在一起發送的，這樣便于信息的同意者對其進行驗證，數

字簽名是對現實中手寫簽名與印章的模擬，數字簽名只有信息發送方一人能產

生，這種唯一性對應了原始數據信息的來源。數字簽名具有驗證數據完整性與信

息來源不可否認性的功能，這正是PKI體系提供的核心功能。

在應用系統中，較小的數據能夠直接簽名，而較大的數據或者文件通常先對

其作數據摘要后再對數據摘要作數字簽名。下式表達了對一段原始數據信息進行

簽名的過程：原始數據信息OriginalMsg先是被單向散列函數Hash作數據摘要

生成摘要信息DigestMsg,然后應用非對稱加密算法DissymmelricalEncrypt及其

私鑰Keypriwe對數據摘要進行簽名（私鑰僅有發送方持有，公鑰需散發給接收

方），最后將簽名結果DigitalSignature與原始數據信息一起發送給同意方：

DigestMsg=Hash(OriginalMsg)

DigitalSignature=DissymmetricaIEncrypt(DigestMsg,Keyprivate)

(3.4)

上式用圖示能夠表示為:

圖8數字簽名的過程圖

信息同意方在同意到原始數據信息OriginalMsg與其數字簽名

DigitalSignature后，能夠對數字簽名進行驗證。首先分離出兩者，然后對原始數

據信息應用同樣的單向散列函數Hash對其作數據摘要得到Digest2,再對接收到

的數字簽名應用非對稱加密算法DissymmetricalEncrypt及其公鑰KeypUbiic對其進

行解密,得到Digest%比較Digestl與Digest2,假如兩者一樣則證明:

1.信息OriginalMsg及其數字簽名DigitalSignature是真實的,確實來自于

私鑰Keyprivaie的持有方。

2.信息OriginalMsg及其數字簽名DigitalSignature在發送過程中是完整的，

未曾遭到篡改。

3.私鑰Keyprivate的持有方發送了信息OriginalMsg及其數字簽名

DigitalSignature這件事是不可否認的。

上述數字簽名的驗證過程能夠表達為：

DigestMsg2=Hash(OriginalMs^)

DigeslMsgl=DissymmetricalEncry/)t(Di^italSiffiature,Keypublic)

DigestMsgl==DigestMsg]?

(3.5)

用圖形表示如下：

圖9數字簽名驗證的過程圖

C.報文識別碼

應用系統跟其它系統通訊時大都是通過發送接收報文方式進行的，除比較常

用的ISO8583,sop報文等，還有比較多的就是自定義的報文格式，自定義農文

需要解決報文的保密性與完整性問題，報文的完整性能夠通過加密算法生成原始

報文的報文標識來識別，這個加密后的報文標識稱之原始報文的識別碼，也叫報

文校驗碼MAC(MessageAuthenticationCode)。而報文的保密性能夠通過對整

個報文及其識別碼進行加密處理來完成，實際應用中識別碼通常能夠通過單向散

列函數對原始報文作數據摘要得到，然后對原始報文與數據摘要作對稱加密，這

樣既保證了報文的完整性，同時也保證了報文的保密性，這里對稱加密算法的密

鑰分發是要緊問題。

D.數字信封

數字信封DE(DigitalEnvelope)是指信息發送方在通訊雙發首次通訊時，

使用對方的公鑰對雙方的通訊密鑰SK(SymmentricKey)進行加密，形成一個

數字信封，然后發給接收方，接收方收到數字信封后進行拆封操作，用自己的私

鑰對信封進行解密得到通訊密鑰，然后雙方能夠用通訊密鑰對自己發送的信息進

行對稱加密⑷。這樣既解決了對稱加密的密鑰分配問題又提高了雙方通訊加密的

效率，畢竟非對稱加密算法比對稱加密算法效率要低下。

3.1.2PKI體系

PKI體系是由政策機構、認證機構與注冊機構構成的，通過使用單向散列函

數、非對稱加密體制等加密解密技術，安全套接字協議SSL,LDAP協議

(LightweightDirectoryAccessProtocol),X.509證書標準等技術,實現數據加

密、身份認證與數字簽名等功能，從而保證數據保密性、完整性、真實性與不可

否認性的一種技術體系。PKI體系很好的解決了網上銀行的大部分安全需求，對

網上銀行的數據安全與業務邏輯安全提供了有力的支持。CA是PKI體系的要緊

實體，數字證書是CA的要緊產品，CA通過數字證書的應用來實現PKI體系所

提供的功能。

1.PKI的構成

PKI由政策批準機構PAA、政策CA機構PCA、認證機構CA與注冊機構

RA構成。PAA創建整個PKI系統的方針、政策，批準本PAA下屬的PCA的政

策，為下屬PCA簽發公鑰證書，建立整個PKI體系的安全策略，并具有監控個

PCA行為的責任U。PCA制定自身的具體政策，包含密鑰的產生、密鑰的長度、

證書的有效期規定及CRL的處理等，同時PCA為其下屬CA簽發公鑰證書。CA

按照上級PCA制定的政策，為具體用戶簽發、生成并公布數字證書，負責CRL

的管理與保護。RA負責接收用戶的證書申請，驗證用戶的身份，向CA提交證

書申請，驗證接收CA簽發的數字證書，并將證書發放給申請者。PKI的構成圖

示如下:

圖10PKI的體系結構圖

2.PKI的操作功能

證書的生成及分發。在用戶向RA提交數字證書申請后，RA負責對申請者

的身份進行認證，認證通過后RA將向CA轉發證書申請。CA負責生成用戶的

數字證書，數字證書的公私密鑰對能夠由用戶產生，也能夠由CA產生。用戶自

己產生的公鑰需提交給CA,CA對公鑰強度驗證后將根據用戶提交的公鑰產生

用戶的數字證書；假如是CA產生用戶的公私密鑰對，則CA不儲存用戶的私鑰,

私鑰需通過安全的方式發放給用戶。CA生成證書后將其公布到相應的目錄服務

器上。

證書的獲取。在PKI體系中，要獲取某個用戶的數字證書，能夠RA處獲得,

也能夠查詢CA的證書目錄服務器，另外用戶也能夠將自己的證書發送給另1人。

證書的廢止。數字證書的持證人假如發生證書丟失、密鑰泄漏時，持證人能夠

向CA或者RA提交證書廢止請求，CA將會把用戶的證書加入到廢止列表中。

廢止列表CRL的獲取與查詢。由于CRL通常都比較大，在線查詢效率比較

低下，因此現在通常在RA端建立一個CRL的鏡像，定期將CA端的CRL同步

到本地，同步又分全部CRL同步與增量同步兩種，全部CRL同步的好處能保證

CRL數據一致，缺點是同步的數據量龐大，通常也沒有必要進行全局同步。增

量同步就是每次只同步CA端新增的CRL部分，增量同步的數據量較小，比較

符合現實。CRL的查詢能夠通過LDAP等訪問。

證書恢復。證書恢復功能為客戶在證書存儲介質損壞或者遺忘口令等情況

下，提供原證書的恢復，申請者向RA或者CA提出證書恢復請求，CA將會為

用戶生成新的數字證書，原先的證書將作廢，同時還會將其加入CRL中。

證書更新。證書更新用于解決客戶證書到期后的續費問題，也有可能是客戶

的證書并未到達有效期而是CA或者RA的本身的數字證書到達了有效期。這時

用戶需更新證書，CA將會為用戶簽發新的數字證書。

3.PKI的服務功能

PKI提供的服務功能包含：數據保空性服務、數據完整性服務、數據真實性

服務、數據不可否認性服務與身份認證服務。這些服務都是通過數字證書的應用

來實現的，在集成這些服務時，還需要應用系統作部分支持才能真正實現這些服

務。

3.1.3一次性口令技術

所謂一次性口令(OTP,OneTimePassword)是指針對傳統可重復使用的口

令而言的。一次性口令只能使用一次，不可重復使用。可重用的口令易受種種攻

擊：

截取攻擊：當口令以明文方式在網絡上傳遞時，容易被攻擊者截取獲得，一

旦口令泄漏則可能被未授權者非法使用。

重放攻擊：當口令以密文方式在網絡上傳遞時，盡管攻擊者無法獲取口令的

明文，但攻擊者能夠截取口令密文后對系統實施重放攻擊。

窮舉攻擊:攻擊者還有可能針對用戶的登錄名，根據系統對口令的限定規則,

嘗試規則范圍內各個可能的口令，對用戶口令實施窮舉攻擊。

窺探：用戶在輸入可重復使用的口令時必定要借助某種輸入設備，如鍵盤、

鼠標、手寫筆等，這時容易被他人或者其它錄影設備窺探到輸入內容，也有可能

被木馬程序等記錄了擊鍵事件而分析出口令。

社交工程：攻擊者通過利用人們心理弱點、本能反應、好奇心、信任、貪婪

等心理陷阱通過電子郵件、電話訪談、釣魚網站等騙取用戶的口令。

垃圾搜索：攻擊者偽裝成垃圾工人收集用戶的垃圾文檔用以分析用戶的口令

等。

一次口令由于每次使用各不相同的口令，因此并不存在上述的問題。一次口

令并不要求用戶記住多個口令，因此也不可能增加用戶與系統的負擔。一次性口

令的原理:在客戶端與服務器端各存在一個相同的算法、一個與用戶有關的種子、

一個不確定的因子，每次系統對用戶進行認證時，用戶將不確定的因子追加到種

子后，然后用算法對其加密算出一個結果，這個垢果作為一個一次性口令提交給

服務器，服務器端用相同的算法對相同種子與不確定因子進行運算，將得出的結

果與用戶提交的結果進行比較，相同則說明用戶輸入的口令是正確的。

一次性口令技術要求服務器端具有與用戶端相同的算法、種子及不確定因

子.這里關鍵是如何保證客戶端、服務器端具有相同的不確定因子C兩端不確定

因子的選擇方式要緊有下列三種：

I.挑戰應答方式。每次用戶請求登錄系統時，服務器端將不確定因子發送

給用戶，稱之一次挑戰，而用戶提交的口令是根據發送來的不確定因子，與用戶

端儲存的種子，由用戶端儲存的算法計算出來的，因此每次計算出的口令不相同。

這里的算法能夠使用單向散列函數算法，也能夠使用對稱加密算法。不確定因子

使用挑戰應答方式的原理能夠圖示如下：

請求登錄，輸入用戶名

發送不確定因子

用c------------------------------------系

運用算法對種子與因子進行

運算得出登錄口令并提交

------------------------------------>

戶統

返回登錄結果

圖11一次性口令應用的原理圖

2.時間同步方式?？蛻舳伺c服務器端以時間作為不確定因子，這

里要求雙方的時間是嚴格同步的，精確度能夠操縱在約定的范圍內，比

如說雙方的時間差不超過一分鐘。

3.事件同步方式。客戶端與服務器端以單向序列的迭代值作為不

確定因子，這里要求雙方每次迭代值的大小相同。這種方式的實現代價

比時間同步方式的小得多，而且也不用向挑戰應答方式那樣多出個挑戰

的交互，這種方式客戶端以單向迭代作為挑戰，迭代作為規則能夠在客

戶端實現。

3.1.3基于J2EE平臺的有關安全技術

1.語言內置的安全技術

Java語言具有強類型檢查，在編譯時就能對變量類型進行檢查；自動內存管

理，在C、C++中內存的分配與回收都需要程序員負責完成，在大型應用中內存

泄漏是個頗為棘手的問題，而Java內置垃圾回收機制，由系統負責內存的管理;

字節碼檢查，JVM(JavaVirtualMachine)對源代碼編譯生成的字節碼進行檢查,

防止惡意代碼對運行環境的破壞；安全的類裝載機制，確保不信任的代碼不可能

影響其它Java程序的運行。

2.密碼技術支持

JCA(JavaCryptographyArchitecture)與JCE(JavaCryptographicExtension)

為加密、解密、數字證書、數據摘要提供完整的支持；提供對各類密碼算法的支

持，包含RSA、DSA、DES、SHA等；提供對PKCS#11的支持。

3.認證與訪問操縱支持

JAAS(JavaAuthenticationandAuthorizationService)與Policy的實現及語法

等提供了細粒度的訪問操縱，抽象的認證APIs能夠插件方式靈活地集成到其它

登錄操縱系統中。

4.安全通訊

5.為PKI提供支持

J2EE提供管理密鑰與證書的工具，廣泛抽象的APIs對X.509證書、廢止列

表、證書路徑、OCSP(On-LineCertificateStotusProtocol)PKCS#lkPKCS#12>

LDAP等提供支持，大大簡化了PKI應用開發與部署的難度⑶。

3.2網絡總體結構

應用系統的總體拓撲圖參考如下示:

圖12應用系統的總體拓撲圖參考

用戶通過Internet網絡向應用系統發起請求，請求在到達Web服務器之前將

通過NSAE(使用兩臺帶SSL加速長的SSL安全網關服務器，并配置為熱備部

署模式)建立128位SSL加密通信通道。

系統應用服務器通過有NSAE經由Web服務器傳過來的Request對象獲取

客戶端證書(假如客戶端使用數字證書認證的話)。在登錄環節，系統應用服務

器通過身份認證及簽名驗證服務器(NetSignServer)所提供的API驗證用戶證

書有效性并完成登錄。

在交易過程中需要對交易簽名時，通過客戶端簽名控件對頁面信息進行簽

名，簽名結果信息及原始信息傳遞至應用服務器后，通過簽名驗證服務器

(NetSignServer)提供的API將簽名結果與原始信息與客戶端證書傳至簽名驗

證服務器進行驗證。

一次性口令的驗證由系統應用程序調用動態密碼系統的服務適配器，由動態

密碼服務器完成驗訐并返回結果。短信密碼的發送，由動態密碼服務器向的短信

網關SMSGateway發送請求實現。

3.3網絡層方案選擇

3.3.1安全連接協議

系統客戶端至服務器端的安全連接常見的協議有SSL、SPKM可供選擇匕

SPKM(SimplePublicKeyMechanism)協議，用于建立點對點之間的安全

通道，結合數字證書要緊適用于內聯網環境，在運用于互聯網時有如下問題⑸：

1.因客戶端在跟服務器端建立連接時需要訪問CRL,而SPKM協議固有的

原因會造成客戶端對廢止列表訪問的時間過長。

2.SPKM協議在客戶端對整個頁面進行數字簽名也是沒有必要的，并不是

用戶提交的所有頁面都需要數字簽名的，而且就算某個頁面需要數字簽名通常也

不是頁面中所有的元素都是需要數字簽名的。比如關于行外轉賬交易而言，收款

人姓名、收款人賬號、收款人開戶行、轉賬金額、付款人賬號是其五要素，客戶

在提交轉賬交易時只需對這五要素進行數字簽名就能夠了，而頁面上還有一些諸

如是否發送Email通知等要素就沒必再被簽名了c超出需求的要素被簽名，一方

面將會增加網絡流量，同時還會導致服務器相應的遲滯。

3.由于SPKM協議并非普遍使用的安全通訊協議，因此在通用的瀏覽器如

IE、Navigator等中沒有支持，需要下載安裝客戶端軟件，這就增加了系統安裝、

保護、使用的難度。

SSL(SecuritySocketLayer)協議已得到各主流瀏覽器內置的支持。由于標

準的SSL協議，在使用客戶端證書時，并未對用戶的交易數據進行顯式簽名，

造成應用系統無法記錄交易數據的數字簽名，給在技術層面保護交易的不可否認

性帶來了一定的困難咒

在應用系統中我們使用SSL協議來建立安全連接。SSL協議簽名的問題可通

過在客戶瀏覽器端安裝簽名控件來完成，簽名控件一方面能夠完成數字簽名，另

一方面，通過自定義簽名格式，只對需要的頁面要素進行簽名，去除不必要的數

據被簽名。

3.3.2安全區域的劃分

通過三臺防火墻將網絡劃分為四個邏輯區域，按由外到內的順序部署。第一

道防火墻之外是Internel區（非授信區）；第一道防火墻與第二道防火墻之間是

Web區，在此區域中部署SSL服務器與應用系統與網站系統的Web服務器等其

它第三方應用系統；第二道防火墻與第三道防火墻之間是系統及網站的應用/DB

區，在此區域中部署應用服務器與數據庫服務器；第三道防火墻之后為其它的核

心系統、中間業務平臺等第三方業務系統。

3.3.2網絡層安全組件

應用系統的最外端部署了綠盟黑洞抗DoS攻擊系統COLLAPSAR600D-5-B,

以操縱拒絕式攻擊與分布式拒絕攻擊；防火墻使用的是天融信防火墻產品

NGFW4000-G,入侵檢測則使用的是啟明入侵檢測NS500系統，漏洞掃描軟件

使用的是冠群金辰承影網絡漏洞掃描器，原有系統被兩道防火墻分隔成三個區。

系統部署時要求在停火區中再增加一道防火墻，一方面隔離Web服務器與

應用服務器；另一方面隔離應用服務器與其它核心系統。增加的防火墻依然使用

的是天融信NGFW4000-G防火墻，此外還增加了兩臺IBMTotalStorageSAN

16M-2的交換機，一套啟明NS500系統。

3.4系統層方案選擇

系統Web服務器的操作系統使用SUSELinux9Enterprise,應用服務器與數

據庫服務器的操作系統使用AIX5L,V5.3,數據庫管理系統使用Oracle10.0.2

FORAIXo

由于軟件系統通常都存在漏洞，操作系統也不例外，不管是Unix、Linux還

是Windows系統。操作系統要求定期安裝系統的最新補丁，并定期對審計日志

進行檢查與備份。另外，UNIX、Linux、NT系統通常包含許多網絡服務應用程

序，如FTP、Teine【等，有些不必要的網絡服務程序務必禁用并關閉對應的端口。

3.5應用層方案選擇

3.5.1數字證書

國外比較著名的數字證書有：Verisign>Etrust、Baltimore等；國內應用比較

廣泛的數字證書要緊有中國金融認證中心CFCA的數字證書、上海數字證書認

證中心SHECA的證書等；另外有些實體建設了自己的CA,向本實體內的系統

及其客戶發放數字證書。

對比分析上述的幾家認證中心的數字證書的優缺點將有助于安全子系統的

數字證書的選擇。下表是比較結果：

表8認證中心比較的表格

方案優點缺點

CFCA良好的公信力，是金融領域高級證書費用較高，但可使

CA的權威用普通證書。

VeriSign國際的發證權威機構國外機構，發證手續煩惱，

費用也不低。

自建CA發證成本較低仍需購買發證軟件；銀行不

具備管理CA的專長（大量的管理

工作）；法律問題（非授信第三

方）等等。

3.5.2動態密碼輔助解決方案

動態密碼方案是以一次性口令技術為基礎的，目前成熟的產品要緊有智能

卡、刮刮卡、動態短信系統等，產品供應商要緊有RSA、Todos等。

應用系統可使用動態密碼系統作為身份認證的輔助解決方案，Todos動態密

碼系統能夠使用手機短信的方式向客戶端發送一次性口令，客戶端僅需有一臺能

夠同意短信的手機就能夠了，這種方案客戶端幾乎沒有投入成本，造價也相對低

廉，安全性強。除手機短信方式，動態密碼系統還有下列幾種客戶端的終端可供

選擇：

智能卡，以IC卡為載體，IC卡的內置芯片實現某個密碼算法，卡內同時儲

存了用戶的種子，每次按某種序列計算出不確定因子。智能K通常還有個啟動

PIN碼，提供對智能卡持有人的認證，加強智能卡的安全性。智能卡具有攜帶方

便，保密性好，即使卡遺失也不怕被他人利用等優點，缺點就是成本相對較高。

刮刮卡，就是通過一次性口令技術事先算出一次性口令的子集或者全集，將

這些口令印制在一張卡片上，再在每個口令上涂蓋上防讀層，以后每次使用時按

系統提示刮開相應位置的涂層，便得到當次的口令，這種卡便稱之刮刮卡。刮刮

卡具有成本低，使用方便的優點，安全性要比智能卡的低，一旦遺失有可能被他

人利用。

動態密碼系統的使用一方面加強了應用系統的安全性，另一方面也增加了客

戶選擇認證措施的余地。

3.6系統運行環境

3.6.1硬件配置

/Web主機

表9Web主機的配置表

型號數量配置備注

0penpower7101G.1CPU,SUSE91HD2*73Gwebserver1門戶用

0penpower7101G.1CPU,SUSE91HD2*73Gwebserver2門戶用

0penpower7101G.1CPU,SUSE91HD2*73Gwebserver3應用用

0penpower7101G,1CPU,SUSE91HD2*73Gwebserver4應用用

/NSAE

表10NSAE加速卡的配置表

型號