對稱密碼學(xué)、非對稱密碼學(xué)（Symmetric Algorithm, Asymmetric Algorithm）
??? 對稱密碼只有一個密匙，加密和解密都使用這個相同的密匙。非對稱密碼有兩個密匙，一個作為公匙可以告訴其他人，一個作為私匙只有自己知道，用公匙加密的數(shù)據(jù)只能用私匙解密，用私匙加密的數(shù)據(jù)只能用公匙解密。
??? 使用對稱密碼，通訊雙方都需要知道密匙，為了驗證身份，發(fā)送方可能需要把密匙傳遞給接收方，這種方式可能帶來一些潛在的安全性問題。非對稱密碼中，A用自己的私匙加密數(shù)據(jù)然后發(fā)送出去，其他人如果能夠用A的公匙解密數(shù)據(jù)，那就能知道這個數(shù)據(jù)一定來自A－－不可抵賴性，一般用戶數(shù)字簽名中；如果其他人需要向A發(fā)送數(shù)據(jù)，可以使用A的公匙加密數(shù)據(jù)，這樣加密后的數(shù)據(jù)只有A才能解密－－保密性，這個用于確保通訊的機密性。使用非對稱密碼通訊的雙方各自擁有自己的一對公匙和私匙，向?qū)Ψ桨l(fā)送數(shù)據(jù)時，使用對方的公匙加密，讓對方用私匙進行解密。
??? 對稱密碼學(xué)的算法簡便高效，密匙短，但很難破譯，加密解密速度快。非對稱密碼一般較弱一些，為了防止被破譯，使用的密匙長度會比較長，例如128位、512位等，加密解密運算所需時間會比較長。為了改善通訊過程中安全性應(yīng)用帶來的性能問題，一般的做法是發(fā)送方先使用一個對稱密匙對消息加密，然后使用接收方的公匙加密這個對稱密匙，一起發(fā)送給接收方。接收方先用自己的私匙解密出對稱密匙，然后再用對稱密匙解密消息數(shù)據(jù)。這樣在傳輸?shù)男畔⒈容^大時，帶來的改善是明顯的。在 X.509 一節(jié)中可以看到這一運用。

??? 數(shù)字簽名
??? 數(shù)字簽名是公共密匙體制的另一種應(yīng)用。A需要向B發(fā)送一段報文，首先A使用特定的Hash算法對要發(fā)送的報文取得一個一定長度（例如128位等）的 Hash值，這個Hash值稱為數(shù)字摘要（Digital Digest）。Hash算法盡量保證不同的報文產(chǎn)生的摘要不相同，即如果發(fā)送的報文在中途被攻擊者修改了，新的摘要跟原來的摘要就不相同。然后A使用自己的私匙對摘要進行加密，加密后的值稱為數(shù)字指紋、數(shù)字簽名（Digital Signature），A把這個數(shù)字簽名和要發(fā)送的報文一起發(fā)送給B。B接收到內(nèi)容后，取出數(shù)字簽名和報文，使用A的公匙對簽名解密，就得到原文的數(shù)字摘要，然后B使用相同的Hash算法對報文獲取摘要值，比較這兩個摘要值是否一致。如果驗證成功，B能夠確定兩件事情：1. 數(shù)據(jù)的確是A發(fā)送的；2. 數(shù)據(jù)在發(fā)送過程中沒有被修改過。

