/網站系統平安的需求分析本文從數據平安和業務邏輯平安兩個角度對應用系統的平安進行需求分析，主要包括保密性需求、完整性需求、可用性需求三局部；隨后對業務邏輯平安需求進行了分析，包括身份認證、訪問控制、交易重復提交控制、異步交易處理、交易數據不可否認性、監控與審計等幾個方面；最后還分析了系統中一些其它的平安需求。2.1數據平安需求2.1.1 數據保密性需求數據保密性要求數據只能由授權實體存取和識別，防止非授權泄露。從目前國內應用的平安案例統計數據來看，數據保密性是最易受到攻擊的一個方面，通常表現為客戶端發生的數據泄密，包括用戶的根本信息、賬戶信息、登錄信息等的泄露。在應用系統中，數據保密性需求通常主要表達在以下幾個方面：A．客戶端與系統交互時輸入的各類密碼：包括系統登錄密碼、轉賬密碼、憑證查詢密碼、憑證交易密碼等必須加密傳輸及存放，這些密碼在應用系統中只能以密文的方式存在，其明文形式能且只能由其合法主體能夠識別。以網銀系統為例，在網銀系統中，通常存有四種密碼：系統登錄密碼、網銀轉賬密碼、柜面交易密碼及一次性密碼。系統登錄密碼用來認證當前登錄者為指定登錄名的合法用戶，網銀用戶的登錄密碼和網銀轉賬密碼由用戶在柜面開戶時指定，用戶在首次登錄網銀系統時，系統必須強制用戶修改初始密碼，通常要求長度不得少于六位數，且不能是類似于111111、1234567、9876543等的簡單數字序列，系統將進行檢查。網銀轉賬密碼是指網銀系統為穩固用戶資金平安，在涉及資金變動的交易中對用戶身份進行了再認證，要求用戶輸入預設的密碼，網銀交易密碼僅針對個人用戶使用，企業用戶沒有網銀交易密碼。建立多重密碼機制，將登錄密碼與網銀轉賬密碼分開管理，有利于加強密碼的平安性。由于用戶在使用網銀時每次都必須先提供登錄密碼，故登錄密碼暴露的時機較多，平安性相對較弱；但登錄網銀的用戶并不是每次都會操作賬戶資金的，所以專門設定網銀轉賬密碼可加強賬戶的平安性。網銀轉賬密碼在網銀開戶時設定，網銀用戶在系統中作轉賬支付、理財、代繳費等資金變動類交易時使用。柜面交易密碼是指用戶在銀行柜面辦理儲蓄時，針對儲蓄憑證（如卡折、存單等）而設的密碼。柜面交易密碼常用于POS系統支付時、ATM取款時、憑證柜面取款時，柜面交易密碼一個明顯的特征是它目前只能是六位的數字，這是由于目前柜面密碼輸入設備的限制而造成的。柜面交易密碼與上述的網銀轉賬密碼的區別在于：網銀轉賬密碼和系統登錄密碼都產生于網銀系統，儲存在網銀系統中，僅限網銀系統中認證使用；而柜面交易密碼產生于銀行柜臺，可以在外圍渠道如ATM、電話銀行、自助終端上修改，它保存在銀行核心系統中，供外圍各個渠道系統共同使用。另外網銀轉賬密碼可以有非數字字符組成，而柜面交易密碼只能是六位的數字。網銀中使用到柜面交易密碼的交易包括：網銀開戶、加掛賬戶。一次性密碼由用戶的智能卡、令牌卡產生，或由動態密碼系統產生通過短信方式發送到用戶注冊的手機上。一次性密碼的作用與網銀轉賬密碼相同，適用的場合也相同。一次性密碼在農商行網銀系統中是可選的平安效勞，用戶需到柜面辦理開通手續才能使用，沒有開通一次性密碼效勞的用戶必須設定網銀交易密碼，開通一次性密碼效勞的用戶則無需設定網銀交易密碼，要求網銀系統自動判斷并提示用戶在某個交易中是要輸入網銀交易密碼還是提示一次性密碼。B．應用系統與其它系統進行數據交換時在特定平安需求下需進行端對端的加解密處理。這里的數據加密主要是為了防止交易數據被銀行內部人士截取利用，具體通訊加密方案參照應用系統的特定需求。2.1.2 數據完整性需求數據完整性要求防止非授權實體對數據進行非法修改。用戶在跟應用系統進行交互時，其輸入設備如鍵盤、鼠標等有可能被木馬程序偵聽，輸入的數據遭到截取修改后被提交到應用系統中，如原本用戶準備向A賬戶轉一筆資金在交易數據遭到修改后就被轉到B賬戶中了。同樣的威脅還存在于交易數據的傳輸過程中，如在用戶向應用系統提交的網絡傳輸過程中或應用系統跟第三方等其它系統的通訊過程中，另外存儲在應用系統數據庫中的數據也有可能遭到非法修改，如SQL注入攻擊等。2.1.3 數據可用性需求數據可用性要求數據對于授權實體是有效、可用的，保證授權實體對數據的合法存取權利。對數據可用性最典型的攻擊就是拒絕式攻擊（DoS）和分布式拒絕攻擊，兩者都是通過大量并發的惡意請求來占用系統資源，致使合法用戶無法正常訪問目標系統，如SYNFlood攻擊等，將會直接導致其他用戶無法登錄系統。另外，應用登錄機器人對用戶的密碼進行窮舉攻擊也會嚴重影響系統的可用性。2.2業務邏輯平安需求業務邏輯平安主要是為了保護應用系統的業務邏輯按照特定的規則和流程被存取及處理。2.2.1 身份認證需求身份認證就是確定某個個體身份的過程。系統通過身份認證過程以識別個體的用戶身份，確保個體為所宣稱的身份。應用系統中身份認證可分為單向身份認證和雙向身份認證，單向身份認證是指應用系統對用戶進行認證，而雙向身份認證則指應用系統和用戶進行互相認證，雙向身份認證可有效防止“網絡釣魚〞等假網站對真正系統的冒充。應用效勞器采用數字證書，向客戶端提供身份認證，數字證書要求由權威、獨立、公正的第三方機構頒發；系統為客戶端提供兩種可選身份認證方案，效勞器端對客戶端進行多重身份認證，要求充分考慮到客戶端平安問題。將客戶端用戶身份認證與賬戶身份認證分開進行，在用戶登錄系統時，采用單點用戶身份認證，在用戶提交更新類、管理類交易請求時，再次對用戶的操作進行認證或對用戶身份進行二次認證，以確保用戶信息平安。2.2.2 訪問控制需求訪問控制規定了主體對客體訪問的限制，并在身份識別的基礎上，根據身份對提出資源訪問的請求加以控制。訪問控制是應用系統中的核心平安策略，它的主要任務是保證應用系統資源不被非法訪問。主體、客體和主體對客體操作的權限構成訪問控制機制的三要素。訪問控制策略可以劃分為自主訪問控制、強制訪問控制和基于角色的訪問控制三種。交易重復提交控制需求交易重復提交就是同一個交易被屢次提交給應用系統。查詢類的交易被重復提交將會無故占用更多的系統資源，而管理類或金融類的交易被重復提交后，后果則會嚴重的多，譬如一筆轉賬交易被提交兩次則將導致用戶的賬戶被轉出兩筆相同額的資金，顯然用戶只想轉出一筆。交易被重復提交可能是無意的，也有可能是成心的：A．用戶的誤操作。在B/S結構中，從客戶端來看，效勞器端對客戶端的響應總有一定的延遲，這在某些交易處理上表達的更為明顯，特別是那些涉及多個系統交互、遠程訪問、數據庫全表掃描、頁面數據簽名等交易，這種延遲通常都會在5至7秒以上。這時用戶有可能在頁面已提交的情況下，再次點擊了提交按鈕，這時將會造成交易被重復提交。B．被提交的交易數據有可能被拿來作重放攻擊。應用系統必須對管理類和金融類交易提交的次數進行控制，這種控制即要有效的杜絕用戶的誤操作，還不能影響用戶正常情況下對某個交易的屢次提交。比方說：當某個用戶在10秒內提交了兩筆相同的轉賬業務，則系統必須對此進行控制；另一方面，當用戶在第一筆轉賬業務完成后，再作另一筆數據相同的轉賬時，則系統不能對此進行誤控制。這里判斷的依據就是交易重復提交的控制因子a，當交易提交的間隔小于a時，系統認為這是重復提交，提交間隔大于a的則不作處理，控制因子的大小由應用系統業務人員決定，系統應可對其進行配置化管理。2.2.4 異步交易處理需求所謂異步交易就是指那些錄入與提交不是同時完成的交易，這里的同時是指客戶端在錄入交易數據與提交交易的過程中，應用系統效勞器端并沒有對錄入的數據進行持久化保存，而異步交易在系統處理過程中，錄入與提交時間上發生在兩個相別離的階段，在兩階段之間，應用系統對錄入的數據進行了持久化保存。由于異步交易是被系統分兩階段受理的，這就涉及到以下三個方面的問題：錄入與提交的關系管理。如何保證提交的數據就是用戶當初錄入的數據。如何記錄交易在兩階段的日志狀態。錄入與提交的關系定義不當將會導致交易錄入與提交被同時完成而違反了業務處理流程，錄入的數據被系統保存后有可能遭到非法篡改，非異步交易執行后的日志狀態不會被更新而異步交易在提交后日志狀態將會被更新。應用系統中需要定義成異步的交易通常有以下兩類：需要授權的交易。出于業務管理和業務平安方面的考慮，大局部管理類和金融類的交易都需要經過一定的授權流程前方能被提交。局部定時交易，如預約轉賬等。預約一筆在周三轉賬的預約轉賬有可能是周一被錄入的，用戶在錄入后，預約轉賬的數據將被網銀系統保存直到周三這筆轉賬才會真正發生。應用系統必須定義簡單、清晰、易維護的錄入與提交關系模型，保證被保存的錄入數據不會被非法篡改，同時要求異步交易的日志狀態是明確的，不應出現錄入與提交相矛盾的日志狀態。2.2.5 交易數據不可否認性需求交易數據不可否認性是指應用系統的客戶不能否認其所簽名的數據，客戶對交易數據的簽名是通過應用系統使用客戶的數字證書來完成的。數字證書的應用為交易數據不可否認性提供了技術支持，而電子簽名法的公布為交易數據不可否認性提供了法律基礎。在應用系統中通常要求對所有管理類與金融類的交易進行數字簽名，以防客戶事后對交易或交易數據的抵賴。應用系統需同時保存客戶錄入的原始數據和簽名后的數據，保存期限依業務部門的具體要求而定。考慮到系統性能和對用戶的響應問題，應用系統可只簽與交易有關的關鍵數據，支付類的交易只對付款人賬號、付款金額、收款人姓名、收款人賬號、收款人開戶行五個字段進行數字簽名就可以了。2.2.6 監控與審計需求平安級別要求高的應用系統應提供對系統進行實時監控的功能，監控的內容包括系統當前登錄的用戶、用戶類型、用戶正在訪問的交易、用戶登錄的IP等。對金融類、管理類的交易以及應用系統登錄交易需要完整地記錄用戶的訪問過程，記錄的關鍵元素包括：用戶登錄名、登錄IP、交易日期及時間、交易名稱、交易相關數據等，對有授權流程的交易要求完整記錄授權的經過，授權記錄與交易記錄分開存放。2.3其它平安需求2.3.1登錄控制需求登錄通常是應用系統的關鍵交易，系統通過登錄交易對用戶身份進行認證。針對不同角色的用戶指定不同的登錄策略：最小權限集用戶，可使用用戶登錄名+靜態登錄密碼+圖形識別碼方式登錄。低平安性。普通權限集用戶，可使用用戶登錄名+動態登錄密碼+數圖形識別碼方式登錄。高權限集用戶，可使用用戶登錄名+數字證書+靜態密碼+數圖形識別碼方式登錄。所有權限集用戶，可使用用戶登錄名+數字證書+動態密碼+數圖形識別碼方式登錄。應用系統可提供客戶端加密控件對用戶輸入的密碼域進行加密處理后再提交。連續登錄屢次失敗的用戶，其IP將被應用系統鎖定，24小時后系統將自動對鎖定的IP進行解鎖。這里登錄失敗的次數和IP鎖定時長根據業務需求說明應由配置文件進行設定。對于首次登錄系統的用戶，系統將強制定位到修改密碼的頁面，要求用戶修改初始密碼重新登錄方可使用系統。對于密碼類型和長度，系統將規則檢查。對于成功登錄的用戶，應用系統自動去除其連續登錄失敗的次數，同時初始化用戶的相關數據并同時對登錄數據進行記錄，以備審計。2.3.2會話控制需求通過應用效勞器自身的會話管理或應用程序的會話管理都可以控制會話的時長設定，設置過久的會話將給客戶端帶來平安風險，而設置過短則影響用戶的正常使用。該機制使在應用層無狀態的HTTP/HTTPS協議，能夠支持需要狀態記錄的互聯網應用，實現用戶登錄后在新的狀態下從事交易、超時斷路等功能。2.3.3被訪問對象控制需求應用系統對用戶的關鍵資源或信息，提供操作權限設置支持，權限分為：查詢和更新兩類。權限為查詢的資源或信息只能對其進行查詢操作，不能進行更新。資源權限由開戶時指定，為加強平安性，權限分配可通過落地處理開通。2.3.4交易提醒需求第三章應用系統平安的總體解決方案3.1平安技術平安技術是平安子系統的理論基礎，平安子系統中主要涉及的平安技術包括：密碼技術、PKI技術體系、一次性口令技術等，另外考慮到目前實際應用中，大局部WEB應用系統是基于J2EE平臺的，J2EE平臺本身也對系統平安提供了較多內置的支持，如JAAS技術等，所以本章中對于J2EE平臺的平安技術特性也有少量的討論。3.1.1密碼技術密碼技術是保護信息系統平安的基礎技術之一，密碼技術可以保證數據的保密性和完整性，同時它還具有身份認證和數字簽名的功能。從密碼體制方面來說，密碼技術可分為對稱密鑰密碼技術和非對稱密鑰密碼技術兩大類。在應用系統中常用的密碼技術主要有以下幾種：A．加密解密技術加密（Encryption）就是指通過特定的加密算法對數據進行變換，將明文（Plaintext）轉換成密文（Cryptograph）；解密（Decryption）是加密的逆過程，解密的過程就是將密文復原為明文。設明文為P，密文為C，E為加密算法，D為解密算法，則加密解密的過程可以記為： (3.1)上述的加密與解密過程沒有使用到密鑰，通常稱之為無密鑰密碼體制。無密鑰密碼主要依靠加密算法提供保密性，在應用系統中這種密碼很少用到，主要使用還是有密鑰的密碼體制，在有密鑰的密碼體制中，密文的保密性依賴于密鑰而不依賴于算法，算法可以公開。其中，只有一個密鑰K的密碼體制稱為單鑰體制（One-keySystem），又稱對稱加密體制（SymmetricalEncryption）；有加密密鑰KE和解密密鑰KD兩個密鑰的密碼體制稱為雙鑰體制（Two-keySystem），又稱非對稱加密體制（DissymmetricalEncryption），有時也叫公開密鑰算法（PublicKeyAlgorithm)。應用系統中經常使用最廣泛的對稱加密算法是DES算法(DataEncryptionStandard)，非對稱加密算法是RSA算法（Receive，Shamir，Adelman）。單鑰體制的加密解密過程可以記為： (3.2)上式用圖示可以表示為：圖5單鑰體制加密解密過程圖雙鑰體制的加密解密過程可以記為： (3.3)上式用圖示可以表示為：圖6雙鑰體制加密解密過程圖還有一種應用系統中經常用到的加密技術是數據摘要，數據摘要就是應用單向散列函數算法，將輸入的任意長度明文變換成固定長度的密文，而將此密文再轉換成明文在數學上來說是困難的。應用系統中應用最廣泛的數據摘要算法主要有MD5和SHA兩種，MD5輸出壓縮值為128bits，SHA輸出壓縮值為160bits。設Hash表示單向散列函數，則數據摘要的過程可以記為： (3.4)上式用圖示可以表示為：圖7數據摘要的過程圖B．數字簽名。數字簽名是指通過密碼算法對原始數據信息進行加密處理后，生成一段原始數據信息的信息標識，這段信息標識稱為原始數據信息的數字簽名。通常數字簽名和原始數據信息是放在一起發送的，這樣便于信息的接受者對其進行驗證，數字簽名是對現實中手寫簽名和印章的模擬，數字簽名只有信息發送方一人能產生，這種唯一性對應了原始數據信息的來源。數字簽名具有驗證數據完整性和信息來源不可否認性的功能，這正是PKI體系提供的核心功能。在應用系統中，較小的數據可以直接簽名，而較大的數據或文件通常先對其作數據摘要后再對數據摘要作數字簽名。下式表達了對一段原始數據信息進行簽名的過程：原始數據信息OriginalMsg先是被單向散列函數Hash作數據摘要生成摘要信息DigestMsg，然后應用非對稱加密算法DissymmetricalEncrypt及其私鑰Keyprivate對數據摘要進行簽名（私鑰僅有發送方持有，公鑰需散發給接收方），最后將簽名結果DigitalSignature與原始數據信息一起發送給接受方：(3.4) 上式用圖示可以表示為：圖8數字簽名的過程圖信息接受方在接受到原始數據信息OriginalMsg與其數字簽名DigitalSignature后，可以對數字簽名進行驗證。首先別離出兩者，然后對原始數據信息應用同樣的單向散列函數Hash對其作數據摘要得到Digest2，再對接收到的數字簽名應用非對稱加密算法DissymmetricalEncrypt及其公鑰Keypublic對其進行解密，得到Digest1。比較Digest1與Digest2，如果兩者一樣則證明：1．信息OriginalMsg及其數字簽名DigitalSignature是真實的，確實來自于私鑰Keyprivate的持有方。2．信息OriginalMsg及其數字簽名DigitalSignature在發送過程中是完整的，未曾遭到篡改。3．私鑰Keyprivate的持有方發送了信息OriginalMsg及其數字簽名DigitalSignature這件事是不可否認的。上述數字簽名的驗證過程可以表達為：(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行為的責任[]。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的證書目錄效勞器，另外用戶也可以將自己的證書發送給別人。證書的廢止。數字證書的廢止列表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）是指針對傳統可重復使用的口令而言的。一次性口令只能使用一次，不可重復使用。可重用的口令易受種種攻擊：截取攻擊：當口令以明文方式在網絡上傳遞時，容易被攻擊者截取獲得，一旦口令泄漏則可能被未授權者非法使用。重放攻擊：當口令以密文方式在網絡上傳遞時，雖然攻擊者無法獲取口令的明文，但攻擊者可以截取口令密文后對系統實施重放攻擊。窮舉攻擊：攻擊者還有可能針對用戶的登錄名，根據系統對口令的限定規則，嘗試規則范圍內各個可能的口令，對用戶口令實施窮舉攻擊。窺探：用戶在輸入可重復使用的口令時必然要借助某種輸入設備，如鍵盤、鼠標、手寫筆等，這時容易被他人或其它錄影設備窺探到輸入內容，也有可能被木馬程序等記錄了擊鍵事件而分析出口令。社交工程：攻擊者通過利用人們心理弱點、本能反應、好奇心、信任、貪婪等心理陷阱通過電子郵件、電話訪談、釣魚網站等騙取用戶的口令。垃圾搜索：攻擊者偽裝成垃圾工人收集用戶的垃圾文檔用以分析用戶的口令等。一次口令由于每次使用各不相同的口令，所以并不存在上述的問題。一次口令并不要求用戶記住多個口令，所以也不會增加用戶和系統的負擔。一次性口令的原理：在客戶端和效勞器端各存在一個相同的算法、一個與用戶有關的種子、一個不確定的因子，每次系統對用戶進行認證時，用戶將不確定的因子追加到種子后，然后用算法對其加密算出一個結果，這個結果作為一個一次性口令提交給效勞器，效勞器端用相同的算法對相同種子和不確定因子進行運算，將得出的結果與用戶提交的結果進行比較，相同則說明用戶輸入的口令是正確的。一次性口令技術要求效勞器端具有與用戶端相同的算法、種子及不確定因子。這里關鍵是如何保證客戶端、效勞器端具有相同的不確定因子。兩端不確定因子的選擇方式主要有以下三種：1．挑戰應答方式。每次用戶請求登錄系統時，效勞器端將不確定因子發送給用戶，稱為一次挑戰，而用戶提交的口令是根據發送來的不確定因子，和用戶端保存的種子，由用戶端保存的算法計算出來的，所以每次計算出的口令不相同。這里的算法可以采用單向散列函數算法，也可以采用對稱加密算法。不確定因子采用挑戰應答方式的原理可以圖示如下：圖11一次性口令應用的原理圖2．時間同步方式。客戶端和效勞器端以時間作為不確定因子，這里要求雙方的時間是嚴格同步的，精確度可以控制在約定的范圍內，比方說雙方的時間差不超過一分鐘。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．平安通訊JavaSecureSocketExtension(JSSE)，JavaGSS-API(JGSS)，JavaSimpleAuthenticationandSecurityLayerAPI（SASL）等提供對TransportLayerSecurity(TLS)、SSL、Kerberos、SASL等協議的實現，提供對基于SSL/TLS的HTTPS完全支持，為的數據完整性、保密性提供支持確保通訊平安。5．為PKI提供支持J2EE提供管理密鑰和證書的工具，廣泛抽象的APIs對X.509證書、廢止列表、證書路徑、OCSP(On-LineCertificateStatusProtocol)、PKCS#11、PKCS#12、LDAP等提供支持，大大簡化了PKI應用開發和部署的難度[3]。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可供選擇[4]。SPKM（SimplePublicKeyMechanism）協議，用于建立點對點之間的平安通道，結合數字證書主要適用于內聯網環境，在運用于互聯網時有如下問題[5]：1．因客戶端在跟效勞器端建立連接時需要訪問CRL，而SPKM協議固有的原因會造成客戶端對廢止列表訪問的時間過長。2．SPKM協議在客戶端對整個頁面進行數字簽名也是沒有必要的，并不是用戶提交的所有頁面都需要數字簽名的，而且就算某個頁面需要數字簽名通常也不是頁面中所有的元素都是需要數字簽名的。比方對于行外轉賬交易而言，收款人姓名、收款人賬號、收款人開戶行、轉賬金額、付款人賬號是其五要素，客戶在提交轉賬交易時只需對這五要素進行數字簽名就可以了，而頁面上還有一些諸如是否發送Email通知等要素就沒必再被簽名了。超出需求的要素被簽名，一方面將會增加網絡流量，同時還會導致效勞器相應的遲滯。3．由于SPKM協議并非普遍采用的平安通訊協議，因此在通用的瀏覽器如IE、Navigator等中沒有支持，需要下載安裝客戶端軟件，這就增加了系統安裝、維護、使用的難度。SSL（SecuritySocketLayer）協議已得到各主流瀏覽器內置的支持。由于標準的SSL協議，在采用客戶端證書時，并未對用戶的交易數據進行顯式簽名，造成應用系統無法記錄交易數據的數字簽名，給在技術層面維護交易的不可否認性帶來了一定的困難[6]。在應用系統中我們采用SSL協議來建立平安連接。SSL協議簽名的問題可通過在客戶瀏覽器端安裝簽名控件來完成，簽名控件一方面可以完成數字簽名，另一方面，通過自定義簽名格式，只對需要的頁面要素進行簽名，去除不必要的數據被簽名。3.3.2平安區域的劃分通過三臺防火墻將網絡劃分為四個邏輯區域，按由外到內的順序部署。第一道防火墻之外是Internet區（非授信區）；第一道防火墻和第二道防火墻之間是Web區，在此區域中部署SSL效勞器以及應用系統和網站系統的Web效勞器等其它第三方應用系統；第二道防火墻和第三道防火墻之間是系統及網站的應用/DB區，在此區域中部署應用效勞器和數據庫效勞器；第三道防火墻之后為其它的核心系統、中間業務平臺等第三方業務系統。3.3.2網絡層平安組件應用系統的最外端部署了綠盟黑洞抗DoS攻擊系統COLLAPSAR600D-5-B，以控制拒絕式攻擊和分布式拒絕攻擊；防火墻采用的是天融信防火墻產品NGFW4000-G，入侵檢測則采用的是啟明入侵檢測NS500系統，漏洞掃描軟件采用的是冠群金辰承影網絡漏洞掃描器，原有系統被兩道防火墻分隔成三個區。系統部署時要求在停火區中再增加一道防火墻，一方面隔離Web效勞器與應用效勞器；另一方面隔離應用效勞器和其它核心系統。增加的防火墻依然采用的是天融信NGFW4000-G防火墻，此外還增加了兩臺IBMTotalStorageSAN16M-2的交換機，一套啟明NS500系統。3.4系統層方案選擇系統Web效勞器的操作系統采用SUSELinux9Enterprise，應用效勞器和數據庫效勞器的操作系統采用AIX5L，V5.3，數據庫管理系統采用Oracle10.0.2FORAIX。由于軟件系統通常都存在漏洞，操作系統也不例外，無論是Unix、Linux還是Windows系統。操作系統要求定期安裝系統的最新補丁，并定期對審計日志進行檢查和備份。另外，UNIX、Linux、NT系統一般包含許多網絡效勞應用程序，如等，有些不必要的網絡效勞程序必須禁用并關閉對應的端口。3.5應用層方案選擇3.5.1數字證書國外比較著名的數字證書有：Verisign、Etrust、Baltimore等；國內應用比較廣泛的數字證書主要有中國金融認證中心CFCA的數字證書、上海數字證書認證中心SHECA的證書等；另外有些實體建設了自己的CA，向本實體內的系統及其客戶發放數字證書。比照分析上述的幾家認證中心的數字證書的優缺點將有助于平安子系統的數字證書的選擇。下表是比較結果：表8認證中心比較的表格方案優點缺點CFCA良好的公信力，是金融領域CA的權威高級證書費用較高，但可采用普通證書。VeriSign國際的發證權