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

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

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

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

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

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

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

WSE 3.0安全性方面整理