??? 常見竊取、攻擊場景簡單描述
??? 應(yīng)用系統(tǒng)最普通的方式是使用用戶名、密碼認證，如果使用明文方式向服務(wù)器發(fā)送認證信息，竊取者在路由上很容易截取到用戶名、密碼。
??? 為了防止攻擊者截獲到明文的密碼，最簡單的方式是將密碼加密后傳送。但這樣攻擊者截獲到加密過的密碼，他雖然不知道密碼的原文，但如果使用加密過的密碼字符串，仍然可以通過服務(wù)器的驗證，這也是重放攻擊（Replay Attack）的一種形式。解決方法是客戶端每次使用一個隨機序列跟密碼一起加密，這樣每一次加密后的結(jié)果都不一樣；客戶端同時把這個隨機序列和加密后的值發(fā)送給服務(wù)器，服務(wù)器用同樣的方法用原密碼和隨機序列進行加密，比較加密的結(jié)果和客戶端發(fā)來的加密結(jié)果是否一致。
??? 這樣做還沒有解決問題，因為攻擊者仍然可以截獲消息中的加密結(jié)果和隨機序列，用以通過服務(wù)器驗證，還需要添加另外一個處理：過期策略。除了隨機序列之外，客戶端在添加一個創(chuàng)建時間，把密碼（Password）、隨機序列（Nonce）、創(chuàng)建時間（CreatedTime）這三個因素一起加密，例如加密值=Base64(SHA-1(Password+CreatedTime+Password))，同樣，客戶端把加密值、隨機序列Nonce、創(chuàng)建時間CreatedTime一起傳給服務(wù)器。在服務(wù)器上驗證機制有所改變。首先，客戶端每一次請求的Nonce都使用一個唯一標識，不會重復(fù)。服務(wù)器維護一個已經(jīng)被處理過的Nonce緩存，每次接收到消息先檢查這個Nonce是否在緩存中存在，如果已經(jīng)存在，說明這個消息已經(jīng)被處理過了，決絕這一次請求服務(wù)；如果不存在，則把這個Nonce添加到緩存，然后處理請求。為了避免緩存的Nonce值越來越多，因此使用一個CreatedTime，并確定一個過期時間，例如5分鐘之后過期，這樣，服務(wù)器只需要保存5分鐘之內(nèi)、還沒有過期的Nonce值。在重放攻擊中，對于那些已經(jīng)過期的消息中的認證信息，服務(wù)器會拒絕處理。如果通過上面兩項檢查，則服務(wù)器使用相同的算法Base64(SHA-1(Password+CreatedTime+Password)) 來驗證認證信息。通過這樣的處理，確保認證信息每一次加密的結(jié)果都不一樣，并且只能被有效的使用一次。

??? X.509
??? 詳細的規(guī)范可以從http://www.rfc.net/，查詢X.509。
??? 不清楚WSE 3.0中具體是如何使用X.509，但大致的數(shù)字簽名步驟如下，應(yīng)當(dāng)相差不多：
??? 1. A準備好要傳送的信息（明文）。
??? 2. A對數(shù)字信息進行Hash運算，得到一個數(shù)字摘要（Digital Digest）。
??? 3. A用自己的私鑰對數(shù)字摘要進行加密，得到數(shù)字簽名（Digital Signature），并將其附在信息上。
??? 4. A隨機產(chǎn)生一個加密密鑰（DES密鑰），并用此密鑰對要發(fā)送的信息進行加密，形成密文。
??? 5. A用B的公鑰對剛才隨機產(chǎn)生的加密密鑰進行加密，將加密后的DES密鑰連同密文一起傳送給B。
??? 6. B收到A傳送過來的密文和加過密的DES密鑰，先用自己的私鑰對加密的DES密鑰進行解密，得到DES密鑰。
??? 7. B用DES密鑰對收到的密文進行解密，得到明文的信息。
??? 8. B用A的公鑰對A的數(shù)字簽名進行解密，得到數(shù)字摘要。
??? 9. B用同樣的Hash算法對收到的明文進行Hash運算，得到一個新的數(shù)字摘要。
??? 10. B將解密的數(shù)字摘要和自己運算的數(shù)字摘要進行驗證是否一致。
??? 對稱密碼學(xué)使用相同的密匙加密和解密消息，因此客戶端和服務(wù)器端都存在密碼保存問題，驗證過程中存在密碼信息直接或間接的傳送，給這種機制帶來一些不安全因素。正由于這樣的因素，非對稱密碼學(xué)，尤其是X.509，目前被普遍運用在Internet的電子商務(wù)中。

