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

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

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

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

??? Kerberos
??? RFC標(biāo)準(zhǔn)中Kerberos工作步驟如下：

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

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

WSE 3.0安全性方面整理