??? Kerberos
??? RFC標準中Kerberos工作步驟如下：

??? 1. Kerberos authentication service request (KRB_AS_REQ)
??? 用戶輸入用戶名、用戶口令登錄工作站機器，工作站向KDC（Key Distribution Center）的AS（Authentication Service認證服務(wù)）發(fā)送認證信息。認證信息只包含用戶帳號，不包含用戶口令。
??? 2. Kerberos authentication service response (KRB_AS_REP)
??? AS為后面工作站與TGS（Ticket Granting Service票據(jù)授權(quán)服務(wù)）之間的通訊創(chuàng)建Session Key（會話口令）SK1，將客戶端信息、TGS服務(wù)信息、SK1、時間戳、有效期等信息使用TGS的口令加密，生成TGT（Ticket Granting Ticket票據(jù)授權(quán)票）。同時KDC在用戶帳號數(shù)據(jù)庫中查詢用戶口令，將TGS服務(wù)信息、SK1使用用戶口令加密打包。最后AS把加密包和TGT發(fā)送給工作站。
??? 工作站接收到返回信息之后，使用用戶登錄時輸入的用戶口令對加密包解密，如果能成功解密，則表示通過了KDC的身份認證，并得到TGS服務(wù)信息和SK1，并且擁有了TGT。
??? 第一點，用戶口令只有用戶與KDC知道，工作站向KDC認證的過程中并不將用戶口令發(fā)送給KDC的AS，而是通過讓工作站自己解密的方式來證明自己。如果工作站無法解密，它將無法與TGS通訊，從而無法使用其它應(yīng)用服務(wù)和資源等。
??? 第二點，AS給工作站頒發(fā)TGT，后面工作站將使用TGT向TGS請求其它應(yīng)用服務(wù)，而無需再進行用戶名、用戶口令的驗證，實現(xiàn)SSO。
??? 第三點，TGS擁有自己的口令，這個口令只有TGS和AS知道，因此工作站雖然拿到TGT，因為是使用TGS的口令加密，其他人包括工作站并不能解密和篡改TGT中內(nèi)容，它只需要在向TGS申請其它應(yīng)用服務(wù)時發(fā)送這個TGT。
??? 第四點，AS為工作站后面與TGS的通訊生成一個Session Key SK1，這個SK1在工作站與TGS之間共享，使得后面TGS與工作站通訊時，TGS能夠?qū)ぷ髡具@個客戶端進行認證。上面已經(jīng)看到工作站如何得到SK1，而AS并沒有直接告訴TGS這個SK1，下面的步驟中你可以看到TGS如何得到SK1。
??? 3. Kerberos ticket-granting service request (KRB_TGS_REQ)
??? 工作站上的用戶請求其它應(yīng)用系統(tǒng)服務(wù)，例如郵件服務(wù)時，郵件客戶端首先查詢工作站上是否已經(jīng)擁有郵件服務(wù)的Service Ticket（服務(wù)票據(jù)），如果沒有則向TGS申請這個Service Ticket。
??? 申請Service Ticket過程如下。工作站將客戶端信息、要申請的服務(wù)信息（郵件服務(wù)）使用SK1加密生成一個驗證器，與TGT一起發(fā)送給TGS。
??? TGS接收到工作站的請求后，使用TGS的口令對TGT解密，得到TGT中的內(nèi)容。首先根據(jù)時間戳、有效期信息檢查是否過期，如果沒有過期，則使用SK1解密驗證器，比較驗證器中的客戶端信息與TGT中的客戶端信息是否一致。如果一致則表示這個請求通過了TGS的認證。
??? 4. Kerberos ticket-granting service response (KRB_TGS_REP)
??? 從驗證器的解密內(nèi)容中，TGS知道工作站是在申請郵件服務(wù)的Service Ticket。同樣，TGS為工作站與郵件服務(wù)之間的通訊創(chuàng)建一個Session Key SK2，將客戶端信息、郵件服務(wù)信息、SK2、時間戳、有效期等信息使用郵件服務(wù)的口令加密，生成郵件服務(wù)的Service Ticket。TGS將SK2使用SK1加密，把這個加密包和Service Ticket一起發(fā)送給工作站。
??? 第一點，從上面3、4步驟中可以看出，TGS如何獲得AS為它和工作站之間建立的會話口令SK1，并使用這個SK1對工作站的請求進行驗證。同樣的方式，TGS為工作站與郵件服務(wù)之間的通訊也創(chuàng)建一個會話口令SK2。
??? 第二點，郵件服務(wù)擁有自己的口令，只有TGS與郵件服務(wù)自己知道。郵件服務(wù)的Service Ticket使用郵件服務(wù)口令加密，其他人包括工作站無法解密，只有郵件服務(wù)自己可以解開。
??? 5. Kerberos application server request (KRB_AP_REQ)
??? 接下來工作站得到TGS的響應(yīng)消息，它得到了郵件服務(wù)的Service Ticket和一個加密包。工作站是使用SK1解開加密包，得到它與郵件服務(wù)器之間通訊的會話口令SK2。
??? 然后工作站將客戶端信息使用SK2加密，生成驗證器，將驗證器和郵件服務(wù)的Service Ticket一起發(fā)送給郵件服務(wù)器，請求郵件服務(wù)。
??? 郵件服務(wù)接收到工作站的請求后，使用郵件服務(wù)口令解密Service Ticket，得到里面的內(nèi)容。首先查看Service Ticket中的郵件服務(wù)信息，確認是否是在向自己請求服務(wù)。然后根據(jù)時間戳、有效期檢查是否過期。如果沒有過期，則使用SK2解密驗證器，比較驗證器中的客戶端信息與Service Ticket中的客戶端信息是否一致。如果上面的驗證全部通過，則這個請求通過了郵件服務(wù)器的認證。
??? 6. Kerberos application server response (optional) (KRB_AP_REP)
??? 在RFC標準中，這一個步驟是可選的。應(yīng)用服務(wù)處理完請求之后，如果需要向工作站發(fā)送信息，則將這些信息發(fā)送回工作站。

??? 最后需要說明的是，在Kerberos V5中，為防止Replay Attack（重放攻擊），上面對驗證器的處理說得并不詳細。首先采用一些處理使得每次驗證器不一樣。驗證器本身有一個有效期，大概5分鐘的樣子。服務(wù)器上將建立一個驗證器緩存，確保一個驗證器在有效期之內(nèi)只能被使用一次。
??? 另外，RFC標準中KDC的AS和TGS可以是在一起，也可以是分開在不同的Server上。
??? 通過上面的過程可以看出，Kerberos使用對稱密碼，而對稱密碼算法高效，密匙短但難以被破譯，如果再采取一些其它措施，例如Strong Password（強密碼）、密碼有效期控制等，不考慮被集成的應(yīng)用等其它因素，這種機制本身非常嚴密，機密性比較高。針對Kerberos機制的一些攻防場景，參考 設(shè)計一個認證系統(tǒng) ，這里有 中文版本 ，不少地方翻譯的不夠準確。微軟基于域環(huán)境實現(xiàn)Kerberos，詳細的資料可以參考微軟官方網(wǎng)站，例如， Kerberos Authentication Explained ； How the Kerberos Version 5 Authentication Protocol Works 。
??? 由于實現(xiàn)Kerberos的機制、被集成的應(yīng)用等各種原因，使得目前Kerberos只能在一個內(nèi)網(wǎng)中使用，例如微軟的域環(huán)境下。

WSE 3.0安全性方面整理